Electronic musical instrument using quantized continuous linear input to trigger octave-modulated sounding of played keypad regions

Abstract

An electronic musical instrument played by fingered input on an array of playable touch regions (e.g. virtual or physical keys), and a secondary user-manipulation (e.g. tilt) of separate and distinct character from the fingered input and produces a responsive output signal of linear character. At quantized intervals, whose timing is independent of user-activation of the regions, the instrument samples the responsive signal for an instantaneous value, converts that value into converted pitch class and octave values, and calculates an output octave based on a combination of the converted octave and a region octave of an active region, whose pitch is outputted at the calculated octave. A unique hold mode activates and deactivates any region by sequential touches thereof. The regions can be transposed via a base value of a chosen region in a reset transpose mode, or by current value of the chosen regions in an iterative transpose mode.

Description

[0001] ELECTRONIC MUSICAL INSTRUMENT USING QUANTIZED CONTINUOUS LINEAR

[0002] INPUT TO TRIGGER OCTAVE-MODULATED SOUNDING OF PLAYED KEYPAD

[0003] REGIONS

[0004] CROSS-REFERENCE TO RELATED APPLICATIONS

[0005] This application claims priority benefit of U.S. Provisional Application No. 63 / 636,232, filed April 19, 2024, the entirety of which is incorporated herein by reference.

[0006] FIELD OF THE INVENTION

[0007] The present invention relates generally to musical instruments, and more particularly to electronic and microtonal musical instruments.

[0008] BACKGROUND

[0009] The “problem” of Just Intonation has been known since Pythagoras observed that whole number ratios are harmonious, as seen with 2: 1 3:2 4:3 5:4 6:5 8:5, etc. Instrument builders have struggled for centuries to build instruments such that all Major & Minor chords are perfectly intoned in all keys. Over time, a standard of 12 keys per octave emerged. Fundamentally, the goal is to fit an interconnected network of iterative relative relationships into a container of 12 fixed keys. Instrument builders accepted a self-imposed limitation that there must be a one-to-one correspondence between the audible pitch and the key pressed to create that pitch. This denotes an intractable problem under that paradigm.

[0010] Attempts were made to address, notably through addition of extra keys. Past efforts on this front have well documented in the annals of historical instrument design. Scala is a software tool usable for experimentation with musical tunings, available online from a website on which a database of 5000+ tunings for keyboard instruments is also made available for download by the public.

[0011] Despite the wealth of experimentation made, the best efforts so far are considered compromises at best, and there remains an opportunity and need to create a novel musical instrument that can break free of the traditional constraint, and introduce new musical capabilities not heretofore possible with conventional instruments.

[0012] Prior patent publications uncovered in a search of the prior art, while not necessarily having similar inventive aim, and having been found to be of no detriment to the particularly claimed novelties of the unique musical instrument disclosed herein, are nonetheless disclosed herein for background and transparency, and include: EP2434480, GB2535210, GB2577087, US4972752,

[0013] US5415071, US5565641, US6066795, US6392131, US6392131, US6670535, US8604364, US8614384, US8686276, US8872011, US9024168, US9530395, US9620093, US10490173, US12027147, US20140149911, USD606082, USD772288, USD772928, USD772929, USD774086, USD775198, and USD862502.

[0014] As further background, the present inventor’s own prior work in the broader field of musical theory, upon which significant further work was undertaken to translate the theoretical into practical, expressive and commercially workable form, is documented The Harmonic Matrix: Exploring the Geometry of Pitch (Proceedings of the International Computer Music Conference 2011, University of Huddersfield, UK, 31 July - 5 August), the entirety of which is incorporated herein by reference.

[0015] SUMMARY OF THE INVENTION

[0016] According to a first aspect of the invention, there is provided an electronic musical instrument comprising: a finger-actuated user input presenting a plurality of touchable regions playable with one or more manual digits of a user’s hands and each having assigned thereto a respective value in which there is embodied representation of a respective region pitch class; a continuous linear input that is variable through user-manipulation of separate and distinct character from said playing of said touchable regions and produces a responsive signal of responsive relation to said user-manipulation; and at least one processor and non-transitory computer readable medium coupled thereto, and having stored therein executable statements and instructions, that, when executed, cause performance of at least the following steps:

[0017] (a) in conjunction with a user-activated status of at least one of said regions, with which there is associated a respective a region octave, converting an instantaneous value of said responsive signal into a converted pitch class and a converted octave; and

[0018] (b) calculating an output octave that is dependent on both said region octave and said converted octave; and

[0019] (c) outputting of a musical output signal that is characterized by:

[0020] (i) equal pitch to the region pitch class of said one of said regions; and (ii) said output octave.

[0021] According to a second aspect of the invention, there is provided a method of modulating musical output signals of an electronic musical instrument, said method comprising:

[0022] (a) receiving fingered user input on touchable regions of the instrument playable with one or more manual digits of a user’s hands;

[0023] (b) also receiving a continuous linear input that is variable through user-manipulation that is of separate and distinct character from fingered playing of said touchable regions, and producing a responsive signal of responsive relation to said user-manipulation;

[0024] (c) in conjunction with a user-activated status of at least one of said regions, with which there is associated a respective a region octave, converting an instantaneous value of said responsive signal into a converted pitch class and a converted octave;

[0025] (d) calculating an output octave that is dependent on both said region octave and said converted octave; and

[0026] (e) outputting of a musical output signal that is characterized by:

[0027] (i) equal pitch to the region pitch class of said one of said regions; and

[0028] (ii) said output octave.

[0029] According to a third aspect of the invention, there is provided an electronic musical instrument comprising: a finger-actuated user input presenting a plurality of touchable regions playable with one or more manual digits of a user’s hands; a continuous linear input that is variable through user-manipulation of separate and distinct character from said playing of said touchable regions and produces a responsive signal of responsive relation to said user-manipulation; and at least one processor and non-transitory computer readable medium coupled thereto, and having stored therein executable statements and instructions, that, when executed, cause performance of at least the following steps:

[0030] (a) monitoring the regions for user-activation of one or more thereof via touched finger engagement by the user; and

[0031] (b) at quantization intervals of non-dependent relationship to user activation of the regions: (i) sampling said continuous linear input for instantaneous values thereof; and (ii) triggering output of musical output signals that are influenced by both the finger-actuated user input and the sampled instantaneous values of the continuous linear input, and are of non-dependently timed relationship to said user activation of the regions.

[0032] According to a fourth aspect of the invention, there is provided an electronic musical instrument comprising: a finger-actuated user input presenting a plurality of touchable regions playable with one or more manual digits of a user’s hands; a continuous linear input that is variable through user-manipulation of separate and distinct character from said playing of said touchable regions and produces a responsive signal of responsive relation to said user-manipulation; and at least one processor and non-transitory computer readable medium coupled thereto, and having stored therein executable statements and instructions, that, when executed, cause performance of at least the following steps:

[0033] (a) monitoring the regions for user-activation thereof via touched finger engagement by the user;

[0034] (b) in response to said touched finger engagement of any selected one of said regions, impart an active status thereto, which: renders the region eligible for later musical output on behalf thereof, without actually initiating said musical output; and is automatically held by the instrument despite subsequent removal of said finger engagement, and is terminated upon a subsequent finger reengagement of said selected one of the regions; and

[0035] (c) subsequently sampling the continuous linear input for an instantaneous value thereof, and in triggered relation thereto, outputting said musical output on behalf of said selected one of the regions, in a manner influenced by the sampled instantaneous value of the continuous linear input.

[0036] According to a fifth aspect of the invention, there is provided electronic musical instrument comprising: a finger-actuated user input presenting a plurality of touchable regions playable with one or more manual digits of a user’s hands; at least one processor and non-transitory computer readable medium coupled thereto, and having stored therein executable statements and instructions, that, when executed, cause performance of at least the following steps: operation of the instrument in an iterative transposition mode in which: a first user-implemented transposition of the regions is performed by transposing the regions according to user-designation of a first chosen region, a default Base Value of which is then used as an updated MainKey by which Currentvalues of the regions are all transposed; and a subsequent user-implemented transposition of the regions is performed by transposing the regions according to user-designation of a second chosen region, the CurrentValue of which is then used as a newly updated MainKey by which Currentvalues of the regions are all transposed. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Preferred embodiments of the invention will now be described in conjunction with the accompanying drawings in which:

[0038] Figure 1 is a front view of an electronic musical instrument according to one preferred embodiment the present invention, implemented in a portable computing device with a touchscreen, a graphical user interface (GUI) of which is shown in a playable state one a home screen thereof presenting an interactive playing surface through which the user plays a keypad of the instrument.

[0039] Figure 2A is another front view of the electronic musical instrument of Figure 1, this time shown one an instrument settings screen of the GUI.

[0040] Figure 2B is another front view of the electronic musical instrument of Figure 1, showing a remainder of the instrument settings screen unseen in Figure 2 A.

[0041] Figure 3 is a schematic diagram of the electronic musical instrument of the preceding figures and interfacing thereof with its user.

[0042] Figure 4 schematically illustrates a plurality of program modules stored in computer readable memory of the electronic musical instrument and executable by one or more processors thereof to implement various novel functionalities of the instrument.

[0043] Figure 5A schematically illustrates a first subset of various variables and inputs used by the program modules of Figure 4 to implement said various novel functionalities of the instrument.

[0044] Figure 5B schematically illustrates a second subset of the various variables and inputs used by the program modules of Figure 4 to implement said various novel functionalities of the instrument.

[0045] Figure 6 is a flowchart illustrating a general overall workflow executed by among the software modules the musical instrument during playing thereof.

[0046] Figure 7 schematically illustrates contents of, and inputs to, a playing Region database which dynamically stores data by which different keypad Regions of the playing surface of the touchscreen GUI are made functionally effective to play the instrument in a manner exploiting the novel functionalities thereof.

[0047] Figure 8 is a flowchart illustrating a workflow implemented by the Multi-Touch Surface Control module of Figure 4, by which user interaction with the playing surface is usefully interpreted by the electronic musical instrument according to activate and deactivate keypad Regions of the playing surface.

[0048] Figure 9 is a flow chart illustrating a workflow implemented by the Activate Region module of Figure 4 to render a given keypad Region of the playing surface active for musical playing purpose in response to an activation instruction from the Figure 8 workflow.

[0049] Figure 10 is a flow chart illustrating a workflow implemented by the Deactivate Region module of Figure 4 to render a given Region of the playing surface inactive for musical playing purpose in response to a deactivation instruction from the Figure 8 workflow.

[0050] Figure 11 is a flow chart illustrating a workflow implemented by the Transpose module of Figure 4 to perform transposition of an adjustable Main Key of the playing surface keypad.

[0051] Figure 12 is a flow chart illustrating a workflow implemented by the set MainKey module of Figure 4 to dynamically update Region data in the playing Region database of Figure 7 in response to change of the adjustable Main Key of the playing surface keypad.

[0052] Figure 13 is a flow chart illustrating a workflow implemented by the Quantize & Sample module of Figure 4 to periodically, at preferably adjustable timing intervals, sample a Continuous Linear Input from an accelerometer or other linear input source, as dynamically variable control input to trigger octave-wise modulation of a musical output signal outputted on behalf of an active keypad Region of the playing surface.

