Zebra 3 feature suggestions

[Ploki]

There is a lot of buzz on the new Knif Audio Knifonium. Will Zebra 3 sound as good as that?

On this topic, I'd rather keep my opinion to myself.

Hmmm...I wonder why?

I haven't yet tried the knifonium - i have a PA-aversion. PAversion. I'll download the demo soon enough tho because i'm curious. I might be disappointed like with oberhausen and the last PA hype - the Amek 200.

Based on quality of Repro-5 and u-he's reputation vs PA reputation and lately consistency/quality of bx plugins... I have a good guess why he'd keep the opinion to himself

[Ficciones]

I love where this is going! May I make a suggestion: could Zebra 3 have a dedicated table devoted to selecting which notes are "active" in a scale, and can the number of steps in the table be related to the .tun file selected? So using a 19 note equal temperament scale would place 19 steps in the table, to select which notes would be triggered algorithmically.

Can't promise that just yet. There's a conceptual problem if we wanted to make this automatable. In Hive 2.0 we have a single parameter that sets the state of 12 notes of a 12-tone scale, which has 4096 combinations. So that parameter has 4096 possible states. Each note more doubles this, so for a 19 note equal temp scale we'd need the parameter to go from 1 to 524288 and so on. At some point we'll reach issues with rounding errors, particularly in hosts which use weird resolution internally. So we'd either need more than 1 parameter in this case or we'd need to forgo automation.

IMO that's a ridiculously fiddly thing to automate, what are the practical use cases? Switching via host automation? Why not just switch patches, like the same patch with different notes. Or change the notes manually and run another take. I mean, the point of this in Zebra 3 would be to assist algorithmic output so you'd be getting a different take with every runthrough anyways.

Compromise: disable automation for that parameter when a non 12 tone scale is loaded.

[Urs]

The point of automation is, you can record it while switching individual notes on or off. This way you can change arpeggii or sequences quickly.

We're even thinking of adding live control via keys because it's such a great performance feature.

