Patent Application
20230186884
This invention relates generally to the field of computer-generated music, and more specifically to a new and useful computer-implemented system and method for scalable similarity-based generation of compatible music mixes.
Creation of music mixes encompasses the creation and combining of music tracks. It is a creative endeavor often associated with DJs and Electronic Dance Music (EDM). Recently, music mix creation has been facilitated by online collections of royalty-free sounds in digital format. One example of such a collection is the sound sample library available from SPLICE.COM of Santa Monica, Calif. and New York, N.Y. Such libraries may contain thousands or even millions of sound samples. The size of such a library presents the technical challenge of retrieving sounds that match criteria in a computationally efficient manner. For the purpose of music mix creation, there is a need for computer-based tools that streamline the search, discovery, and retrieval of musically compatible sounds. This invention provides such a new and useful system and method.
The following description of the preferred embodiments is not intended to limit the disclosure to these preferred embodiments, but rather to enable any person skilled in the art to make and use this disclosure.
The compatibility of music clips (e.g., mixes, stems, or individual tracks) that make up a music mix can be vitally important to the perceptual quality of the mix. A perceptually high-quality mix is a highly consonant and pleasant-sounding mix that reflects, implements, or fulfills the principles of musical harmony. Unfortunately, one may not know beforehand which combination of music clips will produce a perceptually high-quality mix. So, the ability to experiment with different combinations of music clips is useful. Along with the desire for experimentation, there is a desire to produce perceptually high-quality mixes.
In some variations, the computer-implemented techniques disclosed herein assist users in easily discovering combinations of music clips that provide perceptually high-quality musical mixes in the context of music mix creation. The techniques balance the need to experiment with different music clips with the need to efficiently discover perceptually high-quality clips, using a harmonic compatibility approach. The approach includes use of a pitch interval space for computing harmonic compatibility between music clips as distances or similarities between the music clips in the pitch interval space. The distance or similarity between music clips in the pitch interval space reflects the degree to which music clips are harmonically compatible. Given a candidate music clip to add to a partial mix of one or more music clips, the distance or similarity in the pitch interval space between the candidate music clip and the partial mix can be used to determine if the candidate music clip is harmonically compatible with the partial mix. In some variations, an indexable feature space is provided that is both beats-per-minute (BPM)-agnostic and music key-agnostic. That is, harmonic compatibility between clips can be determined even if the clips are at different BPMs or in different keys. Further, an index of music clips can scale to millions of music clips and be used for low latency identification of music clips that are harmonically compatible with a given music clip (e.g., in less than ten milliseconds).
As an example of the problem addressed by the techniques herein in some variations, consider a partial mix that combines music clips from a library of music clips provided by a music mixing computing system (e.g., a cloud-based music mixing computing system). Next, a user of the system may wish to add an additional music clip (e.g., a bassline stem) from the library to the partial mix. The music mixing system may allow users to browse, search for, and access music clips in the library. Such a library can be large (e.g., thousands or millions of music clips). It is very difficult for a user to discover a music clip that is compatible with a partial mix without the help and guidance of the music mixing system. Thus, in creating a complete mix, users may easily become frustrated or overwhelmed attempting to find a compatible music clip. As such, streamlining the process of music mix creation by assisting users in the process of finding a compatible music clip from a large collection of music clips is very important. The appropriate assistance is not only important for the music mixing system operators, which may get more users using the system, more users creating accounts, or more users willing to upgrade accounts, as example benefits, but also to users themselves who will be able to use the music mixing system to streamline their music mix creation process. If the system suggests a music clip that is only rhythmically compatible (e.g., according to onset density) with the partial mix, the resulting mix may be perceived as low-quality. There may be another clip in the library that is more compatible with the partial mix resulting in a perceptually higher-quality mix. The techniques provide for an expanded range of musical attributes when determining music clip compatibility including harmonic attributes. Further, the techniques can be used with more than just harmonic attributes. They can be used with any type of musical attributes, such as rhythmic, spectral, and timbral attributes.
In some variations, the techniques use a harmonic compatibility approach in which the harmonic content of music clips is represented as multi-dimensional vectors in the pitch interval space (or “pitch interval space vectors”). Each pitch interval space vector may have a unique location in the pitch interval space that represents a corresponding unique harmonic configuration. The distances or similarities between those pitch interval space vectors in the pitch interval space can be computed to determine harmonic compatibility between music clips. Further, an element-wise linear combination of pitch interval space vectors (e.g., by averaging or weighted averaging using the vectors' energies) can be used for determining whether a candidate music clip is harmonically compatible with a partial mix. In particular, the distance or similarity in the pitch interval space between (a) the element-wise linear combination of the pitch interval space vectors for the music clips that make up the partial mix and (b) the pitch interval space vector for the candidate music clip reflects the degree to which the candidate music clip is harmonically compatible with the partial mix. Due to their ability to be represented as vectors by a computer, computing an element-wise linear combination of vectors and computing distances or similarities between vectors are relatively efficient computer operations. Thus, the pitch interval space vectors allow the music mixing system to efficiently evaluate large collections of candidate music clips for harmonic compatibility.
The techniques proceed in some variations by receiving a request to suggest a music clip that is musically compatible with a partial mix of previously selected music clips. For example, the previously selected music clip might include a vocal clip and a piano clip. In response to receiving the request, the techniques in some variations linearly combine respective pitch interval space vectors for the previously selected music clips of the partial mix into a pitch interval space vector representing harmonic attributes of the partial mix. The techniques compute distances or similarities in the pitch interval space between the pitch interval space vector for the partial mix and pitch interval space vectors representing harmonic attributes of the candidate music clips. The techniques in some variations respond to the request with a suggestion of a particular candidate music clip that is musically compatible with the partial mix based on the distance in the pitch interval space between the pitch interval space vector representing the partial mix and the pitch interval space vector representing harmonic attributes of the music clip. Returning to the example earlier in this paragraph, the particular music clip suggested might be a bassline music clip that is harmonically compatible with the mix of the vocal and piano clips. If the suggestion is adopted, then a new partial mix is formed. This process may be repeated each time with a new partial music mix that adds or replaces a music clip from the previous partial music mix until a satisfactory music mix is discovered.
In addition to harmonic attributes, the techniques herein in some variations rely on additional musical attributes of a partial mix and candidate music clips such as rhythmic, spectral, or timbral attributes when determining music compatibility between the partial mix and a candidate music clip to ensure that compatibility decisions are not made based only on harmonic qualities of the partial mix and the candidate music clip.
The computing environment of
As used herein, unless the context clearly indicates otherwise, the term “request” refers to a set of one or more calls, invocations, or messages made, sent, or received via an API and the term “response” refers to a set of one or more calls, invocations, or messages made, sent, or received via an API that is caused by a corresponding request. Further, reference herein to a request or response received from an entity (e.g., a device) does not require that the request or response be received directly from the entity and the request or request may traverse one or more intermediate entities before arriving at a target entity. Likewise, reference to a request or response sent to an entity (e.g., a device) does not require that the request or response be sent directly to the entity and the request or response may traverse one or more intermediate entities on its way from a source entity.
While in some variations such as depicted in
The music mix creation process proceeds at Step 1 where electronic device 120 provides a selection of a stack template. A “stack” refers to a music clip generated according to the techniques disclosed herein and may be composed of a set of multiple layered, synchronized, and musically compatible music clips. Thus, a stack is a music clip that may be composed of other stacks or music clips.
In some variations, each layer of a stack encompasses one or more of the music clips of which the stack is composed. For example, a layer of a stack may encompass a drums music clip, a bass music clip, a guitar music clip, a keys music clip, a strings music clip, a vocals music clip, a chords music clip, a leads music clip, a pads music clip, a brass and woodwinds music clip, a synth music clip, a sound effects clip, etc.
In some variations, the selected stack template may be one of a set of predefined stack templates that are available for selection by user 110 using a music mixing computer program or software application at personal electronic device 120. For example, the set of predefined stack templates may be presented in a graphical user interface at personal electronic device 120 for selection of one by user 110. The music mixing application may be a so-called mobile application that is designed to run on personal electronic device 120 and that can be downloaded and installed using an application marketplace (“app store”) such as, for example, the GOOGLE PLAY STORE, the APPLE APP STORE, or the MICROSOFT STORE.
In some variations, personal electronic device 120 is a portable electronic device such as a smartphone, a tablet electronic device, or the like. However, personal electronic device 120 is another type of electronic device in some variations. For example, personal electronic device 120 may be a personal computer or a digital audio workstation (DAW). While in some variations the music mixing application is a mobile application, the music mixing application is a web browser-based application or a thick or thin client application in other variations. No type of electronic device for personal electronic device 120 is required and no type of application for the music mixing application is required. User 110 and personal electronic device 120 are generally representative of what may be possibly many different users and possibly many different personal electronic devices with possibly different types of music mixing applications installed that may be concurrently interfacing with service 100 at any given time.
In some variations, the selection of the stack template received at Step 1 indicates a musical genre, style, category, class, group, family, species, or the like. For example, the selected stack template might be for one of dance, acoustic, random, ambient/drumless, lo-fi and hip hop, trap/rap, etc. In response to front end 102 receiving the selection of the stack template, the selection is provided to back end 104 for further processing. In some variations, back end 104 determines a set of one or more predefined layers that make up the selected stack template. A “layer” refers to a distinct musical part of a stack that a user can configure using techniques disclosed herein. The set of predefined layers may vary among different stack templates that are available for selection. For example, a dance stack template might include a drums layer, a keys layer, a pads layer, a bass, layer, and a synth layer; an acoustic stack template might include a drums layer, a pads layer, a bass layer, a leads layer, and a vocals layer; a random stack template might include a keys layer, a bass layer, a strings layer, and a drums layer; an ambient/drumless stack template might include a pads layer, a leads layer, a bass layer, a vocals layer, and a sound effects layer; a lo-fi and hip hop layer might include a drums layer, a bass layer, a pads layer, and a vocals layer; and a trap/rap layer might include a drums layer, a keys layer, a pads layer, a bass layer, and a synth layer. While in the above examples each stack template is composed of multiple predefined layers, a stack may be composed of just a single predefined layer. Further, using techniques disclosed herein, a user may add additional layers to and remove layers from a selected stack template. Thus, a selected stack template may be viewed as a starting point for the user to begin the music mix creation process so that the user does not need to start from scratch but instead can start from a predetermined stack/mix which the user can then adjust as needed using the techniques disclosed herein.
In some variations, front end 102 provides access to an application programming interface (API) of service 100 to the music mixing application of personal electronic device 120 via an API endpoint of front end 102. The API endpoint may be used by personal electronic device 120 and other electronic devices to make requests over intermediate network(s) 130 of the services and resources of music mixing service 100. Such services and resources may include the ability to receive and respond to requests of Step 1, Step 3, and Step 5 depicted in
In some variations, the API of service 100 that is accessible via the API endpoint of front end 102 conforms to a particular communication style. Possible styles that may be used are the Representational State Transfer (REST) style, the Web Sockets style, or the like. The REST style is a stateless communication protocol that uses a request-response communication model. As such, a new network connection (e.g., a Transmission Control Protocol (TCP) connection) may be established for each HTTP or HTTPS request. The Web Sockets style is a stateful communication protocol and allows full duplex communication over a single network connection (e.g., a single TCP connection). Because of the overhead involved in establishing a network connection, a REST communication style is typically slower than a Web Sockets style in terms of the transmission of network messages. However, the stateless nature of REST reduces memory and buffering requirements for transmitted data. Whether the REST style or the Web Socket style is used by front end 102, data received by and send from front end 102 such as data sent between device 120 and front end 102 may be encapsulated or formatted according to a data interchange format such as JavaScriptObject Notation (JSON), eXtensible Markup Language (XML), or the like.
In some variations, music mixing service 100 itself including front end 102, back end 104, clip-wise pitch interval space vector index 106, and sound library 108 generally adheres to or leverages a “cloud” computing model. A cloud computing model enables ubiquitous, convenient, on-demand network access to a shared pool of configurable resources such as networks, servers, storage applications, and services. A provider of music mixing service 100 may provide its music mixing capabilities to users according to a variety of different cloud computing models including, for example, a Software-as-a-Service (“SaaS”) model. With SaaS, the music mixing capabilities are provided to a user using the music mixing service provider's software applications running on infrastructure provided by a cloud infrastructure provider where the music mixing service provider is a customer of the cloud infrastructure provider. The applications may be accessible from various client devices through either a thin client interface such as a web browser, or an application programming interface. The infrastructure includes the hardware resources such as server, storage, and network components and software deployed on the hardware infrastructure that are necessary to support the music mixing capabilities being provided. Typically, under the SaaS model, the music mixing service provider would not manage or control the underlying infrastructure including network, servers, operating systems, storage, or individual application capabilities, except for limited customer-specific application configuration settings.
Front end 102 and back end 104 generally represent a separation of concerns between a presentation layer of music mixing service 100 and a data access/processing layer of music mixing service 100. In some variations, back end 104 implements the application programming interface (API) that is accessible by electronic device 120 via front end 102.
Sound library 108 encompasses a database of music clips. In some variations, a music clip is stored in sound library 108 as a digital audio signal source such as a computer file system file or other data container (e.g., a computer database record) containing digital audio signal data. For example, the digital audio signal data contained by a digital audio signal source may represent a recording of a musical or other auditory performance by a human or represent machine-generated music or sound. The digital audio signal data of a digital audio signal source may be stored uncompressed, compressed in a lossless encoding format, or compressed in a lossy encoding formatted. Non-limiting examples of possible digital audio data formats for the digital audio signal data of a digital audio signal source indicated by their known file extensions include: .AAC, .AIFF, .AU, .DVF, .M4A, .M4P, .MP3, .OGG, .RAW, .WAV, and .WMA.
In some variations, the digital audio signal data of a music clip in sound library 108 represents a loop. A loop is a repeatable section of audio material and may be created using different music creation technologies including, but not limited to, microphones, turntables, digital samplers, looper pedals, synthesizers, sequencers, drum machines, tape machines, delay units, programming using computer music software, etc. A loop often encompasses a rhythmic pattern or a note or a chord sequence or progression that corresponds to musical bars (e.g., one, two, four, or eight bars). Typically, a loop may be repeated indefinitely and yet retain an audible sense of musical continuity. In some variations, the digital audio signal data of a music clip in sound library 108 represents—in the form of a loop—a track, a stem, or a mix. The track, stem, or mix may be mono or stereo.
In some variations, library 108 contains hundreds, thousands, millions, or more music clips. For example, library 108 may be a collection of user, computer, or machine generated or recorded sounds such as, for example, a music sample library provided by a cloud-based music creation and collaboration platform such as, for example, the sound library available from SPLICE.COM of Santa Monica, Calif. and New York, N.Y.
While it is possible to apply the techniques to library 108 of heterogeneous music clips without distinguishing between different sound content categories of music clips in library 108, it can be beneficial to group music clips into sound content categories. This can be beneficial to increase the efficiency of discovering a compatible music clip in a particular sound content category as a fewer number of candidate music clips in the library (e.g., only those belonging to the sound content category) need to be considered. This can also be beneficial to increase the accuracy of suggesting a compatible music clip as a music clip in the library that does not belong to a desired sound content category will not be suggested as compatible. For example, consider library 108 where it is divided into sound content categories based on musical instrument families. Such sound content categories might include vocals, strings, keyboard, woodwind, brass, and percussion. In this case, a suggestion of a compatible music clip can be made within one of these sound content categories. For such a suggestion, only music clips in library 108 belonging to the sound content category need be considered for the suggestion and music clips not in the particular sound content category do not need to be considered for the suggestion, thereby easing the computational burden to make the suggestion because fewer music clips from library 108 need be considered. Further, if the user desires a suggestion of a compatible music clip in a particular sound content category, then by limiting the suggestion to only a music clip in the sound content category it can be ensured that the suggestion is of a music clip in the desired sound content category
In some variations, the different sound content categories into which audio tracks of library 108 are grouped may reflect categorical differences in the statistical distributions of the underlying digital audio signals in the different sound content categories. In this way, a sound content category may correspond to a class or type of statistical distribution. A top-level sound content category may be further subdivided based on instrument, instrument type, genre, mood, or other sound attributes suitable to the requirements of the implementation at hand, to form a hierarchy of sound content categories. As an example, a hierarchy of sound content categories might include the following top-level sound content categories: loops and one-shots. Then, each of those top-level sound content categories might include, in a second level of the hierarchy, a drum category and an instrument category. Each instrument category might include vocals and musical instruments other than drums. Each instrument category can be further subdivided in a third level of the hierarchy into musical instrument families (e.g., into vocals, strings, keyboard, woodwind, and brass sound content categories).
The above is just one non-limiting example of a possible sound content category hierarchy by which library 108 of music clips can be categorized. Other categories are possible, and the techniques are not limited to any category or set of categories or hierarchy of categories. Further, while sound content categories may be heuristically or empirically selected according to the requirements of the implementation at hand including based on the expected or discovered different categories of sounds in library 108, sound content categories may be learned or computed according to a computer-implemented unsupervised clustering algorithm (e.g., an exclusive, overlapping, hierarchical, or probabilistic clustering algorithm).
For example, music clips in library 108 may be grouped (clustered) into different clusters corresponding to sound content categories based on similarities between one or more attributes extracted or detected from the digital audio signal data of the music clips. Such sound attributes on which the music clips may be clustered might include, for example, one or more of: statistical distribution of signal amplitude over time, zero-crossing rate, spectral centroid, the spectral density of the signal data, the spectral bandwidth of the signal data, the spectral flatness of the signal data, or harmonic attributes of the signal data. When clustering, music clips that are more similar with respect to one or more of these sound attributes should be more likely to be clustered together in the same cluster and music clips that are less similar with respect to one or more of these sound attributes should be less likely to be clustered together in the same cluster. It should be noted that, while a music clip in the library can belong to only a single sound content category, it might belong to multiple sound content categories if, for example, an overlapping clustering algorithm is used to identify the sound content categories.
In some variations, music clips in library 108 are indexed in index 106 by the sound content categories to which they belong or to which they are assigned. By doing so, music clips in library 108 that belong to a particular sound content category can be efficiently identified using index 106. In some variations, a search for compatible music clips is constrained by using 106 to only music clips that belong to a specified or predetermined set of one or more sound content categories. For example, index 106 may be used to search for a compatible music clip where the search space (the set of candidate music clips considered) is constrained to only guitar music clips in library 108.
In some variations, clip-wise pitch interval space vector index 106 indexes music clips in library 108 by clip-wise pitch interval space vectors generated from the music clips. In some variations, a clip-wise pitch interval space vector for a music clip is generated from a set of beat-wise pitch interval space vectors generated for the music clip. A clip-wise pitch interval space vector may represent measures (e.g., two, four, six, eight, ten, twelve, sixteen, etc.) of a music clip at a number of beats per measure (e.g., one, two, four, eight, sixteen, etc.). For example, a clip-wise pitch interval space vector representing a music clip of eight bars with four beats per bar is generated from thirty-two beat-wise pitch interval space vectors. The number of dimensions of a beat-wise pitch interval space vector is the number of pitch classes (e.g., twelve) in some variations. A pitch class is a group of pitches related by octave and enharmonic equivalence. A pitch is a discrete tone with an individual frequency. For example, the number of pitch classes can be twelve where each element of a beat-wise pitch interval space vector corresponds to one of the twelve pitch interval spaces such as, for example {Element 0: Pitch Class C, 1: C♯, 2: D, 3: D♯, 4: E, 5: F, 6: F♯, 7: G, 8: G♯, 9: A, 10: A♯, 11: B}.
In some variations, the pitch interval space represents human perceptions of pitches, chords, and keys as well as music theory principles as distances. Multi-level pitch configurations are represented in the pitch interval space as twelve-dimensional vectors. In some variations, multi-level pitch configurations are represented in the pitch interval space by pitch interval space vectors T(k), calculated as the Discrete Fourier Transform (DFT) of the pitch class distribution or chroma vector input c(n) as follows:
In the above equation:
In some variations, the variable N is twelve and represents the dimension of the input chroma vector. The variable w(k) represents weights derived from empirical ratings of dyads consonance used to adjust the contribution of each dimension k of the pitch interval space. In some variations, w(k) is the set {3, 8, 11.5, 15, 14.5, 7.5} for audio inputs. In some variations, w(k) is the set {2, 11, 17, 16, 19, 7} for symbolic inputs. The variable k may range from 1 to 6 (or 0 to 5) (and need not range from 1 to 12 (or 0 to 11)), since the remaining coefficients are symmetric.
In some variations, the equation for T(k) uses c(n) which is the input chroma vector c(n) normalized by its L-1 norm to allow the representation and comparison of different hierarchical levels of tonal pitch. From the point of view of Fourier analysis, T(k) is interpreted in some variations as a sequence of six complex numbers, each corresponding to a complex conjugate. The sequence of six complex numbers can be visualized as six corresponding circles. A musical interpretation relates each Discrete Fourier Transform (DFT) component to complementary interval dyads within an octave. The musical interpretation assigned to each coefficient corresponds to the music interval that is furthest from the origin of the plane. Integers around each circle represent 0≤n≤N−1 for N−12, corresponding to the positions in the chroma vector c(n). More information on the theoretical underpinnings of the pitch interval space can be found in the paper by Gilberto Bernardes, Diogo Cocharro, Marcelo Caetano, Carlos Guedes & Matthew E. P. Davies (2016) A multi-level tonal interval space for modelling pitch relatedness and musical consonance, Journal of New Music Research, Volume 45, Issue 4, Pages 281-294.
In some variations, the pitch interval space has musical properties including perceptual proximity. That is, algebraic objective measures capture perceptual features of the pitch sets represented by pitch interval space vectors in the pitch interval space. Specifically, Euclidean and cosine distances among multi-level pitch configurations equate with the human perceptions of pitches, chords, and keys as well as tonal Western music theory principles.
In some variations, the pitch interval space also has the property of transposition invariance. That is, transposing a pitch configuration by semitones in the pitch interval space corresponds to rotations of T(k). Hence, the transposition of any pitch interval space vector results in a vector with the same magnitude or the same distance from the center. This property is an important feature of Western tonal music arising from 12 tone equal-tempered tuning in the sense it accords with Western listeners' perception of interval relations in different regions as analogous. For example, the intervals from C to G in C major and from C♯ to G♯ in C♯ major are perceived as equivalent.
In some variations, the harmonic compatibility between two music clips is measured according to a computationally efficient algebraic distance or similarity metric. The distance or similarity metric is computed using the clip-wise pitch interval space vectors representing the two music clips. In some variations, the distance or similarity metric is computed as the sum of the beat-wise pairwise cosine or Euclidean distances. Here, cosine distance refers to a complement of cosine similarity (e.g., 1−cosine similarity) and not the angular distance (e.g., arccos(cosine similarity)).
For example, consider two clip-wise pitch interval space vectors generated for two music clips each composed of the elements of k number of beat-wise pitch interval space vectors generated for the two music clips. For example, k may be thirty-two corresponding to eight bars of music at four beats per bar. In this case, each clip-wise pitch interval space vector has three hundred and eighty-four (384) elements from the thirty-two twelve element beat-wise pitch interval space vectors. In this case, the harmonic compatibility between the two music clips MC1 and MC2 may be computed as follows:
Harmonic Compatibility−1(MC1,MC2)=Σk=132d(bwV1,k,bwV2,k)
In the above equation, bwV1,k represents the beat-wise pitch interval space vector for the k-th beat of one of the clip-wise pitch interval space vectors and bwV2,k represents the beat-wise pitch interval space vector for the k-th beat of the other of the two clip-wise pitch interval space vectors. In the above equation, the function d( ) represents the algebraic distance metric such the cosine distance or the Euclidean distance applied to two beat-wise pitch interval space vectors. In some variations, each beat-wise pitch interval space vector is normalized (e.g., L2 normalized) when used to compute the algebraic distance metric. In some variations, the greater the value of Harmonic Compatibility−1(MC1, MC2), the less harmonically compatible are music clips MC1 and MC2 (the greater the distance between the music clips in the pitch interval space). And the lower the value of Harmonic Compatibility−1(MC1, MC2), the more harmonically compatible are music clips MC1 and MC2 (the shorter the distance between the music clips in the pitch interval space).
In some variations, equivalence between Euclidean and cosine distance metrics is leveraged so that only a single algebraic distance computation is needed to compute the harmonic compatibility between music clips, without requiring the summation of partial distance computations at the beat level. To do this, each beat-wise pitch interval space vector is individually normalized by its L2 norm. Then, a single algebraic distance computation is applied to the clip-wise pitch interval space vectors composed of the L2 normalized beat-wise pitch interval space vectors as follows:
Harmonic Compatibility−2(MC1,MC2)=d(cwV1,cwV2)
Here, cwV1 is the clip-wise pitch interval space vector for music clip MC1 and cwV2 is the clip-wise pitch interval space vector for music clip MC2. Each beat-wise clip interval space vector of cwV1 and each beat-wise clip interval space vector of cwV2 is normalized by its respective L2 (Euclidean) norm, making the sum of the beat-wise cosine distances equivalent to the single Euclidean distance computation at the clip level. By doing so, harmonic compatibility between music clips can be determined in a scalable manner using an approximate nearest neighbors algorithm (e.g., scaling to millions of music clips)
In some variations, generating a clip-wise pitch interval space vector for a music clip includes regular short-time interval detection and spectral analysis performed on the digital audio signal data of the music clip. In interval detection, musical beats in the music clip are identified. In some variations, up to a predetermined number of beats in the music clip are identified. For example, the predetermined number may be thirty-two representing eight bars of music at four beats per bar. However, no number of predetermined beats is required.
Various digital audio signal data processing techniques may be used to identify musical beats in a music clip audio signal. For example, a technique may identify musical note onsets in the signal data's energy or spectrum and then analyze the pattern of onsets to detect recurring patterns or quasi-periodic pulse trains. For example, a beat tracking and bar find method may be used.
In some variations, the spectral analysis of the clip-wise pitch interval space vector generation extracts chroma representations from the digital audio signal data of the music clip on the beats identified by the interval detection. In some variations, a chroma representation for a beat is a twelve-element vector (“chroma vector”) where each element corresponds to one of the twelve pitch classes of the equal-tempered chromatic scale. The value of an element in the chroma vector for the beat numerically indicates the saliency of the corresponding pitch class at the beat in the signal data. A chroma vector may be computed by applying a filter bank to a time-frequency representation of digital audio signal data. For example, the time-frequency representation may result from either a short-time Fourier transform (STFT) or a constant-Q transform (CQT), with the latter providing a finer frequency resolution in the lower frequencies.
In some variations, the beat-wise pitch interval space vectors that make up the clip-wise pitch interval space vector generated for the music clip are generated from the beat-wise chroma vectors. Specifically, a beat-wise pitch interval vector for a given beat of the music clip can be computed as the L1-normalized Discrete Fourier Transform (DFT) of the beat-wise chroma vector generated for the beat as in the equation for T(k) provided above. This may be done for each beat-wise chroma vector to generate the set of beat-wise pitch interval space vectors that make up the clip-wise pitch interval space vector for the music clip.
In some variations, an indexable feature space that is beats per minute (BPM)-agnostic for determining harmonic compatibility between clips is provided. The indexable feature space uses a flat vector representation of a music clip of shape (1, N) that normalizes the clip's duration in terms of a BPM-agnostic measure. In some variations, the BPM-agnostic measure is a predetermined number of bars and a predetermined number of beats per bar. In some variations, the flat vector representation is a BPM-agnostic clip-wise pitch interval space vector representation of the music clip.
At operation 202, a loop-able music clip is obtained. For example, the loop-able music clip can be obtained from sound library 108. The loop-able music clip has a predetermined number of bars of music and predetermined number of beats per bar. For example, the predetermined number of bars may range between two and sixteen bars and the predetermined number of beats per bar may range between two and eight. The loop-able music clip can be any type of pitch-based music clip. For example, the loop-able music clip may correspond to any of the following stack layers or sound content categories: bass, guitar, keys, strings, vocals, chords, leads, pads, brass and woodwinds, synth, sound effects, etc.
At operation 204, the Constant Q transform (CQT) of the music clip is computed using twelve bins per octave. The output of this computation may be a Short-Time Fourier Transform (STFT)-like representation where the resolution in the frequency axis corresponds to that in the music scale (e.g., the resulting frequency bins may be viewed as notes on a piano). The number of frames may be determined by the clip's time duration and the window parameters of the CQT computation akin to a STFT.
At operation 206, a chromatic saliency map is computed from the CQT. The chromatic saliency map represents the music clip in a way that exposes the distribution of pitch classes in the chromatic musical scale. Stated otherwise, the chromatic saliency map represents the music clip in a way that exposes the contribution or presence of specific notes or intervals in the chromatic music scale. The CQT may span multiple octaves. The computed chromatic saliency map may collapse each octave into a single bin, resulting in a twelve by N matrix where twelve is the number of notes in the chromatic musical scale. The number of frames N may remain the same as in the CQT.
In some variations as represented by operations 204 and 206, the chromatic saliency map is computed from the CQT according to a deterministic transformation. However, other deterministic or a non-deterministic approach may be used to generate the chromatic saliency map. For example, the chromatic saliency map may be generated based on a machine learning model (e.g., an artificial neural network model) trained to generate chromatic saliency maps from music clips in the time-domain or from intermediate representations thereof (e.g., CQT representations thereof). Thus, operations 204 and 206 should be viewed as just one possible way to generate a chromatic saliency map for the music clip. However, other ways may be used. For example, the chromatic saliency map may be computed based on a perceptually driven heuristic. For example, a heuristic may reflect that, due to masking effects, some pitch classes may not be aurally perceptible and therefore should not be represented in the chromatic saliency map even though the pitch classes quantitatively exhibit high energy. Instead of generating the chromatic saliency map from a CQT, the chromatic saliency map may be generated from a Short-Time Fourier Transform (STFT) representation or other frequency domain representation of the music clip. The chromatic saliency map may also be generated from a time domain representation of the music clip.
In some variations, the chromatic saliency map encompasses a chromagram representation. The chromagram representation encompasses a sequence of twelve dimensional vectors over a time of the music clip. Each vector corresponds to a frame of the chromagram representation and encodes the music clip's short-time energy distribution for the frame relative to the twelve chroma subbands.
At operation 208, a BPM-agnostic chroma representation of the chromatic saliency map is formed. To make the chromatic saliency map BPM-agnostic, the N chroma frames are aggregated (e.g., summed or averaged) into beat-level resolutions. For example, given a music clip that is eight bars long and has a 4/4-time signature, the number of beats of the music clip is thirty-two. Further assume the number of chroma frames N in this example is twelve hundred (1,200). Thus, in this example, thirty-two chunks of approximately thirty-seven and one-half chroma frames are aggregated for each beat resulting in a twelve by thirty-two BPM-agnostic chroma representation matrix that is composed of twelve dimensional chroma vectors, one for each of the thirty-two beats.
At operation 210, real and imaginary components of a set of beat-wise pitch interval space vectors are computed from the BPM-agnostic chroma representation (e.g., the twelve by thirty-two chroma representation matrix). This involves a Fourier Transform of a real signal. For example, each twelve-element column of the twelve by thirty-two chroma representation matrix (e.g., each chroma vector) may be viewed as a time-domain signal. As a result, the Fourier Transform of the signal results in a complex vector of twelve real values and twelve imaginary values. Because each chroma vector is a real signal, the Fourier Transform is symmetric and therefore only the first half of the coefficients need be retained, resulting in six real and six imaginary values which make up the real and imaginary components of a twelve element beat-wise pitch interval space vector. The result of operation 210 may be two six by M matrices composed of the real and imaginary components of M beat-wise pitch interval space vectors where the M columns of each matrix contains the real or the imaginary components of the M beat-wise pitch interval space vectors. M represents the number of beats. For example, M may be two, four, eight, sixteen, thirty-two, or sixty-four beats, or some other number of beats suitable for the requirements of the particular implementation at hand.
Also at operation 210, the real and imaginary components of each beat-wise pitch interval space vector are concatenated to form a single twelve by M matrix encompassing the M beat-wise pitch interval space vectors.
At operation 212, the matrix of M beat-wise pitch interval space vectors is flattened into a clip-wise pitch interval space vector of shape (1, (twelve*M)). For example, if M is thirty-two beats, then the clip-wise pitch interval space vector has a dimensionality of (1, 384). In some variations, the matrix is flattened column-wise by concatenating the real and imaginary parts of each beat-wise pitch interval space vector into the clip-wise pitch interval space vector.
In some variations, each beat-wise pitch interval space vector of which the clip-wise pitch interval space vector is composed is normalized by its L2 norm (also known as the 2-Norm or Euclidean Norm) before being concatenated together to form the clip-wise pitch interval space vector. This normalization may be performed to leverage the equivalence (proportionality) of Euclidean distance of unit vectors to their cosine distance to solve the problem of identifying in a scalable manner and with low latency harmonically compatible music clips where the two-dimensional feature space representation provided by the matrix of M beat-wise pitch interval space vectors is not readily indexable in an index (e.g., an index support approximate nearest neighbor search).
The feature space of a music clip is represented by a twelve by M matrix encompassing the M beat-wise pitch interval space vectors. The matrix is flattened in operation 212 to make the feature space indexable and the music clip searchable in a scalable manner. Flattening the two-dimensional matrix of M beat-wise pitch interval space vectors into a one-dimensional clip-wise pitch interval space vector as in operation 212 allows an approximate nearest neighbors search algorithm to be used to quickly identify harmonically compatible music clips and allows an approximate nearest neighbors search to scale to millions of indexed music clips where approximate nearest neighbors search typically supports only one-dimensional vectors. The Harmonic Compatibility−2(MC1, MC2) equation discussed above represents how harmonic compatibility between two music clips may be efficiently computed using respective clip-wise pitch interval space vectors.
At operational operation 214, key-agnostic support for the music clip is provided. By being key agnostic, determining harmonic compatibility between clips in different musical keys is possible. Returning to the chroma representation, a circular shift of one element of one column as if it were a time-domain signal is equivalent to transposing the original signal by one semitone. This property that a time-shift in the time-domain is equivalent to a phase rotation in the frequency domain makes it possible to generate transpositions of the music clip directly in the pitch interval space using rotations. For example, a music clip can be indexed such that it can be matched for harmonic compatibility across the twelve keys in the chromatic scale. To do this, the original clip-wise pitch interval space vector generated at operation 212 may be rotated in eleven different ways resulting in a total of twelve clip-wise pitch interval space vectors including the original clip-wise pitch interval space vector. The music clip can then be indexed in index 106 by each of these vectors to allow for matching across different keys. In the case a music clip in one key is matched for harmonic compatibility to another music clip in a different key, then one of the music clips can be pitch-shifted using digital audio signal data processing techniques so that both clips are in the same key. In some variations, support for only a few (e.g., three) semitones above and below the musical key of the original non-pitch shifted music clip is provided. This reduces the number of clip-wise pitch interval space vectors by which a clip is indexed in index 106 and thus the size of index 106. Further, it may prevent noticeable degradation in the perceptual quality resulting from pitch-shifting the original music clip too much (e.g., by more than three semitones up or down on the chromatic scale).
At operation 216, the music clip is indexed by the generated clip-wise pitch interval space vector(s). In some variations, an approximate nearest neighbors-based index supporting approximate nearest neighbors search (e.g., a quantization-based index, a graph-based index, or a tree-based index) is used to index the music clip in index 106 by the generated clip-wise pitch interval space vector(s). For example, a graph-based or a space-partitioning approximate nearest neighbors approach may be used. An approximate nearest neighbors approach can provide an acceptable tradeoff between performance (e.g., quickly identifying a set of one or more music clips that are close in distance in the pitch interval space to a given music clip), scalability (e.g., indexing many music clips), and accuracy (e.g., recall and precision of queries).
In some variations, index 106 is queried by back-end 104 with a “source” clip-wise pitch interval space vector to identify an “answer” set of one or more music clips in library 108 that are indexed by clip-wise pitch interval space vectors that are each close in distance or similarity in the pitch interval space to the source clip-wise pitch interval space vector according to an algebraic distance or similarity measure such as cosine distance or Euclidean distance. If an approximate nearest neighbors search is used, the answer set might not be (but could be) the closest indexed music clips because of the approximate nature of the search. The number of music clips to include in the answer set may be a predetermined number (e.g., a predetermined number of the closest music clips in the pitch interval space). Alternatively, the answer set may include music clips that are all within a predetermined threshold distance or similarity of the source music clip.
In some variations, the query also specifies a set of one or more query constraints that constrain the set of indexed music clips that are included in the answer set. These constraints may be applied when collecting the answer set (e.g., using the approximate nearest neighbors approach) or as a post-search step applied to an initial answer set obtained from the search (e.g., after an initial answer set has been determined using an approximate nearest neighbors search using the source clip-wise pitch interval space vector as the search key). Multiple constraints may be applied conjunctively. That is, if more than one constraint is specified, then a music clip must meet all constraints to be included in the answer set. However, constraints may be applied disjunctively or using Boolean logic (e.g., an expression of the constraints using AND, OR, NOT, or precedence operators).
One constraint already discussed is sound content category. For example, the answer set can be constrained to music clips that all belong to at least one in a set of one or more specified sound content categories. For example, the specified sound content categories can include all the following sound content categories, a subset of these categories, or a superset thereof: drums, bass, guitar, keys, strings, vocals, chords, leads, pads, brass and woodwinds, synth, sound effects, etc.
Another constraint may be beats-per-minute (BPM). This constraint does not affect BPM-agnostic nature of the generated clip-wise pitch interval space vectors. However, it may be desired by the user as part of the mixing process to limit the answer set to music clips that have a certain BPM or within a certain BPM range to avoid introducing noticeable degradation in the perceptual quality of the mix that results from time stretching the music clip in a mix using a time-scale modification algorithm that does not change the pitch of the music clip (e.g., the waveform similarity overlap-add (WSOLA) time scale modification algorithm). In some variations, music clips in library 108 are logically divided by index 106 into a set of non-overlapping BPM buckets and the query specifies one of the buckets by which to constrain the search for compatible music clips. For example, there may be three BPM buckets corresponding to low BPM, mid BPM, and high BPM. For example, the low BPM bucket may contain music clips in library 108 with a BPM below one-hundred BPM, the mid BPM bucket may contain music clips in library 108 with a BPM between one-hundred and one-hundred and fifty BPM, and the high BPM bucket may contain music clips in library 108 with a BPM greater than one-hundred and fifty BPM.
Another possible constraint is musical key. This constraint does not affect the key-agnostic nature of generated clip-wise pitch interval space vectors. However, like with BPM, it may be desired by the user as part of the mixing process to limit the answer set to music clips in a certain key or specified set of keys to avoid introducing noticeable degradation in the perceptual quality of the mix that results from pitch-shifting the music clip in a mix. In some variations, the query specifies a set of one or more of the twelve pitch classes in the chromatic scale by which to constrain the answer set for compatible music clips.
Another possible constraint is chord progression or scale degree progression over a number of bars. For example, it may be desired by the user as part of the mixing process to limit the answer set to music clips that follow a specified chord progression (e.g., specified as a sequence of note names and corresponding bars) or specified scale degree progression (e.g., specified as a sequence of scale degrees and corresponding bars). For example, a chord progression over four bars of music might be specified as Bm for the first bar, D for the second bar, Em for the third bar, G followed by A for the fourth bar. Instead of a specified chord progression, a scale degree progression may be specified. For example, a scale degree note progression over four bars of music might be the first degree (tonic) for the first bar of music, the third degree (mediant) for the second bar of music, the fourth degree (subdominant) for the third bar of music, and the sixth degree (submediant) following by the seventh degree (leading note) for the fourth bar of music. Chord progressions and scale degree progressions of music clips in library 108 may be identified using digital audio signal data processing techniques. In some variations, a music clip satisfies a chord progression or scale degree progression if it contains according to a digital audio signal data processing technique the specified chord progression or the specified scale degree progression.
Returning now to
In some variations, for purposes of determining harmonic compatibility between music clips, drum music clips or other unpitched music clips in library 108 are not considered as candidates. This is because drums and other percussion instruments that are played by striking, shaking, or scraping (e.g., snare drum, bass drum, cymbals, tambourine, triangle, etc.) are usually considered unpitched percussion instruments that produce a weak fundamental frequency. However, some percussion instruments like timpani and pitched toms can have pitch qualities. Thus, there may be no clear delineation between pitch and unpitched music clips in library 108. Digital audio signal data processing techniques may be applied to music clips in library 108 to determine which music clips are sufficiently pitched (e.g., have a detectable fundamental frequency) and which music clips are unpitched (e.g., have a weak fundamental frequency). Pitched and unpitched determinations of music clips in library 108 can be made by users either as an alternative to automatic determination or in conjunction with automatic determination (e.g., by confirming an initial automatic determination).
In some variations, instead of selecting a template to start the stack creation process, the user can select a single “seed” music clip to start the stack creation process. For example, the user may select the seed music clip from library 108, for example, by browsing or searching library 108. Alternatively, the user may record a music clip. For example, the user may use electronic device 120 to record two, four, eight, or more bars of music. For example, the user may sing an 8-bar melody or play an instrument for 8-bars that is captured as a music clip at electronic device 120 via a microphone of or operatively coupled to device 120. In some variations, a clip-wise pitch interval space vector for a recorded music clip is computed at electronic device 120 using techniques disclosed herein. Alternatively, the recorded music clip may be uploaded to service 100 for computation of the clip-wise pitch interval space vector by service 100. Service 100 can then return the computed clip-wise pitch interval space vector to device 120 for use at device 120.
A music clip recorded at device 100 can also be added to an existing stack that is in the process of being created. For example, the user may start the stack creation process by selecting a stack template of one or more music clips. The user may then add a recorded music clip to the current stack. For example, the stack template may start the stack with a keys music clip, a drums music clip, and a guitar music clip. Then, the user may use device 120 to record a vocal melody that the user harmonizes with the current stack. The user may then add the recorded music clip to the current stack to form a new stack that includes the keys music clip, the drums music clip, the guitar music clip, and the recorded vocal music clip. Note that the recorded vocal music clip may be included in the stack by the user without regard to the similarity or distance in the pitch interval space between the recorded vocal track and the other pitch-based music clips of the stack. However, subsequent music clips selected from library 108 to add to the stack or that replace a music clip in the stack may be selected based on the music clip's harmonic compatibility with the recorded vocal music clip according to similarity or distance in the pitch interval space. For example, after adding the recorded vocal music clip to the stack, the user may select to replace the keys music clip provided by the stack template with a different harmonically compatible keys music clip. The selection of the new keys music clip may be based on its harmonic compatibility with the remaining pitch-based music clips in the stack including the guitar music clip and the recorded vocal music clip.
Similar to starting a stack with a user recorded music clip or adding a user recorded music clip to a stack, a stack may be started with a music clip licensed by a recording artist, or a music clip licensed by a recording artist may be added to an existing stack. For example, consider a music mixing competition where contestants use the stacks application disclosed herein where a winner is selected based on the mix judged to be best sounding and where the mix must include at least a music clip provided/licensed by a recording artist sponsoring or supporting the competition. In this example, each contestant might start the competition with a stack that includes a licensed music clip (e.g., a vocal melody sung by the recording artist) as the seed music clip.
Thus, the stack creation process can start in ways other than by selecting a template such as by selecting or recording a seed music clip.
At Step 3, a request for a compatible music clip is received from electronic device 120. For example, assume the stack template returned at Step 2 contains a single “Vocals” music clip or that the seed music clip that is recorded, selected, or uploaded is a “Vocals” music clip. Then, at Step 3, a request for a compatible “Keys” music clip is received. In response to receiving this request for a compatible “Keys” music clip, service 100 may use the clip-wise pitch interval space vector for the “Vocals” music clip in a query into index 106 to determine a compatible (e.g., the most compatible) “Keys” music clip. For example, the determination may be made based on an approximate nearest neighbor search using the clip-wise pitch interval space vector for the “Vocals” music clip in the query. At Step 4, the compatible music clip is returned to the electronic device 120 as a response to the request at Step 3. For example, the most compatible “Keys” music clip may be returned to electronic device 120 to include with the “Vocals” music clip in the current stack at electronic device 120.
Step 3 and Step 4 may be repeated in an iterative fashion until user 110 has decided on a final stack. For example, after the request for a compatible “Keys” music clip, another request for a compatible music clip may be received from electronic device 120 at Step 3. This request may seek a “Leads” music clip that is compatible with current harmonically compatible partial mix (“partial mix”) consisting of the compatible “Vocals” music clip and the compatible “Keys” music clip. Since the current partial mix contains more than one music clip, the individual clip-wise pitch interval space vectors for the constituent music clips may be linearly combined (e.g., by simple linear addition) to form a “partial mix-wise” pitch interval space vector that represents the current partial mix. In some variations, an initial partial mix-wise pitch interval space vector formed based on a linear combination of the constituent clip-wise pitch interval space vectors is normalized at the beat level by L2-normalization to form a final partial mix-wise pitch interval space vector. Then, service 100 may use the partial mix-wise pitch interval space vector in a query into index 106 to determine a compatible “Leads” music clip. For example, the determination may be made based on an approximate nearest neighbor search using the partial mix-wise pitch interval space vector for the compatible “Vocals” and “Keys” music clips in the query. At Step 4, the compatible music clip is returned to the electronic device 120 as a response to the request at Step 3. For example, the most compatible “Leads” music clip to the current partial mix consisting of the “Vocals” music clip and the “Keys” music clip may be returned to electronic device 120 to form a new partial mix consisting of the compatible “Vocals” music clip, the compatible “Keys” music clip, and the compatible “Leads” music clip.
Next, user 110 may wish to add a drum music clip to the current stack. Accordingly, another request for a compatible music clip may be received from electronic device 120 at Step 3. This request may seek a “Drums” music clip that is compatible with the current stack consisting of the “Vocals” music clip, the “Keys” music clip, and the “Leads” music clip. However, because “Drums” music clips may be considered unpitched music clips, a compatible “Drums” music clip may be selected by service 100 using an approach other than the harmonic compatibility approach disclosed herein. For example, service 100 may randomly select a compatible “Drums” music clip from library 108 subject to the genre/style constraints (e.g., of the stack template selected at Step 1) or other user-specified or user-configured constraints (e.g., BPMs). While unpitched music clips may be randomly selected subject to constraints, unpitched music clips may be selected otherwise subject to constraints. For example, a compatible unpitched music clip may be selected subject to constraints based on the compatibility of detected onset patterns in the unpitched music clip and the music clips that make up the current stack.
Next, after adding a “Drums” music clip to the current stack, user 110 may wish to add a compatible “Bass” music clip. Accordingly, yet another request for a compatible music clip may be received by service 100 at Step 3. This request may seek a compatible “Bass” music clip seek that is compatible with current partial mix consisting of the compatible “Vocals” music clip, the compatible “Keys” music clip, and the compatible “Leads” music clips (recall that “Drums” music clips and other unpitched music clips may be excluded from the partial mix for the purpose of determining harmonic compatibility.) Service 100 may form a partial mix-wise pitch interval space vector by linearly combining the clip-wise pitch interval space vectors for the compatible “Vocals” music clip, the compatible “Keys” music clip, and the compatible “Leads” music clip that make up the current partial mix, followed by L2-normalization of the partial mix-wise pitch interval space vector at the beat level. Then, service 100 may use the partial mix-wise pitch interval space vector in a query into index 106 to determine a compatible “Bass” music clip. For example, the determination may be made based on an approximate nearest neighbor search using the partial mix-wise pitch interval space vector in the query. At Step 4, the compatible music clip is returned to the electronic device 120 as a response to the request at Step 3. For example, the most compatible “Bass” music clip to the current partial mix consisting of the compatible “Vocals” music clip, the compatible “Keys” music clip, and the compatible “Leads” music clip may be returned to electronic device 120 to form a new partial mix consisting of the compatible “Vocals” music clip, the compatible “Keys” music clip, the compatible “Leads” music clip, and the compatible “Bass” music clip and a new current stack consisting of the new partial music mix and the “Drums” music clip.
At Step 5, a request may be received by service 100 from electronic device 120 to share the current stack as a complete mix. For example, the current stack may be rendered as a music clip at electronic device 120 or at service 100 for inclusion in library 108, to be stored as a digital audio signal data source at electronic device 120, to be uploaded or otherwise shared with an online social media platform (e.g., the TIKTOK social networking service owned by BYTEDANCE of Beijing, China), to send as a file attachment to an electronic mail (email) message or text (SMS) message, to upload to a cloud-based data storage service or centrally-hosted network file system, or to export in a data format that can be imported into digital audio workstation (DAW) software for further processing.
Further, variations of the stacks-based music mixing application are possible. For example, in one variation, a user may select a set of one or more eight-bar music clips in a digital audio workstation application executing at the user's electronic device. A plugin or an extension to the digital audio workstation application may interface with service 100 over network(s) 130 to retrieve a music clip or a set of music clips in library 108 that is/are harmonically compatible with the selected set of music clips. In this case, the selected set of music clips may or may not be in library 108 or indexed by index 106. The digital audio workstation software or the plugin or extension thereto may generate clip-wise pitch interval space vectors for the selected set of music clips using the techniques disclosed herein and send the generated clip-wise pitch interval space vectors to service 100 over network(s) 130 for use by service 100 to search for harmonically compatible music clips using techniques disclosed herein.
In some variations, GUI 2202 provides a user option to export the stack to a digital audio workstation (DAW) so that the user can continue the music creation process. For example, GUI 2202 may provide the option to export the generated stack for importation into a music production software such as, for example, ABLETON LIVE, PRO TOOLS, CUBASE, etc. From there, the user might use the generated stack as a section in a new song composed by the user using the music production software.
In some embodiments, a system that implements a portion or all the techniques described herein can include a general-purpose computer system, such as the computer system 1600 illustrated in
In various embodiments, the computer system 1600 can be a uniprocessor system including one processor 1610, or a multiprocessor system including several processors 1610 (e.g., two, four, eight, or another suitable number). The processor(s) 1610 can be any suitable processor(s) capable of executing instructions. For example, in various embodiments, the processor(s) 1610 can be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, ARM, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In multiprocessor systems, each of the processors 1610 can commonly, but not necessarily, implement the same ISA.
The system memory 1620 can store instructions and data accessible by the processor(s) 1610. In various embodiments, the system memory 1620 can be implemented using any suitable memory technology, such as random-access memory (RAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above, are shown stored within the system memory 1620 as service code 1625 (e.g., executable to implement, in whole or in part, service 100) and data 1626.
In some embodiments, the I/O interface 1630 can be configured to coordinate I/O traffic between the processor 1610, the system memory 1620, and any peripheral devices in the device, including the network interface 1640 and/or other peripheral interfaces (not shown). In some embodiments, the I/O interface 1630 can perform any necessary protocol, timing, or other data transformations to convert data signals from one component (e.g., the system memory 1620) into a format suitable for use by another component (e.g., the processor 1610). In some embodiments, the I/O interface 1630 can include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example. In some embodiments, the function of the I/O interface 1630 can be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments, some or all of the functionality of the I/O interface 1630, such as an interface to the system memory 1620, can be incorporated directly into the processor 1610.
The network interface 1640 can be configured to allow data to be exchanged between the computer system 1600 and other devices 1660 attached to a network or networks 1650, such as other computer systems or devices as illustrated in
In some embodiments, the computer system 1600 includes one or more offload cards 1670A or 1670B (including one or more processors 1675, and possibly including the one or more network interfaces 1640) that are connected using the I/O interface 1630 (e.g., a bus implementing a version of the Peripheral Component Interconnect—Express (PCI-E) standard, or another interconnect such as a QuickPath interconnect (QPI) or UltraPath interconnect (UPI)). For example, in some embodiments the computer system 1600 can act as a host electronic device (e.g., operating as part of a hardware virtualization service) that hosts compute resources such as compute instances, and the one or more offload cards 1670A or 1670B execute a virtualization manager that can manage compute instances that execute on the host electronic device. As an example, in some embodiments the offload card(s) 1670A or 1670B can perform compute instance management operations, such as pausing and/or un-pausing compute instances, launching and/or terminating compute instances, performing memory transfer/copying operations, etc. These management operations can, in some embodiments, be performed by the offload card(s) 1670A or 1670B in coordination with a hypervisor (e.g., upon a request from a hypervisor) that is executed by the other processors 1610A-1610N of the computer system 1600. However, in some embodiments the virtualization manager implemented by the offload card(s) 1670A or 1670B can accommodate requests from other entities (e.g., from compute instances themselves), and cannot coordinate with (or service) any separate hypervisor.
In some embodiments, the system memory 1620 can be one embodiment of a computer-accessible medium configured to store program instructions and data as described above. However, in other embodiments, program instructions and/or data can be received, sent, or stored upon different types of computer-accessible media. A computer-accessible medium can include any non-transitory storage media or memory media such as magnetic or optical media, e.g., disk or DVD/CD coupled to the computer system 1600 via the I/O interface 1630. A non-transitory computer-accessible storage medium can also include any volatile or non-volatile media such as RAM (e.g., SDRAM, double data rate (DDR) SDRAM, SRAM, etc.), read only memory (ROM), etc., that can be included in some embodiments of the computer system 1600 as the system memory 1620 or another type of memory. Further, a computer-accessible medium can include transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network and/or a wireless link, such as can be implemented via the network interface 1640.
Various embodiments discussed or suggested herein can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices, or processing devices which can be used to operate any of a number of applications. User or client devices can include any of a number of general-purpose personal computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless, and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols. Such a system also can include a number of workstations running any of a variety of commercially available operating systems and other known applications for purposes such as development and database management. These devices also can include other electronic devices, such as dummy terminals, thin-clients, gaming systems, and/or other devices capable of communicating via a network.
Most embodiments use at least one network that would be familiar to those skilled in the art for supporting communications using any of a variety of widely available protocols, such as Transmission Control Protocol/Internet Protocol (TCP/IP), File Transfer Protocol (FTP), Universal Plug and Play (UPnP), Network File System (NFS), Common Internet File System (CIFS), Extensible Messaging and Presence Protocol (XMPP), AppleTalk, etc. The network(s) can include, for example, a local area network (LAN), a wide-area network (WAN), a virtual private network (VPN), the Internet, an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network, and any combination thereof.
In embodiments using a web server, the web server can run any of a variety of server or mid-tier applications, including HTTP/S servers, File Transfer Protocol (FTP) servers, Common Gateway Interface (CGI) servers, data servers, Java servers, business application servers, etc. The server(s) also can be capable of executing programs or scripts in response requests from user devices, such as by executing one or more Web applications that can be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C# or C++, or any scripting language, such as Perl, Python, PHP, or TCL, as well as combinations thereof. The server(s) can also include database servers, including without limitation those commercially available from Oracle®, Microsoft®, Sybase®, IBM®, etc. The database servers can be relational or non-relational (e.g., “NoSQL”), distributed or non-distributed, etc.
Environments disclosed herein can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all the computers across the network. In a particular set of embodiments, the information can reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers, or other network devices can be stored locally and/or remotely, as appropriate. Where a system includes computerized devices, each such device can include hardware elements that can be electrically coupled via a bus, the elements including, for example, at least one central processing unit (CPU), at least one input device (e.g., a mouse, keyboard, controller, touch screen, or keypad), and/or at least one output device (e.g., a display device, printer, or speaker). Such a system can also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as random-access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash cards, etc.
Such devices also can include a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and working memory as described above. The computer-readable storage media reader can be connected with, or configured to receive, a computer-readable storage medium, representing remote, local, fixed, and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information. The system and various devices also typically will include a number of software applications, modules, services, or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or web browser. It should be appreciated that alternative embodiments can have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices can be employed.
Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules, or other data, including RAM, ROM, Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, Compact Disc-Read Only Memory (CD-ROM), Digital Versatile Disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a system device. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.
In the preceding description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments can be practiced without the specific details. Furthermore, well-known features can be omitted or simplified in order not to obscure the embodiment being described.
In the foregoing description and in the appended claims, reference may be made to a column (e.g., a column of a matrix) or an x-axis (e.g., an x-axis of a plot) and reference may be made to a row (e.g., as in a row of a matrix) or a y-axis (e.g., a y-axis of a plot). Unless the context clearly indicates otherwise, a reference in the foregoing description or in the appended claims to a column may be substituted with a row and vice versa and a reference to an x-axis may be substituted with a y-axis and vice versa without loss of generality.
Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot-dash, and dots) are used herein to illustrate optional operations that add additional features to some embodiments. However, such notation should not be taken to mean that these are the only options or optional operations, or that blocks with solid borders are not optional in certain embodiments.
Unless the context clearly indicates otherwise, the term “or” is used in the foregoing specification and in the appended claims in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.
Unless the context clearly indicates otherwise, the terms “comprising,” “including,” “having,” “based on,” “encompassing,” and the like, are used in the foregoing specification and in the appended claims in an open-ended fashion, and do not exclude additional elements, features, acts, or operations.
Unless the context clearly indicates otherwise, conjunctive language such as the phrase “at least one of X, Y, and Z,” is to be understood to convey that an item, term, etc. may be either X, Y, or Z, or a combination thereof. Thus, such conjunctive language is not intended to require by default implication that at least one of X, at least one of Y, and at least one of Z to each be present.
Unless the context clearly indicates otherwise, as used in the foregoing detailed description and in the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well.
Unless the context clearly indicates otherwise, in the foregoing detailed description and in the appended claims, although the terms first, second, etc. are, in some instances, used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first computing device could be termed a second computing device, and, similarly, a second computing device could be termed a first computing device. The first computing device and the second computing device are both computing devices, but they are not the same computing device.
In the foregoing specification, the techniques have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
