Macro Control System

[unfa]

I was thinking for a long time about using stuff like Aftertouch (polyphonic also), mod wheel, expression pedals in ZynAddSubFX internally.

I was using ModWheel through Carla - assigning it to things like Filter Cutoff or FM Gain for manual modulation of the sounds. It's however vastly limited.

Macro controls would also make it much easier to automate stuff - a set number of macros (8 for example) could be exposed as plugin parameters for the hosts, making it easy to automate, without using custom CC channels and MIDI learn.

I think that the great MIDI Learn functionality could be greatly complimented by a Macro system.
Having a bunch of assignable controls that can have move multiple parameters at once (or simply route the parameters out to the main window for easy control) would make it much easier to build complex morphing sounds (you can have a macro that makes a crossfade between voices, while modulating filter LFO speeds and modulation depth) - 1 knob (and through MIDI learn - availably for physical control for live performance) and a ton of motion in the sound.

Also visual feedback for the amount of modulation would be a great thing - I think Helm has did that very well, better than Massive in my opinion, because you can see instantaneous values for all parameters, not just the limits of modulation.

I think we could take the macro system even further than Massive - imagine defining custom mapping curves for each parameter:

Imagine a sound with 5 different layers with different timbres, that you could morph between using the Mod Wheel. Right now If I want to do this I'd need 5 automation lanes to automate the part volume by hand, no way to do this love, when I have only two hands and 2 feet. But such a macro system would make it possible:

This could also allow manual control of effects like distortion, phaser, reverb etc. alll in tight sync - imagine this:

This would allow us to introduce a new level of motion into our sounds, making things more complex and less obvious, and much easier to control live, shifting Zyn to another level of professionalism.

[fundamental]

I like the direction of this feature request. It seems like it would be plain fun to experiment with, useful for actual composition/live use, and it compliments the automation/midi-learn/realtime-automation work nicely 👍

[fundamental]

I like the direction of this feature request. It seems like it would be plain fun to experiment with, useful for actual composition/live use, and it compliments the automation/midi-learn/realtime-automation work nicely 👍

[ssj71]

I really like this idea and this its quite well thought out. Especially for live useage I think this would be huge. Not sure what the proposal for the exact workflow for selecting/adding parameters to the macro would be, context menu or something (which perhaps breaks touchscreen compat)? I suppose drag and drop could possibly be used cleverly here.
Also would these be stored with each preset then? I think that would be best, though perhaps could be interesting too if you could load macro settings from other presets, some might prove to be pretty cool for a multitude of presets.

[ssj71]

I really like this idea and this its quite well thought out. Especially for live useage I think this would be huge. Not sure what the proposal for the exact workflow for selecting/adding parameters to the macro would be, context menu or something (which perhaps breaks touchscreen compat)? I suppose drag and drop could possibly be used cleverly here.
Also would these be stored with each preset then? I think that would be best, though perhaps could be interesting too if you could load macro settings from other presets, some might prove to be pretty cool for a multitude of presets.

[fundamental]

On 02-27, ssj71 wrote: I really like this idea and this its quite well thought out. Especially for live useage I think this would be huge. Not sure what the proposal for the exact workflow for selecting/adding parameters to the macro would be, context menu or something (which perhaps breaks touchscreen compat)?

