added relative controller and CC midi channel support

[akeia]

support was added for relative controllers (centered around value 64). this is currently hardcoded and would need handling in the gui for changing from absolute (0..127) to relative (smaller<64<larger) controller handling. probably configurable for midi controller names. relative controllers elegantly avoid the problem with value ranges and knob state after program load.

support was added for handling midi channels of CC. now 127*16 knobs can be used instead of 127.

I have tested both changes with a Blofeld and Arturia BeatStep and it works for me.

please be aware that your repository does not contain all source codes (f.e. edisyn.gui.PatchDisplay is missing). i was not able to compile and build a complete jar from source. classpath trickery is needed to load my patched classes before your jar. also your repo has no build or project files.

[eclab]

Hi, I have a large number of changes in-house that I have not posted yet because my internet access is very, very poor until a few weeks from now (in a beach town in Italy!).

Your commits are good but I have also added in support for NRPN among many other changes, so I have to merge them by hand. :-( It'll take some time.

In the meantime I have posted the PatchDisplay.java file, I'm sorry about that.

On Jul 24, 2017, at 12:31 PM, akeia notifications@github.com wrote:

support was added for relative controllers (centered around value 64). this is currently hardcoded and would need handling in the gui for changing from absolute (0..127) to relative (smaller<64<larger) controller handling. probably configurable for midi controller names. relative controllers elegantly avoid the problem with value ranges and knob state after program load.

support was added for handling midi channels of CC. now 127*16 knobs can be used instead of 127.

I have tested both changes with a Blofeld and Arturia BeatStep and it works for me.

please be aware that your repository does not contain all source codes (f.e. edisyn.gui.PatchDisplay is missing). i was not able to compile and build a complete jar from source. classpath trickery is needed to load my patched classes before your jar. also your repo has no build or project files.

You can view, comment on, or merge this pull request online at:

https://github.com/eclab/edisyn/pull/3

Commit Summary

• added (hardcoded) support for relative CC values centered around CC=64. Works with f.e. Arturia BeatStep. • added support for handling and storage of midi channels for CCs. 127*16 knobs can be differentiated instead of 127. File Changes

• M edisyn/CCMap.java (114) • M edisyn/Model.java (21) • M edisyn/Synth.java (34) Patch Links:

• https://github.com/eclab/edisyn/pull/3.patch • https://github.com/eclab/edisyn/pull/3.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[akeia]

you could push your current development into a new branch (f.e. named "development"). Put in the build files and leave out all big files (full builds, jars etc. into .gitignore). Then only the java source files get pushed. which should also be possible with very slow internet. I could then apply my changes in your current code. in any case i will check your next version and in case do a new pull request for the changes.

[akeia]

edisyn/Undo.java , edisyn/gui/Undo.java , edisyn/synth/Matrix1000.java and edisyn/synth/Template.java are also missing in the repo. sorry that i did not do a full compare the first time.

[eclab]

I'm going to do a full commit right now but things are a bit in flux for a little while. You'll see new patch editors, but most do not work yet (not tested) -- they're built and compile though.

I didn't check to see how you did channelized CCs but I have to think about that. How often do controllers do channelized CCs? Wouldn't NRPN be a better idea?

At present my munging for storing NRPN and CC is to store CC in low values and NRPN in higher values. Probably have to change the munging to handle channelized CCs, something like CC + 256* channel, and start the NRPNs higher.

On Jul 24, 2017, at 3:34 PM, akeia notifications@github.com wrote:

edisyn/Undo.java , edisyn/gui/Undo.java , edisyn/synth/Matrix1000.java and edisyn/synth/Template.java are also missing in the repo. sorry that i did not do a full compare the first time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[akeia]

i do not know about the capabilities of other devices but the BeatStep can also be programmed to use (N)RPN for the faders (i think only in absolute mode). but NRPN is also per channel in midi (and in the BeatStep). therefore I see that not as exclusive. for maximum input device flexibility all variants should be possible. channelized CC and channelized NRPN.

the midi library has the channel information available for all midi events (message.getChannel()). i did change the key for the HashMaps to use a compound string key to store all information as CC_CHANNEL_PANE (f.e. key 10_1_2 for cc 10 on channel 1 and pane 2). such a key is easily expandable and can be extended (f.e. _1_2_20 for no cc but an nrpn 20 on channel 1). i do not see any advantages for fiddling with the bits. the HashMap operates on key hashes anyway so I do not even see much performance advantages for bit optimized keys. object based keys would also be an option. the string based compound key used is an ad hoc solution.

[eclab]

On Jul 24, 2017, at 5:26 PM, akeia notifications@github.com wrote:

i do not know about the capabilities of other devices but the BeatStep can also be programmed to use (N)RPN for the faders (i think only in absolute mode). but NRPN is also per channel in midi (and in the BeatStep). therefore I see that not as exclusive. for maximum input device flexibility all variants should be possible. channelized CC and channelized NRPN.

Well... channelized NRPN would be kind of crazy. NRPN has 16384 available parameters.

I was about to add the following restriction to intercepting CC versus passing it through. We intercept if (1) it's a CC message and (2) we're not forced to pass it through and (3) it matches our Key (controller) channel or our Key channel is OMNI. That way we can both intercept and pass through CC messages depending on channel, which I think is the right behavior.

I suppose if we set our incoming channel to OMNI, we can still do channelized CC (and by extension NRPN). But do you think it's very useful? It certainly flies in the face of MIDI standards. Unless there was a device that could not send NRPN but could send more than 127 CC values by mapping them per channel, I'd be wary of adding it.

BTW, besides BeatStep, Novation's controllers all send NRPN nicely too.

NRPN can be set up to do relative: you use its INCREMENT and DECREMENT options. But I don't know many controllers which support it. :-(

i do not see any advantages for fiddling with the bits.

Well, there's speed, but granted it's not much.

Sean

[akeia]

BeatStep does not allow relative NRPN (at least I do not find a way). so the channeled relative CC is the best solution for that device. and there are plenty of other devices out there that are crippled in this or that way.

in my personal midi usage NRPN is never used. I do everything with relative controllers. therefore i have no experience with NRPN and have no qualified opinion what would be better.

[eclab]

Okay, I've done a commit which adds two kinds of REL CC (both of which the BeatStep supports, one is rel 1, and the other is rel2, I forget which is which). So you can do:

0. Absolute CC. You're not permitted to set CC parameters 98, 99, 100, 101, 6, or 38.

1. CC REL [64]. This is centered around 64, with >64 being positive values and < being negative values. You're not permitted to set CC parameters 98, 99, 100, 101, 6, or 38.

2. CC REL [0]. This is centered around 0 (two's complement), with > 0 being positive values and <=127 being negative values. You're not permitted to set CC parameters 98, 99, 100, 101, 6, or 38.

3. NRPN. Including increment, decrement, and "fine grained" data entry.

You can also bypass everything to just push raw CC to the underlying synth.

I am leaning against including per-channel CC: it's just too alien to the purpose of MIDI channels I think.

Let me know if things seem to be working (I've been testing on a BeatStep).

Sean

On Jul 24, 2017, at 7:20 PM, akeia notifications@github.com wrote:

BeatStep does not allow relative NRPN (at least I do not find a way). so the channeled relative CC is the best solution for that device. and there are plenty of other devices out there that are crippled in this or that way.

in my personal midi usage NRPN is never used. I do everything with relative controllers. therefore i have no experience with NRPN and have no qualified opinion what would be better.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[akeia]

It works for me (Blofeld, BeatStep) and I like the solution with different shortcuts for different CC types.

Regarding the channels for CC I do not want to get in a lengthy argument but I do not see where the standard disallows such a usage. The relation of midi channels to different sound generator sounds is accepted but in our case the controller hardware is not directly connected to the sound generator. The software communicates with correct midi messaging and channel usage to the synthesizer. The knob controller is more like a mouse or keyboard replacement and logically independent of different sound channels. MIDI messages are a transport layer and I do not see why not to bend the rules on that connection. If it is a bending of midi at all because my (very superficial) search regarding channel usage did not result in a definitive declaration what for channels are not allowed to be used.

[eclab]

On Jul 30, 2017, at 12:24 PM, akeia notifications@github.com wrote:

Regarding the channels for CC I do not want to get in a lengthy argument but I do not see where the standard disallows such a usage.

It still doesn't sit well with me. But tell me, what other devices or major software tools are designed to support using channels to increase the number of available CC parameters for a given facility? I can't think of any but I'm sure there might be some.

Sean

[akeia]

For example all U-He Synthesizers (Diva, Bazille, ACE, ...) , Reaper DAW (native CC learn), Ableton Live (CC learn) do differ CC channels. It is quite common in my experience.

[eclab]

Well, you learn a new thing every day. I had not noticed that Live did it per-channel.

At present Edisyn breaks out CCs per tabbed pane. This means CC#3 can be mapped to different things depending on what pane you're in. This allowed for more mapping when you have limited knobs on your controller (which is the 95% use case), but it means you can't control panes that aren't being shown. And per-channel CC isn't very useful in a single pane, which never has more than 80 or so mappable things on it. So what to do?

On Jul 30, 2017, at 9:46 PM, akeia notifications@github.com wrote:

For example all U-He Synthesizers (Diva, Bazille, ACE, ...) , Reaper DAW (native CC learn), Ableton Live (CC learn) do differ CC channels. It is quite common in my experience.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[akeia]

I think CC per pane is a more "legacy" solution for older controllers. But may be useful for some people. For me its not a solution but a problem ;) My vote is for channel CC for all panels. If it does not get too messy in the code an option to choose "per panel cc" or "global CC" could make everybody happy.