Anatomical random rhythm generator

Abstract

Disclosed is a random music or rhythm generator comprised of software and hardware that serves to augment the creativity of human musicians when creating musical compositions. The generator considers anatomical restrictions when creating music in order to generate humanly playable musical compositions. The generator also features extra components and features which allow musicians to configure, customize, randomize, and share their musical compositions.

Claims

1. A system for music generation comprised of: an algorithm; a plurality of tracks; and, a track database.

2. The system of claim 1 wherein tracks feature a plurality of track settings.

3. The system of claim 2 further comprising a host.

4. The system of claim 3 wherein the host sets a plurality of musical parameters.

5. The system of claim 4 wherein tracks have anatomical associations.

6. The system of claim 5 wherein tracks are connected to a plurality of drum machine synthesizers.

7. A system for music generation comprised of: an algorithm; a host; a plurality of tracks; and, a filter page.

8. The system of claim 7 further comprising a track settings panel.

9. The system of claim 8 wherein tracks are categorized by track type.

10. The system of claim 9 further comprising at least one track group which is comprised of at least two tracks.

11. The system of claim 10 wherein tracks are associated with limbs or digits.

12. The system of claim 11 further comprising a plurality of patterns which are comprised of tracks.

13. The system of claim 12 further comprising a randomize icon.

14. The system of claim 13 wherein patterns are combined considering anatomical associations of the tracks.

15. A method of using a system to randomly generate anatomically possible music comprising: selecting a plurality of drum machines; configuring tracks via track settings; specifically creating anatomical associations to specific tracks; combining and filtering tracks;

16. The method of claim 15 further comprising the system automatically generating a plurality of patterns.

17. The method of claim 16 further comprising randomizing patterns using the randomize icon.

18. The method of claim 17 further comprising patterns being randomized according to anatomical associations of tracks to create playable patterns.

19. The method of claim 18 further comprising saving the pattern.

20. The method of claim 19 further comprising reconfiguring patterns with build filters.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0045] Other objectives of the disclosure will become apparent to those skilled in the art once the invention has been shown and described. The manner in which these objectives and other desirable characteristics can be obtained is explained in the following description and attached figures in which:

[0046] FIG. 1 shows a track, sound, and limb association chart;

[0047] FIG. 2 shows a track settings panel;

[0048] FIG. 3 shows static “track type” chart;

[0049] FIG. 4 shows a dynamic track setting, randomness, and hit chart;

[0050] FIG. 5 shows a “track type” filter page;

[0051] FIG. 6 is a “track type” chart;

[0052] FIG. 7 is a “track type” chart;

[0053] FIG. 8 shows to a configuration page;

[0054] FIG. 9 shows a filters page;

[0055] FIG. 10 is a flow chart;

[0056] FIG. 11 is a table;

[0057] FIG. 12a is an example of an encoding scheme; and,

[0058] FIG. 12b is a continuation of FIG. 12a.

[0059] It is to be noted, however, that the appended figures illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments that will be appreciated by those reasonably skilled in the relevant arts. Also, figures are not necessarily made to scale but are representative.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0060] Disclosed is a random music or rhythm generator that considers human anatomy as music is generated. The generator may be comprised of hardware and software. The hardware device or host may leverage the software or algorithm. The algorithm may also be embedded in a 3.sup.rd party solution or other music software.

[0061] The algorithm has many purposes, one of these purposes being music, rhythm or sound production. The algorithm produces its own sound through a plurality of soundtracks or tracks. The algorithm may act analogously to a player component of a player piano. The algorithm works by sending and returning note information through various software and hardware protocols. The algorithm may be tuned for rhythm creation but may be adapted to handle musical phrases based on human factors like arms or fingers which would correspond to a human keyboard player.

[0062] The host is the other component of the generator. The host sets a plurality of musical parameters such as time signature, tempo, clock, song position, and the like. The host sends information related to the musical parameters to the algorithm. Then the algorithm produces an output that the host can then use to generate sound directly or indirectly through various means.

[0063] The generator is distinct from other traditional rhythm generators by accounting for anatomic possibility when creating rhythm tracks. The generator and its software may generate hundreds of possible rhythms and phrases based on a plurality of settings in the software. However, the system will filter rhythms for anatomic possibility.