Right now the knobs/sliders logic is basically: onClick: return if widget.inactive $remote.send_midi_learn(widget.osc_address) if(midi_learning?) if(event.left_button?) start_drag elsif(event.right_button?) create_radial_menu elsif(event.middle_button?) reset_to_default end The radial menu is already there, but deactive as it didn't seem to serve too much use at the time of release. With that in mind I'm thinking getting the UI to another state 'macro_learning?'. So the workflow which comes to mind is: 1. User goes to 'Automation Macro' subview within the automation view (replaces the top level 'MIDI Learn' spot on the sidebar) 2. User clicks create new macro (on the macro slot that they're interested in) 3. User interface enters macro learning mode (MIDI learn + macro learn indicators are blinking) 4. User clicks on the parameters they're interested in 5. User returns to 'Automation Macro' subview 6. They enter the detailed view for the macro slot canceling any further macro learning 7. They are presented with a list of parameters using the short names as unfa has suggested (this will involve adding osc metadata for virtual ports) 8. Each one of the parameters is then presented with a flat graph corresponding to the current parameter value at the time of learning There's sub workflow procedures for adding an additional macro parameter, trying to change a macro parameter path (e.g. a user mapped /part0/kit0/adpars/VoicePar0/Pvolume, but they want /part0/kit0/adpars/VoicePar1/Pvolume), how the graph editors work, etc.

Also would these be stored with each preset then? I think that would be best, though perhaps could be interesting too if you could load macro settings from other presets, some might prove to be pretty cool for a multitude of presets.

This is a similar delema to storing MIDI learn bindings, which currently aren't stored in instruments (as MIDI CC availablity partially depends upon the physical controller). I think the idea of having a fixed number of slots per instrument for macros and automations makes a lot of intuitive sense. Perhaps 8 Macro slots + 16 automation (current MIDI learn) slots per instrument. (perhaps a few global slots as well). Then the binding of an automation or macro to a host or binding to a MIDI CC is another layer of indirection.

[fundamental]

On 02-27, ssj71 wrote: I really like this idea and this its quite well thought out. Especially for live useage I think this would be huge. Not sure what the proposal for the exact workflow for selecting/adding parameters to the macro would be, context menu or something (which perhaps breaks touchscreen compat)?

Right now the knobs/sliders logic is basically: onClick: return if widget.inactive $remote.send_midi_learn(widget.osc_address) if(midi_learning?) if(event.left_button?) start_drag elsif(event.right_button?) create_radial_menu elsif(event.middle_button?) reset_to_default end The radial menu is already there, but deactive as it didn't seem to serve too much use at the time of release. With that in mind I'm thinking getting the UI to another state 'macro_learning?'. So the workflow which comes to mind is: 1. User goes to 'Automation Macro' subview within the automation view (replaces the top level 'MIDI Learn' spot on the sidebar) 2. User clicks create new macro (on the macro slot that they're interested in) 3. User interface enters macro learning mode (MIDI learn + macro learn indicators are blinking) 4. User clicks on the parameters they're interested in 5. User returns to 'Automation Macro' subview 6. They enter the detailed view for the macro slot canceling any further macro learning 7. They are presented with a list of parameters using the short names as unfa has suggested (this will involve adding osc metadata for virtual ports) 8. Each one of the parameters is then presented with a flat graph corresponding to the current parameter value at the time of learning There's sub workflow procedures for adding an additional macro parameter, trying to change a macro parameter path (e.g. a user mapped /part0/kit0/adpars/VoicePar0/Pvolume, but they want /part0/kit0/adpars/VoicePar1/Pvolume), how the graph editors work, etc.

Also would these be stored with each preset then? I think that would be best, though perhaps could be interesting too if you could load macro settings from other presets, some might prove to be pretty cool for a multitude of presets.

This is a similar delema to storing MIDI learn bindings, which currently aren't stored in instruments (as MIDI CC availablity partially depends upon the physical controller). I think the idea of having a fixed number of slots per instrument for macros and automations makes a lot of intuitive sense. Perhaps 8 Macro slots + 16 automation (current MIDI learn) slots per instrument. (perhaps a few global slots as well). Then the binding of an automation or macro to a host or binding to a MIDI CC is another layer of indirection.

[ssj71]

The radial menu is already there, but deactive as it didn't seem to serve too much use at the time of release.

to me that would be a convenient way to add it, right click any control, radial menu displays the available macro/automation slots. That said though, it would be really nice to have a view where everything is greyed out except the current macro parameters like you describe so you can get a quick view of what the macro is doing in context of how you would build the patch (a list of mapped parameters is not the same). That mode is fewer clicks is you know exactly what you are adding to the macro, but if later you are tweaking and think, "this parameter should be in a macro!" it would be nice to be able to add it without leaving the current view. Both workflows would be very convenient under different circumstances.

This is a similar delema to storing MIDI learn bindings, which currently aren't stored in instruments (as MIDI CC availablity partially depends upon the physical controller).

I think this differs slightly. I would not store midi bindings for the reason you state (though it should be stored in the plugin state when you reopen your daw), but macros IMO are really part of the patch. It describes what parameters are meant to be tweaked in a live manner.

I think the idea of having a fixed number of slots per instrument for macros and automations makes a lot of intuitive sense. Perhaps 8 Macro slots + 16 automation (current MIDI learn) slots per instrument. (perhaps a few global slots as well).

I agree thats a good way to go about it. I'm not sure I'm understanding the difference between a macro and automation slot except maybe the automation restricts to a single parameter. I think we might be fine just exposing 16-32 macros to the host and users can use them to expose single parameters or complex macros.

I don't think you can change the automation ports exposed to the host after the plugin is loaded, so I think its pretty important to generate/allow a label for each macro, so users aren't required to enter the detailed view just to remember if they are automating the glide or the LFO amplitude etc. For single parameters that's simple, but for complex macros, its probably best to allow the user to just name the macro. Then a quick glance at the macro view will remind them what the 14 macros they've set were. I'd expect someone using it in live performance would largely want to see this view and what preset they are on.

Then the binding of an automation or macro to a host or binding to a MIDI CC is another layer of indirection.

I think you mean that you can midi learn on the macro controls and/or it exposes those to the host (which means you must go through the host specific workflow as well for automation) but I think that's reasonable. I can't really come up with a smoother way without really limiting flexibility.

great discussion, this is a really exciting feature idea!

[ssj71]

The radial menu is already there, but deactive as it didn't seem to serve too much use at the time of release.

to me that would be a convenient way to add it, right click any control, radial menu displays the available macro/automation slots. That said though, it would be really nice to have a view where everything is greyed out except the current macro parameters like you describe so you can get a quick view of what the macro is doing in context of how you would build the patch (a list of mapped parameters is not the same). That mode is fewer clicks is you know exactly what you are adding to the macro, but if later you are tweaking and think, "this parameter should be in a macro!" it would be nice to be able to add it without leaving the current view. Both workflows would be very convenient under different circumstances.

This is a similar delema to storing MIDI learn bindings, which currently aren't stored in instruments (as MIDI CC availablity partially depends upon the physical controller).

I think this differs slightly. I would not store midi bindings for the reason you state (though it should be stored in the plugin state when you reopen your daw), but macros IMO are really part of the patch. It describes what parameters are meant to be tweaked in a live manner.

I think the idea of having a fixed number of slots per instrument for macros and automations makes a lot of intuitive sense. Perhaps 8 Macro slots + 16 automation (current MIDI learn) slots per instrument. (perhaps a few global slots as well).

I agree thats a good way to go about it. I'm not sure I'm understanding the difference between a macro and automation slot except maybe the automation restricts to a single parameter. I think we might be fine just exposing 16-32 macros to the host and users can use them to expose single parameters or complex macros.

I don't think you can change the automation ports exposed to the host after the plugin is loaded, so I think its pretty important to generate/allow a label for each macro, so users aren't required to enter the detailed view just to remember if they are automating the glide or the LFO amplitude etc. For single parameters that's simple, but for complex macros, its probably best to allow the user to just name the macro. Then a quick glance at the macro view will remind them what the 14 macros they've set were. I'd expect someone using it in live performance would largely want to see this view and what preset they are on.

Then the binding of an automation or macro to a host or binding to a MIDI CC is another layer of indirection.

I think you mean that you can midi learn on the macro controls and/or it exposes those to the host (which means you must go through the host specific workflow as well for automation) but I think that's reasonable. I can't really come up with a smoother way without really limiting flexibility.

great discussion, this is a really exciting feature idea!

[unfa]

I guess it's be good to have the macro controls available at all times.

I guess one could assign the influence by clicking on the selected Macro Control circle(1 through 8) and then clicking and dragging on a knob/fader/slider to set the desired influence power. It could be positive or negative, and should be denoted visually around the selected GUI control (I like how Helm does this stuff).

I guess a special Macro Control tab should be added with a list of Macros, and a list of assigned controls, where the user can view and change the influence (-1 .. +1) multiplier a well as define the influence function, or mute an influence temporarily (useful for testing out patches and seeing how the influence changes the sound without zeroing the influence and then restoring that from memory).
Copying influence curves between controls/macros could be a nice thing also.

I guess the macro setup should be default be bound to the current patch (saved with Master settings) but also it'd be nice to have an option to save it as a separate thing.

So as I understand the idea is to allow a static number for Macro channels (8) and static number single-parameter automation (MIDI learn) (16?).

I would personally like to have the Macros work globally among all Parts so I can compose multi-part sounds and control them with Macros. I don't think I'd ever need 8 Macros per Part. 8 Macros total should be enough. We can later extend this to 16 if it seems that 8 is a bit limiting, but I don't think so (we could then have 2 Macro banks A and B, 8 Macros each).

Another thing is polyphonic vs. monophonic control.

Helm differentiates between these two allowing the user to route note velocity or polyphonic aftertouch to individual note's parameters. Some parameters accept polyphonic controls (like note velocity and filter) but some don't (like reverb or distortion effects).

I don't know how Zyn could integrate that approach with it's existing velocity sensing functions etc.
Using polyphonic aftertouch could be a great thing (to control note filter, volume, vibrato, modulation depth etc). Any ideas?

[unfa]

I guess it's be good to have the macro controls available at all times.

I guess one could assign the influence by clicking on the selected Macro Control circle(1 through 8) and then clicking and dragging on a knob/fader/slider to set the desired influence power. It could be positive or negative, and should be denoted visually around the selected GUI control (I like how Helm does this stuff).

I guess a special Macro Control tab should be added with a list of Macros, and a list of assigned controls, where the user can view and change the influence (-1 .. +1) multiplier a well as define the influence function, or mute an influence temporarily (useful for testing out patches and seeing how the influence changes the sound without zeroing the influence and then restoring that from memory).
Copying influence curves between controls/macros could be a nice thing also.

I guess the macro setup should be default be bound to the current patch (saved with Master settings) but also it'd be nice to have an option to save it as a separate thing.

So as I understand the idea is to allow a static number for Macro channels (8) and static number single-parameter automation (MIDI learn) (16?).

I would personally like to have the Macros work globally among all Parts so I can compose multi-part sounds and control them with Macros. I don't think I'd ever need 8 Macros per Part. 8 Macros total should be enough. We can later extend this to 16 if it seems that 8 is a bit limiting, but I don't think so (we could then have 2 Macro banks A and B, 8 Macros each).

Another thing is polyphonic vs. monophonic control.

Helm differentiates between these two allowing the user to route note velocity or polyphonic aftertouch to individual note's parameters. Some parameters accept polyphonic controls (like note velocity and filter) but some don't (like reverb or distortion effects).

I don't know how Zyn could integrate that approach with it's existing velocity sensing functions etc.
Using polyphonic aftertouch could be a great thing (to control note filter, volume, vibrato, modulation depth etc). Any ideas?

[unfa]

I wonder if instead of separate Automation and Macro slots shouldn't we just give more Macro slots?

It'd simplify the whole thing - and there's nothing wrong with users assigning a macro that drives only one parameter and uses to value transfer function etc. On the other hand - migrating a single-parameter Automation Control to a Macro Control to unlock extra features (like multiple outputs, transfer function, etc.) could bu cumbersome.

I quess that giving 16 Macro Control slots for the whole instance would be more than enough.

Also - in Zyn 2.x the plugin exposes Part Volume and Panning parameters to hosts - is that still a thing?

I guess it'd be cleaner to just expose the Macro Controls and allow the users to assign all they want to that. I think I once used the Part volume automation, and never more than 1 part at a time, so I would do this by Macros anyway.

[unfa]

I wonder if instead of separate Automation and Macro slots shouldn't we just give more Macro slots?

It'd simplify the whole thing - and there's nothing wrong with users assigning a macro that drives only one parameter and uses to value transfer function etc. On the other hand - migrating a single-parameter Automation Control to a Macro Control to unlock extra features (like multiple outputs, transfer function, etc.) could bu cumbersome.

I quess that giving 16 Macro Control slots for the whole instance would be more than enough.

Also - in Zyn 2.x the plugin exposes Part Volume and Panning parameters to hosts - is that still a thing?

I guess it'd be cleaner to just expose the Macro Controls and allow the users to assign all they want to that. I think I once used the Part volume automation, and never more than 1 part at a time, so I would do this by Macros anyway.

[unfa]

Then we could convert the "MIDI Learn" tab into "Macro Control" tab, with foldable list of Macro controls, like this:

[unfa]

Then we could convert the "MIDI Learn" tab into "Macro Control" tab, with foldable list of Macro controls, like this:

[ssj71]

I hadn't thought about adjustable influence. That could be adjusted through customizing the mapping function, but its probably easier and maybe even clearer the way you've described. The only thing I would add is a checkbox for range [0,1] or [-1,1] so the value either only goes up (or down if influence is negative) or goes both up and down from the knob setting as the macro is moved back and forth. I think it should be that if range [0,1] is selected setting the control knob to lowest and then moving the macro to the highest will move the control knob to its maximum. Contrastingly if range is [-1,1] then the knob must be set to the middle (12 o'clock) to get the full movement through the macro. If a parameter+macro is beyond its min or max value then it is bound to the limit.
kinda obvious stuff probably, but its good to have a clear spec too.

I wonder if instead of separate Automation and Macro slots shouldn't we just give more Macro slots?

I really agree.

I guess that giving 16 Macro Control slots for the whole instance would be more than enough.

I'd do 16 minimum, somebody making a song in a DAW might automate some voices a lot and may want individual control of more than 16 parameters. Maybe. I'd expect 8 to be too few at least, 16 probably covers 99% of users I'd guess.

Another thing is polyphonic vs. monophonic control.

Are you thinking macros "play" like an envelope or are they static mappings to a knob where the user can modulate it manually with a knob, or automated through a daw/midi lfo/midi envelope... ?
I've been assuming a macro is basically a one control to many mapping and is completely independent of time, basically highly customizable "expression" knobs. If you allow such macro to be modulated through an LFO or envelope, then polyphony/monophony/retriggering must be considered but in my mind that really is more a setting of the modulation signal than the macro.

If we are discussing macros that play (change on their own w.r.t. time) then I think we need to add a time knob control to each mapping function. IMHO we'd do better to have macros be static mappings as I describe and allow automation, either through some EGs or LFOs or just by a host or midi signal. I think that lowers implementation complexity and allows more flexibilty. Feel free to counterpoint.

Finally, I'd like to point out that somebody using a daw won't be mapping a macro to a midi signal at all, instead the DAW will be managing the automation (which is nice because then it has more than 128 values). The mockups you've given have fairly prominently focused on the Midi mapping, which might not actually be mapped very often (at least not when in a DAW). I mentioned a little that we should allow the macros to be named by the user so they can easily remember which does what with just a glance at the macro subview ("oh ya, that knob is 'twitch' and this one is 'growl'"). I think if they can see the current preset (maybe the next and previous) the macro values and names, this would become the most commonly used view for live performance.

[ssj71]

I hadn't thought about adjustable influence. That could be adjusted through customizing the mapping function, but its probably easier and maybe even clearer the way you've described. The only thing I would add is a checkbox for range [0,1] or [-1,1] so the value either only goes up (or down if influence is negative) or goes both up and down from the knob setting as the macro is moved back and forth. I think it should be that if range [0,1] is selected setting the control knob to lowest and then moving the macro to the highest will move the control knob to its maximum. Contrastingly if range is [-1,1] then the knob must be set to the middle (12 o'clock) to get the full movement through the macro. If a parameter+macro is beyond its min or max value then it is bound to the limit.
kinda obvious stuff probably, but its good to have a clear spec too.

I wonder if instead of separate Automation and Macro slots shouldn't we just give more Macro slots?

I really agree.

I guess that giving 16 Macro Control slots for the whole instance would be more than enough.

I'd do 16 minimum, somebody making a song in a DAW might automate some voices a lot and may want individual control of more than 16 parameters. Maybe. I'd expect 8 to be too few at least, 16 probably covers 99% of users I'd guess.

Another thing is polyphonic vs. monophonic control.

Are you thinking macros "play" like an envelope or are they static mappings to a knob where the user can modulate it manually with a knob, or automated through a daw/midi lfo/midi envelope... ?
I've been assuming a macro is basically a one control to many mapping and is completely independent of time, basically highly customizable "expression" knobs. If you allow such macro to be modulated through an LFO or envelope, then polyphony/monophony/retriggering must be considered but in my mind that really is more a setting of the modulation signal than the macro.

If we are discussing macros that play (change on their own w.r.t. time) then I think we need to add a time knob control to each mapping function. IMHO we'd do better to have macros be static mappings as I describe and allow automation, either through some EGs or LFOs or just by a host or midi signal. I think that lowers implementation complexity and allows more flexibilty. Feel free to counterpoint.

Finally, I'd like to point out that somebody using a daw won't be mapping a macro to a midi signal at all, instead the DAW will be managing the automation (which is nice because then it has more than 128 values). The mockups you've given have fairly prominently focused on the Midi mapping, which might not actually be mapped very often (at least not when in a DAW). I mentioned a little that we should allow the macros to be named by the user so they can easily remember which does what with just a glance at the macro subview ("oh ya, that knob is 'twitch' and this one is 'growl'"). I think if they can see the current preset (maybe the next and previous) the macro values and names, this would become the most commonly used view for live performance.

[fundamental]

Another thing is polyphonic vs. monophonic control.

Helm differentiates between these two allowing the user to route note velocity or polyphonic aftertouch
to individual note's parameters. Some parameters accept polyphonic controls (like note velocity and
filter) but some don't (like reverb or distortion effects).

I've got more detailed comments later (I misread some of the initial post), but to address this one point quickly, any automation/midi-learn-binding/macro/etc is doing the exact same thing as wiggling the knob on the user interface (with less latency). Having per-note automation/macros is not currently technically feasible.

I wonder if instead of separate Automation and Macro slots shouldn't we just give more Macro slots?

Yep, just ignore the split that I tried to make between a single parameter automation and a macro slot (part of the misreading mentioned above).

I should be able to address some of the other points later today

[fundamental]

Another thing is polyphonic vs. monophonic control.

Helm differentiates between these two allowing the user to route note velocity or polyphonic aftertouch
to individual note's parameters. Some parameters accept polyphonic controls (like note velocity and
filter) but some don't (like reverb or distortion effects).

I've got more detailed comments later (I misread some of the initial post), but to address this one point quickly, any automation/midi-learn-binding/macro/etc is doing the exact same thing as wiggling the knob on the user interface (with less latency). Having per-note automation/macros is not currently technically feasible.

I wonder if instead of separate Automation and Macro slots shouldn't we just give more Macro slots?

Yep, just ignore the split that I tried to make between a single parameter automation and a macro slot (part of the misreading mentioned above).

I should be able to address some of the other points later today

[unfa]

So the macros will be a replcement for current MIDI-learn system, allowing the user to basically move
multiple parameters with one, using adjustible influnces and function curves.

Maybe the curves should be reflecting the parameter changes live. That'd be a non-destructive yet highly intuitive way to manipulate the data. Here'sa 4-step mockup:

You can download the SVG if you want to modify this mockup on your own:
Macros 03.svg.zip

PS: Maybe it'd be nice to allow users to rename the macros, then the header of each macro would look like this:

And the plugin control ports would simply be named M01 through M16 (or Macro 01 through Macro 16) or whatever amount we pick.

[unfa]

So the macros will be a replcement for current MIDI-learn system, allowing the user to basically move
multiple parameters with one, using adjustible influnces and function curves.

Maybe the curves should be reflecting the parameter changes live. That'd be a non-destructive yet highly intuitive way to manipulate the data. Here'sa 4-step mockup:

You can download the SVG if you want to modify this mockup on your own:
Macros 03.svg.zip

PS: Maybe it'd be nice to allow users to rename the macros, then the header of each macro would look like this:

And the plugin control ports would simply be named M01 through M16 (or Macro 01 through Macro 16) or whatever amount we pick.

[fundamental]

Also - in Zyn 2.x the plugin exposes Part Volume and Panning parameters to hosts - is that still a thing?

I think that was just a DSSI thing and for better or worse the DSSI code is separated by several degrees from the LV2/VST versions.

I don't think I'd ever need 8 Macros per Part

The idea behind having macros specific to a single part/instrument would be to simplify setting up instruments which lend themselves well to automation. e.g.:

Imagine having the instrument very_dubstep_wubwub.xiz. presumably some LFO's frequency and depth are going to want to be automated to control the sound. By creating the concept of per instrument macros (and just a small number of them), it's a way for the author of the instrument to signal "this set of parameters is fun to play with" which currently tends to be done in the comment sections of various patches. Per-instrument automation/macro slots may just be an over-complication of the design however.

[fundamental]

Also - in Zyn 2.x the plugin exposes Part Volume and Panning parameters to hosts - is that still a thing?

I think that was just a DSSI thing and for better or worse the DSSI code is separated by several degrees from the LV2/VST versions.

I don't think I'd ever need 8 Macros per Part

The idea behind having macros specific to a single part/instrument would be to simplify setting up instruments which lend themselves well to automation. e.g.:

Imagine having the instrument very_dubstep_wubwub.xiz. presumably some LFO's frequency and depth are going to want to be automated to control the sound. By creating the concept of per instrument macros (and just a small number of them), it's a way for the author of the instrument to signal "this set of parameters is fun to play with" which currently tends to be done in the comment sections of various patches. Per-instrument automation/macro slots may just be an over-complication of the design however.

[unfa]

Hmm. If we were to allocate 16 Macros per instrument and register all of that in a host, finding wchich ones you need to automate in the DAW would become a difficult task.

I usually use XMZ (Master settings) files anyway, because I often use the system insertion effects (as the three slots per Part isn't enough most of the times).

[unfa]

Hmm. If we were to allocate 16 Macros per instrument and register all of that in a host, finding wchich ones you need to automate in the DAW would become a difficult task.

I usually use XMZ (Master settings) files anyway, because I often use the system insertion effects (as the three slots per Part isn't enough most of the times).

[fundamental]

If we were to allocate 16 Macros per instrument and register all of that in a host, finding wchich ones you need to automate in the DAW would become a difficult task.

I had some notes typed up for a more formal proposal/specification, but it's now out-of-date. The idea was roughly:

Master Automation Slot 1..16
Instrument 1..4 Automation Slot 1..4 (each)
Instrument 5..16 would have the same slots, but they would not be exposed to LV2/VST hosts
(32 slots total exposed to plugin host)

three slots per Part isn't enough most of the times

It's off-topic for this thread, but for reference what is your number of desired effects per-part?

[fundamental]

If we were to allocate 16 Macros per instrument and register all of that in a host, finding wchich ones you need to automate in the DAW would become a difficult task.

I had some notes typed up for a more formal proposal/specification, but it's now out-of-date. The idea was roughly:

Master Automation Slot 1..16
Instrument 1..4 Automation Slot 1..4 (each)
Instrument 5..16 would have the same slots, but they would not be exposed to LV2/VST hosts
(32 slots total exposed to plugin host)

three slots per Part isn't enough most of the times

It's off-topic for this thread, but for reference what is your number of desired effects per-part?

[unfa]

Maybe it'd be better to fine a way to allocate different Macros to static 16 ports, instead of having all that stuff out, looking really messy.

Maybe we need Part-level macros and Master-level macros, Part level macros could be controlled by Master-level macros and these would be exposed to the outside world.

Honestly I would just go for a simpler solution. I'm afraid if we make this too complicated, people will not know how to use it. and the extra complexity will do more harm than good.

I think that an optimal thing would be 16 Macro Controls available globally, without relation to any specific part, exposed in Plugin ports for automation and live control. A place on the main panel to view them at all times, and assign easily to controls. MIDI-learn tab turned into a Macro Control management.

As for Part FX: I don't know if it'd make sense performance-wise but having 8 of them would be a great thing. I often need to resort to system Insertion FX anyway to finish my chain, 8 of them would mean I would rarely ever need to use the system inserts for non-master FX.

[unfa]

Maybe it'd be better to fine a way to allocate different Macros to static 16 ports, instead of having all that stuff out, looking really messy.

Maybe we need Part-level macros and Master-level macros, Part level macros could be controlled by Master-level macros and these would be exposed to the outside world.

Honestly I would just go for a simpler solution. I'm afraid if we make this too complicated, people will not know how to use it. and the extra complexity will do more harm than good.

I think that an optimal thing would be 16 Macro Controls available globally, without relation to any specific part, exposed in Plugin ports for automation and live control. A place on the main panel to view them at all times, and assign easily to controls. MIDI-learn tab turned into a Macro Control management.

As for Part FX: I don't know if it'd make sense performance-wise but having 8 of them would be a great thing. I often need to resort to system Insertion FX anyway to finish my chain, 8 of them would mean I would rarely ever need to use the system inserts for non-master FX.

[unfa]

Another idea is an ingenious feature of Calf Filter, that I wish was more popular - inertia.

It acts as a lowpass-filter for the control input - smoothing the motion. Helps to get away with 7-bit MIDI-CC resolution when you need extra smooth motion in your sound.

And another thing - delay. This could allow one swing of a CC control to start a cascade of timed events to occur. You could assign 8 filter cutoffs, each with different control delay, making one short move put 15 seconds of complex motion into your ambient pad. sounds, when playing live.

If it'd be possible to control Macros with other Macros, one could create feedback loops of control signals, that would repeat a sequence slowly making it fade away or loose shaprness with the inertia control... this gets so crazy.

[unfa]

Another idea is an ingenious feature of Calf Filter, that I wish was more popular - inertia.

It acts as a lowpass-filter for the control input - smoothing the motion. Helps to get away with 7-bit MIDI-CC resolution when you need extra smooth motion in your sound.

And another thing - delay. This could allow one swing of a CC control to start a cascade of timed events to occur. You could assign 8 filter cutoffs, each with different control delay, making one short move put 15 seconds of complex motion into your ambient pad. sounds, when playing live.

If it'd be possible to control Macros with other Macros, one could create feedback loops of control signals, that would repeat a sequence slowly making it fade away or loose shaprness with the inertia control... this gets so crazy.

[fundamental]

I've started to try to summarize and formalize this discussion to present it to zynaddsubfx-user and the kvr forums for further discussion. The current rendered version is:
http://zynaddsubfx.sourceforge.net/proposals/automation/parameter-automation-future-plan.html

And it's sitting in the zynaddsubfx's repo to track changes https://github.com/zynaddsubfx/zynaddsubfx/tree/master/doc/automation-proposal . There's certainly some more work to be done to this to make a complete design document, but here's a start. Let me know if there's something else that should be moved into the design document before soliciting more feedback, or if you prefer feel free to make changes to the work-in-progress document directly and submit a pull request to the zyn repo.

[fundamental]

I've started to try to summarize and formalize this discussion to present it to zynaddsubfx-user and the kvr forums for further discussion. The current rendered version is:
http://zynaddsubfx.sourceforge.net/proposals/automation/parameter-automation-future-plan.html

And it's sitting in the zynaddsubfx's repo to track changes https://github.com/zynaddsubfx/zynaddsubfx/tree/master/doc/automation-proposal . There's certainly some more work to be done to this to make a complete design document, but here's a start. Let me know if there's something else that should be moved into the design document before soliciting more feedback, or if you prefer feel free to make changes to the work-in-progress document directly and submit a pull request to the zyn repo.

[unfa]

I've read through.

So we'd have automation slots that could be assigned to single controls (for simple and direct MIDI learn-style control assignement) or to Macros, for advanced control.

I'm not sure about the Automation slots amounts and assignement:

Master Automation Slot 1..32
Instrument 1..4 Automation Slot 1..4
Instrument 5..16 would have the same slots, but they would NOT be exposed to LV2/VST hosts

Is this a refined idea or just a rough concept?
I'm not sure if there should be a division between Master and Part automation slots at all.
I don't know if I'd ever use more than 16 total for a single instrument anyway. 32 total would be probably more than enough.

As for Master - Part automation slots. Maybe it'd be good to have just Master automation slots exposed to host. And Parts would have their own automation slots that could be binded to Master slots. This way a Part can have up to 32 automation slots (that are labelled, and could have default bindings to Master slots, but it's up to the user to enable them or where to bind them).

Maybe Macros should also exist on Master and Part Level for the same reason.

Master though will be a gateway for whatever Parts expose. Master can ignore all that and use something else.

This way loading a new Instrument won't break anything, users can use the host-exposed Automation slots for whichever part they want, and choose which Automation slots and Macros defined in Part level they want to use.

Part level Automation slots and Macros would obviously have access only to parameters saved in XIZ files (inlcluding Part Effects).

[unfa]

I've read through.

So we'd have automation slots that could be assigned to single controls (for simple and direct MIDI learn-style control assignement) or to Macros, for advanced control.

I'm not sure about the Automation slots amounts and assignement:

Master Automation Slot 1..32
Instrument 1..4 Automation Slot 1..4
Instrument 5..16 would have the same slots, but they would NOT be exposed to LV2/VST hosts

Is this a refined idea or just a rough concept?
I'm not sure if there should be a division between Master and Part automation slots at all.
I don't know if I'd ever use more than 16 total for a single instrument anyway. 32 total would be probably more than enough.

As for Master - Part automation slots. Maybe it'd be good to have just Master automation slots exposed to host. And Parts would have their own automation slots that could be binded to Master slots. This way a Part can have up to 32 automation slots (that are labelled, and could have default bindings to Master slots, but it's up to the user to enable them or where to bind them).

Maybe Macros should also exist on Master and Part Level for the same reason.

Master though will be a gateway for whatever Parts expose. Master can ignore all that and use something else.

This way loading a new Instrument won't break anything, users can use the host-exposed Automation slots for whichever part they want, and choose which Automation slots and Macros defined in Part level they want to use.

Part level Automation slots and Macros would obviously have access only to parameters saved in XIZ files (inlcluding Part Effects).

[fundamental]

On 04-25, unfa wrote: I've read through.

Thanks

So we'd have automation slots that could be assigned to single controls (for simple and direct MIDI learn-style control assignement) or to Macros, for advanced control.

Yep, the slot is the same in both cases, though I imagine the workflow for learning simple vs. complex slots would be different. (e.g. mapping all the knobs on a midi controller vs. learning a slot for tuning one instrument withing a plugin hosted song)

I'm not sure about the Automation slots amounts and assignement: Master Automation Slot 1..32 Instrument 1..4 Automation Slot 1..4 Instrument 5..16 would have the same slots, but they would NOT be exposed to LV2/VST hosts Is this a refined idea or just a rough concept?

I would say a rough concept.

I'm not sure if there should be a division between Master and Part automation slots at all.

Same here. I like the idea of being able to save/associate automation slots with instruments (.xiz), but how to do so in a logical manner isn't at all clear.

I don't know if I'd ever use more than 16 total for a single instrument anyway. 32 total would be probably more than enough.

The highish number is mostly for midi controller use. I have one nanokontrol and that has 8 knobs, 8 sliders, and 24 toggle(?) buttons. The existing MIDI learn setup will allow learning as many CCs as you'd like and I'd like to not interfere with that bound too much. Perhaps this is a spot where the difference between 'available slots' and 'host exposed slots' makes sense.

As for Master - Part automation slots. Maybe it'd be good to have just Master automation slots exposed to host. And Parts would have their own automation slots that could be binded to Master slots. This way a Part can have up to 32 automation slots (that are labelled, and could have default bindings to Master slots, but it's up to the user to enable them or where to bind them).

That sounds reasonable. This would mean that there's master and part automation slots, but the host is only exposed to master slots which would have an option to be aliased to particular part slots.

[fundamental]

On 04-25, unfa wrote: I've read through.

Thanks

So we'd have automation slots that could be assigned to single controls (for simple and direct MIDI learn-style control assignement) or to Macros, for advanced control.

Yep, the slot is the same in both cases, though I imagine the workflow for learning simple vs. complex slots would be different. (e.g. mapping all the knobs on a midi controller vs. learning a slot for tuning one instrument withing a plugin hosted song)

I'm not sure about the Automation slots amounts and assignement: Master Automation Slot 1..32 Instrument 1..4 Automation Slot 1..4 Instrument 5..16 would have the same slots, but they would NOT be exposed to LV2/VST hosts Is this a refined idea or just a rough concept?

I would say a rough concept.

I'm not sure if there should be a division between Master and Part automation slots at all.

Same here. I like the idea of being able to save/associate automation slots with instruments (.xiz), but how to do so in a logical manner isn't at all clear.

I don't know if I'd ever use more than 16 total for a single instrument anyway. 32 total would be probably more than enough.

The highish number is mostly for midi controller use. I have one nanokontrol and that has 8 knobs, 8 sliders, and 24 toggle(?) buttons. The existing MIDI learn setup will allow learning as many CCs as you'd like and I'd like to not interfere with that bound too much. Perhaps this is a spot where the difference between 'available slots' and 'host exposed slots' makes sense.

As for Master - Part automation slots. Maybe it'd be good to have just Master automation slots exposed to host. And Parts would have their own automation slots that could be binded to Master slots. This way a Part can have up to 32 automation slots (that are labelled, and could have default bindings to Master slots, but it's up to the user to enable them or where to bind them).

