Using Zebra as a performance modular. My experience and some hopefully not too unfeasible feature requests for Zebra3

[Platipo]

Hello, this is my first post here, but I've been reading you for quite some time.

I'm a long time Zebra user, and I should probably say "lover" as it has been my main instrument for now almost a decade.

Recently, I put myself to the task of making a very complex and articulated performance on one single instance of a synth, possibly you know... making a full sequence which also happens to be playable and usable, and can transform in many ways making use of the performance page.
Here's the "result" maybe a bit cheesy


Now, the experience has helped me understand many things about a synth I believed I knew inside and out or so, and has left me with a few observations and suggestions I'd like to share.

1)voicing&arpeggiator
Afaik, I can set the voicing in the main panel of the synth, it's very cool to have duophonic as an option, yet the issue here is that whatever choice I make, it affects the entire synth, 4 lanes of synthesis obey one single voicing, which makes nearly impossible, unless I missed something critical, to both use MSEGS and the arpeggiator. Wouldn't it be amazing to be able to play a "polytimbral" patch in a more flexible way? Having a chance to set different keymaps for the 4 lanes, and maybe using the arpeggiator as one mode of something like a voicing module, as if it was some sort of a "midi effect" within one of those lanes? That would totally be a gamechanger in this "framework"

2)LFOs and MSEG timing
this left me very perplexed; I had built all my sequences, and my perfectly timed MSEGS, and if I pressed a note, they would, as you would expect, play and stay in phase forever... yet, trying to modulate the loop of all those MSEGS, all of the same length and going at the same speed, with the same modulation source of an equal amount, seems to eventually send the relative phases out of the window. I don't know if there is something I'm missing, but really "morphing" the whole sequence into some "FM mess" and then slowing down and make it intelligible again would be cool, but at the moment is actually unfeasible, as you can sure do the first transformation, but going back just doesn't work.
on the LFOs, I really like them having a chance to be tempo synced but also to be possible to send them "continuously" out of sync, I'm kind of annoyed that there is really no other option, having a possibility to both change the lfo rate continuously, but still with a connection to the BPMs or in a tempo quantized fashion is something I Haven't seen on any VST (I haven't searched that hard to be honest)

3)FX and routing
I love the idea of having the FX section looking a bit like a mixer with 2 sends, yet my main issue is that you can send to the buses only what is on the main lane, OR you can choose to send a whole synth lane on a bus channel... the result is that putting the FX you want on the parts you want can be a bit tricky to say the least... yes, I do understand this is a plugin and not a DAW, yet, even just having a "second" main lane, would make everything a lot easier... I could think of several other possible solutions, but they're probably way harder to implement.

Sorry for the long post, if you made it so far, thank you very much for your time and attention

[pdxindy]

Since you are using Ableton Live, you can use an Instrument Rack and 2 instances of Zebra and solve #1 and #3 at the same time

[Platipo]

Since you are using Ableton Live, you can use an Instrument Rack and 2 instances of Zebra and solve #1 and #3 at the same time

Of course.

I could do a lot of things using a DAW, theoretically along with that logic, I could make something way more complex using synths way simpler than Zebra;

the point is about using Zebra as a "standalone" performance modular, having all parts potentially interacting one with the other within one instance of the same synth, I had a similar response from Steve Duda from Xfer records when I mentioned having made something similar in Serum, yet Serum is clearly designed as a "simple" soundmaking tool, with its well defined limits and a clear stress on simplicity, one patch performances clearly aren't what it is designed for, Zebra on the other hand is a modular, so why not? I wouldn't say I should be "expecting" to be able to do this thing without relying on external software, but I think it's still fair to ask

[Howard]

2)LFOs and MSEG timing
this left me very perplexed; I had built all my sequences, and my perfectly timed MSEGS, and if I pressed a note, they would, as you would expect, play and stay in phase forever... yet, trying to modulate the loop of all those MSEGS, all of the same length and going at the same speed, with the same modulation source of an equal amount, seems to eventually send the relative phases out of the window.

Make sure that modulation source is global i.e. not per voice. I'll check this later on today - thanks for the idea

[Platipo]

Make sure that modulation source is global i.e. not per voice. I'll check this later on today - thanks for the idea

