Zebra 3 Control ABCD - MIDI vs. Macros

[pdxindy]

If the switch approach can be easily accomplished, I'd agree that's the best option. MPE folks could use the current-state option. The rest of us could use them as macros.

Only 1 of the Control A-D knobs is needed for MPE.

[machinesworking]

The best implementation of this IMO comes from Bitwig. It remembers both a universal setting and a project setting.

I still do not get why a patch macro is a bad thing? the argument against it seems to be that people want parameters already mapped to 8 macros like in the Zebra XY grids? but that seems like throwing the baby out with the bathwater to just ditch them because people whinged. Maybe it's my ignorance but I also don't get why developers don't host preset sharing as a way to encourage sales etc. Bitwig doesn't host it's mappings or Grid creations that I know of for example, and no plugin I know of does beside the Reaktor Library. Is it for fear that patch designers won't make commercial patches? or is it maintaining a webpage vs...?

[Fannon]

They can already be made bipolar by clicking the little arrow under the knob. This makes knob position 0 correspond to control value -100. I did a quick test of this and found that the knob still resets to position 0, though. That's not very useful for baking in the sweet spot in the middle of the range. I would definitely want it to reset to the middle position, instead. It's also a little odd to me that in bipolar mode it still displays knob values from 0 to 100 instead of the control values from -100 to 100.

I also like the idea of a switch between MIDI and macro modes.

Thanks, I didn't notice you could do that. But without ressetting then to middle point and initializing midle point by default it's not really helping, right?

[Chris-S]

Is the bipolar switch stored in presets/projects?

EDIT: Tested : No, not saved.

[Dr.Gunjah]

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.

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.

I'm not sure if I understand this. I can get behind the thought process of ditching the macro system because it takes a lot of effort. However, it seems like you did put it the effort anway in form of the "not-macro" controls. It seems like a huge waste to not re-use that for the users that actually want and use macros. So my vote goes to a switch to turn saving their states on or off.

From a user perspective I wonder if we need the state of those control be saved in the actual preset anyway. I honestly care more about it being saved in the project. What should probably be saved in the preset is the uni/bipolar setting, because that seems to be entirely on the sound designer to decide how that macro is supposed to be used. Maybe the default state when switching presets could be fully left for uni and middle position for bipolar.
I guess preset designers may want to save the states in the preset to have the presets show up to the user at "peak flashiness" but it should be possible to design around the defaults to do that.

Also, slight off-topic I've just realized that unlike the other u-he synths, Zebra3 actually exposes the mod wheel to automation. Quite the huge change for me at the usability front
Any chance this will also make it into Repro and Diva?

[Urs]

I'm not sure if I understand this. I can get behind the thought process of ditching the macro system because it takes a lot of effort. However, it seems like you did put it the effort anway in form of the "not-macro" controls. It seems like a huge waste to not re-use that for the users that actually want and use macros. So my vote goes to a switch to turn saving their states on or off.

As I said, we had *hoped* that they'd just work as macros, simply if we save them. But that did not work out. I have no first hand experience (I personally don't care about macros, I have MIDI), but we had a several months long testing phase where there was problem after problem.

[Dr.Gunjah]

Is the issue really storing them? Or is it actually the loading on preset switch? I assume project load shouldn't be much of an issue anyway considering it is once at the beginning of a session.
If you always store them in both preset and project but have two options to load controls on project load/preset switch wouldn't that satisfy everyone?

[inkling]

Forgive my ignorance here (i'm just a simple man) so sorry if this is obvious stuff. A couple of observations when using Bitwig (with Zebra's Control knobs mapped in the Device panel). Which makes them unworkable for me in their current state.

1. Currently Zebra's Control knobs reset to their off position when re-opening a project when Bitwigs Device panel knobs (mapped to Zebra Control knobs) had been saved at particular values.

2. After turning Bitwig's Device panel knobs (mapped to the Zebra Control knobs) to a particular value and then changing presets, Bitwig's Device panel knobs do not re-set to the off position of the new Zebra preset's Control knob state. This causes a jump back to zero when Bitwig's Device panel knob is then moved.

If these two issues could be reversed, ie, the project save retained Bitwigs Device panel knob position in the first example and in the second example, the Device panel knob position reset to off when changing presets that would make Zebra's Control knobs far more useful (if this behaviour would be possible using a switch as discussed previously, then i'm all for it).

[yellowmix]

My understanding is that A-D are performance controls like the virtual pitch wheel and mod wheel and keyboard. They are all host automatable. The latter three are not saved into presets because they are purely performance controls. But when A-D are saved become "macros", where control B default is MPE Expression.

I don't understand what the issue is. I have MPE, I also have a standard MIDI keyboard with an expression (CC11) pedal. If control B position is baked into a preset or project state on load, so what? I either move the pedal where I want it live and it stays there, or host automation will override it in automation read modes if there is automation, or overwrite if in automation write modes. Or users can assign Control B default to another CC or none at all and it becomes pure host automation. Are other people doing something differently?

