Zebra 3 Public Beta (final beta)

[beely]

Why are there limitations on the number of modules - why only 4 filters for example? Why not just have a filter option, and allow people to put as many filters as they want?

*Only* four filters? I mean two is an unusual luxury on most polysynths. Remember, this is per-voice, on a polysynth. I expect that if you put unlimited filters in there, people would complain that Zebra was poorly optimised because they couldn't play chords on their sound that *only* used 14 high-quality filters per voice.

I get some limitations can be annoying, but my view generally is to explore what I *can* do on an instrument, rather than dwell too much on what it can't. And if for some reason you want to make sounds that are super complex and beyond what you can do on regular synths, you're probably looking at a different product like Reaktor, or a modular system, where you can rig up whatever you want to your hearts content - Zebra was never intended to replace those, but instead bring some of the flexibility of modular type systems into a more conventional polysynth framework - hence being described as "semi-modular". Do any non-modular polysynths have an option for unlimited filters per voice these days? Certainly not any of the ones I have, but maybe there are...

Given how much you can do with a single oscillator (including filtering), I don't really see *only* four filters (or oscillators etc) as some kind of problem in practice. (Others may have different opinions, that's fine.) In fact, if anything, one thing I'm often surprised at when going through Zebra presets is for such a complex sound, how *little* modules are often used in a patch. More is not always more. Having said that, Zebra 3 is at the beginning of it's cycle, so it's possible that things might change over it's lifespan according to customer demand and available CPU power.

[PieBerger]

Each of the four primary Osc can have two spectral filters each or one filter plus Spectral Decay, which allows for dynamic filter-like timbres without any modulation! There are also 4 comb and 2 modal filter modules, so in total Zebra3 has 18 polyphonic filters plus 2 global (monophonic) filter modules, for a grand total of 20 filters per patch. But it doesn't enough filters right?

[Urs]

Why are there limitations on the number of modules - why only 4 filters for example? Why not just have a filter option, and allow people to put as many filters as they want?

The reason is quite simple: Because we create all of these modules at startup, which has some compelling advantages going for it as opposed to a dynamic set. A lot of that has to do with parameter automation, but not only.

For instance, we can immediately collect their parameters and report those that are automatable to the host. A fixed set of modules gives us a fixed, persistent layout of parameters. We can do automatic tests for our software that ensures that automatable parameters always have the same IDs even if we add new parameters. So when we add a parameter, we always add it to the end of the entire list.

Our plug-ins typically evolve over the years. I can't think of a plug-in where we have not added parameters and features over the years. It sounds paradox, but this does not work well with dynamic module lists.

So let's look at what happens when we have a dynamic module list. Every time a new module is added, new automatable parameters appear. Now imagine you have a project saved with one version of the software and then open it with a newer version of the software that has parameters added in some of the modules. This is gonna be tricky. We could still move those parameters to the end of the list. But then, adding new modules would also probably move parameters. Either way, some host automation may break.

So dynamic module lists require dynamic parameter lists (or 1000 macro parameters), and make backward compatibility in saved projects really complicated for evolving software. This is emphasised by the plug-in environment where each host has its own way of maintaining a parameter list. In my experience, some hosts don't really like dynamic parameter lists, so it's best to stay away.

There are a lot more arguments to be made about a fixed module layout. Like, we don't need to worry about memory allocation for new modules. They can't be done at any time, they can't be made during realtime threads. So we'd have to have an infrastructure that schedules (and thus delays) module creation on a low priority thread. But for instance we offer MIDI Program Changes that immediately take effect. Those would be delayed then, too, and possibly for seconds when the load is high.

Furthermore, apart from technical details, I think that the fixed module set makes software maintenance easier, like, a reliable structure is a really helpful context when debugging.

[Dalle]

Each of the four primary Osc can have two spectral filters each or one filter plus Spectral Decay, which allows for dynamic filter-like timbres without any modulation! There are also 4 comb and 2 modal filter modules, so in total Zebra3 has 18 polyphonic filters plus 2 global (monophonic) filter modules, for a grand total of 20 filters per patch. But it doesn't enough filters right?

Don’t forget the four EQs with six filters each.

[PieBerger]

Each of the four primary Osc can have two spectral filters each or one filter plus Spectral Decay, which allows for dynamic filter-like timbres without any modulation! There are also 4 comb and 2 modal filter modules, so in total Zebra3 has 18 polyphonic filters plus 2 global (monophonic) filter modules, for a grand total of 20 filters per patch. But it doesn't enough filters right?

Don’t forget the four EQs with six filters each.

Not enough filters to remember

[moss]