That sounds reasonable. This would mean that there's master and part automation slots, but the host is only exposed to master slots which would have an option to be aliased to particular part slots.

[ssj71]

This would mean that there's master and part automation slots, but the host is only exposed to master slots which would have an option to be aliased to particular part slots.

I like that idea, just as long as when a new slot is filled/mapped its automatically mapped to the next available master slot. This way you don't have to map a knob to an instrument slot and map that slot to a master slot just to automate it.

[ssj71]

This would mean that there's master and part automation slots, but the host is only exposed to master slots which would have an option to be aliased to particular part slots.

I like that idea, just as long as when a new slot is filled/mapped its automatically mapped to the next available master slot. This way you don't have to map a knob to an instrument slot and map that slot to a master slot just to automate it.

[fundamental]

There's still plenty left to do, but a fairly large portion of the internals needed to upgrade the automation system have been implemented. As one progress snapshot, here's the current WIP version of the UI

[fundamental]

There's still plenty left to do, but a fairly large portion of the internals needed to upgrade the automation system have been implemented. As one progress snapshot, here's the current WIP version of the UI

[fundamental]

A few more hours into implementation and:

• there are now indicator lines to show the current values of all slots below the labels
• the indicators are connected to the zyn audio process (both the new ones and the circle indicators on the plots)
• the individual parameters display names, though not in the format proposed by this issue (see the feature-issue on the osc-bridge repo)
• the UI updates as soon as a parameter is bound to a slot (new or pre-existing) and if a parameter is bound to a midi CC
• parameters within a slot have a primitive active/inactive color indicator
• parameters can be learned to new slots from the GUI (learning to the same is in the OSC API, but not in GUI interactions yet)

