Increasing the number of MIDI macros

[Schneekardinal]

Editing my .xml preset files I came across

par name="max_midi_parts" value="16" /

changing which would seem to increase the number of possible MIDI macros, which reminded me of a comment by one of the devs about the 16 macro maximum being a cosmetic UI-based limitation and that theoretically more macros could be mapped - I think it was in or on one of unfa's videos. However changing it to different numbers above 16, increasing the value of

mgr-info nslots="16"

and adding a 17th macro via editor didn't seem to work. Is there a way to make this work, or possibly another way to increase macro count?

Please excuse my bad form, I'm a musician and not familiar with using github.

[fundamental]

Please excuse my bad form, I'm a musician and not familiar with using github.

No problem at all. Thanks for taking the time to repost this on github. It seemed like the sort of question which might come up again in the future and putting it in a searchable location seemed like it was for the best

Editing my .xml preset files I came across

par name="max_midi_parts" value="16" /

max_midi_parts in this case refers to the number of 'Parts' which internally is a dreadfully bad name. In terms of interacting with zyn it's the number of instruments that you can have simultaneously with each instrument being independent enough that they get information from different MIDI channels.

the 16 macro maximum being a cosmetic UI-based limitation and that theoretically more macros could be mapped

• I think it was in or on one of unfa's videos.

Yep, the choice of 16 was pretty arbitrary. I know it ended up bothering some people who had gotten used to the prior MIDI learn subsystem which supported arbitrary numbers of mapping. The tradeoff was the old system didn't really have a decent way of visually interacting with all of the mapped parameters.

The new system got a limitation for making the GUI a bit simpler and also for plugin operation since you have to at plugin load (or prior to plugin load in LV2's case) state how many 'ports' a plugin has. I don't know if there's an easy way to change the GUI side, but on the side of the synthesier core, I think it's 2 lines of code to swap out 16 with another number. It's a build time thing, so you can't edit a config without recompiling, so keep that in mind.

I see in src/Misc/Master.cpp lines 750 and 327.

The former has the line automate(16,4,8) Which specifies 16 automation slots which each slot having 4 parameters which can be in a macro setup and each parameter can have a control curve with up to 8 control points.

Line 327 has "slot#16/" which says that there are 16 different OSC paths which can be used to talk with it.

Is there a way to make this work, or possibly another way to increase macro count?

The other way is to use the older MIDI learn subsystem. It was disabled for a while, but @friedolino78 has recently re-enabled them. I don't recall if they added anything on the UI side or if they were purely using the OSC API. So, that's a possible other option, though changing the macro count isn't too tricky.

[friedolino78]

for classic midi learn you can oscsend localhost /midi-map-cc iis or turn a knob while pressing ctrl key than turn HW knob should work too (not sure)

there is also midi-map-nrpn that allows >14k controls per channel

[pgervais]

From a user and developer perspective I'm interested in making sure the classical midi mapping works well on the UI side. Last time I checked (which was prior to the reactivation of the classical midi mapper), I found that the state wasn't great.

I will have some time next week: I'll have a look and file PRs / write some documentation.

[Schneekardinal]

Thank you for the quick help, guys!

[friedolino78]

if you have any ideas regarding gui integration of classic midi learn, let me know. since I run headless only with midi HW, I configure everything in startup scripts using oscsend. so I have no own perspective on how its gui should work. but i could implement it, if there is a good concept.

Am 28.05.21 um 13:34 schrieb Philippe Gervais:

From a user and developer perspective I'm interested in making sure the classical midi mapping works well on the UI side. Last time I checked (which was prior to the reactivation of the classical midi mapper), I found that the state wasn't great.

I will have some time next week: I'll have a look and file PRs / write some documentation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zynaddsubfx/zyn-fusion-issues/issues/284#issuecomment-850354994, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIBJOYSVIKTEUUEDIN3LGTTP55UDANCNFSM45UYQ76Q.

[pgervais]

I've looked at the existing MIDI bindings-related OSC endpoints (excluding the automation ones). The first two in the list below @friedolino78 just added and their purpose is clear to me. I'm having a harder time with the others. Are they deprecated? What is their purpose? It would really help if some with more context could chime in.

Zynfusion uses /midi-learn-values which is not in this list (it has apparently been removed from Zynadd some time ago), and maybe /midi-learn/midi-add-watch and /midi-learn/midi-bind.

/midi-map-cc
/midi-map-nrpn

/midi-learn/midi-add-watch
/midi-learn/midi-remove-watch
/midi-learn/midi-bind
/mlearn-values
/mlearn
/munlearn

[friedolino78]

|/midi-learn/midi-add-watch /midi-learn/midi-remove-watch /midi-learn/midi-bind|

are used inside midimapper.cpp  at least i found:

    rtosc_message(buf, 1024, "/midi-learn/midi-add-watch","");

    rtosc_message(buf, 1024, "/midi-learn/midi-bind", "b", sizeof(storage), &storage);

mlearn and munlearn are for learning via Ctrl-Key while turning SW-Knob and then turning HW-Knob.

and with

|/mlearn-values|

you could observe the learned ports.

Am 01.06.21 um 13:20 schrieb Philippe Gervais:

I've looked at the existing MIDI bindings-related OSC endpoints (excluding the automation ones). The first two in the list below @friedolino78 https://github.com/friedolino78 just added and their purpose is clear to me. I'm having a harder time with the others. Are they deprecated? What is their purpose? It would really help if some with more context could chime in.

Zynfusion uses /midi-learn-values which is not in this list (it has apparently been removed from Zynadd some time ago), and maybe /midi-learn/midi-add-watch and /midi-learn/midi-bind.

|/midi-map-cc /midi-map-nrpn /midi-learn/midi-add-watch /midi-learn/midi-remove-watch /midi-learn/midi-bind /mlearn-values /mlearn /munlearn |

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zynaddsubfx/zyn-fusion-issues/issues/284#issuecomment-852044368, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIBJOYCXG4NP4EE55P6MZLTQS67VANCNFSM45UYQ76Q.

[fundamental]

On 06-01, Philippe Gervais wrote:

Zynfusion uses /midi-learn-values which is not in this list (it has apparently been removed from Zynadd some time ago), and maybe /midi-learn/midi-add-watch and /midi-learn/midi-bind.

At this point zyn-fusion should be using stuff in the /automate/* port subtree. I wouldn't be supprised if there's a few stragglers floating around. Personally I really liked the original MIDI learn subsystem, but it did not play nicely with host automations (i.e. enough people found it clunky to automate a set of midi CC changes compared to host automations). To be fair, the host automations give you a float32 (effectively 24 bits of info), which far and away is better than 7-bit CC messages or even 14-bit NRPNs. The newer automation system also has the notion of parameter curves under the hood, though I don't think that was given a proper UI/UX in the GUI.

[friedolino78]

I'm thinking about simple user interface for the old Midi learn. Just a table with the assigned Controller number and the respective path.