Patent Grant
9263018
The following non-provisional U.S. patent applications (including this one) are being filed concurrently, and the entire disclosure of the other applications are incorporated by reference into this application in their entirety for all purposes:
Drum machines and sequencers have long been used to generate rhythmic accompaniments for musicians lacking access to a full band, drumming proficiency, or a convenient means of recording drumming performances. Musicians typically use prerecorded (“canned”) drum loops to create drum tracks. Drum sequencing with canned loops can be easy to create, however they are extremely limited in their scope of application. For example, drum loops at 100 beats-per-minute (BPM) may not be useable at 130 BPM without significant sample editing and waveform manipulation (e.g., slicing, cutting, etc.). Furthermore, canned loops tend to sound formulaic and repetitive. In short, conventional methods of creating drum tracks using a drum machine or sequencer is typically cumbersome and tedious, with few customizable options that yield unconvincing artificial performances.
In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of embodiments of the invention. However, it will be apparent that various embodiments may be practiced without these specific details.
Certain embodiments of the invention relate to the automatic creation of a continuously changing rhythmic musical accompaniment for a given musical performance based on (1) customizable input parameters, (2) musical arrangement data, and (3) characteristics of the musical performance (i.e., musical performance data). For example, embodiments of the invention can analyze a live or recorded guitar track and automatically generate a suitable percussive accompaniment (e.g., drum track) based on characteristics of the performance (e.g., audio waveform, Musical Instrument Digital Interface (MIDI) data, etc.), characteristics of the arrangement (e.g., chorus, intro, etc.), and input parameters selecting a desired genre, stylistic embellishments, and more. Thus, a fully customizable automatic rhythmic accompaniment can be generated “on the fly” and manipulated in real-time for a realistic and human sounding performance.
In some embodiments, user customizable input parameters can include volume, accompaniment complexity, instrument type (e.g., drum kit type), genre type (e.g., rock, R&B, jazz, soul, etc.), shuffle controls, and more. By allowing a user to select a genre and change accompaniment parameters and characteristics, an appropriate rhythmic accompaniment can be created that better suits the musical performance. For example, a rock-and-roll style accompaniment may better suit a hard rock guitar performance than would a brushed jazz accompaniment. However, any desired combination of user parameters can be implemented.
In certain embodiments, musical arrangement data can identify the basic architectural elements of song, such as verse, chorus, bridge, or the like. Identifying a song section can be useful in determining an appropriate rhythmic accompaniment. For example, an intro to a song may be relatively quiet, subtle, or may slowly increase in volume and complexity, while a chorus section may be up front, loud, lively, and catchy. Consequently, one embodiment may generate an intro section with simple percussive arrangements at low volume with focus on rim shots and ping rides, and a chorus section with complex beats at high volume with a focus on kick and snare drums with crash cymbals. It should be noted that musical arrangement data can be an optional element and may not be required to generate a rhythmic accompaniment.
Musical performance data can be broken down to its elemental components such that the basic or fundamental underlying beat, known as an accent pattern, can be determined. Once the accent pattern of the musical performance is determined, a matching accent pattern (i.e., same fundamental beat) in a musical elements database can be used to create a suitably matching rhythmic accompaniment. Musical performance data can be in any suitable electronic form including audio sample(s), MIDI track(s), or other musical data of musical performances such as guitar riffs, piano melodies, bass lines, or any rhythm or melody from any real or virtual instrument. By determining the accent pattern of a musical performance, implementing user input parameters, and considering musical arrangement data, a very well suited rhythmic accompaniment for the musical performance can be automatically generated and customized to user preference. In some embodiments, the automatically generated rhythmic accompaniment can be generated passively or in real-time.
Block 110 can be a live performance recorded offline and fed into the musical elements database 120. The recorded performances of block 110 can be used to establish a catalogued library of the various musical elements (e.g., accents, systems, etc.) that can be used to create the accompaniments described herein. Block 110 can be a live recorded drummer, however alternative embodiments may employ any suitable recordings, samples, etc., of the basic elements (e.g., accents, systems, fills, etc.) of percussive, melodic, or harmonic performances. For example, musical elements from guitar, bass, violin, piano, or other instrument, virtual or otherwise, can be used to populate the musical elements database 120. It should be noted that other alternative sources of musical elements can be implemented, as would be appreciated by one of ordinary skill in the art with the benefit of this disclosure.
Musical elements database 120 can be a vast library of basic elements that can be used to create a musical accompaniment. MED 120 can include micro-timing data 122, micro-dynamics data 123, system pattern 124, accent pattern data 126, and fills data 128. In some embodiments, micro-timing data 122 relates to shifting a note in time relative to a reference point typically by a small positive or negative amount to simulate a “feel” or groove of a particular style of music or playing style. In some aspects, micro-dynamics data 123 can include small rhythmic embellishments to simulate particular styles of music. For example, adding micro-dynamics may include adding double stick hits, flams, or ghost notes on a snare or tom-tom track. Accent pattern data 126 can relate to the basic elements of a given rhythm, i.e., the basic or fundamental beat. In some implementations, a plurality of stored accent pattern data, referred to as reference accent pattern data, is compared to accent patterns gleaned from musical performances (e.g., musical data) to find a closest match. Once an acceptable match is found, the reference accent pattern is used as a baseline or starting point in generating the rhythmic accompaniment, as further described below. System pattern data 124 can be an accompaniment pattern that can be combined with different accent patterns. For example, one system pattern may include a series of straight 8th note hi-hats, triplets, or any suitable configuration of notes that typically do not constitute an accent pattern. Fills data 128 typically includes one or more short breaks in a particular rhythm that “fills in the gaps” or, for example, indicates the end of a musical bar. It should be noted that although particular musical elements are described herein, more or fewer types of musical elements can be used to generate rhythms, as would be appreciated by one of ordinary skill in the art with the benefit of this disclosure.
User input block 130 can include a user interface to receive one or more user defined parameters to influence the musical accompaniment. Some definable parameters can include a performance volume, rhythmic complexity, instrument type (e.g., drum kit type), genre type (e.g., rock, jazz, fusion, R&B, alternative, folk, etc.), swing, focus (e.g., emphasis on kick, snare, or hi-hat, etc.), and more. In some cases, each definable parameter can be configured in a default setting, or can be controlled by macros or global preset values, as would be appreciated by one of ordinary skill in the art. In certain embodiments, input parameters may be automated in response to detected musical performance characteristics. For example, if a musical performance (i.e., performance data) is determined to have a fast tempo, with loud and frequent accents, then input parameters that complement those features may be automatically selected (e.g., increased volume, simple beat pattern, etc.). Input parameters are further discussed below with respect to
Musical arrangement block 140 can perform an algorithmic analysis of a musical performance to identify the basic architectural elements of song, such as verse, chorus, bridge, or the like. This may be useful when generating an appropriate accompaniment for different portions of a song. For example, an accompaniment may tend to be livelier during a chorus section (e.g., louder, more complex, etc.) than during an intro section. In certain embodiments, musical arrangement data can be an optional element and may not be required to generate a rhythmic accompaniment.
Musical performance block 150 can be configured to perform an algorithmic analysis of a musical performance (e.g., guitar riff, piano riff, bass line, etc.) to determine its basic rhythmic components (e.g., accent pattern). The accent pattern of the musical performance can be matched with a number of reference accent patterns 126 in musical elements database 120 to help generate an appropriate rhythm accompaniment for the musical performance, as further discussed below. In some embodiments, system patterns, fills, micro-timing characteristics, and/or micro-dynamics characteristics can also be algorithmically determined, which can be used to determine which musical style of accompaniment would be most appropriate for the musical performance. For example, if the musical performance is very sloppy and consistently varies behind the beat, then RAGS 100 may generate a similarly patterned accompaniment.
Musical database filtering block 160 is configured to filter the musical elements database 120 based on inputs from the user input block 130, the musical arrangement block 140, and the musical performance block 150, to determine an appropriate combination of musical elements (i.e., accent patterns, system patterns, etc.) to create a suitable accompaniment for a particular musical performance. The selected combination of musical elements can be algorithmically based, probability and/or statistically based, rule based, or any suitable method of filtration and any combination thereof, as would be appreciated by one of ordinary skill in the art with the benefit of this disclosure.
To illustrate the filtering process, a non-limiting example is provided. According to an embodiment, filtering block 160 receives input parameters from input block 130 indicating a low volume, complex rhythm in a jazz style with a 50% shuffle feel and a high number of fills. The particular jazz style selected (selected by player “personality”) is a style replete with micro-timing dynamics but few micro-timing shifts. Filtering block 160 receives an indication from musical arrangement block 140 that the rhythmic accompaniment is for a verse section. Finally, filtering block 160 receives an indication from musical performance block 150 that a musical performance has a particular accent pattern. Filtering block 160 accesses musical elements database 120 and filters through the library of musical elements (e.g., reference accent patterns, system patterns, etc.) to find a combination that meets the requirements of each input 130, 140, 150 (e.g., jazz style, shuffle feel, etc.). For example, filtering block 160 searches through and filters the library of reference accent patterns 126 to find one or more that match the accent pattern of the musical performance. The reference accent pattern is selected (e.g., by algorithmically selected, probability-based selection, etc.) and filtering block determines an appropriate combination of reference system patterns, reference fills, reference micro-dynamics, and reference micro-timing data based on the selected input parameters 130, 140, 150.
In certain embodiments, pattern generation is a modular framework with some custom made modules and script language that can filter, combine and modify patterns, based on the various input parameters described above. For example, certain patterns (e.g., accent patterns, system patterns, etc.) are sent through different modules that modify the “probability” of each pattern. In some cases, modules that modify probability may be drummer styles (see
MIDI generation block 170 can generate a MIDI performance based on the combination of musical elements selected by filter block 160. In the example cited above, the MIDI-based rhythmic accompaniment may be a jazz-styled beat to accompany the musical performance. In summary, MIDI generation block 170 puts together a MIDI-based rhythmic accompaniment (e.g., drum beat) for the musical performance based on the filtered musical elements and input parameters received from filter block 160. In certain implementations, MIDI block 170 is the output of filter block 160. The output can be a MIDI pattern or sequence of single MIDI events that are combined in a MIDI region which is pasted into a MIDI track of a host digital audio workstation (DAW). The many possibilities of MIDI output configurations would be understood by one or ordinary skill in the art. In some implementations, other musical formats besides MIDI can be used.
The software instrument 180 can be any suitable MIDI player configured to play the MIDI performance generated by MIDI generation block 170. In some embodiments, filter block 160, MIDI generation block 170, and software instrument 180, or certain combinations thereof, may be performed by a single functional block of system 100, rather than multiple blocks (i.e., certain functional blocks have multiple functionalities). Similarly, other blocks (e.g., user input block 130 and musical arrangement block 140) can be functionally combined as desired.
At 210, method 200 begins with storing a plurality of musical elements in a database. In some embodiments, the database can be musical elements database 120 of
At 220, method 200 continues with algorithmically analyzing a musical performance to determine its basic rhythmic components. This can be generally referred to as processing performance data. Processing performance data can include receiving input data corresponding to a musical performance, determining one or more patterns of accentuated events in the musical performance, matching the pattern of accentuated events (i.e., accent pattern) from the musical performance to one or more reference accent patterns from the accent reference data of musical elements database 120, and selecting one of the matching reference accent patterns to generate an appropriate rhythm accompaniment for the musical performance, as further discussed below. In certain embodiments, the algorithmic analysis of a musical performance can be performed by musical performance block 150 of
At 230, method 200 continues with receiving and analyzing input data that can include one or more automatically selected or user selected parameters (e.g., performance parameters) to influence the rhythmic accompaniment. This can be generally referred to as processing input data. Some definable parameters can include a volume, rhythm complexity, instrument type (e.g., drum kit type), genre type (e.g., musical styles including rock, jazz, fusion, R&B, alternative, folk, etc.), swing, focus (e.g., emphasis on kick, snare, or hi-hat, etc.), and more. In some cases, each definable parameter can be configured in a default setting, or can be controlled by preset values, as would be appreciated by one of ordinary skill in the art. In some embodiments, input data and any interface thereof (e.g., GUI, touch sensor interface, etc.) is controlled and operated by user input block 130 of
At 240, method 200 includes analyzing arrangement data to determine the basic architectural elements of song, such as verse, chorus, bridge, or the like. This can be useful when generating an accompaniment for different portions of a particular song. For example, an accompaniment may tend to be livelier or showcase a “hook” during a chorus section (e.g., louder, more complex, etc.), rather than during an intro section. Thus, constantly changing song sections can lead to a continuously changing rhythmic accompaniment defined by the particular song section type, as well as the selected genre, existing tracks, player character attributes, user guided performance parameters, and the like. In some embodiments, arrangement data is not required or considered when creating a musical accompaniment and can be omitted from the accompaniment generation process. In some implementations, the arrangement analysis is performed by musical arrangement block 140 of
At 250, method 200 includes generating a musical accompaniment using the processed performance data (e.g., selected musical elements from the database), the selected musical style, and the selected one or more musical performance parameters, where the musical accompaniment includes a plurality of musical elements (e.g., notes, chords, etc.) configured in a predetermined sequence (e.g., along a musical bar). The selected combination of musical elements can be algorithmically based, probability and/or statistically based, rule based, or the like. It should be noted that any suitable method of filtration and any combination thereof can be used. In some embodiments, the arrangement analysis is performed by the generative MIDI musical performance block 170 of
It should be appreciated that the specific steps illustrated in
Input Data
As described above, a rhythmic accompaniment can be based on a musical performance (e.g., on track 1). Alternatively, a rhythmic accompaniment can be based on multiple tracks (e.g., guitar track and bass track). For example, a rhythmic accompaniment may be based on an accent pattern of the guitar track and later switch to an accent pattern of the bass track. In some cases, the rhythmic accompaniment may be based on a combination of accent pattern elements from both tracks.
Groove templates can be selected to change certain musical characteristics of a rhythmic accompaniment. In some embodiments, groove templates are related to micro-timing and micro-dynamic changes. To illustrate groove template implementation, the process typically begins with receiving musical data. The musical data typically includes reference timing data and a succession of musical notes arranged with respect to the reference timing data. For example, this can include an arrangement of musical notes (e.g., MIDI notes) along a musical bar. The musical bar includes reference timing data such as a tempo, a timing of individual notes, etc., as would be known by one of ordinary skill in the art. A groove template can then be selected (e.g., musical style) and the arrangement of musical notes is then altered based on the selected musical style. The manner in which the notes are altered include positive or negative note position shifts from an initial position, additional notes for embellishment, and more, as described below.
In this particular eighth note shuffle template, only positive shifts are applied to the notes. Furthermore, offset line 815 is continuous with no gaps or breaks in continuity in-between, even when looped end to end in successive musical bars, with an offset value specified for every possible position in the bar. Thus, with a continuous offset, the relative position of notes (e.g., arpeggiated notes) remains intact, as shown below in
As result, common drum articulations like flams, drags, and rolls are maintained when the groove template is applied. This also applies to chords where the notes are not played at exactly the same time, like on a piano or strumming a guitar (i.e., arpeggios). In some embodiments, it is also possible to have offsets that are larger than the grid or have in-between shift values. It should be noted that groove patterns are not limited to algorithmically created patterns and could be applied to any audio or MIDI-based event patterns. In further embodiments, input block 130 may include a user interface to visually display the offset line 815 and allow user interaction to edit, manipulate, and change characteristics of offset line 815, target positions, event (e.g., note) resolution (e.g., ⅛ notes, 1/16th notes, etc.), and the like.
At 910, method 900 begins with receiving musical data including reference timing data and a succession of musical notes arranged with respect to the reference timing data. The reference timing data can include a plurality of positions forming a musical bar. In some embodiments, the succession of musical notes can be MIDI data arranged along the musical bar. At 920, system 100 receives input corresponding to a selection of a shuffle groove template. The shuffle groove template can be a selectable “personality” from a particular genre or subset thereof, as described above with respect to
At 930, system 100 determines a continuous positive offset for each position along the musical bar. The continuous positive offset can be represented by an offset line or continuous groove template defining an amount of positive shift to apply to a note or chord at each position along the bar relative to a series of predetermined target notes that define a shuffle pattern, as shown in
It should be appreciated that the specific steps illustrated in
At 1010, a musical performance is received. The musical performance can be a succession of musical notes or chords placed along a musical bar. The musical performance can be represented in any suitable format, including, but not limited to, MIDI sequences.
At 1020, method 1000 continues with quantizing a musical performance, according to an embodiment of the invention. In digital music processing technology, quantization is the process of transforming performed musical notes, which may have some imprecision due to expressive performance, to an underlying musical representation that eliminates this imprecision. The process can result in notes being set on beats and on exact fractions of beats. Thus, a sloppy or imprecise performance can be “corrected” by quantizing the notes and moving them to certain positions along the musical bar that make the performance sound “tighter” or more uniform in its precision. The process of quantization is well known and its application would be known and appreciated by one of ordinary skill in the art.
At 1030, a selection for a first groove template is received and applied to the musical performance, according to an embodiment of the invention. In some embodiments, the first groove template can include micro-timing changes to the musical performance such that certain musical elements fluctuate behind the beat. For example, a quantized kick-and-snare pattern may include snare notes placed precisely on the beat. In one aspect, the first groove template can move the snare notes to varying locations immediately after its quantized location to simulate a “looser” or more human performance. In another embodiment, the first groove template may cause both kick and snare notes to fluctuate before and after the beat (i.e., their quantized starting points) to also simulate a more human sounding performance.
At 1040, a selection for a second groove template is received and applied to the musical performance, according to an embodiment of the invention. In one embodiment, the second groove template can include changes in micro-dynamics to embellish the musical performance. For example, a particular groove template may incorporate additional snare notes in the form of double sticks, flams, and ghost notes throughout the performance. It should be noted that the different groove templates are independent of one another and the application of one groove template may not necessarily affect the placement or alteration of notes incorporated by another groove template. In this case, the musical performance was first quantized to align the notes of the musical performance into an exacting arrangement of notes. The first groove template added micro-timing changes to add an inexact or more realistic sounding element to the musical performance. Adding micro-dynamics (e.g., ghost notes) will not necessarily change the location of any of the existing notes in the musical performance, but merely add notes. However, if micro-dynamics were added to the musical performance first, followed by micro-timing changes, the placements of the added embellishments may be affected since the embellishments may be subject to micro-timing displacements.
At 1050, a selection for a shuffle groove template is received and applied to the musical performance, according to an embodiment of the invention. As described above with respect to
It should be appreciated that the specific steps illustrated in
Arrangement Data
Performance Data
Performance data can be used as an input to generate a rhythmic accompaniment. One advantage of the present invention is the ability to receive a musical performance in a variety of formats, break it down to its elemental rhythmic components (i.e., accent pattern), and create a rhythmic accompaniment based on those elemental components, such that the rhythmic accompaniment sounds particularly well-matched as if it was created specifically for the particular musical performance. The musical performance can be a transient waveform (e.g., analog waveform), a MIDI sequence, or other format, as would be appreciated by one of ordinary skill in the art with the benefit of this disclosure.
The output of instrument 1210 is coupled to preamp 1215 for amplification. A preamplifier (preamp) is an electronic amplifier that prepares a small electrical signal for further amplification or processing. It can be used to boost signal strength to higher levels without significantly degrading the signal-to-noise ratio (SNR). Some electrical audio signals may not require pre-amplification and thus a preamp stage 1215 is not required. The audio waveform 1220 is an analog waveform depicting a snapshot of the magnitude of the audio signal with respect to time. Audio waveforms 1220 can take a variety of shapes, patterns, and characteristics based on the type of signal detected. The various types of audio waveforms and their pertinent characteristics (e.g., frequency, amplitude, phase, etc.) would be understood by those of ordinary skill in the art.
Audio waveform 1220 is coupled to the processing and analysis block 1230. In certain embodiments, the processing and analysis block 1230 performs transient detection with digital signal processing to determine a basic accent pattern to base the rhythmic accompaniment on. In some embodiments, the signal processing can be performed by performance block 150 of system 100. Any suitable system block, processor, or the like, can be used to perform the signal processing described herein.
Referring to
Database 1400 depicts ten different 4-bar reference accent patterns labeled a-j, according to an embodiment of the invention. As described above, the accent pattern determined from the musical data (i.e., musical performance) is compared to the reference accent patterns to find the closest match. Using the accent pattern 1310 determined from
MIDI signal 1520 is coupled to the processing and analysis block 1530. In certain embodiments, the processing and analysis block 1530 determines an accent pattern of MIDI signal 1520. In some embodiments, the accent pattern analysis is performed by musical performance block 150 of system 100. Any suitable system block, processor, or the like, can be used to determine the accent pattern of MIDI signal 1520.
Referring to
Database 1700 depicts ten different 4-bar reference accent patterns labeled a-j, according to an embodiment of the invention. As described above, the accent pattern determined from the musical data (i.e., musical performance) is compared to the reference accent patterns to find the closest match. Using the accent pattern 1610 determined from
A percussion based rhythmic accompaniment 1850 can be generated based on the selected reference accent pattern 1810. Rhythmic accompaniment 1850 includes a bass drum track 1860, a snare track 1870, and hi-hat track 1880, and a cymbal track 1890. In this particular arrangement, the bass drum and snare tracks are configured to track reference accent pattern 1810 with bass and/or snare notes on the first, third, and fourth beats, as shown in pattern 1820. Alternatively, the resulting accompaniment may not match the reference accent pattern and, in fact, may compliment or contrast the particular accent pattern of the musical performance. For example, a musical performance such as a bass line may be a complex accent pattern that a user may want in the forefront of a performance. The rhythmic accompaniment can be configured to highlight the intricacies of the bass line by creating a simple percussive accompaniment that does not detract from the bass performance. For example, the kick, snare, or crash cymbals can be configured to avoid certain notes of an accent pattern and maintain a subtle percussive backdrop. There are a myriad of ways that accent patterns can be used to create rhythmic accompaniments and playing accent patterns with a kick and snare combination is only one of many effective and musically pleasing methods. Although one particular accompaniment 1850 is shown, any number of styles, configurations, and arrangements of rhythmic accompaniments can be generated from a single reference pattern. In addition to a reference accent pattern, user inputs (e.g., groove templates), arrangement data, or other relevant data can be used to shape or influence the resulting rhythmic accompaniment. In some embodiments, depending on the complexity (e.g., see
At 1910, method 1900 begins with receiving musical data, according to an embodiment of the invention. The musical data can be an analog or digitally based musical performance. Analog-based musical data typically includes an audio waveform featuring a number of signal characteristics including audio peaks, patterns, frequency characteristics, phase characteristics, timing characteristics (e.g., tempo), and the like, and may include any suitable instruments including acoustic instruments, electric instruments, or any musical tool that provides an electronic representation (e.g., audio waveform) of a musical performance. Digital data can include any suitable MIDI-based instrument or device configured to generate MIDI patterns. In some embodiments, the musical performance block 150 of system 100 receives the musical data.
At 1920, a succession of accentuated events is identified in the musical data, according to an embodiment of the invention. In certain aspects, musical data can be analyzed to identify accentuated events and non-accentuated events. Accentuated events can be determined for analog-based musical data (e.g., waveforms) by analog or digital signal processing by analyzing its signal characteristics (e.g., audio peaks, patterns, frequency/phase characteristics, tempo, etc.). Accent patterns can be determine for digitally-based musical data (e.g., MIDI data) by analyzing the velocity of MIDI note events, note pitch, note placement or position, note duration, chord progressions, etc., as would be appreciated by one of ordinary skill in the art with the benefit of this disclosure. In some embodiments, the musical performance block 150 of system 100 can identify a succession of accentuated events in the musical data.
At 1930, the succession of accentuated events is analyzed and an accent pattern is determined, according to an embodiment of the invention. As previously described, the accent pattern is a fundamental beat and can be used to create a rhythmic accompaniment. At 1940, the accent pattern is compared to one or more accent reference patterns to find a match or substantially matching pattern. Matching can be based on note placement comparison, algorithmic analysis, probability and statistical analysis, rules or policy based selections, or any suitable method and any combination thereof. In certain embodiments, accent reference patterns can be stored in a database (e.g., accents database 126 of musical elements database 120) for retrieval and analysis. At 1950, the accent pattern is matched to one or more reference accent patterns, and a matching accent reference pattern is selected (1960). At 1970, a rhythmic accompaniment is created based, in part, on the selected reference accent pattern. In some cases, the rhythmic accompaniment may include a constantly changing reference accent pattern to reflect possible user edits performed on any track(s) being followed including changes to genre, arrangements, drummer selections, user guided performance parameters (e.g., complexity, fills, etc.), and the like.
It should be appreciated that the specific steps illustrated in
At 2010, method 2000 begins with identifying a plurality of events in musical data. Events can include accents or non-accent characteristics. At 2020, each event is evaluated to determine if it is an accent. As discussed above, accent patterns can be used to identify the basic rhythmic characteristics of a musical performance (i.e., musical data), such that a suitable rhythmic accompaniment can be created that matches musical performance. This is typically a binary consideration, however accents can be further characterized into a number of categories, which may be helpful in “fine tuning” or tailoring the generated rhythmic accompaniment to the musical performance. In some cases, accents may be loud or soft (e.g., amplitude), as determined at 2030, while others may be high pitched or low pitched (e.g., frequency), as determined at 2040. For example, musical data from a musical performance may have several basic accent patterns (a 4-bar accent pattern and an 8-bar accent pattern) that significantly differ, but each could be used to generate a rhythmic accompaniment. In another example, determining an accent may be based on a prominent pitch among a series of lower or higher pitches. In some cases, the amplitude and frequency of the accents can be considered to identify the better suited accent pattern for a particular musical performance, as would be appreciated by one of ordinary skill in the art with the benefit of this disclosure. Other methods of determining accent patterns may be based on note or event characteristics including note prominence (i.e., volume, velocity, pitch, etc.), event length, tonal characteristics/color, timbre, the signal envelope of the musical performance or a part thereof, arrangement attack, or other suitable event characteristic.
It should be appreciated that the specific steps illustrated in
Filtering Rules and Modifications
As described above, pattern generation can be a modular framework with some custom made modules and script language that can filter, combine and modify patterns, based on the various input parameters described above. For example, certain patterns (e.g., accent patterns, system patterns, etc.) are sent through different modules that modify the “probability” of the selection of each pattern. In some cases, modules that modify probability may be drummer styles (see
Modules can be manually authored rules relating to the name and content of a particular pattern, or tables can be used that, for example, define how well specific pattern combinations work together either serially (relating to the previous pattern) or in parallel (e.g., relating to other parts like accents, fills, reference accent pattern, etc.). In some cases, additional to the filtering rules, certain events (e.g., notes, chords, etc.) can be added, deleted, or moved, their velocities or articulations can be changed, etc. Furthermore, some modules can define an interaction between different parts of the performance (e.g., systems reacting to accents), and apply timing and dynamics of the groove template patterns.
In certain implementations, each pattern (e.g., reference pattern) or a subset thereof in the musical elements database can be assigned a value or probability (e.g., ranging from 0 to 100). Different filters can be used to change this value and the pattern with the highest probability is more likely selected. Depending on the character and the selected variation, a number of patterns can be excluded by setting their probability to 0. Tables can also be used to decrease a probability of certain patterns based on factors including elements that are currently being played, elements played in the previous bar, or external parameters (e.g., song tempo, etc.). For example, if a fast rock pattern is currently being played, the probability of an R&B pattern being played next may be low. For the remaining patterns, their complexity can be calculated and their probabilities modified based on the current value of the complexity parameter.
In some embodiments, events can be added or removed based on filtering rules, probabilities, modules, or combinations thereof. For example, ghost notes on a snare can be added based on certain rules that may indicate that ghost notes can be added where snare events are not already placed, some ghost notes can be transformed into short rolls, or the amount of ghost notes and rolls may be determined by the chosen complexity and tempo, with fewer ghost notes and rolls at higher tempi and more ghost notes and rolls and lower tempi. In another example, snare backbeat strokes can be transformed to a flam (e.g., adding another stroke right before it) in case other parts of the patterns are muted, and a drummer would have had his second hand free. In yet another example, syncopated snare notes may be deleted in a pattern if the intensity is below a certain threshold where the snare switches to a cross stick articulation if the syncopation pattern would not be realistically playable anymore. As such, rhythmic accompaniments can include generated patterns and modifications that are based on what a real drummer would be able to do for added realism. In some situations, there may be filtering rule conflicts. For example, a certain accent pattern may be included with a particular system pattern. In situations where a drummer could not realistically play the system pattern with two hands and maintain the accents, the accent pattern can be permitted because the accent overrides the system pattern. Alternative rules may apply and a user can define musical element hierarchies and rules in any desired configuration.
Although the examples herein include snare placement and some embellishments, any kit piece (e.g., kick drum, tom, hi-hat, etc.) can be manipulated, modified, and applicable per certain rules to better simulate a realistic accompaniment. Also, these concepts also apply more broadly to rhythmic accompaniment generation across all instruments (e.g., guitar, bass, piano, etc.). For example, a pattern on the lower guitar register may be less likely to incorporate phrasing that utilizes notes on the highest frets. These rules and modifications would be understood and actionable by one of ordinary skill in the art with the benefit of this disclosure.
In further embodiments, event articulations, velocities, and kit pieces can be modified. For example, entire patterns or subsets thereof can be moved to a different kit piece. In some cases, articulations can be changes based on a selected intensity. For example, depending on the intensity, snare strokes may be changed from cross stick to normal strokes to rim shots. The velocity of events in a musical bar can be changed based on their position in the bar and the value of the selected intensity. In another example, the opening of a hi-hat (i.e., samples related to the open hi-hat) can change based on the intensity level. These are just a few of the rules and parameters that can be used filter, modify, and alter characteristics of event patterns, particular sounds (e.g., hi-hat characteristics), and the like, and many more rules and modifications would be understood and actionable by one of ordinary skill in the art with the benefit of this disclosure. In alternative embodiments, rhythmic accompaniment generation can be an iterative learning and adaptive process. For example, after frequent use, certain patterns, preferences, and settings can be analyzed by elements of system 100 to determine rhythmic accompaniments that are more likely to suit a particular user's preferences. For instance, a user may typically like more complex rhythms laden with many micro-dynamics. Subsequent rhythmic accompaniments may reflect this preference as a default setting.
System Architecture
It should be appreciated that system 2100 as shown in
In some embodiments, display subsystem 2105 can provide an interface that allows a user to interact with system 2100. The display subsystem 2105 may be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), a projection device, a touch screen, or the like. In general, use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from system 2100. For example, a software keyboard may be displayed using a flat-panel screen. In some embodiments, the display subsystem 2105 can be a touch interface, where the display provides both an interface for outputting information to a user of the device and also as an interface for receiving inputs. In other embodiments, there may be separate input and output subsystems. Through the display subsystem 2105, the user can view and interact with a GUI (Graphical User Interface) 2120 of a system 2100. In some implementations, the GUI shown can include elements from user input block 130, musical arrangement block 140, and/or musical performance block 150. In some embodiments, display subsystem 2105 can include a touch-sensitive interface (also sometimes referred to as a touch screen) that can both display information to the user and receive inputs from the user. Processing unit(s) 2110 can include one or more processors, each having one or more cores. In some embodiments, processing unit(s) 2110 can execute instructions stored in storage subsystem 2115. System 2100 can further include an audio system to play music (e.g., accompaniments, musical performances, etc.) through one or more audio speakers (not shown).
Communications system 2160 can include various hardware, firmware, and software components to enable electronic communication between multiple computing devices. Communications system 2160 or components thereof can communicate with other devices via Wi-Fi, Bluetooth, infra-red, or any other suitable communications protocol that can provide sufficiently fast and reliable data rates to support the real-time jam session functionality described herein.
Storage subsystem 2115 can include various memory units such as a system memory 2130, a read-only memory (ROM) 2140, and a non-volatile storage device 2150. The system memory can be a read-and-write memory device or a volatile read-and-write memory, such as dynamic random access memory. System memory 2130 can store some or all of the instructions and data that the processor(s) or processing unit(s) need at runtime. ROM 2140 can store static data and instructions that are used by processing unit(s) 2110 and other modules of system 2100. Non-volatile storage device 2150 can be a read-and-write capable memory device. Embodiments of the invention can use a mass-storage device (such as a magnetic or optical disk or flash memory) as a permanent storage device. Other embodiments can use a removable storage device (e.g., a floppy disk, a flash drive) as a non-volatile (e.g., permanent) storage device.
Storage subsystem 2115 can store MIDI (Musical Instrument Digital Interface) data relating to accompaniments played on virtual instruments of system 2100 in MIDI database 2134. A musical elements database 2132 can store music elements such as a library of micro-timing data, micro-dynamics data, systems data, accents data, fills, and other musical elements. Storage subsystem 115 may also store audio recording data, and general song data (e.g., with track and instrument data). For MIDI-based tracks, MIDI data may be stored. Similarly, for audio-based tracks, audio data can be stored (e.g., audio files such as .wav, .mp3, and the like). Further detail regarding system architecture and the auxiliary components thereof (e.g., input/output controllers, memory controllers, etc.) are not discussed in detail so as not to obfuscate the focus on the invention and would be understood by those of ordinary skill in the art. In certain embodiments, system 2100 can incorporate system 100 therein.
Processing unit(s) 2205 can include a single processor, which can have one or more cores, or multiple processors. In some embodiments, processing unit(s) 2205 can include a general purpose primary processor as well as one or more special purpose co-processors such as graphics processors, digital signal processors, or the like. In some embodiments, some or all processing units 2205 can be implemented using customized circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself. In other embodiments, processing unit(s) 2205 can execute instructions stored in storage subsystem 2210.
Storage subsystem 2210 can include various memory units such as a system memory, a read-only memory (ROM), and a permanent storage device. The ROM can store static data and instructions that are needed by processing unit(s) 2205 and other modules of electronic device 2200. The permanent storage device can be a read-and-write memory device. This permanent storage device can be a non-volatile memory unit that stores instructions and data even when computer system 2200 is powered down. Some embodiments of the invention can use a mass-storage device (such as a magnetic or optical disk or flash memory) as a permanent storage device. Other embodiments can use a removable storage device (e.g., a floppy disk, a flash drive) as a permanent storage device. The system memory can be a read-and-write memory device or a volatile read-and-write memory, such as dynamic random access memory. The system memory can store some or all of the instructions and data that the processor needs at runtime.
Storage subsystem 2210 can include any combination of computer readable storage media including semiconductor memory chips of various types (DRAM, SRAM, SDRAM, flash memory, programmable read-only memory) and so on. Magnetic and/or optical disks can also be used. In some embodiments, storage subsystem 2210 can include removable storage media that can be readable and/or writeable; examples of such media include compact disc (CD), read-only digital versatile disc (e.g., DVD-ROM, dual-layer DVD-ROM), read-only and recordable Blue-Ray® disks, ultra density optical disks, flash memory cards (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic “floppy” disks, and so on. The computer readable storage media do not include carrier waves and transitory electronic signals passing wirelessly or over wired connections.
In some embodiments, storage subsystem 2210 can store one or more software programs to be executed by processing unit(s) 2205, such as a user interface 2215. As mentioned, “software” can refer to sequences of instructions that, when executed by processing unit(s) 2205 cause computer system 2200 to perform various operations, thus defining one or more specific machine implementations that execute and perform the operations of the software programs. The instructions can be stored as firmware residing in read-only memory and/or applications stored in magnetic storage that can be read into memory for processing by a processor. Software can be implemented as a single program or a collection of separate programs or program modules that interact as desired. Programs and/or data can be stored in non-volatile storage and copied in whole or in part to volatile working memory during program execution. From storage subsystem 2210, processing unit(s) 2205 can retrieve program instructions to execute and data to process in order to execute various operations described herein.
A user interface can be provided by one or more user input devices 2220, display device 2225, and/or and one or more other user output devices (not shown). Input devices 2220 can include any device via which a user can provide signals to computing system 2200; computing system 2200 can interpret the signals as indicative of particular user requests or information. In various embodiments, input devices 2220 can include any or all of a keyboard touch pad, touch screen, mouse or other pointing device, scroll wheel, click wheel, dial, button, switch, keypad, microphone, and so on.
Output devices 2225 can display images generated by electronic device 2200. Output devices 2225 can include various image generation technologies, e.g., a cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED) including organic light-emitting diodes (OLED), projection system, or the like, together with supporting electronics (e.g., digital-to-analog or analog-to-digital converters, signal processors, or the like), indicator lights, speakers, tactile “display” devices, headphone jacks, printers, and so on. Some embodiments can include a device such as a touchscreen that function as both input and output device.
In some embodiments, output device 2225 can provide a graphical user interface, in which visible image elements in certain areas of output device 2225 are defined as active elements or control elements that the user selects using user input devices 2220. For example, the user can manipulate a user input device to position an on-screen cursor or pointer over the control element, then click a button to indicate the selection. Alternatively, the user can touch the control element (e.g., with a finger or stylus) on a touchscreen device. In some embodiments, the user can speak one or more words associated with the control element (the word can be, e.g., a label on the element or a function associated with the element). In some embodiments, user gestures on a touch-sensitive device can be recognized and interpreted as input commands; these gestures can be but need not be associated with any particular array in output device 2225. Other user interfaces can also be implemented.
Network interface 2235 can provide voice and/or data communication capability for electronic device 2200. In some embodiments, network interface 2235 can include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology such as 3G, 4G or EDGE, WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), GPS receiver components, and/or other components. In some embodiments, network interface 2235 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface. Network interface 2235 can be implemented using a combination of hardware (e.g., antennas, modulators/demodulators, encoders/decoders, and other analog and/or digital signal processing circuits) and software components.
Bus 2240 can include various system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic device 2200. For example, bus 2240 can communicatively couple processing unit(s) 2205 with storage subsystem 2210. Bus 2240 also connects to input devices 2220 and display 2225. Bus 2240 also couples electronic device 2200 to a network through network interface 2235. In this manner, electronic device 2200 can be a part of a network of multiple computer systems (e.g., a local area network (LAN), a wide area network (WAN), an Intranet, or a network of networks, such as the Internet. Any or all components of electronic device 2200 can be used in conjunction with the invention.
Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a computer readable storage medium. Many of the features described in this specification can be implemented as processes that are specified as a set of program instructions encoded on a computer readable storage medium. When these program instructions are executed by one or more processing units, they cause the processing unit(s) to perform various operation indicated in the program instructions. Examples of program instructions or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.
It will be appreciated that computer system 2200 is illustrative and that variations and modifications are possible. Computer system 2200 can have other capabilities not specifically described here (e.g., mobile phone, global positioning system (GPS), power management, one or more cameras, various connection ports for connecting external devices or accessories, etc.). Further, while computer system 2200 is described with reference to particular blocks, it is to be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. Further, the blocks need not correspond to physically distinct components. Blocks can be configured to perform various operations, e.g., by programming a processor or providing appropriate control circuitry, and various blocks might or might not be reconfigurable depending on how the initial configuration is obtained. Embodiments of the present invention can be realized in a variety of apparatus including electronic devices implemented using any combination of circuitry and software.
While the invention has been described with respect to specific embodiments, one skilled in the art will recognize that numerous modifications are possible including the displayed representation of the user interface 130 and the configuration of the various elements therein, such as their position, organization, and function, filtering rules and analysis, etc. Thus, although the invention has been described with respect to specific embodiments, it will be appreciated that the invention is intended to cover all modifications and equivalents within the scope of the following claims. In some embodiments, system 100 can be implemented wholly or in part by system 2200.
System 100 depicted in
Network 1306 may include one or more communication networks, which could be the Internet, a local area network (LAN), a wide area network (WAN), a wireless or wired network, an Intranet, a private network, a public network, a switched network, or any other suitable communication network. Network 2306 may include many interconnected systems and communication links including but not restricted to hardwire links, optical links, satellite or other wireless communications links, wave propagation links, or any other ways for communication of information. Various communication protocols may be used to facilitate communication of information via network 2306, including but not restricted to TCP/IP, HTTP protocols, extensible markup language (XML), wireless application protocol (WAP), protocols under development by industry standard organizations, vendor-specific protocols, customized protocols, and others. In the configuration depicted in
In the configuration depicted in
It should be appreciated that various different distributed system configurations are possible, which may be different from distributed system 2300 depicted in
While the invention has been described with respect to specific embodiments, one skilled in the art will recognize that numerous modifications are possible. Thus, although the invention has been described with respect to specific embodiments, it will be appreciated that the invention is intended to cover all modifications and equivalents within the scope of the following claims.
The above disclosure provides examples and aspects relating to various embodiments within the scope of claims, appended hereto or later added in accordance with applicable law. However, these examples are not limiting as to how any disclosed aspect may be implemented,
All the features disclosed in this specification (including any accompanying claims, abstract, and drawings) can be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.
Any element in a claim that does not explicitly state “means for” performing a specified function, or “step for” performing a specific function, is not to be interpreted as a “means” or “step” clause as specified in 35 U.S.C. §112, sixth paragraph. In particular, the use of “step of” in the claims herein is not intended to invoke the provisions of 35 U.S.C. §112, sixth paragraph.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5654517 | Miyamoto | Aug 1997 | A |
| 5714705 | Kishimoto | Feb 1998 | A |
| 5920025 | Itoh | Jul 1999 | A |
| 5962802 | Iizuka | Oct 1999 | A |
| 6051770 | Milburn | Apr 2000 | A |
| 6051771 | Iizuka | Apr 2000 | A |
| 6307141 | Laroche | Oct 2001 | B1 |
| 6703549 | Nishimoto | Mar 2004 | B1 |
| 7323630 | Tsuge | Jan 2008 | B2 |
| 7525036 | Shotwell | Apr 2009 | B2 |
| 20120160079 | Little | Jun 2012 | A1 |
| 20120174735 | Little | Jul 2012 | A1 |
| 20150013527 | Buskies | Jan 2015 | A1 |
| 20150013533 | Buskies | Jan 2015 | A1 |
| 20150221297 | Buskies | Aug 2015 | A1 |
| Entry |
|---|
| International Search Report and Written Opinion for International PCT Application No. PCT/US2014/042682, mailed Sep. 24, 2014, 10 pages. |
| “Feel-Good Factor, Giving Your MIDI Tracks a Live Fee: Part 1”, SOS, Jul. 1, 2011; http:jjwww.soundonsound.comjsosjjul01/articlesjgrove1.asp, downloaded on Sep. 12, 2014, 5 pages. |
| “Feel-Good Factor, Giving Your MIDI Tracks a Live Fee: Part 2”, SOS, Aug. 1, 2011; http://www.soundonsound.comjsosjaug01/articlesjgroove2.asp, downloaded on Sep. 12, 2014, 5 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20150013528 A1 | Jan 2015 | US |