Still to be done:

• Learning a macro from within the UI
• Making the min/max/gain/offset knobs do anything beyond eye candy
• Unlearning a slot from within the UI
• Unlearning a parameter from within the UI
• Testing this in a VST host (it should work in VST/LV2 hosts already, but I have not tested to confirm)
• File loading and file saving
• Testing it with floating point parameters (it should go nicely with the floating point filter update)

[fundamental]

A few more hours into implementation and:

• there are now indicator lines to show the current values of all slots below the labels
• the indicators are connected to the zyn audio process (both the new ones and the circle indicators on the plots)
• the individual parameters display names, though not in the format proposed by this issue (see the feature-issue on the osc-bridge repo)
• the UI updates as soon as a parameter is bound to a slot (new or pre-existing) and if a parameter is bound to a midi CC
• parameters within a slot have a primitive active/inactive color indicator
• parameters can be learned to new slots from the GUI (learning to the same is in the OSC API, but not in GUI interactions yet)

Still to be done:

• Learning a macro from within the UI
• Making the min/max/gain/offset knobs do anything beyond eye candy
• Unlearning a slot from within the UI
• Unlearning a parameter from within the UI
• Testing this in a VST host (it should work in VST/LV2 hosts already, but I have not tested to confirm)
• File loading and file saving
• Testing it with floating point parameters (it should go nicely with the floating point filter update)

