Zebralette 3 Public Beta Announcement (Revision 15573)

[lobanov]

For me, it's incomprehensible how anyone can consider this GUI as good. The layout is indeed well done, but that's where the positives end. Regardless of size, all the knobs look extremely unpolished, not rendered at all? It's the worst resolution I've ever seen. The shadows on knobs, buttons, sliders, etc., look so flat without any depth or smoothness. And this cold, sterile white and grey choice of colors... horrible. I understand that this is a beta and a freeware product. I've already inquired whether this is the final GUI version but haven't received a response yet. If it is, please invest a bit more care into this GUI. I've never understood how u-he can show so much attention to detail in the sound of their products but do the exact opposite when it comes to their GUIs.

1. This is BETA. GUI it BETA too. A draft. It's not old Zebralette 2. It's completely new Zebralette 3. And it's BETA. We are testing it.

The last UI of Zebralette 2 was nice and useful. But it wasn't BETA.

2. You can make your own GUI for any u-he synth yourself. You can change knobs, colors, fonts. You can even change the layout. U-he plugins are highly customisable in this regard. I don't think that something have been changed.

[Ploki]

rendering isn’t an issue you can change graphics easily (although i’m not bothered by it) - the snappiness and interactivity and immediacy and smoothness of the gui tho is a very welcome upgrade

[Grv Courier]

Incredibly powerful

[smilinggoat]

This sounds fantastic. Congratulations! Looking forward to its big sibling!

[Chris-S]

<del>

[Fannon]

Also, Control A / B (or macros, XY pads) are usually meant as global modulations, not per voice modulations.

That is not necessarily so.

We have often made our Macros emit Control A/B because many of our presets are set up with them, but then many people had no means to send them (e.g. NKS controller in NKS mode).