[0064] FIG. 1 shows a track, sound, and limb association chart. The chart shown is a representation of a plurality of percussion sounds produced by the anatomical random music or rhythm generator. The generator and algorithm as shown uses six tracks, however, the system may use between four and ten tracks. While four to ten tracks is a preferred setting, it may be possible for the system to use or process between zero to ten thousand or more tracks. Each track (in a preferred embodiment) may be connected to a drum or other instrumental machine synthesizer, which generates sounds like kick drums, snares, cymbal crashes, and the like. Suitably, the system can handle an unlimited number of tracks, e.g., between zero and ten-thousand plus.

[0065] The chart of FIG. 1 shows a moment in time, a plurality of tracks, a percussion sound associated with each track and a limb associated with each percussion sound. At this particular moment the music or rhythm generator is playing kick drums 1 and 2, snare drums 1 and 2, and crash cymbal 1 and 2. If a musician were to play the percussion sounds shown on the track chart on a physical drum set, the musician would simultaneously use their legs to hit kick drums 1 and 2 and their arms to hit snare drums 1 and 2 and crash cymbals 1 and 2.

[0066] The chart shown in FIG. 1 is an example of the anatomically impossible percussion sounds that random music or rhythm generators may prompt musicians to play. Traditional rhythm generators may use probabilities to create a pattern or sound. Traditional generators, using probability alone, are prone to creating anatomically impossible rhythm tracks such as the one shown by FIG. 1. Such rhythm tracks may be generated then filtered by the random anatomical musical generator disclosed by this application.

[0067] Tracks may have an associated limb or digit. Anatomical associations may allow the filter to create an anatomically possible output. Anatomical associations combined with a category called “track types” are what make the algorithm, and therefore the system, unique. Anatomical association settings may include arm, leg, finger, toe, or any. Using an arm or leg setting on multiple tracks restricts those tracks so that one limb cannot exceed two drum hits at the same time, reflecting anatomical realities.

[0068] While setting a track to a specific limb may create anatomical restrictions, setting a track to “any” may lift anatomical restrictions. For example, six tracks set to “any” could use every available sequence position and trigger six hits at the same time, throughout the entire sequence. Although this sequence may be busy and non-musical, it is an option. Similarly, setting all six tracks to arm would keep the rhythm simple, and no three tracks could be triggered at the same time.

[0069] FIG. 2 shows a track settings panel example. In one example, each of the tracks has its own individual settings that affect how rhythms are generated. The track settings may be track type, “track type” filter, limb, note, randomization, lock, and velocity minimum or maximum. These settings may be controlled by a randomness dial 201, a note dial 202, and a limb dial 203. Also shown is a filters tab 204 and a note audition tab 205. Although other settings may exist, they may not always affect rhythm generation.

[0070] An important track setting is “track types”. “Track types”” are a category of track models that may classify specific tracks. The system may have an internal database of “track types” which represent rhythmic possibilities based on musical time signatures and other user selected settings. The database may contain an unlimited amount of “track types”. “Track types” may be categorized as static, dynamic, or scripted.

[0071] FIG. 3 is a chart that speaks to a plurality of static “track types”. For this track example, the time signature is set by the host to four-four. Typically, this means a sixteen-step sequence will be used in a single bar or musical phrase, but in other time signatures or settings, the number of steps can vary. The “track type” chart shows “track type” note frequency on the left column and shows the representation of that note frequency on the right column. The representation of the “track type” is represented with ones and zeros. Ones represent percussive hits and zeros represent the lack of a hit. As shown in the representation column, a static track may hit every note in the sequence, every other note in the sequence, or may hit only on quarter notes. Tracks do not need to be 16 steps, they can be 7, 14, 16, 32, up to 1024 and even larger in some use cases. FIG. 4 is a track setting, randomness, and hit chart that speaks to dynamic tracks. Like the previous static track example, the time signature is set by the host to four-four and the user or algorithm chose a sixteen-step sequence to be used in a single bar or musical phrase. Dynamic tracks differ from static tracks in that they incorporate a randomization setting. The randomization setting may range from zero to one hundred, with zero being no randomization and one hundred being the maximum. Whenever the “track type” on a track calls for a random element, the randomization setting is used. As shown in the “track type” chart of FIG. 4, the number of hits on a dynamic track is a function of track's settings and randomness. In the “track type” chart in the track setting column, Xs represent a random variable. If there are no Xs in the track type, then the randomness setting will not affect the output. The randomness column shows different degrees of associated randomness, and the hit column shows the number of percussive hits that may be generated by combining the track setting and randomness setting. Due to probabilities associated with randomization, a track setting with a randomization setting of seventy-five will likely have more hits than the same track with a randomization setting of ten.