I also don't understand why A-D can't be empty/unassigned macros in presets. I appreciate the tremendous effort in assigning it to all presets in Zebra2. But I didn't expect it. Or is it that u-He is holding itself up to a standard no other company does?

I'm looking at Serum/Serum 2, Phase Plant, etc., having presets with empty macro slots, and modwheel often unassigned. Omnisphere 3 has "The Orb", a single XY pad automatically "intelligently" assigned to parameters (it's a black box so no idea how it works, when it works since it's got varying efficacy). Biotek has had its XY pad prominently featured. Zebra 2 having 4 of them on all presets is beyond ambitious and you actually did it. So scaling it back to 4 individual controls is still ambitious. 4 controls are like 2 XYs, but you don't have to think about control pairs being cohesive.

If a designer designed an expressive performance patch then macros make sense. But many presets don't have that many dimensions. And I like the ability to tweak and add my own macros, which is harder to do if there aren't any empty ones. There's a junk and color system, people can figure out what presets they're going to use or not. If they want to add macros of their own they can bake them in.

[Sound Author]

I've been scratching my head trying to figure out how to assign Timbre (CC#74) in such a way that doesn't change the sound for a user who doesn't have an MPE controller, and in my case, I'm not sure I can do that with the way Controls A-D are the only "Timbre Targets" available...and because Timbre isn't a MIDI source I can assign by itself, I'm unable to create patches with Timbre assignments that won't immediately sound different for someone using a standard controller, and that's mostly because of the way Timbre behaves on my Exquis by Intuitive Instruments...

On the Exquis, Timbre at least behaves like a bipolar signal, with positive and negative gestures and a center position for the pad... But it's been brought to my attention that Timbre itself is not a bipolar signal, but a unipolar signal ranging from 0-127. So, because of the way that Timbre is implemented on the hardware surface, at least on my Exquis, this suddenly becomes a complex issue...

When using the Exquis, the first thing I notice when assigning Timbre via Controls A-D as a "Timbre Target" is that the "center position" of the pad slightly nudges the target parameter above its initial position. This is no good because anyone using a standard controller will likely hear a completely different sound. Okay. There's a "bipolar" button. That should be our fix.

Uh oh.

The result of that seems like what happens when you "bipolarize" something that's already bipolar and you end up with a range of -3 to 1... But wait... I thought Timbre was a unipolar signal ranging from 0-127. The only way that we could produce that result is if the Timbre signal was converted to a range of -1 to 1 behind the scenes...and if that's the case, is that conversion happening on a hardware level or in Zebra 3?

Obviously, this is more of a problem with discontinuity between hardware MPE controllers, but because of that discontinuity between MPE controllers, I think we need some kind of a solution for that?

Otherwise, MPE is pretty much useless to me as a sound designer if a user is going to hear a completely different sound when using a standard controller...or even a different MPE controller that behaves differently. MPE might be great for anyone who's enjoying their own personal music making experience, but for anyone distributing patches to hundreds of people using different controllers, it becomes a huge nightmare.

I guess maybe that's more of an indictment of MPE discontinuity, but I thought I would post my TED Talk in here since it does intersect with Controls A-D in this way.

[Sound Author]

I guess a better example of what I'm trying to say is this: 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.

I'm honestly not sure there's any way to mitigate this issue with a different system for Controls A-D, but if it's possible, it would make Zebra 3 quite literally the only synth plugin that provides a workaround for issues like this...at least that I know of.

[pdxindy]

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.

Even if MPE is not enabled?

[Sound Author]

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.

Even if MPE is not enabled?

If you turn MPE off then all of the "nudging" that was caused by Timbre's center position slightly moving the target parameter away from its initial position suddenly vanishes, and therefore changes the sound you programmed...which is pretty much the same result as not having an MPE controller with Timbre.

The Exquis is my first MPE controller, so I don't know how Timbre is handled in other MPE controllers. But if you have a unipolar signal like Timbre, and then you make the experience of it bipolar on the hardware surface, all of a sudden you've created a nasty problem for software developers...and sound designers.

I don't know how Timbre came about, but if they wanted the experience of it to be bipolar, then they should have made the signal bipolar and we wouldn't have any of these weird, confusing center position problems.

[Urs]

MPE specs define Timbre as "preferably bi-polar, but if a controller or a sound generator can only do unipolar, it's fine too".

Our experience tells us, nothing works with or without MPE right out of the box without any compromise. Furthermore, sounds optimised for one controller may not necessarily work well with another.

Ideally, Controllers that are set to bipolar should probably default to the center position to make sense. That's not the case here, so that needs to be fixed.

Then, creating presets for controllers with bi-polar timbre should be possible.

[pdxindy]

It seems like Zebra 3 presets should remember the unipolar/bipolar setting for Control A-D