This invention relates generally to music software, and more particularly to music software that provides a method of creating, playing and rearranging musical songs on mobile devices.
With mobile devices becoming more personalized and integrated as multi-purpose communication, entertainment, data storage and other functional devices, and the continued broad based appeal of these devices across an ever more mobile human population, the desire for an entertaining musical game and musical composer that operates on and integrates effectively with cellphones and other mobile devices becomes apparent.
Previous inventions involving musical rearrangement (for example, U.S. Pat. No. 5,952,598 and U.S. Pat. No. 5,728,962) focus on systems involving production and playback on a local personal computer or system and therefore do not solve the special needs of mobile devices and wireless communication. Furthermore these inventions differ in that they primarily involve automated methods of analyzing and rearrangement of musical data as opposed to creation and rearrangement of musical data either predetermined by the music composer themselves, or, more uniquely, by the end user via input commands on a mobile device in a real-time, game playing environment.
Because of the unique technical, physical and operational characteristics of mobile devices, the present invention is designed in such a way as to operate efficiently and effectively within these traits. For example, mobile devices are designed to be small in physical size and therefore this invention is designed to function within a small physical space. In order to be economically viable on low-cost consumer mobile devices, the inventions components are uniquely designed for maximum functionality with very small software code and data sizes and low processor overhead (Instructions Per Minute or MIPS). Similarly, the invention is designed to operate effectively on an Internet server for subsequent downloading of song data across limited bandwidth on wireless networks. Furthermore, because the invention is musical in nature and the human ear is very sensitive to audio artifacts and timing errors, considerations are made in the invention's design to ensure timely communication between instructions from an end-user's input and playback of the musical result. In order to appeal to a broad global population and allow for a large body of musical song data to be available quickly, the invention is designed to be very easy to use by people with or without musical abilities and considerations are made to allow for existing musical data and MIDI playback technology to interface easily with the invention.
The present invention and its advantages over the prior art will be more readily understood upon reading the following detailed description and the appended claims with reference to the accompanying drawings.
The subject matter that is regarded as the invention is particularly pointed out and distinctly claimed in the concluding part of the specification. The invention, however, may be best understood by reference to the following description taken in conjunction with the accompanying drawing figures in which:
a, 9b, 9c and 9d show user interface screen displays for changing instruments sounds.
a, 10b, 10c and 10d show user interface screen displays for rearranging notes, beats, durations, pitchbend data, grace notes, patterns and other musical data.
Overview
The present invention allows a user to rearrange musical content consisting of a digital music file (such as a file consisting of MIDI (Musical Instrument Digital Interface standard) sequence data) residing on a computer device. For example, the digital music file could reside on a mobile device, such as a cellphone or personal digital assistant (PDA), or on a different computer device for subsequent download and further playback or interactive playback on a mobile device. As used herein, the term “computer device” refers to any device having one or more computing microprocessors with embedded software functionality. This includes, but is not limited to, personal computers, main frame computers, laptop computers, personal digital assistants (PDAs) including wireless handheld computers and certain cellphones. Although applicable to many types of computer devices, the present invention is particularly useful with mobile devices such as cellphones, PDAs and other similar devices. The term “mobile device” refers to portable electronic handheld devices that containing a computing microprocessor(s) with embedded software functionality, and can include wireless communication protocols and functionality, user interface control(s) such as buttons or touch screen displays, audio speaker(s) and/or input-output jacks for audio or video and other common features.
In one embodiment, a user is allowed to rearrange musical content consisting of a MIDI file containing a 16-measure repeating musical pattern in 4/4 time with 4 distinct musical parts such as drums, bass, harmony and solo. Parts may be thought of a individual members of a musical ensemble where a drummer would play the drum part, a bass player would play the bass part, a piano or guitar player would play the harmony part and a saxophonist would play the melody or solo part. A single MIDI instrument is assigned to each of the solo, harmony, and bass parts, and these parts may be polyphonic. The drum part breaks down further and may itself contain up to four different MIDI drum instruments. They may also be polyphonic. Each musical part consists of four distinct patterns where a pattern is a single track of MIDI sequence data on a single MIDI channel. These patterns are described herein as A, B, A-variation and B-variation. The patterns, since they reside on their own unique MIDI channels, may differ from one another in any way, except that as noted above, the melodic patterns must share a MIDI instrument. In the present invention, each pattern is one single measure or measure, although the invention could easily allow for patterns less than a measure or more than a measure. Likewise the invention could allow for more than four musical parts, greater than or less than 16 measures and allow for different time signatures. Thus, the musical data in our description consists of four musical parts in 4/4 time (drums, bass, harmony and solo) where each part contains four distinct one measure patterns which we refer to a A, B, A-variation and B-variation. In addition to the musical content specified in the MIDI sequence file, a control file is provided which specifies which pattern of each part is active in each of the 16 measures of the song. In each measure, only one pattern of each part may be active at one time, and the part may also be muted. The control file also specifies the MIDI instrument assigned to each part, the initial MIDI note numbers of the drum parts and the tempo of the song. Users are allowed to rearrange which parts and which part patterns are playing at any given time, what MIDI instruments are assigned to the given parts and patterns, the tempo of the song, the volume of the parts and patterns, the notes of the parts and patterns and a variety of other MIDI effects such as note duration or hold, grace notes, pitch bend, chord creation, chord inversion, and accents.
Content Format
The musical content consists of a MIDI file containing all the part patterns and a control file containing the control settings. One feature of the invention is that the MIDI file can be created using any standard commercial MIDI editing software program, no custom program is necessary. Likewise, the control file is created using any standard commercial text editor or word processor. The part patterns are stored as a one measure MIDI sequence, with each of the four part patterns assigned to a different MIDI channel.
The control file is a computer text file that defines the initial state of the control parameters. The control parameters contain some of the musical elements that can be rearranged or changed during operation by a user. Other elements are included in the MIDI sequence file itself. The control file specifies the initial state of whether a part is ON (active) or OFF (muted), the MIDI instruments assigned to the parts, the MIDI note numbers assigned to the drum part and the song tempo. Each line of the control file consists of a key-value pair separated by an ‘=’ character (key=value). To conserve memory, spaces are not allowed. The line termination characters may be either “\n” (newline character) or “\r\n” (newline followed by carriage return).
On the same text line following the pattern setting, a MIDI program number and MIDI bank number is optionally specified for the part. This is done by appending a ‘,’ followed by the MIDI program number, followed by another ‘,’, followed by the MIDI bank number. If not specified, the program and bank numbers are assumed to be 0. If only one number is specified, it is assumed to be the program number. These values are stored in a data structure, sometimes referred to as a “control grid”, during runtime operation. Although defined initially by this text file, these values are changed in real-time during operation. For example, if the user prior to the start of measure 4 on the solo channel hits a button to turn off the A-variation pattern, the character “a” would change to a “−” and the synthesizer would respond accordingly. Following is an example control file as it would appear in a computer text file.
In this example the first line “s=AAAaAAAaAAAaBbBb,80” indicates the solo part would play the A pattern for 3 measures, followed by the A-variation pattern for the fourth measure, followed by the same four measure pattern two more times for measures five through twelve, followed by the B pattern, B-variation pattern, B pattern and B-variation pattern in measures thirteen through sixteen. The numeral “80” at the end of the first line indicates MIDI program #80 should be used for the instrument assignment for the solo part. The harmony (h), drum (d), and bass (b) parts read similarly. The “dk=36”, “ds=40”, “dt=63” and “dh=42” indicate the corresponding drum instrument assignments. For example, “dk=36” indicates that the drum 1 instrument is what is assigned to MIDI note number 36, typically the kick drum. Finally the “t=120” indicates the song tempo is to play at 120 beats per minute.
Computer Application for Simulating Mobile Device Operation
After creating the MIDI sequence file and control file, they are loaded into a computer software program for auditioning and simulating the operation experienced on a mobile device. This software program may reside on a local personal computer or on an Internet server computer.
Downloading to the Mobile Device
Once the content author is satisfied with the musical results, they save their data file(s) (e.g. the MIDI file(s), control data file(s) or any combination thereof and download them to the mobile device. The download mechanism is not specific to this invention but may include; a onetime download of the output data files by a device manufacturer to a mobile device where they are stored in memory and shipped with the device to customers, a physical (wired) connection between a local computer and the mobile device, a wireless connection between a local computer and the mobile device, or a wireless download via a cellular wireless network and wireless service provider such as Sprint, ATT, Cingular, etc. (When downloading from a local computer, the data files can be first transferred to the local computer from a removable computer-readable storage media, such as floppy disks, CD-ROMs or other optical media, magnetic tapes and the like.) It is also possible that a standard set of control data is downloaded and stored in a mobile device by a device manufacturer (as presets) and MIDI sequence data is downloaded separately.
In any event, the data files will reside on a computer-readable medium of one form or another. As used herein, the term “computer-readable medium” refers generally to any medium from which stored data can be read by a computer or similar unit. This includes not only removable media such as the aforementioned floppy disk and CD-ROM, but also non-removable media such as a computer hard disk or an integrated circuit memory device in a mobile device.
Extensions to the MIDI Synthesizer
Once the music content data is on the mobile device, the end user can initiate playback and interaction using their mobile device to rearrange the musical elements specified above. The mobile device should have an integrated MIDI synthesizer when the digital music file is based around MIDI. One of the advantages of this invention is that it can work in conjunction with many commercially available MIDI synthesizer designs. As such, the MIDI synthesizer design is not described in detail here. However, in one embodiment of this invention, there is a set of synthesizer functions or extensions that are included in the synthesizer design to enable very efficient operation on a mobile device. These extensions are described in detail in the next several paragraphs.
One extension to the MIDI synthesizer involves adding a special “game playback mode”. The MIDI synthesizer enters this mode when it receives the corresponding mode message, encoded using a unique MIDI control change message shown in
Part patterns are changed by enabling or disabling MIDI channels. For example, to change the solo part from pattern A to B, you could send a MIDI program change message to turn off channel 1, and another program change message to turn on channel 2. Alternatively, the game playback mode provides a simpler method of doing this using a unique MIDI control change message. This message is usually sent on the master MIDI channel for that part but may be sent on any channel for the part. Drum instrument remapping is also accomplished using unique MIDI control changes. To accomplish this, four control change messages are defined whose values are the note numbers of the four drum instruments.
The game playback message, part pattern and drum re-mapping messages are shown in
Additional extensions to the MIDI synthesizer design allow for the following functionality. When MIDI playback starts, the synthesizer does not reset channel program assignments or MIDI tempo. These will have been sent by the CPU as part of game playback mode initialization (described more fully later) prior to MIDI playback. MIDI controllers 15–19, described above, are enabled. The synthesizer is capable of remapping note-on and note-off key numbers on the drum channels, 9–12. The synthesizer implements a channel enable flag to enable or disable MIDI channels according to the pattern assignment. A disabled MIDI channel does not respond to note-on events to conserve note polyphony and processor load. The MIDI synthesizer is enabled to allow the MIDI sequence data to loop continuously. MIDI program changes and MIDI tempo changes are disabled so these messages in the MIDI file are ignored. Instead, the CPU controls program changes and tempo by sending the appropriate game mode command messages to the DSP.
Messaging System Between CPU and DSP
Many mobile device designs include two microprocessors with a data buffer or FIFO (first in first out) between them. As shown in
Also shown in
While in game playback mode, the CPU (17) continuously streams the MIDI sequence data to the synthesizer on the DSP (21) using the large MIDI FIFO (20). The CPU (17) maintains the control data for changing part pattern assignments, drum note assignments and other data and sends messages to the DSP (21) to effect the changes in the synthesizer. The synthesizer on the DSP (21) in turn sends control and synchronization messages back to the CPU (17). This handshaking is explained further below.
Synchronization Event
In order for the CPU (17) to know the current play position of the MIDI playback, the DSP (21) (or synth on the DSP (21)) sends synchronization events to the CPU (17) at the start of each measure. This event is specified using a MIDI text event, which is a kind of meta event that can be embedded in a MIDI file at an arbitrary time. The format of a synchronization event is “!\” although other formats could be defined. When the synthesizer parses a synchronization event, it sends a synchronization message to the CPU (17) to signify the synth status for display and to trigger another synchronization message transfer to the DSP (21) containing the control grid assignments for the next measure. Note that these synchronization events are proprietary and should not be confused with standard MIDI sync events. The format chosen here for synchronization events should avoid any confusion with other text events that may be present in the MIDI sequence, however another text event could certainly be used.
During playback, synchronization messages are sent to the CPU (17) at the start of each measure. This allows the CPU (17) to know which measure is currently active so the currently active measure can be displayed on the mobile device display. When the CPU (17) receives a sync event, it proceeds to send synchronized control messages to the DSP (21) to set up the pattern assignments for the next measure as determined by the current settings in the control grid. The MIDI control messages are sent using a “synchronized control change” command, which means the DSP (21) will not execute the commands until it parses the next synchronization event. Until then, these sync messages are stored in a sync queue. If however, a user changes the pattern assignment, a non-synchronized control message is sent to the DSP (21) immediately to change the pattern. This is done to ensure a fast correspondence between a users input action and the resultant musical effect. In this instance, the user changed pattern assignment also updates the control change message currently stored in the sync queue. When a user changes a part pattern, the control grid is updated to store that newly selected pattern for the next measure and all subsequent measures until the end of the 16 measure song. For example, if the part pattern assignment for the bass part was AAAAaaaaBBBBAAAA and in measure 8, beat 3, the user changed the pattern to “b”, then the control grid would be updated to AAAAaaaabbbbbbbb. This is the most musical method of interaction. It would not make sense, for example, for the user to have to reselect the “b” part at every measure. Likewise, in order to allow the user to create a 16 measure song and hear it played back the same way, patterns should only be changed until the end of the song and then start over.
Synchronized Messaging
The synthesizer on the DSP (21) exposes a number of its event handling functions to the CPU (17) via the messaging system between the CPU (17) and DSP (21). The exposed functions include the ability to send MIDI note-on, note-off, program change, and control change messages to the synth. Another synthesizer function is exposed that implements a “synchronized” MIDI control change. Control changes sent using this message will be executed synchronously with the next sync event the DSP (21) parses. Synchronized messages received by the DSP (21) are stored in a local queue until needed. The queue is specified to hold four events but could hold more. For each entry, the queue must store the MIDI channel number, MIDI status, and associated MIDI data (up to two bytes). When the synth parses a sync event in the MIDI stream, it first processes all events pending in the queue, and then it sends the sync message to the CPU (17). Messages received by the DSP (21) without the sync flag set are executed immediately and cause any matching pending event to be cleared. Pending events match a current event if the event type and channel numbers match.
An example timeline of messages between the CPU (17) and DSP (21) during playback is shown below:
----Initialization
In addition to the above messages, the DSP (21) periodically sends DATA_REQ messages to the CPU (17) requesting that the MIDI buffer be filled with additional MIDI sequence data. When the CPU (17) receives a DATA_REQ message, it fills the MIDI buffer with MIDI data and replies to the DSP (21) by sending a DATA_READY message. To enable MIDI looping, when the CPU (17) reaches the end of the MIDI track, the CPU (17) continues to send MIDI data starting at the beginning of the MIDI track. This way the DSP (21) continues to play MIDI data as if it was part of a longer sequence. In order to loop the MIDI data while keeping perfect time, the CPU (17) must send the delta time event just prior to the MIDI end of track message. After sending the delta time event, the CPU (17) begins sending MIDI data starting after the first delta time event in the track. Note that the first delta time event in the track will always have a value of 0. This is because the track will contain at least the sync text event at time 0, and probably many other events at time 0. When the MIDI sequence file is first loaded for playback, the CPU (17) parses the content and determines the file offset of the first event in the track following the first delta time, then the file offset of the start of the MIDI end of track event. During looped playback, the CPU (17) sends data up to the file offset of the start of the MIDI end of track event, and then continues to send MIDI data starting at the file offset of the first event in the track following the first delta time. This means that the MIDI end of track event is never sent during playback.
Mobile Device User Interface
One of the most unique features of this invention is the ability to use the standard button layout found on most mobile devices such as cellphones to mix or rearrange a musical song. For this reason a user interface design is included in the invention. The user interface is designed such that a user can bring up the application, hit PLAY, start punching buttons and hear obvious musical changes. This immediate feedback is what grabs a user's attention, is fun, and leads them into deeper functionality of the invention. For the purposes of describing this part of the invention, the term “page” is used to indicate a single screen display and the term “level” denotes a different layer of functionality and corresponding set of display pages. All of the user interaction functionality described in the above invention can be described in 3 levels. Level 1 is the first page that comes up after initialization and is represented on a single screen. This level allows for playing and mixing a song by turning musical parts on or off, selecting the part patterns, setting the tempo of the song and selecting PLAY, PAUSE or STOP. It is intended to appeal to any user whether they have any musical abilities or not and consequently contains the most basic and easy to use user functionality. Level 2 consists of 5 pages, DRUM, BASS, HARM, SOLO and UTILITY. The DRUM, BASS, HARM and SOLO pages allow the user to change the instrument sound for the corresponding part and in the case of the drum part, the four instrument sounds. The UTILITY page allows for utility functions such as loading, saving and deleting of songs in memory and the resetting of default values for a song. It also allows for rendering a song to a standard MIDI file and sending it to a friend with a text message. Level 3 allows for further song editing including changing the notes of the patterns and a variety of other MIDI effects such as note duration or hold, grace notes, pitch bend, chord creation, chord inversion and accents. It should be noted that depending on the exact implementation of the invention and the mobile device that the invention resides on, this user interface design will likely have to be modified. For this reason, this part of the design should be used as a guideline and followed as closely as possible within the parameters of the implementation.
Upon initialization of the application, the Level 1 “mix” page is displayed. As shown in
The tempo is represented in beats per minute or BPMs. Hitting enter while on this field blinks the TEMPO field and allows the user to use the cursor buttons to change the tempo value. Since the number buttons are being used for mixing, data entry is not allowed on this page. Each song plays for 16 measures and then loops back to the beginning and plays again. This continues until the user initiates stop. The vertical measure at the right of the display fills in as the music progresses from measure 1 to measure 16 to help the user identify where they are in the song. Moving the cursor button selects the following fields in this order: PLAY>TEMPO>MIX>DRUM>BASS>HARM>SOLO>PLAY, etc. Cursoring to DRUM, BASS, HARM, or SOLO and then pressing enter button brings the user to Level 2 for the corresponding part where they can change the instrument assignment for that part. (see below) Selecting MIX brings the user to the UTILITY page where they have access to the utility functions.
Level 2 functionality expands the mixing capabilities by allowing users to change the sound of an instrument. There are four separate pages in level 2, one for each part.
As shown in
Level 3 represents the most detailed user functionality of the invention but in some ways also the most musical. As shown in
As shown in
Also shown in
As shown in
As shown in
Also shown in
As shown in
Also shown in
As shown in
Other Embodiments
In a second embodiment of the invention, the musical rearrangement functionality resides entirely in a computer application on a local personal computer or Internet server computer. In this embodiment, the user loads, creates and auditions MIDI sequence data and rearranges the musical data or mix to their liking entirely within this application. The user interface design described above can be used or an entirely different user interface with similar functionality can be used. When done, a user downloads the final result to their mobile device for playback. The downloaded file(s) can consist of a proprietary file(s), such as the MIDI sequence and control data files described above for the purpose of further rearranging on the mobile device, or it can be rendered and saved as a standard MIDI sequence file (SMF) for use as a non-rearranging song on the mobile device. The advantage to downloading a standard MIDI sequence file is that it can operate on any MIDI compatible mobile device, i.e. where no further elements of this invention reside. A standard MIDI file on a mobile device can be used as a ringtone (the file that plays when your phone rings), a message or appointment alert or simply function as a place to store and listen to songs of the users liking. This is very convenient on a mobile device because users can take their songs with them anywhere they go. The invention's uniqueness is further amplified in this embodiment by the computer application acting as a ringtone composer where the user can design their own ringtones.
In a third embodiment of the invention, all unique message commands described in the synthesizer extensions and messaging system above are exchanged with standard MIDI messages, proprietary messages, or a combination of the two that are already designed and present in the target synthesizer or are available for design in the target synthesizer. This allows the user rearrangement functions of the invention to work with any existing synthesizer design without modifications. Although this may increase the size of the application and processor load, it may in some cases be the preferred or only method, if for example, the synthesizer cannot be designed or modified with the extension functionality described above. For example, MIDI channels can be muted by sending a null or silent program change message and activated by sending a “valid” MIDI program change and drum part note numbers can be changed algorithmically by adding to the current drum note numbers. The synchronization event messages can be generated outside the synthesizer functionality using separate code and a different time base. Other possibilities exists also depending on the specifications of the target synthesizer.
In a fourth embodiment of the invention, the MIDI sequence data is not constructed in any particular format, including the format described in the first embodiment which defines which MIDI channels contain which musical parts and patterns, how many measures the patterns are, etc. Instead, the MIDI sequence data consists of any arbitrary standard MIDI sequence file with or without any regard to specialized format. This allows the invention to operate on a large body of existing MIDI song files or song files designed for other standard playback systems without modification thereof. The invention in this embodiment subsequently reads and displays pertinent song data to the user (for example the data which is allowed to be rearranged), such as which MIDI instrument is assigned to which MIDI channel, which drum notes and instruments are being used, which beats or strong beats (based on MIDI velocity for displaying a smaller set of “important” beats) are being used, song tempo, etc.; and unique or standard MIDI controllers are used for rearranging the song data. The control data file is either a preset configuration consisting of a standard set of musical elements for rearrangement or is constructed “on the-fly” when the MIDI sequence data is read into memory. The user interface on a computer or on the device changes as necessary to display the song elements available for rearrangement.
As shown in the descriptions above, the invention provides a unique method and process for creating, rearranging and playing musical content on mobile devices. The invention is both useful as an entertaining musical game as well as a method for personalizing mobile cellphones, PDAs and other mobile devices. The functional characteristics and method of the invention are designed such that they integrate seamlessly with the unique physical, economic and functional attributes of mobile devices while still allowing some flexibility in the final applied application. While the description above contains many specifics, these should not be construed as limitations on the scope of the invention. Many other variations are possible, some of which have been described in the alternative embodiments. Accordingly, the scope of the invention should be determined not by the embodiments described and illustrated, but by the appended claims and their legal equivalents.
This application claims the benefit of U.S. Provisional Application No. 60/278,802, filed Mar. 26, 2001.
Number | Name | Date | Kind |
---|---|---|---|
3986423 | Rossum | Oct 1976 | A |
4508002 | Hall et al. | Apr 1985 | A |
4771671 | Hoff, Jr. | Sep 1988 | A |
4881440 | Kakizaki | Nov 1989 | A |
4915001 | Dillard | Apr 1990 | A |
4974178 | Izeki et al. | Nov 1990 | A |
5131042 | Oda | Jul 1992 | A |
5204969 | Capps et al. | Apr 1993 | A |
5208421 | Lisle et al. | May 1993 | A |
5231671 | Gibson et al. | Jul 1993 | A |
5301259 | Gibson et al. | Apr 1994 | A |
5315057 | Land et al. | May 1994 | A |
5405153 | Hauck | Apr 1995 | A |
5541354 | Farrett et al. | Jul 1996 | A |
5567901 | Gibson et al. | Oct 1996 | A |
5574243 | Nakai et al. | Nov 1996 | A |
5596159 | O'Connell | Jan 1997 | A |
5679912 | Asai et al. | Oct 1997 | A |
5728962 | Goede | Mar 1998 | A |
5736663 | Aoki et al. | Apr 1998 | A |
5792971 | Timis et al. | Aug 1998 | A |
5864080 | O'Connell | Jan 1999 | A |
5886274 | Jungleib | Mar 1999 | A |
5900567 | Fay | May 1999 | A |
5952598 | Goede | Sep 1999 | A |
5990404 | Miyano | Nov 1999 | A |
6194647 | Tateno | Feb 2001 | B1 |
6423893 | Sung et al. | Jul 2002 | B1 |
Number | Date | Country |
---|---|---|
0 484 043 | May 1992 | EP |
0 484 046 | May 1992 | EP |
401179195 | Jul 1989 | JP |
402311899 | Dec 1990 | JP |
403126995 | May 1991 | JP |
404146490 | May 1992 | JP |
405257466 | Oct 1993 | JP |
Number | Date | Country | |
---|---|---|---|
20020170415 A1 | Nov 2002 | US |
Number | Date | Country | |
---|---|---|---|
60278802 | Mar 2001 | US |