[0072] The third “track type” is scripted tracks. Like the other “track type” examples, the time signature in this example is set by the host to four-four, A sixteen-step sequence was selected by the user or algorithm to be used in a single bar or musical phrase. A scripted track uses a dynamic scripting language to generate rhythms that are more complex than static and dynamic rhythms. Scripted tracks are highly configurable and open-ended, allowing for parametric possibilities such as, “at least four hits but no more than seven, and ensure one space exists between all notes”. Or, “sixteen hits, each hit being progressively louder in order to create a sonic ramping effect”.

[0073] FIG. 5 shows a “track type” filter page wherein tracks may be combined or filtered. The “track type” filters page may feature a list of “track type” filters that may be organized by ID: number 501, name 502, description 503, and enablement 504. Different icons such as the “invert selection” icon 505, “select all” icon 506, “clear all” icon 507, “copy track settings” icon 508, “paste track settings” icon 509, and “copy all tracks” icon 510 are shown on the lower portion of the “track type” filters page.

[0074] “Track types” may be useful for creating sonic structure. If “track types” and settings are combined in a preset, similar “track types” may create a different feel from one preset to the next. For instance, a user may mix various “track types” among the user's X tracks to generate rhythms that are busy, sparse and minimalistic, or somewhere in-between.

[0075] To store “track types” the software may feature an internal database. If the user wants a desired effect, the “track type” filter allows the user to select which “track types” may be eligible to play on a specific track. The user may set a single “track type” to be eligible to be played on a track or a user may select a group or pool of eligible “track types” and select “track types” randomly from the pool. It is important to note that only one “track type” is active on a given track at a time.

[0076] FIG. 6 is an example output and “track type” chart which speaks to a combination of six tracks with a track type, “X0X0X0X0X0X0X0X0.” As shown the myriad of tracks correspond to the track type, “X0X0X0X0X0X0X0X0” because the tracks have hits in places that correspond to the “track types” variability.

[0077] FIG. 7 is a “track type” chart which speaks to a combination of six tracks with a track type, “XXXX000000000000.” As shown the myriad of tracks correspond to the track type, “XXXX000000000000” because the tracks have hits in places that correspond to the “track types” variability, the table shows the results for each track based on the “track type” “definition” after being processed.

[0078] The ability to filter tracks types is a key element of music composition using the system. Using a filter, track 1 may be set to allow a group of “track types” that are different from the group track 2 allows, which are different than groups of “track types” allowed for the other tracks. In one example, when tracks are randomized, while each of the four to ten tracks of this example are using a different track type, the user may create an exponential amount of variation. It is important to note that filters may be inclusive or exclusive and that not all tracks have to be set to allow the same “track types”. As stated above, the amount of randomized tracks may preferably be four to ten, but in other embodiments the amount used or employed may be between zero and ten thousand or more.

[0079] Using a combination of settings provided by the host and the track settings, sequences may be generated automatically in order to create a supply of rhythmic variation. Again, the sequence generator considers anatomical restrictions and the “track type” on each track, to generate multi-track patterns that are anatomically possible if limb associations are proper. Without limb associations the tracks are randomly built and assembled into a multi-track sequence.

[0080] When the user is satisfied with an outcome they may save or lock tracks into their current generated pattern. Locked patterns will not be affected by updates or by the user further randomizing the pattern.