[Funkybot's Evil Twin]

One trick I've found helpful in the VCV world is to use one quantizer with a root transpose, and feed the output of that into a second quantizer where I'm locking it to an absolute scale. So for example Quantizer 1 is set to play notes C, Eb, F, G, Bb. Nice little C minor-ish pentatonic thing. Now, let's say I use CV (say a sample and hold, or a mod mapper set to a divided clock) to modulate the Transpose input of that quantizer. So the first quantizer gets transposed up two full steps and maybe you've got E, G, A, B, D.

So now...you've got some very not C minor sounding notes, so you take the CV output of Quantizer 1 and route to the input of Quantizer 2, which is maybe set to C, D, Eb, F, G, A, Bb and now you've got (with rounding down) Eb, G, A, Bb, D which works a lot better. Or rounding up, you'd get F, G, A, C, D, which also works. Any input ends up within that second scale, but you can quickly create generative sequences based on the root of the first quantizer.

So yeah...scale quantizer+root transpose into 2nd scale quantizer would be fun for Z3.

[Ficciones]

The point of automation is, you can record it while switching individual notes on or off. This way you can change arpeggii or sequences quickly.

We're even thinking of adding live control via keys because it's such a great performance feature.

Yes, a mode where keys select sub-snapshots of the note quantization would make a lot more sense to me than a single parameter. Then you can reliably jump between different note selections. I'm not clear how you'd do that anywhere near as reliably with a parameter.

[vvilms]

I think he wants to have a transition from previous value to new value when playing a new note (see above).

Alright, so. I was gonna hold off asking for this one until ^that was either implemented or confirmed to be implemented, but:

I think the option to increment the MMAP with a note-off message would be quite dandy as well. Especially in-tandem with the glide modifier. IE. The option to transition across the onset, or the release.

[MorpherX]

One big disadvantage of Zebra 2 is that you don't see all modulations in the Mod-Matrix. If you have a complex preset you are searching endless to find all modulations and if you found them you are not able to mute single modulations.

Therefore a big wish for Zebra 3:
Please show "all" modulations in the Mod-Matrix with the ability to mute the single modulations in order to find out whats going soundwise.

[EvilDragon]

Mod matrix is not the main method of modulation in Zebra, which is why it's not supposed to be an overview of all modulation in the patch.

[recursive one]

One big disadvantage of Zebra 2 is that you don't see all modulations in the Mod-Matrix. If you have a complex preset you are searching endless to find all modulations and if you found them you are not able to mute single modulations.

+ Many.

Was trying to reverse-engineer a Zebra preset with lots of subtle and slow and therfore not easily detectable modulations and an empty mod matrix. I thought my brain would explode before I realize what LFO does what.

Imo, if a synth does have a matrix any assigment should be visible here (not only Zebra, same problem exists also in Spire, Virus TI/Viper, but these have fixed modsources like LFOs and envelopes so it's much easier to track).

Also a way to quickly disable any modulation is a must imo.

[EvilDragon]

Except Zebra has direct mod assignments right next to the parameter it modulates, and mod matrix is just an adjunct.

[recursive one]

Except Zebra has direct mod assignments right next to the parameter it modulates,

If it didn't have that, it would be a complete calamity

Ofc, it's manageable but i find the co-existence of two separate modulation systems somewhat confusing. Maybe that's because I use/program Zebra much less than some other synths, but I don't quite undretand what's the logic here. Yes, it's cool that I can assign a mod source right at the modulated parameter but why wouldn't it automatically appear in the matrix, like in Serum or Rapid?

If i'm not mistaken (I only have a demo), making a drag and drop assigment in Hive also automatically crates a modmatrix entry in Hive.

[EvilDragon]

It's not that strange of a design. A number of Waldorf synths have fixed modulation assignments along with mod matrix, for example (that are not just filter envelope amount kind of thing).

[Urs]

Hive's ModMatrix is a byproduct of reworking Zebra's ModMatrix for V3. It's a lot more advanced and not all parts of the UI could be leveraged back into Z2.

The difference in Zebra between a direct assignment slot and ModMatrix is the control rate. Direct assignments have a granularity of 4 samples (audio rate, but not as fast as, say, ACE or Bazille) while ModMatrix slots have a granularity of 16-64 samples. The exact granularity varies depending on buffer size and timing of MIDI events.

For Hive 2 I have experimented with a fixed granularity of 16 samples, but the quality difference was audible only in edge cases while costing twice as much CPU as the variable 16-64. So I left it at that.

Anyhow, a granularity of 4 is top notch for a control rate, so it makes sense to keep it for standard modulation paths for Z3. We will probably reduce it for paths with a lot of built-in redundancy. For instance any gain staging: Module volume/mix/pan parameters can typically live with a lower control rate and thus don't need direct mod assignments. If a higher control rate is vital for the case at hand, a separate mixer module with direct assignments can be used. This way we reduce a lot of clutter without actually losing any functionality.

[recursive one]

It's not that strange of a design. A number of Waldorf synths have fixed modulation assignments along with mod matrix, for example (that are not just filter envelope amount kind of thing).

You mean hardware or software? In hardware i think that makes sense as you want the most common modulation targets for LFOs or envelopes immediatelly accessible without menu diving.

Now that Urs has explained that the assigments made directly or via the matirx have different rate, it starts making some sense to me. But then it probably would be more convenient if I could set the modulation rate in the matrix for each slot separately. E.g. I assign an LFO to pitch and try different rates to define what sounds best and how the CPU handles that without affecting the rest of the assigments. I've got no slightest idea if that would be possible to implement tho, as I only ever saw selectable mod rates in Dune but they are global.

[Urs]

I've got no slightest idea if that would be possible to implement tho

Individual modulation rate is possible per module, but it would account for all parameters of a module at once, making the CPU skyrocket.

Having a few, fixed HiRes-slots is the most economic option.

But there's another thing. In synth history there are three paradigms of modulation assignments. I call them as follows:

- on source: Set LFO/Env depth where the modulator is (e.g. LFO-Depth on vintage Roland synths)
- on target: Set LFO/Env depth where the target parameter is (e.g. direct assignments in Zebra)
- intermediate: Set Mod Depth in a separate entity (e.g. ModMatrix or Moog Modular-style attenuator/vca modules)

I find that "on source" is very limiting. The reusability of modulators is completely up to how many depth knobs you'd like to add. Therefore, some synthesizers conceptually have modulators for dedicated sections, such as the Schmidt C. This is my least favourite because it's an unnecessary impediment of usability, and even if a target selector is present, you still need to look at two places to edit target and depth (long ways of mousing, but no big problem with two hands on hardware).

I find that "on target" is the most usable. You edit the modulation right next to parameter's actual setting. It's also limited in the number of things that can modulate stuff, but a source selector is a good remedy. I prefer this over all other approaches because it's very direct and lends itself to economic implementation (less mousing, and allows editing of source as well as target with two hands at once).

I prefer a ModMatrix over "on source" for their vast flexibility. That flexibility is bought by having to look at three places to set up modulations. Hence we add a ModMatrix commonly as addition to "on target" modulations. Our new-in-Hive on-source editing thing is somewhat a remedy, but it's far from perfect. There's still more mousing involved than in any other approach. In hardware, a ModMatrix is particularly taxing as you commonly don't have three hands. There's a lot of arm-waving involved when editing source, target and matrix to create the sound you want.