[fundamental]

• Unlearning slots works
• Unlearning parameters works
• Learning macros form within the UI works
• Gain/Offset knobs work on real data
• Floating point parameters work fine

• The plots don't update to the right curves when changing to the view for the first time
• VST test and serialization are still to do
• Layout for the gain/offset/clear needs to be cleaned up
• Temporary active/disabled (i.e. not erased) states are TBD

[fundamental]

• Unlearning slots works
• Unlearning parameters works
• Learning macros form within the UI works
• Gain/Offset knobs work on real data
• Floating point parameters work fine

• The plots don't update to the right curves when changing to the view for the first time
• VST test and serialization are still to do
• Layout for the gain/offset/clear needs to be cleaned up
• Temporary active/disabled (i.e. not erased) states are TBD

[fundamental]

Automations are confirmed to work within Renoise and this work has been merged into the master branch of the ZynAddSubFX repo.

[fundamental]

Automations are confirmed to work within Renoise and this work has been merged into the master branch of the ZynAddSubFX repo.

[unfa]

Awesome! Is this already on Gumroad?
I can't wait to dig all of this up and try it out!

[unfa]

Awesome! Is this already on Gumroad?
I can't wait to dig all of this up and try it out!

[fundamental]

On 07-02, unfa wrote: Awesome! Is this already on Gumroad? I can't wait to dig all of this up and try it out!

