Microsoft Technology Licensing, LLC

Mark T Burton

Todor C Fay

R Donald Thompson, Iii

R Donald Thompson

System and method for employing slot level cache locking are disclosed. When a rich media file request occurs, a general lock is put on the cache to determine whether the file has already been allocated a location in the cache. If a location has been previously allocated, an attempt is made to lock the specific slot in the cache where the file is stored and the general cache lock is released. If a slot has not been previously allocated, a next available slot is obtained and the cache slot is locked. The general lock on the cache is released. Once the cache slot lock is achieved, processing of the file request continues, such as by requesting the file from a third party server. Upon release of the general cache lock, additional media file requests can be processed concurrently without having to wait for the continued processing of the file request.

Cache slot lock for multi-thread file request

A system and method for employing slot level cache locking are disclosed. When a rich media file request occurs, a general lock is put on the cache to determine whether the file has already been allocated a location in the cache. If a location has been previously allocated, an attempt is made to lock the specific slot in the cache where the file is stored, and if successful, the general cache lock is released. In the event a slot has not been previously allocated, a next available slot is obtained and the cache slot is locked. The general lock on the cache is released. In either scenario, once the cache slot lock is achieved, the processing of the file request continues such as by requesting the file from a third party server. Additionally, upon release of the general cache lock, additional media file requests can be processed concurrently without having to wait for the continued processing of the file request.

System and method for employing slot level locking of a cache

A music generation system includes a segment manager and a plurality of segment objects. Each segment object has one or more track objects. Each track object containing a time sequence of musical performance data. Some of the track objects are dependent track objects and some of the track objects are controlling track objects. The dependent track objects contain dependent musical performance data that is interpreted based on controlling musical performance data contained in one or more of the controlling track objects. Each of the controlling track objects contains a predefined type of controlling musical performance data, wherein a plurality of different control type identifiers correspond respectively to different predefined types of controlling musical performance data. When a dependent track object needs controlling musical performance data, the track object calls the segment manager with an argument comprising a control type identifier. The segment manager responds by calling one or more segment objects with arguments that include the received control type identifier. In response a called segment object identifies one of its track objects that contains the requested type of controlling musical performance data and returns the musical performance data from the identified track object to the segment manager.

Inter-track communication of musical performance data

A musical performance is generated by a segment object and a plurality of constituent track objects. Multiple segment instances can be played concurrently by instantiating multiple state objects corresponding to the segment instances. Each state object stores state information for the track objects of the segment object. When calling a track object to play a portion of its track, the state object provides the stored state information and the track object plays in accordance with the provided state information. The track object updates the state information and returns it to the segment object. Each state object calls the same track objects, but maintains a different set of state information for use by the track objects. This allows multiple concurrent instances of the tracks, without requiring actual duplication of the track objects.

Playing multiple concurrent instances of musical segments

The invention utilizes segments and tracks to generate and playback musical performances. A segment is implemented as a programming object, and represents a specified musical piece. The segment comprises a plurality of tracks, each of which is implemented as a programming object. The tracks are of different types, and generate music in a variety of ways. However, every track supports an identical track interface that is utilized by the segment object. To play the musical piece, a performance supervisor makes repeated calls to the segment object to play specified intervals of the musical piece. In response, the segment object calls its track objects, requesting them to play the specified interval. The tracks generate the requested interval in accordance with their own methods. In some cases, the track objects communicate and cooperate with each other to generate their musical tracks.

Track-based music performance architecture

A system for processing music events includes a plurality of different music sources that provide music events to a performance manager. In response to receiving a music event, the performance manager calculates a time sequence of individual MIDI commands to implement the music event, and places a first of these events in a command queue. The performance manager monitors the command queue, and removes and processes individual commands from the command queue at the times indicated by their timestamps. Upon removing a non-concluding individual command of particular time sequence from the command queue, the music processing component determines a subsequent individual command of the particular time sequence and places it in the command queue. Upon receiving a flush instruction for a particular music source, the performance manager identifies any individual commands in the command queue corresponding to the music source, processes any of the commands that are off commands, and discards any other commands. Certain commands have associated reset values that are applied when the commands are removed from the queue in response to a flush instruction.

Dynamically halting music event streams and flushing associated command

A music processing system that processes music events includes a performance supervisor and a graph object. The graph object defines an ordered graph of music event processors, through which music events are routed. The graph object has a graph interface with methods allowing an application to insert and remove event processors in the graph. In addition, the graph interface has a method that can be called to update a music event data structure that represents the music event. This updating consists up supplying an identification of a music event processor that is next to receive the music event. Each event processor has a processor interface, which includes an initialization method and a process event method for performing the actual processing of a music event. Each processor supports one of a plurality of delivery timing modes, and also supports a subset of available event types. When inserting a music event processor in a graph, an application program can specify which instrument channel the event processor is to act upon.

System and method for arranging and invoking music event processors

The present invention includes a system and a method for a series of discrete MIDI events to be represented by a single curve event. The curve event is stored as a curve data structure and may include one or more sub-curve data structures. Each sub-curve data structure represents one or more of the series of discrete MIDI events. The curve data structure identifies when the curve event should start, the type of MIDI events that the curve represents, and a list of one or more sub-curve data structures. Each of the sub-curve data structures identify a curve-shape, the start time for the playback of the sub-curve, the end time for the playback of the sub-curve, the minimum and maximum values that the sub-curve reaches, and an orientation of the sub-curve. At performance time, each sub-curve event in the curve data structure is converted into time-stamped, discrete MIDI events that can be provided as input to a MIDI device. This is accomplished by, for each sub-curve identified in a curve structure: (1) establishing the starting point of sub-curve; (2) establishing the value for the first MIDI event; (3) establishing the ending time of the sub-curve; (4) establishing the value for the last event; (5) generating a series of MIDI events between the first and last MIDI events.

Growing community of inventors

Redmond, WA, United States of America

Mark T Burton