Honored that you responded (I'm sorry, but I'm such a fan, the Virus manual you wrote has been the most enlightening read ever about synthesis for me, and I'm almost "hating" how good, playable and instructive your patches are) I reopened a previous version of the project where I had used the Modwheel (which I guess is global enough) to modulate the MSEG loop, and it works perfectly; it all stays in phase like clockwork.

I don't know, I must have made some silly mistake last time, even though I checked thoroughly again and again, I couldn't find it, now it works... it was either (and quite likely) my mistake or some irrepetible glitch. On a secondary observation, it seems for this deviated sonic purposes of mine, the loop speed range is a bit too small to make it properly "usable", yet, I could always, being in a DAW accept the idea of changing the global tempo along with the loop speed

is there anything you can mention about the first and the third issue?
The first in particular, I'd love the idea of having say, an arpeggiated line frequency modulating another oscillator which might be playing something entirely different, or feeding a pad or so through a comb filter while the filter tuning is being controlled by an arpeggiator... or many others I couldn't easily do with an instrument rack (well, I could do some, using Zebra, a midi arpeggiator and Zebrify in series, but I'd rather not go "paraphonic")

[Urs]

Hehehe, digging the video/patch!

There are a lot of things to be considered.

First of all, the voicing and pretty much all concepts in Zebra2 predate my newly found interest in modular synthesis. It's modular in the way I thought of modularity in 2013, in the context of polyphonic synthesizers. Some main properties of modularity I defined for myself back then were free routing of audio signals and free N : M routing of modulation sources and targets. It was "modularity as a means of economics - without the spaghetti" but it wasn't about "modularity as a form of expression". Latter isn't impossible, as you show, but Zebra was certainly not designed with this in mind.

Voicing is an issue, for sure. I have spent days if not weeks trying to figure out how to join modern aspects of modularity with the option to be polyphonic. There are numerous philosphical and technical hurdles there - and even marketing hurdles. Polyphony always assumes the concept of voices as complete entities. A voice plays a note and that note is heard in the form of sound produced by that voice. There are easy ways to have multiple voices share one note (unison), but all constructs which come to mind that have a voice share multiple notes are somewhat crippled: Paraphonic voices share a common VCF/VCA whatsoever, Duomode is somewhat "mono plus". These modes are essentially polyphonic oscillators funneled through a monophonic architecture.

But there isn't a concept I can think of where a single voice shares multiple independent Note/Gate signals while still being placed in a polyphonic context. Not even MPE does that (even though some of our newer software - ACE, Bazille, Diva - can play duophonic on multiple MIDI channels). There are concepts where each voice is its own synthesizer (Oberheim 2/4/8-Voice) or where control signals can depend on voice index.

Now, why do I bring this up? - Because the Grid in Zebra, the matrix that connects the modules, is the heart of a single voice. And because signals can cross from one lane to another, it isn't possible to treat each lane as a separate entity. The modules placed in a Zebra patch have to be processed left to right, top to bottom. It's not possible to process some modules based on one key on the keyboard, another on the next and so on. In other words, the Grid isn't the entity which can provide means to process one lane from arpeggiator or another from keyboard, yet another from MIDI channel 2.

It gets even worse when we dig deeper. We could say, envelope 1 gets triggered by the first note, env 2 by the second and so on, and oscillators/filters/amplifiers could do the same. But then, as you know, you can use envelope 2 to modulate oscillator 1. What happens if you play two notes, you lift the first note and play another? Is it note 1 again or note 3 now because it was played after note 2? And when/how do you trigger new voices and which keys do you assign to them?

Therefore I think either polyphony or modularity has a superposition to the other. There's IMHO no way to make a synth that isn't "polyphonic with a modular voice architecture" or "monophonic modular with enough modules to create multiple voices". That is, IMHO there isn't a good concept where modularity and polyphony are on the same conceptual level.

That said, we do have explored concepts which leverage modular techniques in a polyphonic setting. Hive 2 is full of "modular as a form of expression" - mostly by promoting triggers and gates beyond note level and by souping up the modulation matrix. For Zebra3 we're going furher than that, e.g. by creating some sort of independence for up to 4 keyfollow operators, each with their own quantizers, modulations, glides and pitch sources (keys, special keys, sequencer, arpeggiator etc.). We're probably also going to explore the good old concept of "expression keys" to be used as trigger sources for envelopes and stuff.

Now, to be a bit more specific to the OP:

I guess I went through lengths to explain how "polytimbrality" in a single patch poses a difficulty. We can't do it for Zebra2, but we will certainly in Zebra3 adopt some of the dynamic abilities of Hive 2's Shape Sequencer in form of new, dynamic MSEGs. Like Hive, the sequencer (arpeggiator possibly too) will be able to run somewhat independent of notes played. It might become polyphonic as well, and judging from my recent work on CVilization, sequencing will become a dynamic and expressive, too. Hence, while facing the impossibility of polytimbrality, we'll certainly add means that help to cross boundaries.

Now, MSEG timing. Unfortunately, accelerating things is almost always only feasible by modulating the derivative (speed) rather than the unit itself (position). But when you modulate the speed/rate of a thing, you literally push it out of any locked synch to any fixed tempo. And when that happens, all sorts of effects work against your expectation of a comeback. Tiniest rounding errors, minimal gaps in resolution make it almost impossible to "work as intended". The thing can't know what's gonna happen in the next few seconds and it can't know where you're going to go with it. Hence, processing just a millisecond too many on four times the speed results in four milliseconds of delay, and these effects tend to add up.

Instead, going the FM-way (PM, actually) and modulating the *position* as opposed to the rate is a viable option to create the same kind of effect. But going back simply also means to go back through all the iterations that were added.

Other concepts offer means of resynching. That's easier said than done, and it's also prone to unmet expectations, e.g. if a LFO/envelope slowly "locks back in" after the action is over.

It isn't easy. I've tried a lot, there's no sufficient way known to which doesn't require very expensive computation for an otherwise CPU friendly purpose.

Lastly. FX routing. There's great news for this, at least for Zebra3. Zebra3 will have complex mixing tools which can be instantiated in either Grid (FX and voice). You'll be able to dynamically pull signals from any lane to any other, even multiple lanes at once. That'll do the trick. (I'm reluctant to make the normal voice mixer overly complicated when most of the time the simple 4 in 1 is sufficient, along with the additional sends).

Need coffee.

- U

[Platipo]

Hehehe, digging the video/patch!

Thanks, receiving appreciation for my work on my favourite synth by its creator is quite rewarding
Far from wanting to "spam", here's an "earlier version" of it, which I left unlisted as well... it seemed to me to be a little too "experimental" for the common taste, in which I also tried that thing of accellerating the MSEGS, yet I made sure I retriggered a note, to get everything back in synch as you can hear sometime around 4.40

But there isn't a concept I can think of where a single voice shares multiple independent Note/Gate signals while still being placed in a polyphonic context. Not even MPE does that (even though some of our newer software - ACE, Bazille, Diva - can play duophonic on multiple MIDI channels). There are concepts where each voice is its own synthesizer (Oberheim 2/4/8-Voice) or where control signals can depend on voice index.

There wasn't as far as I know no concept such as a "wireless modular polysynth" even in the plugin world before Zebra, that was quite an idea, and the success even just through word of mouth, of a synth so complex is a testament to the fact that it was and it is a great idea. Progress as far as I know happens precisely because of people capable and willing to challenge paradigms

Looking at the way Zebra is laid out, its "performance" panel, it almost seems begging to be used as a standalone performance instrument, though it might not be its only or main inclination, it is one which would be in my opinion wise and productive to encourage

Now, why do I bring this up? - Because the Grid in Zebra, the matrix that connects the modules, is the heart of a single voice. And because signals can cross from one lane to another, it isn't possible to treat each lane as a separate entity. The modules placed in a Zebra patch have to be processed left to right, top to bottom. It's not possible to process some modules based on one key on the keyboard, another on the next and so on. In other words, the Grid isn't the entity which can provide means to process one lane from arpeggiator or another from keyboard, yet another from MIDI channel 2.

Never suggested handling this through separate midi channels, just through keymapping, the idea is of something which is well... technically monotimbral, yet pratctically multitimbral, somehow like the patch I used in the video.
Yet I understand with my rusty knowledge of computer programming, that no matter the implementation, the processing order could be quite a hurdle.

It gets even worse when we dig deeper. We could say, envelope 1 gets triggered by the first note, env 2 by the second and so on, and oscillators/filters/amplifiers could do the same. But then, as you know, you can use envelope 2 to modulate oscillator 1. What happens if you play two notes, you lift the first note and play another? Is it note 1 again or note 3 now because it was played after note 2? And when/how do you trigger new voices and which keys do you assign to them?

On this imho the only possible way is to "define" a set of rules and apply them, making them known to the users as both features and limitations;
I used to have an Ultranova, and I was amazed by the fact that in the "animate" section I could trigger envelopes touching a knob, even envelopes which weren't even triggered by the note on message (which I suppose was the reason for the synth having 6 envelopes) I always wondered how it was possible for a per note modulation source to also be triggerable as a global one, yet I suppose they did it somehow.
Here, envelopes could use a similar logic; being them too mappable to the keyboard, and "possibly" switchable from global mod sources to per-note, adding possibly some depth and nuance (or useless complication for many, I know) and also giving a possibility to map some global envelope somewhere not so musically useful in the keyboard so that it can trigger global events in the patch

Therefore I think either polyphony or modularity has a superposition to the other. There's IMHO no way to make a synth that isn't "polyphonic with a modular voice architecture" or "monophonic modular with enough modules to create multiple voices". That is, IMHO there isn't a good concept where modularity and polyphony are on the same conceptual level.

There isn't YET
I suppose I don't have to get into praising your work to say how your plugins have in many ways challenged a lot of paradigms, this would just be another one

That said, we do have explored concepts which leverage modular techniques in a polyphonic setting. Hive 2 is full of "modular as a form of expression" - mostly by promoting triggers and gates beyond note level and by souping up the modulation matrix. For Zebra3 we're going furher than that, e.g. by creating some sort of independence for up to 4 keyfollow operators, each with their own quantizers, modulations, glides and pitch sources (keys, special keys, sequencer, arpeggiator etc.). We're probably also going to explore the good old concept of "expression keys" to be used as trigger sources for envelopes and stuff.

Now, to be a bit more specific to the OP:

I guess I went through lengths to explain how "polytimbrality" in a single patch poses a difficulty. We can't do it for Zebra2, but we will certainly in Zebra3 adopt some of the dynamic abilities of Hive 2's Shape Sequencer in form of new, dynamic MSEGs. Like Hive, the sequencer (arpeggiator possibly too) will be able to run somewhat independent of notes played. It might become polyphonic as well, and judging from my recent work on CVilization, sequencing will become a dynamic and expressive, too. Hence, while facing the impossibility of polytimbrality, we'll certainly add means that help to cross boundaries.

Really looking forward to it, I've seen many wonderful things in videos about Hive2, and I was impressed by its first version a few years ago at Musikmesse, if I wasn't so damn broke I would surely have a lot more firsthand experience on Hive2; possibly all those will make most of my "politimbrality"/voicing issues nearly non existant, as even just on videos on your yt channel the use of the arpmod to control the tune of something is widely explained, and would make all those idea like arpeggiating a combfilter on a pad or the like quite feasible (yes I could kinda do it with an MSEG in Zebra2 too, yet it's far from being the most straightforward thing to do)

Now, MSEG timing. Unfortunately, accelerating things is almost always only feasible by modulating the derivative (speed) rather than the unit itself (position). But when you modulate the speed/rate of a thing, you literally push it out of any locked synch to any fixed tempo. And when that happens, all sorts of effects work against your expectation of a comeback. Tiniest rounding errors, minimal gaps in resolution make it almost impossible to "work as intended". The thing can't know what's gonna happen in the next few seconds and it can't know where you're going to go with it. Hence, processing just a millisecond too many on four times the speed results in four milliseconds of delay, and these effects tend to add up.

Oddly enough, as I wrote in my response to Howard's comment, as I tried again it seemed to work perfectly, no idea if it not working on several attempts was just a glitch, or now magically the universe has made your MSEG stay in time as Howard Scarr's attention has been drawn to the issue

Instead, going the FM-way (PM, actually) and modulating the *position* as opposed to the rate is a viable option to create the same kind of effect. But going back simply also means to go back through all the iterations that were added.

Interesting idea, will try to put it into practice

Other concepts offer means of resynching. That's easier said than done, and it's also prone to unmet expectations, e.g. if a LFO/envelope slowly "locks back in" after the action is over.

Had similar issues with resyncing global LFOS, plenty of "unmet expectations" to use your words, I nearly gave up using them at all, or at least using their resync option

It isn't easy. I've tried a lot, there's no sufficient way known to which doesn't require very expensive computation for an otherwise CPU friendly purpose.

As I said already... it actually works, and hopefully will still work next time I try

Lastly. FX routing. There's great news for this, at least for Zebra3. Zebra3 will have complex mixing tools which can be instantiated in either Grid (FX and voice). You'll be able to dynamically pull signals from any lane to any other, even multiple lanes at once. That'll do the trick. (I'm reluctant to make the normal voice mixer overly complicated when most of the time the simple 4 in 1 is sufficient, along with the additional sends).

This is great

Need coffee.

- U

Thank you very much for devoting time and energies to write such an extensive answer to my questions I'm sorry I can't offer you at least some coffee

[Howard]

Far from wanting to "spam", here's an "earlier version" of it, which I left unlisted as well... it seemed to me to be a little too "experimental" for the common taste…

I guess my tastes aren't common, because I preferred this "earlier version"… not only because your charming assistant made an appearance.