[0053] Figure 14 is a flow chart illustrating a workflow implemented by the Convert uString module of Figure 4 to convert the sampled instantaneous value of the Continuous Linear Input collected in Figure 13 into a musically usable uString value for triggering of octave-wise modulation.

[0054] Figure 15 A is a flow chart illustrating a partial workflow implemented by the Octave Modulation module of Figure 4 to perform said octave-wise modulation, showing primarily a polyphonic branch of this workflow.

[0055] Figure 15B is a flow chart illustrating a remainder of the Figure 15A workflow, and particularly showing a monophonic branch thereof.

[0056] Figure 16A is a flow chart illustrating a polyphonic branch of a workflow implemented by the Update Active Regions module of Figure 4 to ultimately formulate one or more musical output signals to be outputted one behalf of one or more active Regions, taking into account any preceding modulation thereof.

[0057] Figure 16B is a flow chart illustrating a monophonic branch of a workflow implemented by the Update Active Regions module of Figure 4 to ultimately formulate a singular monophonic output signals to be outputted one behalf of one active region from among one or more active regions.

[0058] DETAILED DESCRIPTION

[0059] As referenced briefly above, Figure 1 illustrates one preferred embodiment of a novel musical instrument 10 of the present invention, in the illustrated instance embodied in a smartphone or tablet computer 12 running a novel software application for generating musical output in a manner not heretofore enabled by conventional musical instruments, electronic or otherwise. In this embodiment, a touchscreen display 14 of the musical instrument 10 is the physical interface through which the user plays a plurality of “keys” of the instrument, in this case a plurality of virtual keys 16 visually displayed on the touchscreen display 14, as one form of user-input by which the instrument is played, in combination with one or more other user inputs described herein that enable novel musical capabilities uniquely enabled by the inventive instruction 10. In other embodiments, the keys 16 may instead be physically embodied in mechanically depressible keys, rather than onscreen virtual keys displayed on a touchscreen display 14, whether these be integrated mechanical keys of a dedicated musical instrument unusable for computing purposes other than musical use, or mechanical keys of a peripheral keyboard device connectable to a smartphone, tablet computer, laptop computer or desktop computer running equivalent or comparable software capable of the various functionalities attributed herein to the software of the detailed embodiment. In the case of the latter, a conventional computer keyboard (e.g. standard QWERTY keyboard) may embody the keys of the musical instrument 10.

[0060] Turning momentarily to Figure 3, illustrated schematically therein are various hardware componentry embodied in and used by the musical instrument 10, in this case denoting hardware componentry of the smartphone or tablet computer 12 functionally leveraged by the musical instrument functionality of the present invention, including the touchscreen display 14, one or more speakers 18 (referred to hereinafter only in the singular, which will be understood to encompass both a singular speaker and multiple speakers), one or more processors 20 (referred to hereinafter only in the singular, which will be understood to encompass both a singular processor and multiple processors), non-transitory computer readable working memory 22 (random access memory), non-transitory computer readable storage memory 24 and, at least in the illustrated embodiment, an accelerometer 26 that is exploited to provide at least one continuous input of linear character, typically a tilt measurement for one of three orthogonal axes X, Y, Z of a local reference plane of the instrument 10. In the illustrated embodiment, at least one data output port 28 (e.g. USB- C) is included by which musical signals produced for control of, or recording by, external equipment (e.g. via Musical Instrument Digital Interface, MIDI) can be outputted from the musical instrument 10, whether instead of, in supplement to, outputting of audible musical output from the speaker 18. These components 18-28 of the instrument 10 are all interconnected, either directory or indirectly, by a bus 30.

[0061] The speaker 18 of the illustrated example in Figures 1 and 2 is an integrated speaker 18 of the smartphone or table 12, though audible musical output may instead be made from an external speaker connected to the instrument 10, whether by wired connection (e.g. USB cable) to the data output port 28, or to a separate analog headphone jack, if so equipped, via analog audio cable; or via wireless (e.g. Bluetooth) connection) to the instrument. For example, in the case of a smartphone or tablet computer with only a singular connection port (e.g. USB-C), the data output port 28 may be used for wired connection of the instrument 10 to an external speaker (e.g. via USB audio) or wired connection of the instrument to external MIDI-receptive equipment 32 for MIDI control thereof, or MIDI recording thereby (e.g. in a digital audio workstation DAW), by MIDI over USB. In examples where the instrument 10 is embodied in a dedicated musical device, not a mobile computing device like a smartphone or tablet, a dedicated MIDI port may be provided. The term speaker is used herein in a broad sense, as a device for emitting audible sound waves, and encompasses a headphone or earphone within the meaning thereof.

[0062] Stored within the storage memory 24 is a software application 36 for implementing the musical functionality of the electronic musical instrument 10, embodied in executable statements and instructions executable by the processor 20 to perform any all processes, steps and functionalities described herein, except for any steps that instead explicitly attributed to performance by the user 34. The software application 36 of the illustrated embodiment is composed of the plurality of different software modules schematically illustrated in Figure 4, including a MultiTouch Surface Control module 38 A, a Quantize & Sample module 38B, a Transpose module 38C, a Convert uString module 38D, a Set MainKey module 38E, an Octave Modulation module 38F, an Activate Region 38G module, an Update Active Regions module 38H, a Deactivate Region module 381, and an Output module 38 J. The purpose, executional details and interaction within and among at least a majority of these various modules are described below in enablement of at least one preferred embodiment of the present invention, though it will be appreciated different subsets of the modules may be omitted in embodiments where novelty and inventive step is possessed among a different remaining subset of the modules. It will also be appreciated that subdivision of various processes, steps and functionalities among different modules of the software application may vary from the particular examples given in the context of the illustrated embodiment, which is modeled after a working pre-commercial prototype of the present invention. Accordingly, any reference herein to particular steps, tasks, processes, functionalities being performed by a specific one of the illustrated modules may instead be attributed more generally to the software application as a whole, whose modular design may vary from that of illustrated embodiment.

[0063] Referring again to Figure 1, the touchscreen 14 is a multi-touch touchscreen 14 capable of simultaneous detection of multiple touches by a respective multiple of the user’s manual digits. In the home screen of the graphical user interface (GUI) displayed on the touchscreen 14 of Figure 1, the software application displays a virtual keypad 40 composed of a two-dimensional grid of individually demarcated keys 16, which in the Figure 1 example are hexagonal in shape and laid out in a hexagonal grid, but may vary in shape and grid format, for which there may be a shape selection submenu 42 in the settings menu 44, as shown in Figure 2A, by which the user 34 can switch the displayed key shape of the keypad 40, for example between hexagonal keys in a hexagonal grid, square keys in an offset square grid, and round keys 16 fitted to a hexagonal grid. The portion of the overall touchscreen surface area occupied by the keypad 40 is be referred to as the playing surface of the instrument 10 in this touchscreen example, where the keys are virtual keys all occupying a singular planar surface. In other embodiments, with physically separate hardware keys, the equivalent to the present playing surface may be referred as a playing area occupied by the physical keys. In the touchscreen implementation, the display may be zoomed in and out in user- controllable fashion, e.g. after selection of a resize option 45 in the settings menu 44 of figure 2A, for example using a conventional “pinch” gesture commonly used for zoom functionality on touchscreen devices, which zoom controls how many, and which, of the keys 16 of the overall keypad 40 are on screen at a given time, thus effectively changing a playable size and / or zone of the overall keypad 40. A touch and drag of the zoomed keypad may be used to change the visible / playable zone, and a double-tap gesture, for example, locking in the selected zoom level and playable zone.

[0064] At such user-adjustable size of the keypad 40, the identically sized and shaped keys 16 each occupy a respective Region of the playing surface grid, and the MultiTouch Surface Control module 38A continuously monitors for user-touch of any of these Regions to detect user “playing” of the respectively displayed key 16 at that Region of the touchscreen playing surface. The illustrated keypad, in totality at its fully zoomed out size, measures seven columns wide and eight rows high, though the arrayed quantity of keys in the total keypad 40 may vary, for example depending on the scale and screen size of the touchscreen-equipped device in which the instrument 10 is embodied.

[0065] Among the many prior art patents referenced above, are electronic musical instruments embodied in touchscreen devices with hexagonal keys two dimensionally arrayed over a playing surface in a hexagonal grid, based on which techniques for programmed display of this type of playing surface, and monitored touch of the respective Regions of the playing surface, is well within the ambit of the person of ordinary skill in the art, and thus not described herein in any further detail. In the software application 36, each Region of playing surface grid is mapped to a respective (x,y) coordinate address of that grid. Owing to hexagonal grid pattern, the x-axis of this coordinate addressing system is a diagonal axis oriented diagonally of the rectangular touchscreen 14, as can be seen in Figure 17, where the coordinate addresses of the hexagonal keys 36 are shown mapped to the playing surface for the reader’s understanding of this staggered grid addressing scheme. As shown, Region (0, 0) is typically situated centrally of the grid and may be referred to as a Home Region, and the key displayed at this central Region (0, 0) may be likewise referred to herein as a Home Key, from which positive x coordinates of the addressing scheme run rightward, negative x coordinates of the addressing scheme run leftward, positive y coordinates of the addressing scheme run upward, and negative y coordinates of the addressing scheme run downward. Explanation of how these address coordinates of the keypad are used will follow hereinafter.

[0066] The musical instrument 10 produces musical sound efficiently & precisely using two distinct types of user input, and a novel process by which those two inputs are cooperatively processed to generate novel musicality unseen in conventional musical practice. The two forms of distinct user input include Keypad Input Data 46 and Continuous Input Data 48 of a linear type, which in the illustrated instance is a continuous input from the accelerometer 26, particularly an input therefrom signifying angular tilt of the musical instrument 10 using gravitational acceleration measurements taken along one of the three orthogonal axes of the instrument’s local coordinate system, which in the illustrated context of a tablet or smartphone embodied instrument is typically characterized by an X-Y plane lying parallel to the touchscreen 14, with the X-axis running laterally of the rectangular touchscreen 14 (along the shorter width dimension thereof) and the Y-axis running longitudinally of the rectangular touchscreen (along the greater height dimension thereof) a Z-axis lying normally thereto. In the present example, the tilt measurement used as the Continuous input data 48 is one measuring tilt of the X-Axis (xTilt), where the tilt is a lateral tilt of the instrument 10 leftward and rightward. In Applicant’s prototype, an xTilt function provides measurement values in radians, in a range of [-7t, 7t], where a zero value denotes a default horizontal orientation of the X- axis in a screen-up orientation of the instrument 10, and -7t and TI denote horizontal orientation of the X-axis in a screen-down orientation of the instrument, with the positive and negative values denoting achievement of such orientation in rightward and leftward tilt, respectively, from the default horizontal orientation. Given the instrument will typically not be played in screen-down orientations, the xTilt values may be clamped to extremes of 7t± / 2. In other implementations, xTilt values may be numerical expression of gravitational acceleration rather than angular measure, varying in absolute value between zero (no gravitational acceleration along the X-axis, denoting a horizontal orientation thereof) and one (1g of gravitational acceleration along X the X-axis, denoting a vertical orientation thereof), with negative values denoting leftward tilt and positive values denoting rightward tilt. Regardless of the numerical form of the accelerometer derived input data, it is scaled by the software application to an open range of (-1, 1), as described in more detail further below.