I did some exploration and totally love it

[charlesnyiha]

Each of the four primary Osc can have two spectral filters each or one filter plus Spectral Decay, which allows for dynamic filter-like timbres without any modulation! There are also 4 comb and 2 modal filter modules, so in total Zebra3 has 18 polyphonic filters plus 2 global (monophonic) filter modules, for a grand total of 20 filters per patch. But it doesn't enough filters right?

Don’t forget the four EQs with six filters each.

Not enough filters to remember

Lol okay fine I admit Z3 has enough filters

[charlesnyiha]

Why are there limitations on the number of modules - why only 4 filters for example? Why not just have a filter option, and allow people to put as many filters as they want?

The reason is quite simple: Because we create all of these modules at startup, which has some compelling advantages going for it as opposed to a dynamic set. A lot of that has to do with parameter automation, but not only.

For instance, we can immediately collect their parameters and report those that are automatable to the host. A fixed set of modules gives us a fixed, persistent layout of parameters. We can do automatic tests for our software that ensures that automatable parameters always have the same IDs even if we add new parameters. So when we add a parameter, we always add it to the end of the entire list.

Our plug-ins typically evolve over the years. I can't think of a plug-in where we have not added parameters and features over the years. It sounds paradox, but this does not work well with dynamic module lists.

So let's look at what happens when we have a dynamic module list. Every time a new module is added, new automatable parameters appear. Now imagine you have a project saved with one version of the software and then open it with a newer version of the software that has parameters added in some of the modules. This is gonna be tricky. We could still move those parameters to the end of the list. But then, adding new modules would also probably move parameters. Either way, some host automation may break.

So dynamic module lists require dynamic parameter lists (or 1000 macro parameters), and make backward compatibility in saved projects really complicated for evolving software. This is emphasised by the plug-in environment where each host has its own way of maintaining a parameter list. In my experience, some hosts don't really like dynamic parameter lists, so it's best to stay away.

There are a lot more arguments to be made about a fixed module layout. Like, we don't need to worry about memory allocation for new modules. They can't be done at any time, they can't be made during realtime threads. So we'd have to have an infrastructure that schedules (and thus delays) module creation on a low priority thread. But for instance we offer MIDI Program Changes that immediately take effect. Those would be delayed then, too, and possibly for seconds when the load is high.

Furthermore, apart from technical details, I think that the fixed module set makes software maintenance easier, like, a reliable structure is a really helpful context when debugging.

This is a really good explanation, thanks a lot Urs! I understand now why the set of modules is fixed. And the modules are ultimately sufficient for most sounds anyway so I guess it's not really a huge issue at the end of the day

[HcDoom]

Maybe this questions was already asked - but, are we going to get a dedicated arp module - something which is easier to use then current setup with 4in1 and mod mappers (refering to latest Urs Z3 arp video)?

[shonky]

Any chance of including a clipper with the main release, like the one included with filterscape?

Hoping it would be fairly easy to incorporate if the codes already available

[pdxindy]

I did some exploration and totally love it

Adding the second Osc to the second Filter input is only for the Filter FM. (It's not a bug)
To add two osc's together, just put them both in the same lane and they combine.
You could also use a mixed module to combine two osc's from different lanes if you want to treat the osc's individually in some way.

[Urs]

Maybe this questions was already asked - but, are we going to get a dedicated arp module - something which is easier to use then current setup with 4in1 and mod mappers (refering to latest Urs Z3 arp video)?

Yes, that's gonna come in a subsequent update, maybe V3.1 or V3.2

(hence in the video the emphasis on it does not have an arpeggiator yet)

[Urs]

Any chance of including a clipper with the main release, like the one included with filterscape?

Hoping it would be fairly easy to incorporate if the codes already available

Do you mean for security reasons or for sound design? - The clipper in the Distortion module uses the same code afaik as our output clippers in Filterscape, MFM2 and Uhbik.

[Sampleconstruct]

A really cool feature in Z3 is to drag and drop complex single cycle waveforms into the different slots in a given MSEG, morph between the waveforms with e.g. an LFO, modulate MSEG speed with something else and then modulate things like osc pitch, volume, filter cutoff, RM frequency, whatever with that MSEG. Wild stuff....

[moss]

I did some exploration and totally love it

Adding the second Osc to the second Filter input is only for the Filter FM. (It's not a bug)
To add two osc's together, just put them both in the same lane and they combine.
You could also use a mixed module to combine two osc's from different lanes if you want to treat the osc's individually in some way.

Yes, thanks, meanwhile I learned this as well. The info is pretty hidden in the manual and the UI does not give any hints what the inputs are for.