Config parameters for enabling and setting keyboard split #63
Comments
|
This was never a configuration option so far. IIRC Split was en/disabled via MIDI program change at runtime. see |
|
I am not sure if this is the best place to suggest this but the transpose/split options are not so ideal if one for example would like to use an 88 key board to map the two manuals all on channel 1. The current behavior is rather random. One can transpose the upper manual to reach the upper octave of your 88 keys (excellent!) One can map the lower keyboard to a section of the 88 note keyboard. (great!) But the split point moves with the upper region and not the lower, so that there is a gap of dead keys between them. Also there is no way to shift the lower manual to use the keys below the normal range even with transpose. So the bottom octave is unreachable (the pedals can be put there though). So in the end the 88 keys can have the two manuals mapped over them but you never can use more than 61 keys. There must be dead regions. Seems dumb (sorry) One would have like the split point to not move when I transpose the upper region to use the top octave of keys, so I essentially gain an octave if I do that. Also would like transposing the lower manual to use the bottom octave of keys to be possible (also without changing the physical split point on the keyboard). Now it will not go down there, it only transposes without adding any physical keys to the input even if they now would map to the valid range. I know that most keyboards will let you setup zones transposes and channels to achieve this but sadly not mine. I just have channel 1 across all keys that is it. It seems you almost gave me what I need but somehow dropped the ball on the goal line. I took a look at the source code being a computer scientist, but I had trouble finding what to change. Sorry for all the text. One more point. Even if I had a keyboard that could set this up it would not help me as I use many keyboards, whatever is available, so I count on the setup being on my laptop not on the keyboard. |
|
It's been nearly a decade since I've looked into key-split,
The relevant part here are the |
|
Jesus that was quick, I will have a look. |
|
Hi again, Yes it was simple enough. I believe I found the problem and fixed it in the attached code. It should now work to use any keyboard zone from 0 to 127 at the same time for any regions of the B3 manuals.. Rather than forcing there to be gaps in coverage. I did not change the loadKeyTableB or loadKeyTableC. They could be made to work differently but that was not my issue. They assume one is playing from a 61 note keyboard but maybe that makes some sense for those, but not for loadKeyTableA. I put some long comment explaining the short code in the file. Hope this can be propagated to the repo. cheers, /john |
|
That looks reasonable. Would you mind posting the output of |
|
I was rudely trying to not learn how to use git (again). Normally I mess that up and call one of my grad students to fix it. (Yes I am old, stopped serious programming when git came along. Learned and then forgot it a few times now... ) My downloaded version (not branch) complies fine but I have not tried it with the keyboard yet. Here is normal diff: The background of my mucking with this is that I really like your B3 sound but the GUI gave me hung notes too often. Really great program though thanks a lot for it. My band mates have praised the sound. /john |
|
Ok tested with my keyboard and the bottom got fixed byt the gap remained. I fixed that now too. New diff; new function; |
This is reformatted patch from @johnfolk, who describes it: The 'problem' was that the MIDI note range always was starting from the non-transposed left edge (24 or max (left, 36)) to the non-transposed split point. If there were unused keys to the left (i.e. less than 24 or 36) they were not used even if they might map to B3 keys and were above 'left'. The last region had the same issue but the code was somewhat different before leading to somewhat different effects but the casuse was similar, the unused note numbers on the left edge. The strategy now is to use all possible MIDI note numbers by adjusting the `first_MIDI_Note` and transpose to maintain the difference between them but move the first MIDI lower as much as possible. Thereby extending the range of note numbers that would be attmpted to match the B3's range. Then adjust if needed the start MIDI and key to match the left boundary from the previous split point (as before). The main thing is to be sure that the mapping constant: `offset = trnp + firstkey - first_MIDI_Note` has not changed and that we respect the left limit on first_MIDI_Note. While increasing the range to the left to include any unused MIDI note numbers that would map to valid keys. This works correctly for a reasonble range of `m->transpose + m->nshA_PL, m->splitA_PL`. Note numbers will stay >= 0. If transposes get wild they simply will not map to any keys. At the end of the day the Midi+transpose must hit the limited key ranges or the table seems to get set to 255. Which is fine.
|
I'd love to be able to call a grad-student to clean up after me :) Applied as c7445ed. Thank you! |
In "default.cfg", i've only found config parameters for setting the "transposition" of split-regions, but no way of configuring the split regions itself.
The text was updated successfully, but these errors were encountered: