This invention relates to musical systems, including a system for generating and implementing digital music tuning files.
As is known in the art, western music is based primarily on standard equal-tempered tuning (e.g., 12-TET tuning). However, it can be observed that these equally-tempered tuning systems all compromise the natural intervals that exist as physical properties of both sound and music.
Standard equal-tempered tuning also limits modern music to the same 12 tones per octave for each piece of music composed and played. In addition, the interval in between each of these 12 notes in standard western tuning is an irrational value of
which only approximates the natural intervals, and only works when the octave is fixed at 12 notes.
As is also known in the art, western standard tuning has traditionally used the Rational-number frequency of 440 Hz as its generally-accepted standard reference pitch. However, when the Irrational, equally-tempered
interval is applied to this Rational-number reference pitch (and then repeatedly applied to each resulting pitch), the 11 other calculated pitches in the octave all result as Irrational-number frequencies.
Accordingly, there is a need for a system and method for tuning musical instruments that does not compromise the natural musical intervals, and that does not also limit the number of available tones to 12.
There also is a need for a system and method for tuning musical instruments that is not based upon irrational numbers. Rather, what's needed is a tuning system that uses rational numbers for all frequencies and intervals. By calculating p-smooth integer sequences, and then transforming those sequences into playable octaves of musical frequencies, a system and method for generating and implementing digital tuning files based on rational numbers can be realized.
Accordingly, there is also a need for a system and method of generating and implementing digital tuning files based on p-smooth number sequences with digital musical instruments.
Because many contemporary digital music instruments are by default programmed to standard western equally-tempered tuning, there also is a need for a system and method of retuning digital musical instruments using digital tuning files.
According to one aspect, one or more embodiments are provided below for a method of modifying an audio output of a digital musical instrument, the method comprises receiving information regarding the digital musical instrument, the information including a tuning file type used by the digital musical instrument, and wherein the digital musical instrument includes memory storing a first set of first musical note notations with each first musical note notation within the first set of first musical note notations correlated to a corresponding first musical note frequency, receiving a sequence of p-smooth numbers, choosing a subset of the sequence of p-smooth numbers and assigning the subset as a first octave of second musical note frequencies, assigning each second musical note frequency within the first octave of second musical note frequencies a corresponding second musical note notation, assigning each second musical frequency and its corresponding second musical note notation within the octave of second musical note frequencies as a unique tonic, for each tonic, generating a corresponding second octave of third musical note frequencies, assigning each third musical note frequency within the second octave of third musical note frequencies a corresponding third musical note notation, storing into a digital file of the tuning file type each tonic, each second octave of third musical note frequencies corresponding to each tonic, and each third musical note notation corresponding to each third musical note frequency, loading the digital file into the digital musical instrument memory, and correlating, within the digital musical instrument memory, each first musical note notation within the digital musical instrument's first set of musical note notations with a corresponding third musical note notation and the third musical note frequency corresponding to the corresponding third musical note notation from the digital file.
In other embodiments, the choosing a subset of the sequence of p-smooth numbers further comprises choosing a first p-smooth number from the sequence of p-smooth numbers and designating the chosen first p-smooth number as a first lower frequency limit, doubling the first p-smooth number to determine a first upper frequency limit, choosing p-smooth numbers from the sequence of p-smooth numbers between the first lower frequency limit and the first upper frequency limit, and including the first lower frequency limit, the first upper frequency limit, and the chosen p-smooth numbers between the first lower frequency limit and the first upper frequency limit in (C)(3) in the first octave of second musical note frequencies.
In other embodiments, the choosing p-smooth numbers from the sequency further comprises octave multiplying and/or octave dividing any one of the p-smooth numbers in the sequence of p-smooth numbers between the first lower frequency limit and the first upper frequency limit.
In other embodiments, the generating a corresponding second octave of third musical note frequencies for each tonic further comprises designating each tonic as a second lower frequency limit of a respective octave, doubling each tonic to determine a second upper frequency limit of the respective octave, choosing p-smooth numbers between the second lower frequency limit and the second upper frequency limit, including the second lower frequency limit, the second upper frequency limit, and the chosen p-smooth numbers between the second lower frequency limit and the second upper frequency limit in the second octave of third musical note frequencies.
In other embodiments, the correlating within the digital musical instrument memory further comprises for each first musical note notation within the digital musical instrument's first set of musical note notations, identifying a corresponding first musical note frequency, for each second musical note notation corresponding to each first musical note notation, identify a corresponding second musical note frequency, determining a frequency difference between the corresponding first musical note frequency and the corresponding second musical note frequency, adding the frequency difference to the corresponding first musical note frequency and/or subtracting the frequency difference from the corresponding first musical note frequency to determine a mapped musical note frequency, and correlating, within the digital musical instrument's memory, each first musical note notation with each corresponding mapped musical note frequency.
In other embodiments, the sequence of p-smooth numbers includes at least one chosen from the group of 3-smooth, 5-smooth, 7-smooth, 11-smooth, 13-smooth, 17-smooth, and 19-smooth.
In other embodiments, the digital musical instrument includes a musical instrument digital interface (MIDI) instrument.
In other embodiments, the method further comprises generating chord diagrams, for the digital musical instrument, corresponding to at least some of the third musical note notations.
In other embodiments, the method further comprises generating fingering diagrams, for the digital musical instrument, corresponding to at least some of the third musical note notations.
In other embodiments, the correlating, within the digital musical instrument memory, each first musical note notation within the digital musical instrument's first set of musical note notations with a corresponding third musical note notation and the third musical note frequency corresponding to the corresponding third musical note notation from the digital file is triggered by a device including at least one of a foot pedal, a digital musical keyboard, a digital musical guitar, a digital musical interface, a computer, and a smartphone.
According to another aspect, one or more embodiments are provided below for a method of modifying an audio output of a digital musical instrument, the method comprises receiving information regarding the digital musical instrument, the information including a tuning file type used by the digital musical instrument, and wherein the digital musical instrument includes memory storing a first set of first musical note notations with each first musical note notation within the first set of first musical note notations correlated to a corresponding first musical note frequency, receiving a sequence of p-smooth numbers, choosing a subset of the sequence of p-smooth numbers including a first lower frequency limit, a first upper frequency limit equal to twice the first lower frequency limit, and a set of p-smooth numbers from the sequency of p-smooth numbers between the first lower frequency limit and the first upper frequency limit, and assigning the subset as a first octave of second musical note frequencies, assigning each second musical note frequency within the first octave of second musical note frequencies a corresponding second musical note notation, assigning each second musical frequency and its corresponding second musical note notation within the octave of second musical note frequencies as a unique tonic, for each tonic, generating a corresponding second octave of third musical note frequencies, assigning each third musical note frequency within the second octave of third musical note frequencies a corresponding third musical note notation, storing into a digital file of the tuning file type each tonic, each second octave of third musical note frequencies corresponding to each tonic, and each third musical note notation corresponding to each third musical note frequency, loading the digital file into the digital musical instrument memory, and correlating, within the digital musical instrument memory, each first musical note notation within the digital musical instrument's first set of musical note notations with a corresponding third musical note notation and the third musical note frequency corresponding to the corresponding third musical note notation from the digital file.
According to another aspect, one or more embodiments are provided below for a method of modifying an audio output of a digital musical instrument, the method comprises receiving information regarding the digital musical instrument, the information including a tuning file type used by the digital musical instrument, and wherein the digital musical instrument includes memory storing a first set of first musical note notations with each first musical note notation within the first set of first musical note notations correlated to a corresponding first musical note frequency, receiving a sequence of p-smooth numbers, choosing a subset of the sequence of p-smooth numbers and assigning the subset as a first octave of second musical note frequencies, assigning each second musical note frequency within the first octave of second musical note frequencies a corresponding second musical note notation, assigning each second musical frequency and its corresponding second musical note notation within the octave of second musical note frequencies as a unique tonic, for each tonic, generating a corresponding second octave of third musical note frequencies, assigning each third musical note frequency within the second octave of third musical note frequencies a corresponding third musical note notation, storing into a digital file of the tuning file type each tonic, each second octave of third musical note frequencies corresponding to each tonic, and each third musical note notation corresponding to each third musical note frequency, loading the digital file into the digital musical instrument memory, correlating, within the digital musical instrument memory, each first musical note notation within the digital musical instrument's first set of musical note notations with a corresponding third musical note notation and the third musical note frequency corresponding to the corresponding third musical note notation from the digital file using the steps comprising for each first musical note notation within the digital musical instrument's first set of musical note notations, identifying a corresponding first musical note frequency, for each second musical note notation corresponding to each first musical note notation, identifying a corresponding second musical note frequency, determining a frequency difference between the corresponding first musical note frequency and the corresponding second musical note frequency, adding the frequency difference to the corresponding first musical note frequency and/or subtracting the frequency difference from the corresponding first musical note frequency to determine a mapped musical note frequency, and correlating, within the digital musical instrument's memory, each first musical note notation with each corresponding mapped musical note frequency.
In other embodiments, the choosing p-smooth numbers from the sequence further comprises octave multiplying and/or octave dividing any one of the p-smooth numbers in the sequence of p-smooth numbers between the first lower frequency limit and the first upper frequency limit.
Other aspects and advantages of the invention will be apparent from the following description and the appended claims.
Various other objects, features and attendant advantages of the present invention will become fully appreciated as the same becomes better understood when considered in conjunction with the accompanying drawings, in which like reference characters designate the same or similar parts throughout the several views, and wherein:
In general, the system according to exemplary embodiments hereof provides a system and method to generate and implement digital tuning files for use with a digital musical instrument. Specifically, the system described herein generates and implements digital tuning files for digital musical instruments based on p-smooth integer sequences. For example, the digital musical tuning files may be used to tune an electronic musical instrument (e.g., a synthesizer) to a non-factory setting of musical notes.
In another embodiment, the digital music tuning files may be incorporated directly into an electronic musical instrument and/or software (e.g., a synthesizer) as internal Frequency Table Arrays, rather than as external digital music tuning files.
In some embodiments, it may be preferable for the output of the system to be compatible with known technical standards that define communications protocols and digital interface requirements for digital musical instruments (e.g., with the musical instrument digital interface (MIDI)).
As is known in the art, music can be visually represented with symbols by using a Musical Notation system, as well as by using a Note-Naming Convention. For standard 12-TET tuning, the Western Notation System includes multiple staffs of 5 horizontal lines, and its Note-Naming Convention uses Alphabet letters and sharp/flat symbols (A, A#, B, C, etc.).
As a result, in some embodiments where the tunings need to be represented visually, a novel 7-line Musical Notation Staff and custom Note-Naming Convention have been implemented, to allow p-smooth tunings with more than 12 notes per octave to be displayed visually.
As is known in the art, a p-smooth number is an integer whose largest prime factor is less than or equal to P. For example, the following integers are 5-smooth numbers since all of these numbers include prime factors that are less than or equal to 5: 1, 2, 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 24, 25, . . . .
In some embodiments, the application generates the instrument-specific Fingerings, Chord Diagrams and Mappings that musicians will require in order to play a selected p-smooth tuning on their instrument of choice.
In some embodiments, a MIDI File, generated by calls to an external Artificial Intelligence Music Generator API, is mapped by the application to a selected p-smooth tuning, and then output as a unique retuned MIDI composition.
In some embodiments, after the application generates a MIDI file composition retuned to a selected p-smooth tuning, the file is converted to an Audio file (.way, .mp3, etc.) and then used to generate an NFT (Non-Fungible Token), or other digital token, by automatic submission to an external NFT API (e.g., a blockchain-based timestamping (TSS) API).
In some embodiments, a selected p-smooth tuning is mapped by the application from audible p-smooth frequencies to equivalent p-smooth frequencies in the visible and near-visible electromagnetic color spectrum. This is accomplished by taking an audible p-smooth octave of audio frequencies in Hz between 420 Hz and 870 Hz, and then converting the Hz to THz, in the range of 420 THz to 870 THz, which encompasses the electromagnetic spectrum between Infrared light and Ultraviolet light.
For example, an electromagnetic p-smooth octave of light-frequencies are output by the application to tunable lasers, which then emit laser beams that are the colors of the corresponding audible musical frequencies. As a specific example, an audible frequency of 576 Hz, which is a D note, is mapped to 576 THz, which is the color green.
In some embodiments, instead of generating tuning files, the application instead generates the specifications required to build a non-digital instrument that will play p-smooth tunings. For example, the application generates the hole size and placement required to build a native-American flute that will play a specific p-smooth tuning.
The local and/or backend system 100 includes one or more computers and/or servers 104 including one or more software systems 106, one or more applications 600, and one or more databases 700. The one or more software systems 106 may include operating systems, system software, web server software, social networking software, communication software, software applications, scripts, firmware, other types of software systems and any combinations thereof. The applications 600 and databases 700 will be described in other sections.
The computing devices 300 (e.g., the digital musical instruments, computers, etc.) and the local and/or backend controller 100 may preferably be connected to one or more networks 102 (e.g., the Internet, LAN, WAN, wireless communication systems, cellular communication systems, telephony or other types of communication systems or protocols) and may communicate thereby. In other embodiments, the computing devices 300 and the local and/or backend system 100 may simply communicate via one or more wired connections (e.g., USB cables).
In some embodiments, the local and/or backend controller 100 may include a cloud platform (e.g., one or more backend servers), one or more local controllers, or any combination thereof. In some embodiments, the local and/or backend controller 100 includes a cloud platform that interfaces with one or more local controllers. For example, administrators of the system 10 may interface with the system 10 via a local controller in communication to a cloud platform.
In some embodiments, the application 200 provides a graphical user interface (GUI) that enables a user U to interface with the application 200, the local controller and/or backend 100, and the overall system 10. The application 200 may generally provide an interface with which the user U may enter information for the system 10 to utilize (e.g., upload to the backend 100), and interface controls (e.g., touchscreen buttons, etc.) for a user U to activate while interacting with the system 10. The application 200 also may display data and other types of information that a user U may read or otherwise consume and/or provide to other users U. In general, and in some embodiments, the application 200 may provide a primary interface with which a user U may interact with the system 10.
In some embodiments as shown in
Then (at 206), for each p-smooth number sequence with seed values and upper frequency limits determined, the set of integers between and including the seed value and the upper frequency (2× the seed value) are stored into new arrays (e.g., “phase 1 octave arrays”). Accordingly, each phase 1 octave array will include all of the p-smooth numbers between (and including) its seed value and its upper frequency value for its particular p-smooth number.
Next (at 208), for each phase 1 octave array, a subset of numbers included in each phase 1 octave array is chosen and arranged into individual sets of tonics (e.g., “core tonics”). The core tonics within each subset of each octave array are chosen using the following guidelines:
Additional playable notes outside the core tonics also may be determined (at 210). For example, the guidelines shown above may be applied to p-smooth numbers within each original p-smooth number sequence above the upper frequency (2× the seed value) and then “octave dividing” down may be applied to determine additional playable notes. Next (at 212), each set of core tonics and its respective additional playable notes are combined into a new array (e.g., “tonic sets”).
Then (at 214), for each tonic set, each element within the tonic set is matched with its musical notation (e.g., F#, G, G#, etc.) and stored into a new array as tonic notes in the same order as the tonic sets.
Next (at 216), each tonic note is used to generate a new scale of playable notes for the respective tonic note, and each new scale is saved into new arrays (e.g., “phase 2 octave arrays) at 218. In some embodiments, this includes assigning each tonic note as the lower frequency of its respective new scale, doubling the tonic (2×) to determine the upper frequency of the new scale, and then determining the p-smooth integers between the lower and upper frequencies to complete each octave. Given this, it is understood that the details regarding determining the lower frequency value(s), upper frequency value(s), and the integers between the lower and upper frequency value(s) as described in other sections in relation to generating the phase 1 octave arrays also pertain to this step.
First (at 302), additional user-provided information provided by a user U regarding the transformation of the musical frequencies into digital tuning files is collected. In some embodiments, this user-provided information may include at least some of the following: (i) the phase 2 octave array(s) generated in 200 that are of interest, (ii) the tonic sub-selection (optional) (e.g., sub-selections that are slight variations to the primary array of tonics), (iii) the user's preferred selective octave to start with (optional), (iv) the user's preferred number of playable notes (optional), (v) the type of digital instrument that the resulting tuning file(s) will be used to tune (this will determine the file format type of the resulting tuning file(s)), and (vi) any other required user-provided information.
Next (at 304), playable frequencies for each phase 2 octave array generated in 200 and identified in 302 are generated and mapped (at 306) to matching arrays of musical note notations (e.g., 600/D#).
Then (at 306), a unique tuning file for each tonic is generated in the file format compatible with the user's selected type of digital musical instrument provided by the user in 302. Each tuning file is then stored (loaded) in the proper folder location (at 308) (e.g., within the digital musical instrument or an associated controller) so that it may be implemented into a selected digital musical instrument.
Then (at 310), using the tuning files, the digital musical instrument is tuned and/or retuned to the desired musical note notation to output frequency correlation provided in the files.
Then (at 404), once this difference in frequency has been determined, each newly generated playable frequency and its musical note notation is mapped to the corresponding native musical note notation in the memory of the digital musical instrument (e.g., to the digital instrument's note number for the respective musical note notation) by adding and/or subtracting the difference in frequency to the normally triggered frequency.
Once the above process has been completed, the user U may use his/her digital musical instrument to play the p-smooth number sequences as electronic music.
It is understood that the descriptions of steps provided above is meant for demonstration and that other steps also may be performed. It also is understood that not all of the steps must necessarily be performed, and that the steps may be performed in different order.
System Structure
The database(s) 700 including databases 702, 704, and 706 may comprise one or more separate or integrated databases, at least some of which may be distributed. The database(s) 700 may be implemented in any manner, and, when made up of more than one database, the various databases need not all be implemented in the same way. It should be appreciated that the system is not limited by the nature or location of database(s) 700 or by the manner in which they are implemented.
Each of the internal applications 600 may provide one or more services via an appropriate interface. Although shown as separate applications 600 for the sake of this description, it is appreciated that some or all of the various applications 600 may be combined. The various applications 600 may be implemented in any manner and need not all be implemented in the same way (e.g., using the same software languages, interfaces or protocols).
In some embodiments, the applications 600 may include one or more of the following applications 600:
The applications 600 also may include other applications and/or auxiliary applications (not shown). Those of ordinary skill in the art will appreciate and understand, upon reading this description, that the above list of applications is meant for demonstration and that the system 10 may include other applications that may be necessary for the system 10 to generally perform its functionalities as described in this specification. In addition, as should be appreciated, embodiments or implementations of the system 10 need not include all of the applications listed, and that some or all of the applications may be optional. It also is understood that the scope of the system 10 is not limited in any way by the applications that it may include.
In some embodiments, the database(s) 700 may include one or more of the following databases:
It is understood that the above list of databases is meant for demonstration and that the system 10 may include some or all of the databases, and also may include additional databases as required. It also is understood that the scope of the system 10 is not limited in any way by the databases that it may include.
Various applications 600 and databases 700 in the system 10 may be accessible via interface(s) 142. These interfaces 144 may be provided in the form of APIs or the like and made accessible to users U via one or more gateways and interfaces 144 (e.g., via a web-based application 200 and/or a mobile application 200 running on a user's device 300). In some embodiments, the system 10 may be interacting with External 3rd Party Applications E via RESTful API calls, rather than interacting with users.
In some embodiments as shown in
It is understood that any steps described above are meant for demonstration and that additional steps may be performed, not all of the described steps may be performed, and the steps may be taken in different orders. It also is understood that the scope of the assembly 10 is not limited in any way by the steps taken during its use.
It also is understood that any aspect and/or element of any embodiment of the system 10 described herein or otherwise may be combined with any other aspect and/or element of any other embodiment described herein or otherwise in any way to form additional embodiments of the system 10 all of which are within the scope of the system 10.
Computing
The services, mechanisms, operations and acts shown and described above are implemented, at least in part, by software running on one or more computers or computer systems or devices. It should be appreciated that each user device is, or comprises, a computer system.
Programs that implement such methods (as well as other types of data) may be stored and transmitted using a variety of media (e.g., computer readable media) in a number of manners. Hard-wired circuitry or custom hardware may be used in place of, or in combination with, some or all of the software instructions that can implement the processes of various embodiments. Thus, various combinations of hardware and software may be used instead of software only.
One of ordinary skill in the art will readily appreciate and understand, upon reading this description, that the various processes described herein may be implemented by, e.g., appropriately programmed general purpose computers, special purpose computers and computing devices. One or more such computers or computing devices may be referred to as a computer system.
According to the present example, the computer system 800 includes a bus 802 (i.e., interconnect), one or more processors 804, one or more communications ports 814, a main memory 810, removable storage media 810, read-only memory 808, and a mass storage 812. Communication port(s) 814 may be connected to one or more networks by way of which the computer system 800 may receive and/or transmit data.
As used herein, a “processor” means one or more microprocessors, central processing units (CPUs), computing devices, microcontrollers, digital signal processors, or like devices or any combination thereof, regardless of their architecture. An apparatus that performs a process can include, e.g., a processor and those devices such as input devices and output devices that are appropriate to perform the process.
Processor(s) 804 can be (or include) any known processor, such as, but not limited to, an Intel® Itanium® or Itanium 2® processor(s), AMD® Opteron® or Athlon MP® processor(s), or Motorola® lines of processors, and the like. Communications port(s) 814 can be any of an RS-232 port for use with a modem-based dial-up connection, a 10/100 Ethernet port, a Gigabit port using copper or fiber, or a USB port, and the like. Communications port(s) 814 may be chosen depending on a network such as a Local Area Network (LAN), a Wide Area Network (WAN), a CDN, or any network to which the computer system 800 connects. The computer system 800 may be in communication with peripheral devices (e.g., display screen 810, input device(s) 818) via Input/Output (I/O) port 820. Some or all of the peripheral devices may be integrated into the computer system 800, and the input device(s) 818 may be integrated into the display screen 810 (e.g., in the case of a touch screen).
Main memory 810 can be Random Access Memory (RAM), or any other dynamic storage device(s) commonly known in the art. Read-only memory 1608 can be any static storage device(s) such as Programmable Read-Only Memory (PROM) chips for storing static information such as instructions for processor(s) 804. Mass storage 812 can be used to store information and instructions. For example, hard disks such as the Adaptec® family of Small Computer Serial Interface (SCSI) drives, an optical disc, an array of disks such as Redundant Array of Independent Disks (RAID), such as the Adaptec® family of RAID drives, or any other mass storage devices may be used.
Bus 802 communicatively couples processor(s) 804 with the other memory, storage and communications blocks. Bus 802 can be a PCI/PCI-X, SCSI, a Universal Serial Bus (USB) based system bus (or other) depending on the storage devices used, and the like. Removable storage media 810 can be any kind of external hard-drives, floppy drives, IOMEGA® Zip Drives, Compact Disc-Read Only Memory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital Versatile Disk-Read Only Memory (DVD-ROM), etc.
Embodiments herein may be provided as one or more computer program products, which may include a machine-readable medium having stored thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process. As used herein, the term “machine-readable medium” refers to any medium, a plurality of the same, or a combination of different media, which participate in providing data (e.g., instructions, data structures) which may be read by a computer, a processor, or a like device. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory, which typically constitutes the main memory of the computer. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to the processor. Transmission media may include or convey acoustic waves, light waves and electromagnetic emissions, such as those generated during radio frequency (RF) and infrared (IR) data communications.
The machine-readable medium may include, but is not limited to, floppy diskettes, optical discs, CD-ROMs, magneto-optical disks, ROMs, RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions. Moreover, embodiments herein may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., modem or network connection).
Various forms of computer readable media may be involved in carrying data (e.g. sequences of instructions) to a processor. For example, data may be (i) delivered from RAM to a processor; (ii) carried over a wireless transmission medium; (iii) formatted and/or transmitted according to numerous formats, standards or protocols; and/or (iv) encrypted in any of a variety of ways well known in the art.
A computer-readable medium can store (in any appropriate format) those program elements that are appropriate to perform the methods.
As shown, main memory 810 is encoded with application(s) 822 that support(s) the functionality as discussed herein (an application 822 may be an application that provides some or all of the functionality of one or more of the mechanisms described herein). Application(s) 822 (and/or other resources as described herein) can be embodied as software code such as data and/or logic instructions (e.g., code stored in the memory or on another computer readable medium such as a disk) that supports processing functionality according to different embodiments described herein.
During operation of one embodiment, processor(s) 804 accesses main memory 810 via the use of bus 802 in order to launch, run, execute, interpret, or otherwise perform the logic instructions of the application(s) 822. Execution of application(s) 822 produces processing functionality of the service(s) or mechanism(s) related to the application(s). In other words, the process(es) 824 represents one or more portions of the application(s) 822 performing within or upon the processor(s) 804 in the computer system 800.
It should be noted that, in addition to the process(es) 824 that carries(carry) out operations as discussed herein, other embodiments herein include the application 822 itself (i.e., the un-executed or non-performing logic instructions and/or data). The application 822 may be stored on a computer readable medium (e.g., a repository) such as a disk or in an optical medium. According to other embodiments, the application 822 can also be stored in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the main memory 810 (e.g., within Random Access Memory or RAM). For example, application 822 may also be stored in removable storage media 810, read-only memory 808, and/or mass storage device 812.
Those skilled in the art will understand that the computer system 600 can include other processes and/or software and hardware components, such as an operating system that controls allocation and use of hardware resources.
As discussed herein, embodiments of the present invention include various steps or operations. A variety of these steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the operations. Alternatively, the steps may be performed by a combination of hardware, software, and/or firmware. The term “module” refers to a self-contained functional component, which can include hardware, software, firmware or any combination thereof.
One of ordinary skill in the art will readily appreciate and understand, upon reading this description, that embodiments of an apparatus may include a computer/computing device operable to perform some (but not necessarily all) of the described process.
Embodiments of a computer-readable medium storing a program or data structure include a computer-readable medium storing a program that, when executed, can cause a processor to perform some (but not necessarily all) of the described process.
Where a process is described herein, those of ordinary skill in the art will appreciate that the process may operate without any user intervention. In another embodiment, the process includes some human intervention (e.g., a step is performed by or with the assistance of a human).
As used in this description, the term “portion” means some or all. So, for example, “A portion of X” may include some of “X” or all of “X”. In the context of a conversation, the term “portion” means some or all of the conversation.
As used herein, including in the claims, the phrase “at least some” means “one or more,” and includes the case of only one. Thus, e.g., the phrase “at least some ABCs” means “one or more ABCs”, and includes the case of only one ABC.
As used herein, including in the claims, the phrase “based on” means “based in part on” or “based, at least in part, on,” and is not exclusive. Thus, e.g., the phrase “based on factor X” means “based in part on factor X” or “based, at least in part, on factor X.” Unless specifically stated by use of the word “only”, the phrase “based on X” does not mean “based only on X.”
As used herein, including in the claims, the phrase “using” means “using at least,” and is not exclusive. Thus, e.g., the phrase “using X” means “using at least X.” Unless specifically stated by use of the word “only”, the phrase “using X” does not mean “using only X.”
In general, as used herein, including in the claims, unless the word “only” is specifically used in a phrase, it should not be read into that phrase.
As used herein, including in the claims, the phrase “distinct” means “at least partially distinct.” Unless specifically stated, distinct does not mean fully distinct. Thus, e.g., the phrase, “X is distinct from Y” means that “X is at least partially distinct from Y,” and does not mean that “X is fully distinct from Y.” Thus, as used herein, including in the claims, the phrase “X is distinct from Y” means that X differs from Y in at least some way.
As used herein, including in the claims, a list may include only one item, and, unless otherwise stated, a list of multiple items need not be ordered in any particular manner. A list may include duplicate items. For example, as used herein, the phrase “a list of XYZs” may include one or more “XYZs”.
It should be appreciated that the words “first” and “second” in the description and claims are used to distinguish or identify, and not to show a serial or numerical limitation. Similarly, the use of letter or numerical labels (such as “(a)”, “(b)”, and the like) are used to help distinguish and/or identify, and not to show any serial or numerical limitation or ordering.
No ordering is implied by any of the labeled boxes in any of the flow diagrams unless specifically shown and stated. When disconnected boxes are shown in a diagram the activities associated with those boxes may be performed in any order, including fully or partially in parallel.
While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not to be limited to the disclosed embodiments, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.
This application claims priority to U.S. Provisional Application No. 63/291,915 filed Dec. 20, 2021, the entire contents of which are hereby fully incorporated herein by reference for all purposes.
Number | Name | Date | Kind |
---|---|---|---|
5501130 | Gannon | Mar 1996 | A |
6323408 | Liu | Nov 2001 | B1 |
20080184872 | Hunt et al. | Aug 2008 | A1 |
20210056941 | Chang | Feb 2021 | A1 |
20220199058 | Grant | Jun 2022 | A1 |
Entry |
---|
“Microtuning and Alternative Intonation Systems,” midi.org. https://www.midi.org/midi-articles/microtuning-and-alternative-intonation-systems [Date accessed: Jul. 29, 2021]. |
Number | Date | Country | |
---|---|---|---|
63291915 | Dec 2021 | US |