[0081] Tracks may have an associated note that is triggered any time a hit is required. In digital music, this is normally a musical instrument digital interface protocol often referred to as a “note number”, which can range from 0-127. Note numbers may communicate pitch information across instruments. In a hardware control-voltage scenario, pitch information may need to be conveyed using control voltage output rather than the note number. In this case, the host can take the note number and make the necessary conversion before sending it to the output. The algorithm may trigger specific sounds through the host using the note setting. In the prototype, the note is tied to a track in a 1:1 relationship. However, the 1:1 ratio is configurable and there are creative use cases where the ratio may change over time.

[0082] Digital communication between the algorithm and the host is an important part of the system. It is often the case that the host may provide song position to the algorithm whereby the algorithm sends back the elements of the currently created pattern that correspond to the bar or song position. Thereafter, the host is responsible for routing those notes to downstream synthesizers. Alternatively, the algorithm can generate a file or structure that allows the host to play the notes. In many use cases, the host would also record the output from the algorithm in order to play it back the same way, in the future, without the algorithm needing to be present. It is also possible for the algorithm to record and store these internally for later use depending on the embodiment.

[0083] Two ways the user may change a pattern may be by using a randomize icon 801 or a next sequence icon 802 shown in FIG. 8. Pressing the randomize icon 801 will cause the generator to randomly select a “track type” for each track based on available types set in the “track type” filter and build a new set of sequences based on the given track settings. Pressing the next sequence icon 802 causes the generator to produce a variation of the existing settings that leaves “track types” unchanged. A pattern may have subtle variations when the next sequence icon 802 is selected and may be completely rearranged if the randomize icon 801 is selected. Track generation quality may be monitored by a track quality indicator 805. Further, queue size may be monitored by the queue size indicator 806. When the user is satisfied with the outputs the user may save their settings using a save drum kit icon 803 or a save preset icon 804.

[0084] If the pattern is still not satisfactory, a user may select a different pattern from saved “track types” and settings or from some other preset configuration. Presets may add creative direction to the otherwise random process of making music which the system employs. Presets may come preloaded on the system and may be created or shared by users.

[0085] Presets may also be generated in a random fashion via a “make everything random” icon. Using the “make everything random” icon may combine all “track types” in a random preset. When the “make everything random” icon is selected, all tracks will load their respective track filters and generate random patterns.

[0086] A drum kit is a collection of notes that correspond to tracks and an important tool for making music digitally. Drum kits may also be an important part of the system. Drum kits are useful when the user has many drum machines in their collection. Often, drum kits are changed. Changing the drum kit may change the notes on each track to correspondent notes in the drum kit. Changing the drum kit may not affect the sequence process or the song position. Drum kits may be changed many times while the sequence is being played without affecting the overall rhythm. However, changing drum kits may change the notes or sounds being played.

[0087] FIG. 9 shows a filters page. As shown, the filters page features a web filter 901, a swing filter 902, an injector filter 903, a swapper filter 904, a slicer filter 905, and an ejector filter 906. The filters may be non-binary and may be modulated. During playback or sequence generation, several real time and build filters can be used to change the overall feel or structure of a multi-track sequence by interacting with a portion of the sequence called the active sequence. The filters may remove notes, add slight delays in notes, inject notes, swap notes between tracks, split notes into two new notes, change the note number or pitch on a note, or other creative use cases. A slight delay in notes or swing is popular and may be found in other drum machines and software. However other filters by the system are not common or known.

[0088] Build filters are used when the pattern is generated or re-built based on various events, and playback filters are designed for “real-time” changes to the actively playing sequence. Neither filters need to permanently modify the underlying structure of the pattern, and each type of filter may have its own settings. For example, a “note injector” may have a setting of 90 out of 100, which may indicate there is a 90% chance it will create a new note during playback during any particular playback interval. It may also have settings for the maximum number notes it will create during a single pattern playback.

[0089] A build filter, for example, may use a generated sequence, then “drop” or otherwise silence a particular percentage of notes in the sequence. If the pattern were set to repeat 10 times in a row, the same notes that were silenced would be silenced each and every time, so each of the 10 playbacks would be identical. The notes silenced would be “permanent” until the sequence is rebuilt or the build filter's settings are changed and the new settings take effect.

