Zebra 3 Control ABCD - MIDI vs. Macros

[Sound Author]

If people use our instruments with controllers that do not support Pressure or even Velocity, that is a choice they make, not ours. We're sad that people miss out.

I'm honestly not trying to be argumentative, but this is literally the point of view that I was expressing in an earlier post...

If your controller doesn't have aftertouch, that's okay. You still experience the same patch everyone else does; you just don't get to hear what aftertouch does.

In this case, if you don't have an MPE controller with Timbre, you suddenly hear a completely different sound, especially if Timbre is assigned to something really noticeable like filter frequency.

The only reason I'm repeating myself here is because I'm not sure my point is getting through. When Timbre modulation is assigned via Controls A-D, because it's handled as a unipolar signal, the center position (50% of the modulation depth) moves the target parameter away from its original manually set position. But if I unplug my MPE controller, the Timbre signal vanishes, so 50% of the modulation depth also vanishes.

This is a huge problem for sound designers who care about different users with different controllers hearing the same sound before they even touch their MIDI controllers. And this is why Ou_Tis and I have been hung up on this.

If the the manually set knob value was the starting point, then both standard MIDI controller users and MPE users alike would hear exactly the same sound when they open the patch, and that was my basis for suggesting that Timbre be its own dedicated modulation source because it would disentangle it from Controls A-D completely and they could remain simple unipolar knobs.

As it is now, I can't really use Timbre at all without producing a noticeably different sounding patch for non-MPE users, and to me, that's nothing short of a tragedy because it means that the only people who will hear the patch I actually made will be MPE users, and I have no reason to make sounds exclusively for a small audience of MPE users.

Zebra 3 is not the only synth that handles Timbre this way. I've had this discussion with other developers. Sometimes people ask me why I still haven't made sounds with MPE expression. THIS is the reason why. Timbre is such a cool thing, but because of the way it's implemented in almost every synth I've tried to use it with, I pretty much have no use for it, other than tinkering with it for about 20 minutes and then saying to myself "It's a shame I can't use Timbre in my soundsets".

[Urs]

We know that the bipolar setting for A..D is buggy in that it does not reset to the center position. Once fixed, it's fixed, and a bipolar Timbre setup with it.

[Sound Author]

