Menu
▾
▴
linuxsampler-devel
|
From: Hans P. S. <hp...@se...> - 2018-05-24 10:04:55
|
Hi, Is there any interest into extending the number of MIDI keys from 128 to 128 * 16 in LinuxSampler ? The background for this is to have better support non-12-scale music and also to have organ sounds clearer especially for majors. The four missing bits will be stolen from the channel bits simply for standard MIDI, when a special parameter is given to LinuxSampler. This also allows to save such music into regular MIDI files and re-play them. --HPS |
|
From: Christian S. <sch...@li...> - 2018-05-25 11:11:22
|
On Donnerstag, 24. Mai 2018 11:45:23 CEST Hans Petter Selasky wrote: > Is there any interest into extending the number of MIDI keys from 128 to > 128 * 16 in LinuxSampler ? There is probably no high demand for such a feature. Are there actually any real devices which are doing it exactly this way (borrowing from MIDI channel bits that is)? I mean there are real devices which support a more fine graded note control beyond the 128 notes limitation. But usually they do it like this: they send a regular note-on (0-127), then they send a regular coarse/fine tuning message pair, and if the new note would be a note nr where another note is already active on, then they simply send it on another MIDI channel for not changing the tuning of the old note. CU Christian |
|
From: Hans P. S. <hp...@se...> - 2018-05-25 12:16:09
|
On 05/25/18 13:11, Christian Schoenebeck wrote: > On Donnerstag, 24. Mai 2018 11:45:23 CEST Hans Petter Selasky wrote: >> Is there any interest into extending the number of MIDI keys from 128 to >> 128 * 16 in LinuxSampler ? > > There is probably no high demand for such a feature. Are there actually any > real devices which are doing it exactly this way (borrowing from MIDI channel > bits that is)? > > I mean there are real devices which support a more fine graded note control > beyond the 128 notes limitation. But usually they do it like this: they send a > regular note-on (0-127), then they send a regular coarse/fine tuning message > pair, and if the new note would be a note nr where another note is already > active on, then they simply send it on another MIDI channel for not changing > the tuning of the old note. > > CU > Christian Hi, I didn't know there were MIDI coarse/fine tuning messages and these also work realtime? Do you have a reference? I've made a patch for ZynaddSubFX to do this: https://sourceforge.net/p/zynaddsubfx/code/ci/hps-subdivision-feature/tree/ The reason is that for organ sounds you don't get a phase polluted major unless you adjust the tones a bit. Here is the math: C-major frequencies: C = base * pow(2.0, 0 / 12.0) E = base * pow(2.0, 4 / 12.0) G = base * pow(2.0, 7 / 12.0) The base frequency is not relevant, so cancel it. C-major frequency factors: C = pow(2.0, 0 / 12.0) E = pow(2.0, 4 / 12.0) G = pow(2.0, 7 / 12.0) Computing all the differential tones in logarithmic scale and get: 12.0 * log(G - C) / log(2) = -12.059 ... 5.9 cent over 12.0 * log(G - E) / log(2) = -24.824 ... 82.4 cent over 12.0 * log(E - C) / log(2) = -23.326 ... 67.4 cent under 12.0 means the 12'th halftone 24.0 means the 24'th halftone osv. Trying to rectify this with 96 tones per octave: C = pow(2.0, 0 / 12.0) E = pow(2.0, 3 / 12.0 + 7 / 96.0) G = pow(2.0, 7 / 12.0) 12.0 * log(G - C) / log(2) = -12.059 ... 5.9 cent over (same as before) 12.0 * log(G - E) / log(2) = -24.177 ... 17.6 cent over 12.0 * log(E - C) / log(2) = -23.941 ... 5.9 cent under (identical error - cancels) Examples with samples from Nord Electro adjusted using aduacity: http://home.selasky.org/privat/nord/major_CEG_corrected.mp3 http://home.selasky.org/privat/nord/major_CEG_uncorrected.mp3 Summary in C-major the E shall be reduced by: (8-7)/96*1200 = 12.5 cent To reduce phase errors. --HPS |
|
From: Christian S. <sch...@li...> - 2018-05-25 13:53:18
|
On Freitag, 25. Mai 2018 14:15:47 CEST you wrote:
> I didn't know there were MIDI coarse/fine tuning messages and these also
> work realtime? Do you have a reference?
There are actually several standard messages regarding tuning, for example:
1. Standard MIDI Pitchbend message.
2. Roland GS scale tuning SysEx message (tuning individual 12 notes of each
octave in cents).
3. MIDI RPN #1 ("fine tuning part in cents").
4. MIDI RPN #2 ("coarse tuning part in half tones").
And as I am looking at it, there are even more tuning related MIDI messages.
The following might be a starting point for you:
http://www.somascape.org/midi/tech/spec.html
http://www.microtonal-synthesis.com/GS_XG.html
And I have to correct my previous email: IIRC the comman way is using actually
pitch bend messages, not coarse/fine tuning messages (take the "Seaboard" as an
example of a real world hardware product doing that).
Implementation status of the messages above in LinuxSampler:
1. Supported of course (real-time).
2. Supported (real-time).
3. No supported ATM.
4. Supported (but not real-time ATM, resets part ATM).
> I've made a patch for ZynaddSubFX to do this:
>
> https://sourceforge.net/p/zynaddsubfx/code/ci/hps-subdivision-feature/tree/
>
> The reason is that for organ sounds you don't get a phase polluted major
> unless you adjust the tones a bit.
Sound like you are resembling the Hermode Tuning algorithm, which usually uses
Roland GS ScaleTuning (in real-time) to adjust purity of harmonies (3rd, 5th
and 7th) in real-time.
But getting back to my actual question; as far I understand you correctly,
there are no real-world hardware products which use the MIDI channel bits for
the tuning purpose you described, so you came up with this idea, correct?
CU
Christian
|
|
From: Hans P. S. <hp...@se...> - 2018-05-25 14:54:07
|
On 05/25/18 15:53, Christian Schoenebeck wrote: > so you came up with this idea, correct? Yes, for my experiments and projects sake. I'll see if I can use some of the described methods instead. Using up all the MIDI channels was just a last resort, also latency wise. --HPS |
|
From: Christian S. <sch...@li...> - 2018-05-25 17:22:29
|
On Freitag, 25. Mai 2018 16:53:42 CEST Hans Petter Selasky wrote: > On 05/25/18 15:53, Christian Schoenebeck wrote: > > so you came up with this idea, correct? > > Yes, for my experiments and projects sake. > > I'll see if I can use some of the described methods instead. Using up > all the MIDI channels was just a last resort, also latency wise. Ok, I see. I first thought you are referring to this solution since there might be some kind of exotic hardware organ or something that sends these messages already. Well under that circumstance I would definitely not use the MIDI channel bits for that. In the end, you can also invent a new MIDI message like "fine tune only the next note on this part" (i.e. by picking an arbitrary NRPN or a short SysEx). Latency was an issue with the old classic DIN MIDI jacks, but it is definitely not with todays USB and Bluetooth LE based MIDI connections anymore. Existing controllers like the previously mentioned "Seaboard" use the described method of using pitchbend and MIDI channel distribution simply because it would work with most sound expanders and plugins out of the box. CU Christian |
Thanks for helping keep SourceForge clean.
X