[0090] Playback filters are for real-time changes or live performance. For instance, a real-time filter may add one or more notes to a sequence as it's playing back. However, playback filters don't have a “memory”, so setting the pattern to repeat 10 times in a row may result in experiencing 10 slightly different variations of the underlying pattern as nothing was permanently changed during playback and events are simply changed or added in a random fashion. The level of randomness is part of the filter's own settings. Additional features of the system may be related to the algorithm, QR codes, and the hardware element of the system. The algorithm may use artificial intelligence and machine learning to learn and make decisions based on user preferences or data stored in another medium or another computer network. The algorithm may generate settings or sequences as a QR code to allow easy import, export, and sharing of settings and sequences between users. The hardware may have the ability to send and receive presets or sequences via QR codes or wirelessly. The hardware may connect to the cloud in order to share and receive presets and sequences from other users of the platform.

[0091] FIG. 10 is a flow chart that speaks to the steps of building and configuring a pattern. One may start this process by pressing a randomize button. The randomize button randomizes settings and triggers a settings change. Thereafter, tracks may be configured by the user via track settings. Configurable track settings may be randomization, track type, “track type” filter, limb, note, randomization, lock, and velocity minimum or maximum. These changes in settings cause the algorithm to recalculate and call the next button automatically. The algorithm reviews the settings and creates new patterns. Then the new patterns are stored. Simultaneously, the next button pulls the next pattern from storage. Next, build filters may make semi-permanent adjustments to the pattern. Then the pattern enters a listen loop, which is a cycle of listening and refinement on the part of the user. During this cycle, the user may use playback filters to make automatic real-time adjustments to the pattern as it plays. The user may change drumkits or notes. The user may change playback filter settings. Patterns may be further configured and changed with build filters. Once the user is satisfied with the “way” that patterns are generated (based on settings, filters, etc.) the settings themselves can then be saved for future recall as a “preset”. Future patterns can then be generated under the same criteria by recalling the “preset” settings. The patterns generated (the order of notes, timing, velocity, etc.) would likely be different than when the settings were originally saved. Lastly, the user may save the current pattern when they are satisfied with the pattern outcome.

[0092] If the user is satisfied with the pattern itself (the series of notes, etc.) the pattern can also be saved for future recall. Saving the pattern for future recall can be useful if the musician is away from their studio or is using the device for live performance.

[0093] The user may change drum kits at this point and the change will be reflected in the saved pattern if the user desires

[0094] FIG. 11 shows a track group, track, and limb association chart. As shown, tracks are categorized into track groups. The purpose of the chart shown is to disclose how track groups may be used to generate random anatomically possible patterns or rhythms. Groups may create anatomically possible patterns and rhythms by preventing groups from colliding pursuant to user settings. It should be noted that the chart is in no way intended to be limiting of the subject matter disclosed in this specification. Although the terms “Group,” “Track”, “Leg”, and “Arm” are used, it should be understood that other terms or designators (e.g., colors) for a group, composition, or appendage could be used to organize the relevant information contained within the table.

[0095] Although the method and apparatus is described above in terms of various exemplary embodiments and implementations, it should be understood that the various features, aspects and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead might be applied, alone or in various combinations, to one or more of the other embodiments of the disclosed method and apparatus, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Thus the breadth and scope of the claimed invention should not be limited by any of the above-described embodiments.

[0096] Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open-ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as meaning “including, without limitation” or the like, the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof, the terms “a” or “an” should be read as meaning “at least one,” “one or more,” or the like, and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that might be available or known now or at any time in the future. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future.

[0097] The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases might be absent. The use of the term “assembly” does not imply that the components or functionality described or claimed as part of the module are all configured in a common package. Indeed, any or all of the various components of a module, whether control logic or other components, might be combined in a single package or separately maintained and might further be distributed across multiple locations.

[0098] Additionally, the various embodiments set forth herein are described in terms of exemplary block diagrams, flow charts and other illustrations. As will become apparent to one of ordinary skill in the art after reading this document, the illustrated embodiments and their various alternatives might be implemented without confinement to the illustrated examples. For example, block diagrams and their accompanying description should not be construed as mandating a particular architecture or configuration.

[0099] All original claims submitted with this specification are incorporated by reference in their entirety as if fully set forth herein.