Yeah, that would fix it, but then you end up with what appears to be a bipolar macro knob (I know, you don't consider them to be macro knobs.) I mean, don't get me wrong, I'll take whatever solution I can get. Will the patch save the zero position for bipolarized Controls A-D?

[Urs]

Will the patch save the zero position for bipolarized Controls A-D?

Yes, that is the point of that bugfix.

[SamDi]

TL;DR

• don't understand the term macros vs. A-D beeing no-macros. Aren't they?
• please give us 8 of them
• please save state like value and uni/bi-d. in the presets. Don't understand the claimed interference between state saving and MIDI/MPE
• don't understand the neccessity of setting MIDI CC in preferences, should be mapped via DAW or at least common MIDI learning

/TL;DR




It's seems to be a very big topic, and I am not sure, if I can make my point in this post very well, but let's try.

First I want to state, that I personally are unhappy, that the great macro system from Hive2 didn't find it's way into Zebra 3.

Also I admit, that I have difficulties to understand, why some premises are set as they seem to be set.

So a lot of discussion has emerged about Zebra 3's Control A-D. These are user definable MIDI Control Changes to be used in Zebra's modulation system. We used to have two, A (defaulting to MIDI CC#2 Breath Controller) and B (defaulting to MIDI CC#11 Expression), but now we have four.

I never understood, what should have been the benefit of two parameters, where a MIDI CC is set in the preferences in opposite of having these as macros and handle them via common MIDI learning or leave it to the DAW to map it with a MIDI CC.

Unfortunately, about 20 years ago, some DAW manufacturers and plug-in API maintainers decided that MIDI was a thing from the past. So they kind of took MIDI out or put it into a lesser position than other means of expression, e.g. parameter automation. So some DAWs simply don't offer a good MIDI workflow, and some users in turn don't even use MIDI based input devices for music production.

Because it IS from the past. MIDI is perfectly fine as a protocol between a HW controller and the DAW. But it is an anachronism as a protocol between the DAW and a synth plugin itself. MIDI (1) has a low time resolution, a low value resolution and needs workarounds to have polyphonc parameters, while VST3 and CLAP have time resolution on sample rate, high resolution on parameter values and easily integrate polyphonic expression. It's unfortunate, that allmost all DAWs and allmost all synth providers missed to integrate note expression from VST3. The same as CLAP is not fully established overall. Because if it would, there would be no need to implement MPE on synth side, because they would be approached via the plugin format protocol, while it would be task of the DAW to handle input controllers formats, independent, if they were just Poly-AT or MPE or MIDI 2.0.

So it's really the DAW, which should be the hub of communication between HW controllers, mapping from MIDI to synth parameters and not the synth itself.

But MIDI is not dead, it is very much alive, with MPE and MIDI 2.0 and an abundance of Controllers that now send MIDI via standard USB protocols etc. - therefore, MIDI Control Changes are still absolutely relevant, even if not for everyone. D'oh, some of these MIDI-is-dead hosts do their own "MIDI Learn" and pass it on as automation even though it could just pass the raw MIDI for a better experience...

What you also seem not to take under consideration is, that one might have an n to m relation between HW controllers and plugin synths. So it's a good approach to map the mostly 8 MIDI faders of most controllers via script to often 8 macro controls/remote controls/quick controls or however they are called in the DAW. These you can then map to often 8 macro controls of plugin synths, where the presets decide how these 8 macros then should be used.

As a result you can connect each controller and once mapped, each has direct access to the 8 synth macros. How would you handle this in Zebra, where some controllers have different CCs on faders? You would need different preference settings for this. A DAW can handle multiple HW controllers much better, than a synth could ever do.

We have also, quite deliberately, not added a macro system to Zebra 3. Most sound designers do not have the patience to set them up. In fact, we spent 7 years setting up XYs for our Zebra 2 and Hive soundsets. In our experience, tagging presets and setting up macros costs at least as much as the sound design itself, because many - if not most - sound designers won't do it (or decline the job, or charge double the money and still do a half decent job, not everyone, but quite a few). So we have had a full time position for 7 years, analysing presets, setting things up, and now that is over and we won't do it anymore. Factory defined macro controls are not a commercially viable thing to do for factory libraries of a size and quality that do our synths justice, not when humans have to do it.

I don't know. I mean, each of the big synths today has macros and each are defined. I don't know, if their sound desingner, had the same struggle as your's, but they did have to do the job also.

Furthermore, to be honest, I don't get, how it was so difficult to define the macros for Hive 2. I mean, as I perceive, they are mostly set in a pretty common way, with 1,2 for OSC vol and detune, 3,4 Filter cutoff/res, 5,6 ENV attack/release and 7,8 Fx delay,reverb dry/wet. It's really mostly that way. So I don't understand, how the sound designers had to scratch their head for each single preset.

But at the end, I personally do not care so much, how many of the macros are really used in factory presets. It would be OK for me, if some were left blank. But for me it would be important, to have nevertheless 8 of them for personal use, because 4 is too few. And it would be important that they can be saved with state in the preset.

So because we don't have macros, the people who would like to have them, wish for Controls A-D to be macros. That is also what we had hoped to do, as macros and performance controls commonly target the same parameters in the same way. It makes a lot of sense to make the effort once and be done with it. Make no mistake, setting up Control A-D in a 1200 preset factory library was a huge pain point, and one of the major reasons it took so long to get us here.

What I don't understand in this discussion: you talk about A-D not beeing macros. What are they then? What is the definition of a macro in this context and what's inherently needed to name them a macro? In my understanding A-D controls are kind of macros already, aren't they?

So our hope was for Control A-D to

• be user definable MIDI Control Changes (works!)

Why? As stated before it should be normal MIDI mapping of a parameter or better mapped from the DAW. No need to map a parameter with MIDI CC from the synth itself. What should be the benefit of it? I have no problem with it, that MIDI CCs can assigned to them in the synth preferences, but it should not lead to the consequence, that the current values are then not saved in the presets.

• be automatable knobs that remote control those MIDI Control Changes (works!)
• be macro controls that save with preset (didn't work out because...)

Yes and yes, would be very important.

However, once we managed to merge all these concepts, and the parameters of knobs A-D saved with preset, things got mangled up for the MIDI crowd. MPE would behave irrational because the last Timbre expression was saved and recalled with preset. I can't go into too much detail, but being able to save macro-based variations of presets led to less playable sounds for the expressive keyboard players.

No why? When you link e.g. Cutoff to MIDI cc and save a value of that in the preset, why should it get mangled up when loading another preset. It's normal then, that the HW fader position doesn't match with the new preset and there are several strategies (jump, pickup, etc.) how to get back in sync between HW fader status and synth parameter again.

Furthermore, I really don't get, what MPE (parameters) should have to do with macro/parameters. They should be completely independent of each other. Why should an MPE MIDI CC (e.g. 74), which is used in multiple channels, be affected from a macro knob, which is kind of monophonic? Why should one want to map it to CC 74 then, when it is already used for MPE slide? The ways you do expression by a HW controller should be separated from how you change sound via faders or knobs. I don't see, why saving A-D values in the preset should affect polyphonic expressivity.

In order to remedy the situation, we dropped the macro concept for A-D, but people can "bake" A-D into the preset. So if people use A-D like macros, and want top preserve the setting in a presets, they can do so by baking the settings into the preset. This works, but it is also merely a workaround. (But it is a great feature for people who want to free a few Controllers for other purposes)

I don't see how, baking in the current A-D values, means updating the parameters and reset A-D does help in opposite beeing able to save A-D position and state in the preset.

Now, how do we save this in a future update?

Some options are:

• better labelling so people can't mistake A-D as macros (probably the least satisfying solution)
• add 4 "User Macros", but they are empty by default, or maybe they optionally duplicate A-D

Please give us 8

[*] add automatic macros, but that requires a lot of dev and it may not be satisfying
[*] add a switch/setting that enables A-D to be used as proper macros, not sure how to do this reliably[/list]

Would be also OK, but make it A-H then.

[Urs]

You ask a lot of questions, I don't think I have the time to answer them all. Everything was explained in depth (but scattered) in other threads leading up to this thread. The statements in the opening post are the baseline of discussion.

I can't go back to re-establish all fundamental facts that you put in question. For instance in our experience, setting up macros is the most expensive part of preset design. You can either accept that as fact or not. If you can't then we do not have many grounds to continue the discussion of Control A..D.

Likewise, MIDI is one of the few industry standards. It will not go away. I won't discuss this either, and if our motivation to support it can not be accepted, then we have even less grounds to continue the discussion of Control A..D.

[jooster]

[*] don't understand the term macros vs. A-D beeing no-macros. Aren't they?

Macro = control with offset (i.e., preferred value); a plain control takes its value from the cc message, a macro adds its value from the preset.

Furthermore, I really don't get, what MPE (parameters) should have to do with macro/parameters. They should be completely independent of each other. Why should an MPE MIDI CC (e.g. 74), which is used in multiple channels, be affected from a macro knob, which is kind of monophonic? Why should one want to map it to CC 74 then, when it is already used for MPE slide? The ways you do expression by a HW controller should be separated from how you change sound via faders or knobs. I don't see, why saving A-D values in the preset should affect polyphonic expressivity.

CC74 (timbre) is routed to one of the ABCD controls inside Zebra3. This makes timbre available for anyone without an mpe controller yet can be controlled by mpe if one has one. Because they share that one Control slot, a saved macro value and live MPE expression both write the same place, which is the entire reason saving A–D values caused MPE patches to misbehave.

[SamDi]

You ask a lot of questions, I don't think I have the time to answer them all. Everything was explained in depth (but scattered) in other threads leading up to this thread. The statements in the opening post are the baseline of discussion.

Yes, there are some questions, though many are kind of rhethorical.

I can't go back to re-establish all fundamental facts that you put in question. For instance in our experience, setting up macros is the most expensive part of preset design. You can either accept that as fact or not. If you can't then we do not have many grounds to continue the discussion of Control A..D.

Likewise, MIDI is one of the few industry standards. It will not go away. I won't discuss this either, and if our motivation to support it can not be accepted, then we have even less grounds to continue the discussion of Control A..D.

I don't think, that what I can "accept" or not, does matter to the discussion, how A-D can be well implemented. You can support MIDI as you want, though it is kind of "useless" IMHO, because DAWs can do that mapping already via parameter updates and map MIDI CC to this, so there is no need for it. You didn't answer, how one can handle multiple-MIDI-controller setups with each having different MIDI CC values on their mostly 8 knobs.

My point is, the discussion of A-D beeing macros or non-macros is artificial, because they ARE macros already, but not "correctly" implemented, because they don't save their state with the preset.

Maybe the macro vs. non-macro discussion made sense in Hive 2, where the "real macros" are heavily used, while A-B are kind of a side phenomen, not heavily supported over all presets.

But in Zebra 3 there is nothing other than A-D and they are the new macros now, because they do exactly what macros do, meaning controlling multiple other parameters at once.

So the first point of my thread is, adressing that really the state should be saved. Furthermore I still don't see, even when a MIDI CC is controlling it or it is used for MPE, why it should conflict with a preset saved value. What's the difference of beeing set to 0 and then get overwritten by MPE-keypress and receiving 64@CC74 or having another value first? The bake-in option does not help (me).

Second point is, that 8 macros would be nicer, than 4. Even if your sound designers don't use them, there are sometimes cases, where 4 macros can be to less for own presets. Most MIDI controllers have 8 faders, knobs, etc. so it would be cool to beeing able to fully map them to A-H.

[*] don't understand the term macros vs. A-D beeing no-macros. Aren't they?

Macro = control with offset (i.e., preferred value); a plain control takes its value from the cc message, a macro adds its value from the preset.

Yeah, but that's exactly, what A-D do, they add offsets to the affected parameters via modulation, while beeing controlled by a MIDI CC or automation. That's exactly what macros normally do, not?

Furthermore, I really don't get, what MPE (parameters) should have to do with macro/parameters. They should be completely independent of each other. Why should an MPE MIDI CC (e.g. 74), which is used in multiple channels, be affected from a macro knob, which is kind of monophonic? Why should one want to map it to CC 74 then, when it is already used for MPE slide? The ways you do expression by a HW controller should be separated from how you change sound via faders or knobs. I don't see, why saving A-D values in the preset should affect polyphonic expressivity.

CC74 (timbre) is routed to one of the ABCD controls inside Zebra3. This makes timbre available for anyone without an mpe controller yet can be controlled by mpe if one has one. Because they share that one Control slot, a saved macro value and live MPE expression both write the same place, which is the entire reason saving A–D values caused MPE patches to misbehave.

How does a saved macro value after loading a preset and then a live send update to that value via MIDI CC (independent if it's MPE or not) interconflict? When first MIDI CC is send, the macro value updates to that. Is that a problem? I mean other synths also use macros to map MPE dimension in it (Serum and Pigments as far as I am aware), and these save macro values also. What makes them different? Also, if this would really be a problem dedicated to MPE only, then macro behaviour could change, as soon as Zebra is switched to MPE mode.

[Urs]

Second point is, that 8 macros would be nicer, than 4. Even if your sound designers don't use them, there are sometimes cases, where 4 macros can be to less for own presets.

When I open a synth with macros and browse the factory library and most presets have only like the first few macros assigned (even of only 4...), I feel like they failed at making a good preset library. It comes across half assed. That's why we went through the pains of filling the gaps. 7 years.

This is exactly about controllers with 8 knobs such as NKS. Later expects the plug-in to tell it what parameters to map those 8 knobs to. If we have 8 macros, we assign those 8 macros, as we did in Hive 2 and Zebra 2. But if half of the library has half assed assignments, then we didn't do a good job at NKS - many presets won't have any function on some of those knobs. Hey, we would even fail the NKS quality control process.

When first MIDI CC is send, the macro value updates to that. Is that a problem?

Yes, obviously.

[NAD]

When I open a synth with macros and browse the factory library and most presets have only like the first few macros assigned (even of only 4...), I feel like they failed at making a good preset library. It comes across half assed.

I find this very surprising coming from you. I'm sure if one of your sound designers sent you a Zebra patch that didn't use up every single available module you wouldn't call that half-assed!

If anything, I actually appreciate presets that don't attempt to use every possible feature of a synthesizer (and that includes macros). I think it shows restraint and it can often be more interesting or creative. Minimalist presets can showcase a unique feature of the synth without burying it in complexity. In other words, not using all the macros can be intentional and good. In my most humble opinion of course!

[pdxindy]

If anything, I actually appreciate presets that don't attempt to use every possible feature of a synthesizer (and that includes macros). I think it shows restraint and it can often be more interesting or creative. Minimalist presets can showcase a unique feature of the synth without burying it in complexity.

Even minimalist presets (most of mine are that), can benefit from subtle variations controlled by two or more A-D knobs. The restraint is in how they are used, not whether they are used.

[NAD]

The restraint is in how they are used, not whether they are used.

Why not both?