[0067] Alternate implementations, still using accelerometer input as the Continuous Linear Input Data 48 could instead use tilt measurement along the Y-axis (yTilt), where the tilt is longitudinal tilt of the instrument 10 upward and downward instead of lateral tilt leftward and rightward. In other embodiments, the Continuous Linear Input Data 48 also need not be limited to accelerometer derived instrument orientation data, and may be any Continuous Linear Input that can likewise be scaled to a range of (-1, 1), examples of which include a dial, slider, wheel, mouse, touch strip, sensor, keyboard, trackball, joystick, digital camera, field detector, acceleration, distance, temperature, motion, eye movements, biometric data, etc. Many linear inputs are configured to instead give input in the range of [0, 1], which can likewise be scaled to the usable range of (-1, 1) for the intended purpose of this linear input in the context of the present invention. For example, a mouse pointer location along one of two axes of its two-dimensional coordinate system divided by screen size in that dimension provides a linear input in the range [0, 1], as do many electronic sensors.

[0068] Parallel handling of the Keypad Input Data 46 and the Continuous Linear Input Data 48 is schematically illustrated in Figure 6, where the Keypad Input Data 46 is handled by the MultiTouch Surface Control module 38A in accordance with the more detailed workflow of Figure 8, while the Continuous Linear Input Data 48 is sampled by the Quantize & Sample module 38B in accordance with the more detailed workflow of Figure 13, both of which will be described in more detail further below. As schematically denoted in Figure 6, the sampled instances of the Continuous Linear Input Data 48 ultimately serve to modulate, and more specifically perform an octave-wise modulation of musical output signals instructed from playing of the keypad. Figure 7 illustrates a Region database that stores a respective Regional Dataset for each Region of the keypad 40, which Regional Dataset includes a Position (x,y) constant 50, which Position (x,y) serves as a name or unique identifier for the given Region, and at the same time also a readable address of where that Region resides within the grid pattern of the keypad 40 (column x, row y). For each Region Position (x,y), there is stored a unique BaseValue constant 52, expressed as a unitless ratio of arbitrarily scalar, which in the present microtonal embodiment reflective of a Harmonic Table implementation, has a value BaseValue = 2A((log2(MAx * NAy) - [log2(MAx * NAy)J), or or BaseValue = 2A( x(log2(M)) + y(log2(N)) - [x(log2(M)) + y(log2(N))J). In the present embodiment, M = 5 and N = 3, from which the regional BaseValues of the 7 x 8 keypad are tabulated as follows:

[0069] "(-3, 5)": 1.9439999999999993, "(-3, 4)": 1.2959999999999996, "(-2, 4)": 1.6199999999999999,

[0070] "(-1, 4)": 1.0125000000000002, "(-3, 3)": 1.7279999999999998, "(-2, 3)": 1.08,

[0071] "(-1, 3)": 1.3499999999999999, "(0, 3)": 1.6874999999999996, "(1, 3)": 1.0546874999999993,

[0072] "(-3, 2)": 1.152, "(-2, 2)": 1.4400000000000002, "(-1, 2)": 1.8,

[0073] "(0, 2)": 1.1249999999999998, "(1, 2)": 1.4062499999999991, "(2, 2)": 1.7578124999999993,

[0074] "(3, 2)": 1.0986328124999998, "(-3, 1)": 1.536, "(-2, 1)": 1.9200000000000004,

[0075] "(-1, 1)": 1.2, "(0, 1)": 1.5, "(1, 1)": 1.8749999999999996,

[0076] "(2, 1)": 1.1718749999999996, "(3, 1)": 1.4648437499999998, "(-3, 0)": 1.024,

[0077] "(-2, 0)": 1.2800000000000002, "(-1, 0)": 1.6, "(0, 0)": 1.0,

[0078] "(1, 0)": 1.2499999999999998, "(2, 0)": 1.5624999999999996, "(3, 0)": 1.953125,

[0079] "(-3, -1)": 1.3653333333333335, "(-2, -1)": 1.7066666666666672, "(-1, -1)": 1.0666666666666669,

[0080] "(0, -1)": 1.3333333333333335, "(1, -1)": 1.6666666666666665, "(2, -1)": 1.0416666666666665,

[0081] "(3, -1)": 1.3020833333333335, "(-3, -2)": 1.8204444444444448, "(-2, -2)": 1.1377777777777782,

[0082] "(-1, -2)": 1.422222222222223, "(0, -2)": 1.7777777777777781, "(1, -2)": 1.1111111111111112,

[0083] "(2, -2)": 1.3888888888888888, "(3, -2)": 1.7361111111111114, "(-2, -3)": 1.5170370370370367,

[0084] "(-1, -3)": 1.8962962962962975, "(0, -3)": 1.1851851851851853, "(1, -3)": 1.4814814814814816,

[0085] "(2, -3)": 1.8518518518518519, "(3, -3)": 1.1574074074074077, "(0, -4)": 1.5802469135802473,

[0086] "(1, -4)": 1.9753086419753083, "(2, -4)": 1.234567901234568, "(3, -4)": 1.5432098765432103,

[0087] "(2, -5)": 1.6460905349794241, "(3, -5)": 1.0288065843621403

[0088] The invention is not limited this combination of N, M values, and others that Applicant has experimented with, and found to be functional, with notably different musicality from one another, include M = 3 and N = 5, M = 15 and N = 9, M = 9 and N = 15, M = 9 and N = 7, M = 11 and N = 13, M = 11 and N = 19, which list is not intended to be limiting on the scope of the invention. In alternative to calculation of all the BaseValue constants by the software application itself, they alternatively may be populated into the software application by way of a lookup table.

[0089] The Position (x,y) and BaseValue constant are immutables of the dataset, dependent variables of which include an isActive variable 54 for denoting whether a given Region is active or inactive (eligible or ineligible for generating musical tones that are subject to octave-wise modulation by the Octave Modulation module 38F), a Voice / Channel variable 56 to which an available audio channel is assigned to the Region when activated, a CurrentValue variable 58 that stores a current and optionally transposed value of the BaseValue ratio of the Region, a pitchClass variable 60 that stores a current and optionally transposed pitch class of the Region (the Region Pitch Class rPC), an octave (8ve) variable 62 that stores a current octave value of the Region (Region Octave R8ve), based on a latest modulation thereof by the Continuous Linear Input 48. Additional output-related variables of the dataset of each Region include an isPlaying variable 64 indicative of whether a musical signal is being outputted on behalf of the respective Region, a pitchBend variable 66 and MidiNote variable 68 whose values are populated by conversion of the R8ve and rPC values into MIDI format for outputting of the musical signal in such MIDI format on behalf of the respective Region, and optionally a Frequency variable 70 populated by conversion of the R8ve and rPC values into a frequency value for use in calculation of the MIDI note and pitch bend values and / or usable to output a frequency parameter signal for driving of one or more oscillators of a software synthesizer. The pitchBend and MidiNote variables 68 are useful for cases where the Output Module 38J uses MIDI to playback user-selectable libraries of sampled instrument sounds (e.g. Soundfont SF2 files, as illustrated at a instrument voice selection submenu 72 of the settings menu 44 in Figure 2A), or when the Output Module 38J is bypassed to instead send the MIDI signals to one or more external MIDI devices 32. The frequency variable 70 can instead be used in cases where the Output Module 38J embodies therein one or more software synthesizers for integrated sound synthesis by continuous input of a frequency parameter signal to one or more oscillators of such synthesizer(s). The frequency variable 70 is derivable by multiplying the CurrentValue ratio by a fundamental pitch, expressed in Hertz, for example standard fundamental pitch A = 440 Hz, though as disclosed herein, the fundamental pitch may itself be a user-adjustable variable, allowing the user 34 to vary the tuning of the instrument from standard A = 440.

[0090] The optional transposition of the CurrentValue variable 58 and the pitchClass variable 60 is enabled by a user-controllable transposition functionality, activated on screen in the illustrated embodiment by an on-screen Transpose Button 74 displayed on the same home screen of the GUI as the keypad 40, for example in a common button header shared by a settings button 75 that switches the touchscreen from the home screen of Figure 1 to the settings screen of Figures 22A & 2B. User selection of the Transpose Button 74 triggers calling of the transpose module 38C, the purpose of which is to enable the user 34 to change the value of a MainKey variable 76 that will universally transpose all Regions of the keypad 40 by updating the CurrentValue and pitchClass variables 58, 60 of each Region in the Region database of Figure 7, by running the Set MainKey module 38E in accordance with the illustrated workflow thereof in Figure 12. Absent user adjustment of the MainKey variable through such use of the transpose module 38C, the default value of the MainKey variable is 1.0, the result of which is that the default CurrentValue variable 58 in Figure 7 is equal to the BaseValue variable 52, and the frequency associated with each key is the multiplication product of that key’s BaseValue and the set / stored fundamental frequency (e.g. A = 440), whereby the home key (with a baseValue of 1.0) is tuned by default to the fundamental frequency, absent any user transposition of MainKey. The default Region pitchClass rPC in the present microtonal implementation is the value of the exponent of the above referenced calculation of BaseValue, so pitchClass = log2(NAx * MAy) - log2(NAx * NAy)J, or pitchClass = x(log2(N)) + y(log2(M)) - |x(log2(5)) + y(log2(3))J. The default initial value of the R8ve variable 62, prior to any modulation thereof by the Continuous Linear Input data 48, is R8ve = [log2(NAx * MAy)J or R8ve = |x(log2(N)) + y(log2(M))J.

[0091] The illustrated embodiment has two different transpose modes: Reset Mode, and Iterative Mode, between which user selection is possible via a transpose submenu 78 in the settings menu 44, as illustrated in Figure 2B, where toggling between the two modes sets the value of the transpose mode variable 80 in Figure 5 A between two different values respectively indicative of the two transpose modes. In performance of a transposition in Reset Mode, the MainKey variable 76 (Figure 5 A) is assigned the BaseValue of a user selected key 16 in the keypad 40 (other than the Home Key), whereas in Iterative Mode, the transposition instead assigns MainKey the CurrentValue of such user selected key 16. The flowchart on the right side of Figure 11 illustrates the workflow of the transpose module 38C executed when the user touches the Transpose Button 74 on the home screen of Figure 1, as illustrates at step 1100. At step 1101 a transpose flag is set to an ON state, and the currently set transpose mode (Reset or Iterative) is checked at subsequent step 1102. If the transpose function is set to Iterative Mode, then the workflow jumps ahead to step 1104 to notify the user that transpose is now ON, for example by changing a background colour of the playing surface from a default colour (e.g. white) to a distinctly different transpose-notification colour (e.g. blue). If the transpose function is found to be in Reset Mode at step 1102, then the workflow performs intermediary step 1103 in preceding relationship to step 1104, at which step 1103 the value of MainKey is first reset to its default value of 1.0, though in other embodiments, the reset value could be set to values other than 1.0 (e.g. via user adjustability of a variable reset value).

[0092] The related flowchart on the left side of Figure 11 illustrates workflow that occurs at step 801 of the Figure 8 workflow executed in response to each touch of the keypad 40 of the playing surface at preceding step 800. At step 1105, the keypad touch 800 triggers a check of whether transpose is ON or OFF, and if found to be OFF, then the rest of the Figure 11 transposition workflow is bypassed at step 1106, and the Figure 8 workflow (described further below) continues to process key touches in a default manner, for the purpose of playing the instrument rather than implementing transposition of the keypad. If it is found at step 1105 that transpose is ON, then the rest of the Figure 8 is bypassed, the Region Position(x,y) of the touched key 16 is identified at step 1107, and transpose is set back to OFF (the default setting) at step 1108. At next step 1109, a check is made of the currently set transpose mode. If the transpose function is found to be in Reset Mode, then step 1110A is performed to retrieve the BaseValue of touched Region Position(x,y). If the transpose function is instead found to be in Iterative Mode, then alternative step 1110B is performed to instead retrieve the CurrentValue of touched Region Position(x,y). This retrieved BaseValue or CurrentValue of the touched Region Position(x,y) is then passed to the Set MainKey module 38E at final step 1111 of the Figure 11 Transpose module workflow.

[0093] The workflow of the Set MainKey module 38E is shown in Figure 12, where the updated MainKey value from the transpose module 38C is received at step 1201, and fed into a loop at step 1202 for updating the CurrentValue and Region pitchClass rPC of every Region of the keypad 40, one by one, thus setting each and every Region to the newly transposed MainKey. In this loop, first the BaseValue of the given Region Position(x,y) is retrieved from the Region database of Figure 7 at step 1203, and this retrieved BaseValue is multiplied by the updated MainKey value at step 1204, for the purpose of deriving an updated CurrentValue for the given Region of the keypad 40. The CurrentValue of a given Region however must be constrained to [1 < CurrentValue < 2], and so at step 1205, the Set MainKey module 38E checks whether the calculated multiplication product of the retrieved BaseValue and the received MainKey value exceeds 2.0, and if so, this product is divided by 2.0 at step 1206 (reducing it by one octave). The resultant value from step 1205 or 1206 is then assigned as the updated CurrentValue of the given Region Position(x,y) at step 1207, terminating the current iteration of the loop at step 1208, from which the loop 1203-1208 is repeated until all Regions of the keypad 40 have been set to the transposed MainKey, thus completing the Set MainKey workflow at step 1209.

[0094] Turning back to Figure 8, which illustrates handling of key touches of the playing surface keypad 40 by the MultiTouch Surface Control module 38 A, in instances where a given key touch is passed through at steps 801 and 1105, rather than diverted through transposition steps 1107- 1111 of Figure 11, the MultiTouch Surface Control module 38 A, at least in the illustrated embodiment, then checks at step 802 which one of two different playing modes the musical instrument is current in: a Touch Mode or a Hold Mode, between which user selection is enabled by a playing mode submenu 82 in the settings menu 44 of Figure 2A, which user-selection is stored in the PlayMode variable 84 of Figure 5B. In Touch Mode, the keys 16 of the keypad functionally behave like keys of a conventional keyboard instrument: when a key is touched, it is active for sound-making purpose, and when the touch is removed, any sounded note made on behalf of that key ceases. Hold Mode deviates from this conventional key behaviour and instead uses each touch as a “toggle” that switches the key’s respective Region Position(x,y) in the keypad 40 between an active state and an inactive state. That is, each key touch thus “activates” or “deactivates” the respective Region Position(x,y) of the playing surface keypad 40. As explained in more detail further below, activation of a Region does not always trigger generation of a musical output signal, at least in the illustrated embodiment with additional functionalities (threshold and rest) that will impact whether a given activation triggers musical output or not, though in simpler embodiments of reduced functionality (e.g. lacking threshold and rest functions), activation may instead always correlate with musical output. With continued reference to Figure 8, if the instrument 10 is in Touch Mode, which will typically be the default playing mode given its familiar analogous relationship to conventional keyboard instruments, then the module monitors for changes in touched and untouched statuses of all the Region Positions(x,y) of the keypad at step 803. In the event of a new touch (Touch Down) detected at a given Region Position(x,y) at step 803, the module calls the Activate Region module at step 804A and passes thereto the identification of that newly touched Region Position(x,y) for activation thereof. Detection of touch movement within the boundaries of a touched Region (TouchMovesWithin) does not trigger deactivation of the given Region, and instead maintains the active status thereof. In the event of a touch removal (Touch Up) detected at a given Region Position(x,y) at step 803, the module instead calls the Deactivate Region module at step 804B and passes thereto the identification of that Region Position(x,y) for deactivation thereof. Detected movement of a touch from inside the boundaries of an already touched Region Position(x,y) to fully outside the boundaries thereof (TouchMovesOut) likewise triggers deactivation of that given Region, and activation of any neighbouring region into which that touch is moved, where this is detected as a new touch (Touch Down or Touch Moves Within) of that neighbouring region (if not already active, for example under prior touch thereof by another finger of the user 34).

[0095] If at step 802, the MultiTouch Surface Control module 38A instead detects that the instrument 10 is in Hold Mode, then the module bypasses steps 803-804 and instead monitors for any new touches (Touch Down) at any of the Region Positions(x,y) of the keypad at step 805. In the event of a new touch (Touch Down) detected at a given Region Position(x,y) at step 805, the module first checks at step 806 whether that given Region is currently active or inactive. If found to be already active, then the module calls the Deactivate Region module at step 807A and passes thereto the identification of that Region Position(x,y) for deactivation thereof. If the newly touched Region is instead found to be inactive, then the module instead calls the Activate Region module at step 807B and passes thereto the identification of that Region Position(x,y) for activation thereof. In Hold Mode, lack of any detected touches results in no action taken. Hold Mode allows the instrument 10 to be played without continuous touch of the keypad 40, and is preferably accompanied by visual feedback on the touchscreen 14 of which Region Positions(x,y) are currently active, for example by a visual “glow” or “highlight” effect displayed by the respective keys 16 of those active Regions. This visual distinction of active keys may also be imparted in Touch Mode, though less essential therein given the inherent visual feedback on which keys 16 are active, given the occupation thereof by the user’s fingertips. In brief summary of the novel hold mode, each touched key is held or latched in its active state in automated fashion by the instrument itself, until such time as that same key is touched again. This diverges from the “hold” or “latch” function provided on some commercially available keyboard synthesizers, where activation of a hold button enables self-latching or self-hold (sustain) of the note sounded by that key, but a later replaying of that same key does not release the latched or held state of its note.

[0096] Figure 9 illustrates the workflow of the Activate Region module 38G called by steps 804 A and 807B of the Figure 8 workflow of the MultiTouch Surface Control Module 38 A. At step 901, the Activate Region module 38G receives identification of the Region Position(x,y) being activated. From among a plurality of audio channels available (in enablement of polyphonic output from the instrument 10), the module 38G, at step 902, identifies an available audio channel and assigns it to the identified Region Position(x,y) by assigning a unique identifier of that available audio channel to the Voice / Channel variable 56 in the Region database. The module 38G sets the isActive variable 54 of the given Region Position(x,y) to YES / TRUE at step 903, and retrieves the CurrentValue of the given Region Position(x,y) at step 904. At step 905, the module 38G calculates the base two logarithm of the updated CurrentValue, referred to here as logRatio for brevity, as a useful precursor to calculation of the current Region Octave R8ve and Region pitchClass rPC, respectively calculated in next steps 906 & 907. The Region Octave R8ve is calculated as the floor of the calculated logRatio (R8ve = [logRatio]), and stored as the R8ve variable 62 in the Region database. The R8ve variable calculated at step 906 will, by default, initially have a value of zero the first time it is activated. The Region pitchClass rPC is calculated as rPC = logRatio - [logRatio], and is likewise stored in the Region database as rPC variable 60.

[0097] Figure 10 illustrates the workflow of the Deactivate Region module 381 called by steps 804B and 807B of the Figure 8 workflow of the MultiTouch Surface Control Module 38 A. At step 1001, the Deactivate Region module 381 receives identification of the Region Position(x,y) being deactivated, and at step 1002 terminates any current musical output signals being outputted on behalf of that identified Region Position(x,y), whether by ceasing transmission of a continuous frequency parameter signal to one or more oscillators of a software synthesizer, and / or sending of a MIDI note-off signal to terminate MIDI playback or recording. Having terminated any such musical output signals, the isPlaying variable 64 for the given Region Position(x,y) in the Region database is set to NO / FALSE at step 1003, the audio channel previously assigned to the given Region Position(x,y) is unassigned at step 1004, rendering that channel available for any other Region Position(x,y) subsequently activated, and the isActive variable 54 of the given Region Position(x,y) is set to NO / FALSE at step 1005.

[0098] Having dealt with how imparted and released touch of the playing surface keypad 40 is interpretable as commands to activate and deactivate the different Region Positions(x,y) of the playing surface, thereby enabling user playing of the keypad 40 of the playing surface with the fingertips of one or more digits of one or both hands, attention is now turned to the handling of the Continuous Linear Input by which musical tones instructed by such keypad playing of the instrument are modulated in a novel octave-wise fashion. In the illustrated embodiment, instead of sampling the Continuous Linear Input Data 48 at fixed timing intervals, the preferred implementation employs a variable quantization approach to the sampling and modulation evaluation process, where the Continuous Linear Input is instead sampled at an adjustable timing interval (quantization interval), that can be user-adjusted in the settings menu 44 at a quantization adjustment tool 86 thereof, illustrated in Figure 2B. The illustrates quantization adjustment tool 86 is implemented as a slider adjustment enabling user variation of the quantization interval within a predefined range, displayed by an accompanying numerical readout of the currently set value. The user-set value can be stored as the Quantization Timelnterval variable 88 of Figure 5 A. That said, Quantization Timelnterval 88 may alternatively be variably controlled by a variable control input CI2, schematically shown at 90 in Figure 5B, enabling real-time variation of the Quantization Timelnterval 88 on the fly during playing of the instrument 10, independently of the settings menu 44. Such variable control input CI2 may be a local control input or device parameter, for example a prerecorded rhythm sequence or an accelerometer measurement discrete from that used as the Continuous Linear Input (e.g. y Tilt as the former, and xTilt as the latter), or an auxiliary or external control input originating from an external source, and communicated to the instrument on a dedicated or broadcasted basis. The quantization adjustment tool 86 in the settings menu 44 may therefore be used to dictate a default value of Quantization Timelnterval 88 in the absence of any auxiliary control input CI2 optionally routed to variably control the quantization interval.

[0099] The quantization approach to the sound modulation is governed by the Quantize & Sample module 38B, whose workflow is schematically illustrated in Figure 13, and whose purpose is to receive and handle the Continuous Linear Input Data, as schematically denoted at 1300. Like the MultiTouch Surface Control module, the Quantize & Sample module 38B runs continuously. To start, the Quantize & Sample module 38B monitors for expiration of the Quantization Timelnterval at step 1301, for example running a timer from the previously lapsed quantization interval and comparing same against the current value of the Quantization Timelnterval, whether fixed by the quantization adjustment tool 86 or variably controlled by auxiliary control input CI2 shown at 1301 A. Upon expiration of the quantization interval, the module 38B takes an instantaneous sample value of the Continuous Linear Input Data 48 (e.g. xTilt from the accelerometer 26) at step 1302, or alternatively samples an input at any triggered instance denoted by receipt of a trigger signal from an external control trigger schematically shown at 1302 A. The sampled value is stored as the SampleValue variable 91 in Figure 5 A.

[0100] The present embodiment includes a user controllable gate, implemented by the UserGate variable 92 of Figure 5A, that by default is assigned an open status that, anywhere this UserGate is implemented in the data workflow, permits passage of data onwardly past this point of the workflow, but is user-switchable to a closed status preventing such onward passage of data to bypass remaining downstream steps of that workflow. Figure 13 includes one such gated instance in the workflow at step 1303, where if the UserGate is open, the sampled instantaneous value of the Continuous Linear Input 48 obtained at step 1302 is passed through for subsequent processing, but if the UserGate is closed, that sampled instance of the Continuous Linear Input 48 is instead discarded, and not processed any further, with the result that any musical output signals outputted on behalf of active Regions of the keypad 40 are not subjected to octave-wise modulation by this sampled instance of the Continuous Linear Input 48. Any such musical output signals already being outputted by the output module 38J at the time of the gate-discarded sample of the Continuous Linear Input 48 was taken at step 1302 thus continue to be outputted (so long as the associated Active Regions on behalf of which they are being outputted continue to be active) in a manner unaffected by the latest sampled instance of the Continuous Linear Input 48, rather than being modulated thereby in an octave-wise fashion that would otherwise occur if the UserGate were open.

[0101] The UserGate is thus usable to sustain any already outgoing musical output signals in a manner unmodulated by the Continuous Linear Input 48 so long as the UserGate remains closed. 1

[0102] User control over the open and closed status of the UserGate in the illustrated embodiment is implemented by a multipurpose Flush or Sustain button 94 displayed on home screen of the GUI in nearby adjacency to the playing surface occupied by the keypad 40, for example in neighbouring or nearby relation to the Transpose Button 74. Touch of this Flush or Sustain Button 94 at one subRegion 94A thereof, e.g. a right subRegion thereof, closes the UserGate (sets UserGate variable 92 to a closed status), and maintains the closed status thereof so long as that touch is maintained, and reopens the UserGate upon removal of that touch from this sustaining subRegion of the Flush or Sustain Button 94. Touch of this Flush or Sustain Button 94 at another subRegion 94B thereof, e.g. a left subRegion thereof, instead functions to flush (stop) all outgoing musical output signals being outputted at the time when this flushing subRegion 94B of the Flush or Sustain Button 94 is touched, effectively silencing / muting / pausing such musical output (whether that be audible output from the instrument itself or connected audio equipment, or outbound MIDI signals from the instrument to any connected MIDI devices). A Flush Button variable 95 dependent on the touched or untouched status of this flush controlling subRegion 94B of the Flush or Sustain Button 94 may be employed track the status of the flushing function for algorithmic use thereof in workflow described further below.

[0103] This silenced / muted / paused state is maintained so long as that touch of the flushing subRegion 94B of the Flush or Sustain Button 94 is maintained. This enables to user to perform a “rest” of the outputted tone(s), but without deactivating any Active Regions of the keypad, which therefore remain eligible for modulation by any sampled instances of the Continuous Linear Input Data 48 received during such rest. Upon release, outputting of the rested musical output signal(s) will resume, in modulated fashion based on any sampled and processed (not gate-discarded) instances of the Continuous Linear Input Data were received during the rest. In other embodiments, the sustain and flush functions may be mapped to visually separated buttons in the GUI, in contrast to the example where the subRegions of the home screen assigned to these functions are located within the bounds of a singularly visualized Flush or Sustain Button 94, within which boundaries a user can slide their touch from one subRegion to the other without triggering any other functionality assigned to any intervening other button, whereby the two subRegions 94A, 94B of this multipurpose Flush or Sustain Button 94 operate as separate but neighbouring buttons, even if not visually demarcated from one another as such, like the individually demarcated keys 16 of the keypad 40. Optionally, the Sustain Button 94 may have a reversed polarity, such that by default it is closed and all messages are discarded until a user touch opens the gate whereupon the messages resume.

[0104] Turning back to Figure 13, having now described operation and user-control over the UserGate that is implemented at step 1303 in dependent relation to either user input at the Flush or Sustain Button 94, or some other optional control input CI3 to the UserGate sustain functionality (e.g. footswitch or other external signal source), as schematically illustrated at 1303A of Figure 13 and 96 of Figure 5B, attention is turned to remaining steps of the Figure 13 workflow. A second gate in this workflow is implemented at step 1304, this time a threshold gate that checks to see whether the value of a Threshold Value variable 98 (Figure 5B) is exceeded by a threshold gate control input CI4, shown schematically at 100 in Figure 5B. The threshold gate control input CI4 may, for example, be based on one or more input measurements from the accelerometer 26 of the musical instrument 10. In one example, the threshold gate control input CI4 is a calculated vector magnitude of the instrument’s acceleration, calculated as llvll = (x2+ y2+ z2), where x, y and z are simultaneous acceleration measurements from the accelerometer from along its three coordinate axes X, Y, Z. In this example, the threshold gate at step 1304 is only opened if llvll > Thresholdvalue, meaning that octave-wise modulation and triggering of new musical output signals only occurs only if the musical instrument 10 is experiencing acceleration of greater magnitude than the Thresholdvalue.

[0105] The user can thus vary how often modulation and new output occurs not only through adjustment of the Quantization Interval in the settings, but also in real-time dynamic control of the instrument by varying the amount of acceleration applied to the instrument in handheld manipulation thereof, moving it slowly in some instances and rapidly in others. In an alternative example, in which the lateral xTilt measurement from the accelerometer 26 of the musical instrument 10 is used as the Continuous Linear Input Data 48 inputted at 1300, the longitudinal y Tilt measurement from the accelerometer 26 may be used as the gate control input CI4 to the threshold gate, whereby compound tilting of the musical instrument in lateral and longitudinal directions is used to influence the how often musical output signals are modulated and outputted. The ThresholdValue variable 98 may be inputted or variably controlled via another control input CI5, schematically shown at 102 in Figure 5, whereby the comparison at step 1304 is whether CI4 > CI5, as shown at gate control decision 1304A. Though not specifically illustrated, the settings menu 44 may include user manipulatable options for setting what parameter is assessed by the threshold gate, and setting what value or control input is used to dictate the Thresholdvalue used by the Threshold gate to make such assessment.

[0106] If the threshold gate at step 1304 is closed, then the sampled instantaneous value of the Continuous Linear Input 48 obtained at step 1302 is discarded and not processed any further, with the result that any musical output signals instructed Active Regions of the keypad 40 are not subjected to octave-wise modulation by this sampled instance of the Continuous Linear Input 48, and no new sounds are outputted on behalf of that Active Region. If the Threshold gate at step 1304 is open, then this sampled instance of the Continuous Linear Input 48 is instead confirmed at step 1305 as usable input (SampledValue) to the convert uString module 38D, and is outputted thereto at step 1306 for the purpose of converting the sampled instantaneous value of the Continuous Linear Input 48 into a musically useful data format composed of an 8ve value and Pitch Class value of equivalent data format as the Region Octave R8ve and Region pitchClass rPC of each Region Position(x,y) of the keypad 40.

[0107] The illustrated embodiment is capable of employing either user-selectable one of two conversion modes that ultimately arrive at such musically useful data format: a uString conversion mode of logarithmic character that covers the entire audible range, and a Linear conversion mode that instead imposes limits on the octave modulation imparted by the Continuous Linear Input Data, for example limiting such modulation to 3, 4, or 5 octaves (i.e. + / -1.5, + / -2.0, + / -2.5). User selection between these conversion modes is enabled via a conversion type submenu 104 of the settings menu 44, as shown in Figure 2B, with a toggle option 104 A for switching between uString and Linear modes of input conversion, and an octave-limit selector 104B for choosing between at least two, and three in the illustrated example, different octave limit options. The chosen conversion type is saved as the uString / Linear variable 106 shown in Figure 5B, and in case of Linear mode being chosen, the Linear Range variable 108 is updated to reflect any user change of the octave-limit from its default value. In the event that the conversion type submenu 104 is set to uString, the octavelimit selector 104B switches to a uString type selector for selecting between different uString types (explained in more detail further below), with any user change of the displayed uString types from a default value being accordingly recorded in the uString Type variable 110. The term uString, to the best of the Applicant’s knowledge, is one that was coined by the inventor, and should not be confused with any other known use of such term that may exist in other literature, nor be interpreted to have any supplemental or alternative meaning beyond that in which it is used herein and in the inventor’s cited prior literature.

[0108] The workflow of the Convert uString module 38D is shown in Figure 14, and starts at 1400 with receipt of the SampledValue of the Continuous Linear Input Data 48 from the Quantize & Sample workflow of Figure 13, or retrieval thereof from stored SampleValue variable 91. At step 1401, the Convert uString module 38D checks the uString / Linear variable 106 to determine the user- specified type of conversion to be undertaken on the stored SampleValue 91. If the conversion type is found to be set to Linear, then at step 1402 the Convert uString module 38D retrieves the stored ±octave range value in the Linear Range variable 108, and at step 1403 converts the SampledValue into its musically usable form by scaling the SampledValue to the ±octave range specified by the Linear Range variable 108. So, for example, if the user set the octave range limit to four (meaning ±2.0), then the Sampled Value is scaled to a range of -2.0 to 2.0, and that scaled conversion of the SampledValue is saved as the Converted Value variable 112 of Figure 5A at step 1409. This Converted Value is a musically usable decimal number whose integer value denotes an octave (8ve) of this Converted Value, and whose mantissa denotes a pitch class (PC) of this Converted Value, thereby completing linear conversion of the SampledValue of the Continuous Linear Input Data 48 into a musically representative value.

[0109] Returning back to step 1401, if the Convert uString module 38D instead determines that the conversion mode is set to uString, then steps 1402-1403 are bypassed in favour of step 1404, which then checks which uString type has been set by default, or by user-selection from the settings menu 44, by checking the present value of the uString Type variable 110. In the illustrated embodiment, there are three uString types: a default Universal String, a Physical String analogous to a guitar or cello string, and an Inverse String. If the default Universal String is the set uString type, then the SampledValue is scaled to the open range of (-1, 1) at step 1405A. If the Physical String is the set uString type, then the SampledValue is instead scaled to the closed-bottom opentop range of [0, 1) at alternative step 1405B. If the Inverse String is the set uString type, then the SampledValue is instead scaled to the half-open half-closed range (-1, 0] or [0, -1) at alternative step 1405C. The scale ranges are open at their extreme values of +1 and -1 to prevent zero- denominator calculation errors in the subsequent calculation steps, which error prevention can be achieved by clamping the extreme limits of -1 and 1 to close approximations thereof at sufficiently long number of significant digits, for example -0.9999999 and 0.9999999 respectively, or some other repeating string of 9’s to a suitable number of significant digits.

[0110] Next at step 1406, the Convert uString module 38D checks whether the scaled SampleValue (x) is greater than or equal to zero, in order to decide which one of two different conversion calculation options to perform next to derive a ModifiedSampleValue (z). If x > 0.0, then the Convert uString module 38D performs calculation of z = l / (l-x) at step 1407A. If x < 0.0, then the Convert uString module 38D instead performs calculation of z = 1 + x at step 1407B. Next at step 1408, the Convert uString module 38D takes the base two logarithm of ModifiedSampleValue z, the result of which is the musically useful ConvertedValue of the SampledValue, which ConvertedValue variable 112 is then stored at step 1409. As already described for the alternate linear conversion workflow path that ultimately arrives at this same step 1409, the ConvertedValue is a musically usable decimal number whose integer value denotes an octave (8ve) of this musically usable number, and whose mantissa denotes a pitch class (PC) of this musically usable number. The convert uString module thus effectively converts any usable Continuous Linear Input Data 48 into a musical value whose constituent parts (integer & mantissa) are in equivalent data format to the Region pitchClass rPC and Region Octave R8ve of each Regional Dataset in the Region database of Figure 7. A final step 1410 in the Convert uString workflow of Figure 14, is passage of the calculated ConvertedValue from the Convert uString module 38D to the Octave Modulation module 38F.

[0111] Before turning to the workflow details of the Octave Modulation module 38F, illustration of which is given in Figures 15A and 15B, attention is once again turned to the settings menu 44 of Figure 2A, which in the illustrated embodiment includes a polyphonic / monophonic selector 114 for user-selection between polyphonic and Monophonic Modes of the instrument 10. In polyphonic mode, any and all active Regions are subjected to octave-wise modulation in the Figure 15A workflow of the Octave Modulation module 38F. In contrast, in Monophonic Mode, the octave-wise modulation is performed in Figure 15B on only a singular one of the active Regions, and more particularly to a one thereof that is found to be closest in pitch class to the uString point denoted by the ConvertedValue 8ve.PC. User manipulation of the polyphonic / monophonic selector 114 in the settings menu 44 switches the value of a Polyphonic / Monophonic variable 116 between two possible states each indicative of a respective one of these two modes.

[0112] Having established the illustrated embodiment’s inclusion of switchable polyphonic and Monophonic Modes, Figure 15A shows a mainly polyphonic branch of the workflow of the Octave Modulation module 38F, a remaining monophonic branch of which is shown in accompanying Figure 15B. This multi-branch workflow of the Octave Modulation module 38F is triggered by the final step 1410 of the Convert uString module 38D, and starts at 1501 of Figure 15A with receipt of the Converted Value therefrom. At step 1502, the Octave Modulation module 38F checks whether the instrument is in Polyphonic or Monophonic Mode. If found to be in Polyphonic mode, the module 38F identifies any and all Active Regions at step 1503, for example by checking the isActive variable 54 of every Regional Dataset in the Region database. For each Region Position(x,y) whose isActive status is found to be YES / TRUE, the Octave Modulation module 38F then starts execution of a processing loop at step 1504 to individually process each such identified Active Region in a respective iteration of this loop. The processing loop performs a comparative evaluation between the Pitch Class PC of the Converted Value 8ve.PC received from the Convert uString module 38 and the Region pitchClass rPC of the active Region being processed, as recorded in the pitchClass variable 60 of the Regional Dataset of that active Region. First, the Octave Modulation module 38F retrieves the Region Pitch Class rPC of the active Region at step 1505, and then checks whether rPC > PC at step 1506. If it is found that rPC > PC, then rPC is left unchanged as schematically denoted by step 1507A.

[0113] On the other hand, if it is found that rPC < PC, then the recorded rPC in the pitchClass variable 60 (a decimal value with a zero integer) has a one added thereto at alternative step 1507B, which in the data format 8ve.PC denotes the addition of an octave thereto (O.rPC + 1 = l.rPC). The resultant value from step 1507A or 1507B then has the 8ve value of the Converted Value added thereto at step 1508, thus calculating an updatedR8ve.rPC for the active Region Position(x,y), by which the Active Region inherits the octave of the Converted Value of the sampled Continuous Linear Input 48. As schematically denoted by step 1509, it is evaluated whether the value of updatedR8ve is unequal to the currently recorded R8ve value of pitchClass variable 60 of the active Region, i.e. whether the comparative evaluation and inheritance of the Converted Value Octave has resulted in a change of octave or not. If a change in Octave is found to have occurred, then updatedR8ve is deemed to constitute, or be part of, a newRegionValue(x,y) at step 1510 that needs to be assigned to the evaluated Active Region in place of the currently recorded R8ve thereof to dictate the octave of a musical output signal to be outputted on behalf of that Active Region. To initiate such Active Region update and musical signal output, the Octave Modulation module 38F calls the Update Active Regions module 38H at step 1511. On the other hand, if updatedR8ve is found to be equal to the currently recorded R8ve variable 60 of the active Region at step 1509, then no updating of the Regional data set of this active Region is required or performed, and steps 1510- 1511 are bypassed, and the processing loop of steps 1504-1511 is repeated until all Active Regions have been processed, upon which the Octave Modulation workflow ultimately terminates at step

[0114] 1512.

[0115] Turning back to step 1502, if the Octave Modulation module 38F instead found the instrument 10 to be in Monophonic Mode, the module 38F bypasses steps 1503-512 of Figure 15A, in instead runs the monophonic branch of the workflow shown in Figure 15B, which starts at step 1513 by identifying all presently Active Regions, in matching fashion to step 1503 described above, which alternatively can be performed prior to decision step 1502 to omit the need the need for step

[0116] 1513, but which is included nonetheless in Figure 15B to illustrate the monophonic branch of the workflow as a totality on one page. In setup of a search of the Active Region of nearest Region pitchClass rPC to the Converted Value 8ve.PC, the Octave Modulation module 38F at step 1514 initializes a set of search variables: a candidateRegion variable for holding the Position(x,y) identity of a candidate Active Region at any point in the search, a candidateAdjustedPitch variable for holding an octave-adjusted Pitch Class effectivePitch of that candidate Active Region, and a minDiff variable for holding the calculated Pitch Class difference between the effectivePitch of that candidate Active Region and the Converted Value from the uString Conversion module.

[0117] At step 1515, the Octave Modulation module 38F then starts execution of a processing loop to individually process each identified Active Region in a respective iteration of this loop. At first step 1516 of this processing loop, the module 38F calculates a normal difference (diffNorm) as the absolute value of the difference between the Region pitchClass rPC of the current Active Region and the Pitch Class PC of the Converted Value according to diffNorm = abs(rPC - PC). At next step 1517, the module 38F calculates a wrapped difference (diffWrap) as diffWrap = abs((rPC +1) - PC) that accounts for the known “wrap around” phenomenon of musical pitch, which if unaccounted for, could result in false positives in the search for nearest region pitchClass rPC to the Converted Value Pitch Class PC. At next step 1518, the module 38F assesses which of these two calculated differences is the lesser of the two. If diffWrap is found to be less than diffNorm, then at step 1519A an effectivePitch of the Active region is set as effectivePitch = rPC + 1 (the Region pitchClass shifted one octave up, in equivalency to step 1507B of the polyphonic processing loop of Figure 15 A), and a confirmed difference variable (diff) of Active Region is set to diffWrap (diff = diffWrap). On the other hand, if diffNorm is found to be less than diffWrap at step 1518, then at alternative step 1519B the effectivePitch of the Active region is instead set as effectivePitch = rPC (the Region pitchClass, unshifted, in equivalency to step 1507A of the polyphonic processing loop of Figure 15 A), the confirmed difference is set to diffNorm (diff = diffNorm). Next, at step 1520, the module 38F checks whether this confirmed difference of the given Active Region is the closest so far found to the Converted Value Pitch Class PC, by checking whether diff < minDiff. If yes, then at step 1521, the set of search variables are update with the details of this most recently evaluated Active Region, by setting: candidateRegion = Position(x,y) of this evaluated Active Region, candidateAdjustedPitch = effectivePitch of this evaluated Active Region and minDiff = diff of this evaluated Active Region. If minDiff is found at step 1520 to already contain a lower value than diff, then step 1521 is bypassed (leaving the search variable set unchanged), and the search & processing loop repeats at step 1522 until all Active Regions have been evaluated, whereupon the search variable set will be populated that the details of the Active Region having the closest Region pitchClass rPC to the Converted Value Pitch Class PC.

[0118] At step 1523, having completed the search & processing loop, the Active Region currently identified by its Position(x,y) in the candidateRegion variable of the search variable is assigned thereto a newMonoRegi on Value = candidateAjustedPitch + 8ve. In other words, the octave 8ve of the Converted Value is added to the effectivePitch of the Active Region that was found to be closest to the Converted Value or uString Point, whereby this confirmed-closest Active Region inherits the octave of the Converted Value of the sampled Continuous Linear Input 48, in equivalent fashion to step 1508 of the polyphonic processing loop of Figure 15 A. As schematically denoted by step 1524, the module 38F then evaluates whether the octave and pitch class values of the newMonoRegion Value are unequal to those of any musical output signal already being outputted, i.e. whether the derived newMonoRegi on Value signifies that a change in musical output signal is necessitated from what is already being currently being outputted in this Monophonic Mode. If a change is found to have occurred, then newMonoRegi on Value should be adopted to dictate the octave of a new musical output signal to now be outputted in place of the prior musical output signal, and on behalf of this confirmed closest Active Region. To initiate such update of both this Active Region and the musical output signal being outputted, the Octave Modulation module 38F calls the Update Active Regions module 38H at step 1525. On the other hand, if newMonoRegi on Value is equal in octave and pitch class to the existing musical output signal, then no change is found at decision step 1524, then no updating is required of the Regional data set of this active Region nor of the already outputted musical output signal, and the Octave Modulation workflow is terminated at step 1526.

[0119] The polyphonic workflow of the Update Active Regions module 38H is illustrated in Figure 16A for instances where the instrument is in Polyphonic Mode. The purpose of which is to update the musical output signal(s) outputted on behalf of the active Regions, whether that be initiation of such output on behalf of one or more Active Regions on behalf of which no musical output signals were already being outputted, and / or change the musical output signals of one or Active Regions for which output was already being outputted given change(s) in octave imparted by the Octave Modulation module on such Active Region(s). First at step 1601, the module 38H receives the newRegionValue(x,y), which contains at least the Updated Region Octave updatedR8ve, and may also contain the Region pitchClass rPC, for example as a combined decimal value updatedR8ve.rPC. Next, at step 1602, the module 38H checks whether the given Active Region has its isPlaying variable set to YES / TRUE, indicative that a musical output signal is already being outputted on behalf of that Active Region. If so, then the module stops such musical output, whether in the form of a frequency parameter signal whose stoppage is shown at 1603 A, a MIDI signal whose stoppage is shown at 1603B, or a combination thereof. Such stoppage may be documented in a dynamically updated database of actively outputted notes of all active Regions, as shown at 1604.

[0120] If the isPlaying variable was instead found to be set to NO / FALSE at step 1602, then such musical signal stoppage at 1603 A and / or 1603B is instead bypassed, and the workflow jumps to step 1605, where the updatedR8ve is used, in combination with received or retrieved Region pitchClass rPC, to calculate an updated CurrentValue for the Active Region as 2A(updatedR8ve.rPC). Next at step 1607, the module 38H uses the updated CurrentValue updatedR8ve.rPC to calculate a frequency for the intended musical output signal to be generated, by multiplying the updated CurrentValue updatedR8ve.rPC of the active Region by the fundamental pitch. Referring momentarily to Figure 5A, the fundamental pitch (e.g. standard fundamental pitch A = 440) is stored in memory as a global parameter 118, and may be accompanied by a finetuning variable 120 whose value is user-adjustable via a fine tuning tool 122 in the settings menu, shown in Figure 2B as a slider adjustment enabling user adjustment of a finetuning ratio whose default or user-adjusted value is stored in said finetuning variable 120. Multiplication of the fundamental pitch by this finetuning ratio enables user-adjustment of the fundamental pitch within a predefined range, for example enabling adjustment of default fundamental pitch (e.g. A = 440) by ±A tone, for alternate tuning of the instrument 10. So, at step 1606 of Figure 16A, the updated CurrentValue updatedR8ve.rPC of the active Region is therefore multiplied by the fundamental pitch (and the finetuning ratio, in embodiments incorporating such capability) to derive the frequency for the intended musical output signal to be outputted on behalf of the given active Region.

[0121] In embodiments or scenarios where a musical output signal is to be outputted in MIDI format, the frequency from step 1606 is converted at step 1607 to MIDI note and pitch bend, using known MIDI note calculation midi note = 12 * log2(frequency / 440) + 69, and converting the mantissa of any resulting decimal number to a pitch bend, for example converting mantissa of 0.5 or less directly to a pitch pend, and for mantissa above 0.5, instead shifting the MIDI note up one, and calculating a pitch bend of the mantissa minus one: let midiFloat = 12 * log2(frequency / 440.0) + 69.0 var midiNote = Int(midiFloat) let mantissa = midiFloat - Double(midiNote) var pitchBend: Double if mantissa >= 0.5 { midiNote += 1 pitchBend = mantissa - 1.0

[0122] } else { pitchBend = mantissa

[0123] } midiNote = max(0, min(127, midiNote)) let pitchBendValue = UIntl6((pitchBend * 8192).rounded() + 8192) return (midiNote, pitchBendValue)

[0124] Steps 1605-1607 include therein, or are accompanied by, update of the Regional dataset in the Region Database of Figure 7, as shown schematically at 1608, which update includes at least the updated CurrentValue and the updated Region Octave (updatedR8ve), which may be accompanied by updated storage of the calculated frequency, MIDI note and pitchBend, or any subset thereof. At step 1609, the formulated MIDI and / or frequency parameter musical output signals are then documented in the dynamically updated record of outputted notes at 1604, and actualized by the Audio Output module 38J at step 1610 as audio signals to the integrated or connected speaker(s) to create audible sound, or as transmitted MIDI signals to external MIDI equipment for audible sounding or recording thereby, as schematically illustrated. At 1611 is schematically shown use of the flush function of the Flush or Sustain button 94 to impart a musical rest by silencing any and all actively outputted notes in dynamically updated database. Meanwhile, the Currentvalues of all Active Regions have been updated, and the flush function 1611 has no impact on continued processing by the Octave Modulation module of any sampled instances of the Continuous Linear Input Data 48 at Quantization Intervals occurring during the musical rest so that outputted musical signals, once resumed after the musical rest, will reflect the latest influence of the Continuous Linear Input Data 48.

[0125] The monophonic workflow of the Update Active Regions module 38H is illustrated in Figure 16B for instances where the instrument in in Monophonic Mode. First at step 1651, the module 38H receives the newMonoRegionValue(x,y) from step 1523 Figure 15B Octave Modulation workflow. Next, at step 1652, the module 38H stops the output of any musical output signal already being outputted, again whether such output is in the form of a frequency parameter signal, a MIDI signal or a combination thereof, in equivalency to steps 1603A-1603B in the polyphonic workflow of Figure 16A. Such stoppage may be documented in a dynamically updated database in which one or more parameters of any actively outputted mono note are tracked, as shown at 1653, in equivalence to 1604 of the polyphonic workflow of Figure 16A. Next, at step 1654, newMonoRegi on Value (x,y) is used to calculate an updated CurrentValue for the Active Region as 2A(newMonoRegionValue), in equivalence to step 1605 of the polyphonic workflow of Figure 16A. Next at steps 1655-1656, the module 38H uses the updated CurrentValue to calculate Frequency, MIDI note and MIDI pitch bend in equivalent fashion to steps 1606-1607, and at steps 1656-1658 documents the formulated musical output signals in the dynamic database 1653 and actualizes the musical output signals through the Audio Output module 38 J, in equivalency to steps 1609-1610 of the polyphonic workflow of Figure 16A, thus completing the monophonic workflow of the Figure 16B scenario. The flush functionality is again schematically denoted at 1659, in functional equivalency to that shown at 1611 of the polyphonic workflow of Figure 16 A.

[0126] Though not specifically illustrated in the flowcharts, the software application preferably also converts pitch classes to contrasting grayscale or colour for contracting visualization of the keys 16 of the keypad 40 on the touchscreen in such touchscreen embodiments. In one nonlimiting implementation of a grayscale keypad, the pitch class 1.0 is set to 0.5 RBG. The range expands lighter & darker to the tritone above & below i.e. 2 and 1 / ^2, at this place, it flips from white to black: let logValue = log2(inputValue) let v: CGFloat = (logValue <= 0.5)

[0127] ? CGFloat((logValue / 0.5) * 0.5 + 0.5) / / Scale (0, 0.5) to (0.5, 1)

[0128] : CGFloat(((1.0 - logValue) / 0.5) * 0.5) / / Scale (0.5, 1) to (0.5, 0) return UIColor(red: v, green: v, blue: v, alpha: 1.0)

[0129] Mapping to colour can be achieved similarly to grayscale, but may instead use a lookup table. Visible light is in the range 380 to 750 nanometers(nm), not quite one octave (doubling). Artistic license may be involved to fit the gradient across a one-octave range.

[0130] It will also be appreciated that the instrument 10 is not limited to microtonal embodiments, and can be implemented in Equal Temperament by discarding pitch bend and fine tuning, and using an Equal Tempered version of the Harmonic Table, in which the BaseValue = 2A(((Mx+Ny)%12) / 12), where % is the modulus operator, with M = 4 & N = 7 being one working example, though other workable combinations are possible, for example including M = 7 & N = 4, M=2 & N = 1, and M = 1 & N = 2. An Equal Temperament lookup table has only twelve unique BaseValues, which for the embodiment M = 4 & N = 7 would appear as follows: "(-3,5)": 1.887748625, "(-3,4)": 1.259921050, "(-2,4)": 1.587401052,

[0131] "(-1,4)": 1.000000000, "(-3,3)": 1.681792831, "(-2,3)": 1.059463094,

[0132] "(-1,3)": 1.334839854, "(0,3)": 1.681792831, "(1,3)": 1.059463094,

[0133] "(-3,2)": 1.122462048, "(-2,2)": 1.414213562, "(-1,2)": 1.781797436,

[0134] "(0,2)": 1.122462048, "(1,2)": 1.414213562, "(2,2)": 1.781797436,

[0135] "(3,2)": 1.122462048, "(-3,1)": 1.498307077, "(-2,1)": 1.887748625,

[0136] "(-1,1)": 1.189207115, "(0,1)": 1.498307077, "(1,1)": 1.887748625,

[0137] "(2,1)": 1.189207115, "(3,1)": 1.498307077, "(-3,0)": 1.000000000,

[0138] "(-2,0)": 1.259921050, "(-1,0)": 1.587401052, "(0,0)": 1.000000000,

[0139] "(1,0)": 1.259921050, "(2,0)": 1.587401052, "(3,0)": 1.000000000,

[0140] "(-3,-1)": 1.334839854, "(-2,-1)": 1.681792831, "(-1,-1)": 1.059463094,

[0141] "(0,-1)": 1.334839854, "(1,-1)": 1.681792831, "(2,-1)": 1.059463094,

[0142] "(3,-1)": 1.334839854, "(-3,-2)": 1.781797436, "(-2,-2)": 1.122462048,

[0143] "(-1,-2)": 1.414213562, "(0,-2)": 1.781797436, "(1,-2)": 1.122462048,

[0144] "(2,-2)": 1.414213562, "(3,-2)": 1.781797436, "(-2,-3)": 1.498307077,

[0145] "(-1,-3)": 1.887748625, "(0,-3)": 1.189207115, "(1,-3)": 1.498307077,

[0146] "(2,-3)": 1.887748625, "(3,-3)": 1.189207115, "(0,-4)": 1.587401052,

[0147] "(1,-4)": 1.000000000, "(2,-4)": 1.259921050, "(3,-4)": 1.587401052,

[0148] "(2,-5)": 1.681792831, "(3,-5)": 1.059463094,

[0149] Equal Temperament embodiments do not require the precision mathematics used in microtonal emboidments, and can be alternately calculated using MIDI note numbers. Global Parameter FineTuneFrequency 120, and Region Database parameters pitchBend 66 and Frequency 70 are not used. Conversion formula from Frequency to MIDI note is MIDI note = (12 x log2(Frequency / 440 Hz)) + 69, though the conversion can also use ratios by factoring out the Global Reset fundamental 118, reframing the calculation as MIDI note = (12 x log2(ratio) + 69).

[0150] Since various modifications can be made in my invention as herein above described, and many apparently widely different embodiments of same made, it is intended that all matter contained in the accompanying specification shall be interpreted as illustrative only and not in a limiting sense.

Claims

CLAIMS:

1. An electronic musical instrument comprising: a finger-actuated user input presenting a plurality of touchable regions playable with one or more manual digits of a user’s hands and each having assigned thereto a respective value in which there is embodied representation of a respective region pitch class; a continuous linear input that is variable through user-manipulation of separate and distinct character from said playing of said touchable regions and produces a responsive signal of responsive relation to said user-manipulation; and at least one processor and non-transitory computer readable medium coupled thereto, and having stored therein executable statements and instructions, that, when executed, cause performance of at least the following steps:(a) in conjunction with a user-activated status of at least one of said regions, with which there is associated a respective a region octave, converting an instantaneous value of said responsive signal into a converted pitch class and a converted octave; and(b) calculating an output octave that is dependent on both said region octave and said converted octave; and(c) outputting of a musical output signal that is characterized by:(i) equal pitch to the region pitch class of said one of said regions; and(ii) said output octave.

2. The electronic musical instrument of claim 1 wherein the finger-actuated user input comprises a touchscreen display in which there is displayed a plurality of touchscreen keys each visually denoting a respective one of the regions.

3. The electronic musical instrument of claim 1 wherein the finger-actuated user input comprises a physical keyboard having a plurality of depressible keys each denoting a respective one of the regions.

4. The electronic musical instrument of any preceding claim wherein the regions are laid out in a grid, and the value of each region is dependent on coordinate address thereof within said grid.

5. The electronic musical instrument of claim 4 wherein said coordinate address has x, y coordinates and the respective value of each region is equal to Nxx MY, where N and M are unequal integers.

6. The electronic musical instrument of claim 5 wherein N = 5 and M = 3.

7. The electronic musical instrument of claim 5 or 6 wherein the region pitch class of each region is equal to log2(r) - [log2(r)J, where r = N x MY.

8. The electronic musical instrument of any preceding claim wherein the executable statements and instructions are configured to calculate the converted pitch class by converting the instantaneous value of the responsive signal to a converted ratio value, taking a base-two logarithm of said converted ratio value, and subtracting a floor of said base-two logarithm of said converted ratio value from said base-two logarithm of said converted ratio value.

9. The electronic musical instrument of claim 8 wherein the executable statements and instructions are configured to convert said instantaneous value of the responsive signal to said converted ratio value by calculating one of either:1 + x if said movement responsive output signal is less than zero; or1 / (1 - x) if said movement responsive output signal is greater than zero; where x is said instantaneous value of the responsive output signal.

10. The electronic musical instrument wherein the executable statements and instructions are configured to, before deriving the converted pitch class, scale the movement responsive output signal to one of the following interval options: (-1, 1), [0, 1), (-1, 0] or [0, -1).

11. The electronic musical instrument of any preceding claim wherein the continuous the linear input comprises an accelerometer, and the responsive signal is responsive to tilt of the instrument.

12. The electronic musical instrument of any preceding claim wherein the executable statements and instructions are configured to sample said continuous linear input at quantization intervals of non-dependent relationship to user activation of the regions.

13. The electronic musical instrument of claim 12 wherein said quantization interval is a variably adjustable quantization interval.

14. The electronic musical instrument of claim 13 wherein said quantization interval is user- adjustable.

15. The electronic musical instrument of any preceding claim wherein the outputting of the musical output signal in step (c) is conditional on first checking whether said musical output signal differs from a previously initiated musical output signal that is still ongoing, and outputting saidmusical output signal only after determination of a difference thereof from said already outputted musical output signal.

16. The electronic musical instrument of claim 15 wherein the said musical output signal is outputted only after terminating said previously initiated musical output signal.

17. The electronic musical instrument of any preceding claim wherein said outputting of the musical output signal is conditional to a preceding check of whether a threshold value of a trigger parameter is exceeded.

18. The electronic musical instrument of claim 17 wherein said trigger parameter is accelerometer-derived.

19. The electronic musical instrument of claim 17 or 18 wherein said trigger parameter is a vector magnitude of instrument acceleration.

20. The electronic musical instrument of any preceding claim wherein the executable statements and instructions are configured to enable operation of the instrument in a polyphonic mode, in which conversion of said instantaneous value of said responsive signal into the converted pitch class and the converted octave triggers calculation of multiple output octaves, one for each of a plurality of active regions of simultaneously active status.

21. The electronic musical instrument of any preceding claim wherein the executable statements and instructions are configured to enable operation of the instrument in a monophonic mode, in which said musical output signal is a singularly outputted musical output signal, even in instances where said one of the regions is one of a plurality of active regions of simultaneously active status.

22. The electronic musical instrument of claim 21 wherein the executable statements and instructions are configured to output said singularly outputted musical output signal on behalf of a particularly selected one of said plurality of active regions after determination that said particularly selected one of said plurality of active regions is nearest, in a particular parameter, to the converted instantaneous value of the responsive signal.

23. The electronic musical instrument of claim 22 wherein said particular parameter is pitch class.

24. The electronic musical instrument of any preceding claim wherein the executable statements and instructions are configured to enable operation of the instrument in at least a HoldMode, in which finger engagement of any selected one of the regions imparts an active status thereto, which: renders the region eligible for musical output on behalf thereof in step (c), and is automatically held by the instrument despite subsequent removal of said finger engagement, and is terminated upon a subsequent finger reengagement of the same selected one of the regions.

25. The electronic musical instrument of claim 24 wherein the statements and instructions are configured to enable user-switching between said Hold Mode and a Touch Mode, in which the active status of any finger-engaged region is instead terminated upon removal of said fingerengagement.

26. The electronic musical instrument of any preceding claim comprising a user-operated rest control to operable to: silence any musical output being outputted immediately preceding user-input on said rest control; hold said silence throughout a duration of said user-input on said rest control; and trigger resumed musical output upon release of said user-input from said rest control.

27. The electronic musical instrument of claim 26 wherein the statements and instructions are configured to perform one or more repetitions of steps (a) and (b) within said duration of said user input on the rest control, whereby the resumed musical output after release of said user-input, in at least some instances, is of octave shifted relationship to said musical output immediately preceding said user-input on said rest control owing to updated calculation of the output octave during said silence.

28. The electronic musical instrument of any preceding comprising a user-operated sustain control operable between open and closed states, among which the open state permits repeating execution of steps (a) through (c) to dynamically modulate musical output in an octave-adjusted manner with each repeated execution, and the closed state instead bypasses at least step (c) to sustain any existing musical output without octave-adjusted modulation thereof.

29. The electronic musical instrument of any preceding claim wherein calculating the output octave in step (b) comprises adding the converted octave to a conditionally selected one of either the region octave, or the region octave plus one, dependent on a preceding conditional criteria check.

30. The electronic musical instrument of claim 29 wherein said preceding conditional criteria check is whether the converted pitch class exceeds the region pitch class, in which case the converted octave value is added to the region octave plus one.

31. A method of modulating musical output signals of an electronic musical instrument, said method comprising:(a) receiving fingered user input on touchable regions of the instrument playable with one or more manual digits of a user’s hands;(b) also receiving a continuous linear input that is variable through user-manipulation that is of separate and distinct character from fingered playing of said touchable regions, and producing a responsive signal of responsive relation to said user-manipulation;(c) in conjunction with a user-activated status of at least one of said regions, with which there is associated a respective a region octave, converting an instantaneous value of said responsive signal into a converted pitch class and a converted octave;(d) calculating an output octave that is dependent on both said region octave and said converted octave; and(e) outputting of a musical output signal that is characterized by:(i) equal pitch to the region pitch class of said one of said regions; and(ii) said output octave.

32. The method of claim 31 wherein said at least one of said regions in step (c) is a plurality of active regions, and step (d) comprises calculation of multiple output octaves, one for each of said plurality of active regions of simultaneously active status.

33. The method of claim 31 wherein said at least one of said regions in step (c) is a plurality of active regions, step (d) comprises first evaluating which particular one of said plurality of active regions is nearest, in a particular parameter, to the converted instantaneous value of the responsive signal, and step (e) comprises outputting said musical output signal on behalf of said particular one of said plurality of active regions.

34. The method of claim 33 wherein said particular parameter is pitch class.

35. The method of any one of claims 31 to 34 comprising performance of step (a) in a Hold Mode of the electronic instrument, in which finger-engagement of any selected one of the regions imparts an active status thereto, which:renders said selected one of the regions eligible for output of the musical output signal behalf thereof in step (e) at the calculated output octave of step (d), and is automatically held by the instrument despite subsequent removal of said fingerengagement, and is terminated upon a subsequent finger reengagement of the same selected one of the regions.

36. The method of claim 35 further comprising switching, in response to user-selection among different modes, between said Hold Mode and a Touch Mode, in which the active status imparted to any region by said finger-engagement is instead terminated upon removal of said fingerengagement.

37. The method of any one of claims 31 to 36 comprising, after step (a) and before step (b), receiving user-input on a user-operated rest control of the instrument to silence any musical signal being outputted on behalf of any of the regions, said user input being maintained throughout steps (c) and (d) to extend said silence for a duration of steps (c) and (d), during which silence the output octave is still calculated in step (d), and step (e) is executed after release of said user input on the user-operated rest control, which terminates the silence and triggers the musical output signal at the calculated octave.

38. An electronic musical instrument comprising: a finger-actuated user input presenting a plurality of touchable regions playable with one or more manual digits of a user’s hands; a continuous linear input that is variable through user-manipulation of separate and distinct character from said playing of said touchable regions and produces a responsive signal of responsive relation to said user-manipulation; and at least one processor and non-transitory computer readable medium coupled thereto, and having stored therein executable statements and instructions, that, when executed, cause performance of at least the following steps:(a) monitoring the regions for user-activation of one or more thereof via touched finger engagement by the user; and(b) at quantization intervals of non-dependent relationship to user activation of the regions:(i) sampling said continuous linear input for instantaneous values thereof; and(ii) triggering output of musical output signals that are influenced by both the finger-actuated user input and the sampled instantaneous values of the continuous linear input, and are of non-dependently timed relationship to said user activation of the regions.

39. The electronic musical instrument of claim 38 wherein said quantization interval is a variably adjustable quantization interval.

40. The electronic musical instrument of claim 39 wherein said quantization interval is user- adjustable.

41. The electronic musical instrument of any one of claims 38 to 40 wherein the musical output signals are modulated by the sampled instantaneous values of the continuous linear input.

42. The electronic musical instrument of claim 41 wherein the musical output signals are modulated in octave-wise relationship to region octaves associated with the regions.

43. An electronic musical instrument comprising: a finger-actuated user input presenting a plurality of touchable regions playable with one or more manual digits of a user’s hands; a continuous linear input that is variable through user-manipulation of separate and distinct character from said playing of said touchable regions and produces a responsive signal of responsive relation to said user-manipulation; and at least one processor and non-transitory computer readable medium coupled thereto, and having stored therein executable statements and instructions, that, when executed, cause performance of at least the following steps:(a) monitoring the regions for user-activation thereof via touched finger engagement by the user;(b) in response to said touched finger engagement of any selected one of said regions, impart an active status thereto, which: renders the region eligible for later musical output on behalf thereof, without actually initiating said musical output; and is automatically held by the instrument despite subsequent removal of said finger engagement, and is terminated upon a subsequent finger reengagement of said selected one of the regions; and(c) subsequently sampling the continuous linear input for an instantaneous value thereof, and in triggered relation thereto, outputting said musical output on behalf of said selected one of the regions, in a manner influenced by the sampled instantaneous value of the continuous linear input.

44. The electronic musical instrument of claim 43 wherein the musical output is modulated by the sampled instantaneous value of the continuous linear input.

45. The electronic musical instrument of claim 44 wherein the musical output signal is modulated in octave-wise relationship to a region octave associated with said selected one of the regions.

46. The electronic musical instrument of any one of claims 1 to 30 and 38 to 45 wherein the executable statements and instructions are configured to enable operation of the instrument in an iterative transposition mode in which: a first user-implemented transposition of the regions is performed by transposing the regions according to user-designation of a first chosen region, a default BaseValue of which is then used as an updated MainKey by which Currentvalues of the regions are all transposed; and a subsequent user-implemented transposition of the regions is performed by transposing the regions according to user-designation of a second chosen region, the CurrentValue of which is then used as a newly updated MainKey by which Currentvalues of the regions are all transposed.

47. An electronic musical instrument comprising: a finger-actuated user input presenting a plurality of touchable regions playable with one or more manual digits of a user’s hands; at least one processor and non-transitory computer readable medium coupled thereto, and having stored therein executable statements and instructions, that, when executed, cause performance of at least the following steps: operation of the instrument in an iterative transposition mode in which: a first user-implemented transposition of the regions is performed by transposing the regions according to user-designation of a first chosen region, a default Base Value of which is then used as an updated MainKey by which Currentvalues of the regions are all transposed; and a subsequent user-implemented transposition of the regions is performed by transposing the regions according to user-designation of a second chosen region, the CurrentValueof which is then used as a newly updated MainKey by which Currentvalues of the regions are all transposed.

48. The electronic musical instrument of claim 46 or 48 wherein said iterative transposition mode is one of a plurality of user-selectable transposition modes, another of which is a reset transposition mode, in which the first user-implemented transposition is performed in equivalent fashion to that of the iterative transposition mode, but the subsequent user-implemented transposition differs from that of the iterative transposition mode, and first resets the updated MainKey to a default value thereof, then uses the BaseValue of the second chosen region, rather than the CurrentValue thereof, to update the newly reset MainKey from its default value.

Images