The next release is planned to be out in a week or two. The current blockers are finishing off serialization for the new automation system and updating the windows build scripts.

[fundamental]

On 07-02, unfa wrote: Awesome! Is this already on Gumroad? I can't wait to dig all of this up and try it out!

The next release is planned to be out in a week or two. The current blockers are finishing off serialization for the new automation system and updating the windows build scripts.

[fundamental]

Serialization is added, so this release should be basically ready.

[fundamental]

Serialization is added, so this release should be basically ready.

[mikobuntu]

Serialization is added, so this release should be basically ready.

I don't mind that there is no Win build yet, I'm ready to have fun with this on Linux now :)

[mikobuntu]

Serialization is added, so this release should be basically ready.

I don't mind that there is no Win build yet, I'm ready to have fun with this on Linux now :)

[fundamental]

@mikobuntu The release will be out this week, so hopefully you can wait a little longer :p

[fundamental]

@mikobuntu The release will be out this week, so hopefully you can wait a little longer :p

[mikobuntu]

@fundamental Thank you, looking forward to using/ &| /testing this :)

[mikobuntu]

@fundamental Thank you, looking forward to using/ &| /testing this :)

[mikobuntu]

@fundamental Just downloaded Zyn-Fusion 3.0.2 :) I can report success running in Bitwig on Ubuntu 16.04 ... ( i just need to learn exactly how to use the macro system properly ) Automation is indeed working for the Macro slots, thank you :)

[mikobuntu]

@fundamental Just downloaded Zyn-Fusion 3.0.2 :) I can report success running in Bitwig on Ubuntu 16.04 ... ( i just need to learn exactly how to use the macro system properly ) Automation is indeed working for the Macro slots, thank you :)

[fundamental]

https://www.ableton.com/en/manual/instrument-drum-and-effect-racks/#using-the-macro-controls, the yamaha Motif, and Elektron Analog Four (Mk1) designs might be helpful when considering usability concerns with future revisions.

[fundamental]

https://www.ableton.com/en/manual/instrument-drum-and-effect-racks/#using-the-macro-controls, the yamaha Motif, and Elektron Analog Four (Mk1) designs might be helpful when considering usability concerns with future revisions.