In my view, adding a new Timbre controller that nearly no-one (I'd estimate less than 5% of our users) can make use of would be a step backwards. Sound designers would not cater for it, and those who do would leave out the people again who don't have MPE controllers. We would again be forced to add Timbre to a Macro control, just like Control A/B and the cycle begins again.

Therefore I'm not convinced that detaching Timbre from Control A makes sense. Even more so since we have said for many years that people with MPE controllers should set it to MIDI CC#74, which is Timbre in MPE.

Ok, I get your perspectives on it. If there's a clear and strong convention to use Control A always for Timbre it might work out well enough and could be a pragmatic solution.

But I'm not so sure it really changes the problem that most presets are not made with MPE in mind and then assigning Control A to Timbre is a hit and miss. It looks like the patches work with MPE right away, but in the worst actually you'd have to first unassign or change all the existing Timbre modulations and then start again with something that actually works.

Or maybe let's phrase it like that: My personal preference is to not have timbre assigned at all for patches that were not specifically designed for MPE Controllers. If this is missing, I'll add the modulations myself.

Maybe a compromise could be to have Timbre as modulation source and then be able to modulate Macros with it? That would allow you most flexibility, including choosing how strong it actually should modulate the Timbre macro? I think this is how it works in Vital.

[Urs]

I think the problem is that for MPE you pretty much have to program specific presets, and then even more specific presets for certain controllers. A preset that works well for a Linnstrument does not necessarily work well for an Osmose.

This is a general problem that is not easily solved, and we can not possibly adapt all our presets to work well with Osmose, Linnstrument, Seaboard, Continuum and what-have-you. We can offer the infrastructure, but we can't dedicate all our preset manufacturing to MPE only.

Our goal is to instead publish a range of presets that are specifically crafted for these instruments and controllers. Maybe we're able to come up with some guidelines as well, or a selection of best practices.

Also please remember that we only recently went beta with full MPE support and we are still testing this for a reason. We have a solid selection of MPE controllers in our HQs, and we're still in the process of getting familiar with the technology.

[pdxindy]

This is a general problem that is not easily solved, and we can not possibly adapt all our presets to work well with Osmose, Linnstrument, Seaboard, Continuum and what-have-you. We can offer the infrastructure, but we can't dedicate all our preset manufacturing to MPE only.

IT wouldn't cover every situation, but expression curves would go quite a ways in allowing users to adjust presets for different MPE controllers.

[Fannon]

I think the problem is that for MPE you pretty much have to program specific presets, and then even more specific presets for certain controllers. A preset that works well for a Linnstrument does not necessarily work well for an Osmose.

This is a general problem that is not easily solved, and we can not possibly adapt all our presets to work well with Osmose, Linnstrument, Seaboard, Continuum and what-have-you. We can offer the infrastructure, but we can't dedicate all our preset manufacturing to MPE only.

Our goal is to instead publish a range of presets that are specifically crafted for these instruments and controllers. Maybe we're able to come up with some guidelines as well, or a selection of best practices.

Also please remember that we only recently went beta with full MPE support and we are still testing this for a reason. We have a solid selection of MPE controllers in our HQs, and we're still in the process of getting familiar with the technology.

Thanks for the reply, Urs! Yes, thats well put and exactly the Problem. I do have a Linnstrument and while it's a really great MIDI Controller, it is very limited in what modulation ranges actually work for timbre.

That's also the reason why I'm having the troubles with the default assignment of Timbre to Control A. In many cases this makes the presets unusable with a MPE device, except I start unassigning or adjusting the Control A modulations. Or I need to enable/disable MPE per preset.

But I would also never expect a lot of presets to work perfect out of the box for my MPE controller, because they're all so different to each other.

[NeonBuddha]

Hello, this is my first post here
The next evolution of Zebra is extremely impressive so far. This new oscillator is a complete reimagining of what wavetable creation can possibly be. I always felt that Z2 had the conceptual superiority with it's spline-approach but now with this new editor, that concept is allowed to truly take flight
The new oscillator effects are equally lovely and versatile, and the Harmor/Razor-style partial detuning takes the synth to a completely new world of possibilities. The morphable mseg is also kickass

My only question/request/criticism however is whether there are going to be some higher oversampling options? I usually run my projects at 48khz and I sometimes noticed zipper noise/aliasing artefacts particularly when sweeping the higher part of some windowed sync-type sounds with bell-like waveforms. I also heard similar high-frequency artefacts when for example aggressively high-passing the init-saw with the filter fx.
Alot of times these artefacts, even if present, are masked by the full spectrum but for a small handful of sounds, they could get annoyingly noticable. For some reason the effect seemed to get stronger when increasing the oscillator resolution. Assuming that this is just expected aliasing, it would be nice to tame it, even at extra cpu-cost.

Anyway, nitpick aside, this is thoroughtly impressive. Thank you, Urs and the whole u-he team! Your work is always a gift to the music world and Zebralette/Zebra 3 is shaping up to be a Magnum Opus

[uhoenig]

Maybe a compromise could be to have Timbre as modulation source and then be able to modulate Macros with it? That would allow you most flexibility, including choosing how strong it actually should modulate the Timbre macro?

To me this sounds like a good idea to help make presets MPE compatible.

[SteveElbows]

I'd love to see that sort of detail discussed also on the MPE thread, because I do think timbre needs more discussion there and its all fallen a bit quiet in that thread this year.

[Fannon]

I'd love to see that sort of detail discussed also on the MPE thread, because I do think timbre needs more discussion there and its all fallen a bit quiet in that thread this year.

Good point! I'll try to write up some points from my posts above and put it to the dedicated thead.

See viewtopic.php?p=8853303#p8853303

[marcinrau]

Thank you Urs and the entire team for this amazing synth!

[Chalisque]

Two things.

1. Is this a graphics glitch? (Happens when paused, displays fine when playing. This is with Reaper in Linux. Patch is Funky Northerner.)



2. Locking pitch bend while changing presets would be nice. (Is this already possible?)