Zebra PC blog

[Urs]

This system makes it trivially easy to see what each parameter is modulating and to what degree, and to assign any new arbitraty modulation you want. This might not work as well in something more complex like Zebra, but it's worth a thought at least.

Ah.. yes... I see!

I have thought about this stuff in the past. But I've postponed these concepts for times when everybody has dual or quad 4GHz processors

I would love to make knobs show the actual parameter value on an "outer ring" with all ongoing modulations counted in. But I'm scared about the additional cpu load when 30 or so knobs have to be painted each and every 50 ms... thus I decided that I will have the modulators paint their current values (I must still add that to the envelopes...), just like the LFOs do in Filterscape. Seeing this and listening to the played sound lets you IMHO sufficiently correlate the visual experience with the sonic perception, at least in most cases (classical examples are filter sweeps, tremolo, panning, vibrato). I might experiment with that in the future though. Just seeing that 70% of Filterscape's cpu load in the GUI is drained by the EQ Curves and the balls, has convinced me that it's too early for too heavily animated GUIs.

Now... with the way I handle parameters, it is not possible to modulate *every* parameter without a noticeable cpu hit, such as required by preset morphing. In my stuff, every continuous parameter is smoothed, in order to avoid zipper noise when turning the knobs. So, there's kinda queue internally that's optimized to handle a few parameters very quickly (i.e. parameter automation, MidiLearned knobs etc.), but it will not like to have 500 parameters mangled at once.

Preset Morphing and full parameter modulation (like in the Nord, the MotU MX4 or in the TimewARP 2600) is IMHO viable for synths with up to 200 parameters, but not necessarily in monsters like Zebra 2 which already has 17000 parameters with only 50% of its modules currently implemented. (Well, 4000 parameters for each of 4 oscillators with the morphodelic custom waveforms... 16 waveforms * 32 control points * 4 spline controls each plus alternatively 16 waveforms * 128 linear control points at fixed x-position, no need to worry, you'll not be overwhelmed by the number of parameters).

That's why I went for the XY controls in the first place. These give you the freedom to modulate/morph up to 64 parameters in a convenient way (you can use MidiCCs to remotely control them), but as I must admit, the set up procedure has been far from ideal. I still think that 64 parameters provide for a good basis to mangle patches in any manner that makes musically sense. I just see that this scheme must be improved for better usability.

Cheers,

Urs

[kuniklo]

I would love to make knobs show the actual parameter value on an "outer ring" with all ongoing modulations counted in. But I'm scared about the additional cpu load when 30 or so knobs have to be painted each and every 50 ms

You wouldn't have to actually do this, at least not to emulate the nord method. They don't do this kind of dual-indicator for every modulator, just the relatively static ones that are direct performance controllers. Doing this for things like velocity and aftertouch *seems* like it would be a pretty low cpu hit since they don't update very much. I can see how this wouldn't be possible for LFOs, though. It would be nice to have access to more than just velocity mod in the inline expandable controls you've pictured though.

That's why I went for the XY controls in the first place. These give you the freedom to modulate/morph up to 64 parameters in a convenient way (you can use MidiCCs to remotely control them), but as I must admit, the set up procedure has been far from ideal.

That makes sense. Perhaps you could do something more nord-like for the XY controllers? Sounds like you're headed in that direction anway.

Anyway, thanks for taking the time to think about these issues. I know it must seem like I've been on a little bit of a crusade lately but I really do think that the most profitable areas of development in vsts at this point are usability and raw sound quality/versatility. Thank god you seem to be focused on both. As far as applying some of these ideas to Zebra goes, perhaps it makes the most sense to continue to do parallel Filterscape/Zebra development? I'd like to have a simpler, performance oriented synth like VA with an emphasis on usability and quick sound design *AND* a more flexible, open-ended semi-modular like Zebra that can cover a lot more ground at the price of some loss of immediacy. Seems like a good working heirarchy of tools to me.

[rockin1]

I would love to make knobs show the actual parameter value on an "outer ring" with all ongoing modulations counted in. But I'm scared about the additional cpu load when 30 or so knobs have to be painted each and every 50 ms...

Maybe an alternative for an "outer ring" is to show not the actual value, but the modulation range. You could have different colored notches on the "outer ring" to show the max value reached by velocity modulation, key scale modulation, matrix, matrix modulation, and XY modulation. Or for a simpler version, just show velocity and key scale mod values when the module is collapsed. This would allow you to still see the mod range even when the module is collapsed. Then it only needs to be expanded for editing...

[rockin1]

It would be nice to have access to more than just velocity mod in the inline expandable controls you've pictured though.

Maybe one additional row that can be assigned via a popup?

Anyway, thanks for taking the time to think about these issues. I know it must seem like I've been on a little bit of a crusade lately but I really do think that the most profitable areas of development in vsts at this point are usability and raw sound quality/versatility. Thank god you seem to be focused on both.

I definitely share your opinion kuniklo and I'm also very happy to see that Urs is making progress on both of these items (and much more!). It surprises me how little attention is given to both of these items by many developers.

I'd like to have a simpler, performance oriented synth like VA with an emphasis on usability and quick sound design *AND* a more flexible, open-ended semi-modular like Zebra that can cover a lot more ground at the price of some loss of immediacy. Seems like a good working heirarchy of tools to me.

I definitely agree with the desire to work in both ways also. But let's not forget the power of an easy edit page. Maybe someday we can get close to having our cake and eating it too!

matthew

[Urs]

It would be nice to have access to more than just velocity mod in the inline expandable controls you've pictured though.

Maybe one additional row that can be assigned via a popup?

Well, I thought about this. But there are a lot of technical issues to solve before this is achievable. I.e. the order of processing modulators plays a role and - most of all - the Attack phase is introduced before anything in the voice is actually processed, naturally on a Note On event. Thus, at that time there's no knowledge about any modulator states except for the global ones. So, the list is either short or I have to change some fundamental principles in the engine structure. I'm not yet sure which way to take. It may have to wait for a later version...

Cheers,

Urs

[Urs]

I know it must seem like I've been on a little bit of a crusade lately...

Nah, that's highly appreciated. I think that most comments or anxious questions of you and others show that I'm up to the right direction.

I'm now writing my 3rd plugin engine. The first one (Zoyd) wasn't flexible enough for extension. The second one (Zebra 1) wasn't portable enough and still too complicated. The new engine is clean, built of reasonably small objects and is pretty extensible. Most of all it's tested with 4 plugins already.

The funny thing with the new engine is that whatever nice little idea came up, I could implement it very quickly. Well, and these things are also available for extension of the other plugins.

One example are the new knobs with built-in menu. All of my plugins (maybe not in MFM, I don't remember) have menus next to modulation depth knobs. In Z2 I'm experimenting with knobs that offer a contextual menu to select the modulation source (and other occasions). The name of the modulator then pops up in the label below the knob. I think that this is pretty elegant, but it has yet to be tested for usability in a wider field test. If it withstands the critical views of BT and the Beta Team, I will put this into future versions of Filterscape as well.

A great side effect of these knobs is, they suddenly "know" about the modulation source. So they can send a message like "hey guys, user has touched something called Env2!" and thus a pane that's highly populated by Env2 controls can say "Eh, cool, that's me - I'll change my background colour!". And that's just great. The interface gets alive in a subtle way.

A weird aspect of the new stuff is, it has some basic paradigms that oblige me to implement things accurately. There's no room for hacks. If I hacked anything to accomodate Zebra, it might happen that I couldn't compile Filterscape anymore. So I'm urged to think things through and to add extensions that don't compromise the original functionality. This sometimes costs more time, because one has to think in a wider range than just the single plugin, but on the other hand, I've always been happy afterwards that yesterday's ideas don't get in the way of today's new requirements and vice versa.

So yeah, whatever happens here in terms of improvement can flow back into Filterscape. Just note that not a single dsp algorithm is gonna be identical in Z2 and FilterscapeVA while the GUI library and the formal organization stuff don't differ in a single line of code. However, the development of Zebra2 is mostly R & D for better dsp algorithms and concepts. Some stuff is based upon things I did for FilterscapeVA. Might happen that some stuff in the next rev of Filterscape will be based upon things in Zebra2, but they'll never be identical.

Cheers,

Urs

[kuniklo]

One example are the new knobs with built-in menu. All of my plugins (maybe not in MFM, I don't remember) have menus next to modulation depth knobs.

I'd have to try this for a while to be sure if I liked it, but it sounds like a good approach.

A great side effect of these knobs is, they suddenly "know" about the modulation source. So they can send a message like "hey guys, user has touched something called Env2!" and thus a pane that's highly populated by Env2 controls can say "Eh, cool, that's me - I'll change my background colour!". And that's just great. The interface gets alive in a subtle way.

This I definitely like the sound of. Anything that helps diagnose a patch faster makes a big difference. These little quantitative advantages can quickly add up to a qualitative advantage.

[pummel]

Someone brought up the idea of being able to save "portions" of a patch. This seems interesting to me. In addition to simply loading / saving complete patches, it would be nice if we could load / save / copy / paste portions. I am not sure how one would draw the line between one portion and another. But its an interesting thought that no one but Big Tick has experimented with yet ( to my knowledge ).

[kuniklo]

Someone brought up the idea of being able to save "portions" of a patch. This seems interesting to me. In addition to simply loading / saving complete patches, it would be nice if we could load / save / copy / paste portions. I am not sure how one would draw the line between one portion and another. But its an interesting thought that no one but Big Tick has experimented with yet ( to my knowledge ).

Absynth does this too. It's a handy feature.

[Sascha Franck]

You can save "portions of patches" in Kontakt too.
Of course, in an ideal world, one would be able to select a certain bunch of things, such as, say, OSCs and envelopes and then save them as some sort of macro.

[Urs]

You can save "portions of patches" in Kontakt too.
Of course, in an ideal world, one would be able to select a certain bunch of things, such as, say, OSCs and envelopes and then save them as some sort of macro.

Yeah... hehe, let's deconstruct that...

I'll make saveable "templates" for certain modules/parameter groups, just like Zebra 1.5 lets you save, load, copy, paste spectral waveforms. This will be extended for stuff like the Grid, Arpeggiator, Waveforms, Effects.

I'm thinking of a concept to make presets partially loadable, so to extract certain modules of your choice. Everything I thought of here is tedious though. It might be better to make presets partially saveable.

However, I think that there's a conceptual problem here. The only way of saving "portions" or makros for multiple modules that makes sense requires an engine where the number of each type of module is not limited. The main reason for Zebra's way of modularity using a fixed maximum number of modules is performance, another reason for this is maintainability by a single developer. But there are other reasons which I'll explain later.

Honestly, I'm not too much a fan of sub-presets. Apart from being too lazy to code something sophisticated here, I think they have some serious disadvantages:

- sub-presets IMHO lead to less intelligently done patches. Say, you combine 4 sub-presets with 2 or 3 envelope settings each. This would require 10+ envelopes being present. Some if not most envelope settings might be mergeable into a single envelope setting. Would you now start "harmonizing" the resulting patch by eleminating redundant envelope settings? If not, would you want to tweak this patch any further, considering that it has become overly complex?

- I own a Wavestation. The Wavestation is The Mother Of Reusing Sub-Presets (among being other mothers). When stepping through a bank of presets (which are all "Multis"), you hear the same "Singles" over and over again. I think that sub-presets lead to annoying deja vus in the preset domain.

- taking up the first points, I also think that sub-presets lead to lazyness when programming the synth. Combine two or three settings, it sounds great, no need to drive it any further. In turn, you will not really have to learn the synth, you just learn to adjust small things here and there. But then, the fun starts when getting lost in the depth of the thing. You will trick yourself when using sub-presets!

- on the point of unlimited number of modules, here is one example why this is so: Zebra and Filterscape have a pretty unique property, and that's the insanely high control rate. Their modulators update every 4 samples instead of 16 - 128 as in most other synths. Not all modulations take advantage of this, but some critical ones do and I think it's audible. Only some fully modular environments such as Reaktor offer a control rate of every 1 sample. Most of these are quickly turned into cpu hogs. Nevertheless I think I found an elegant way to achieve a very high control rate *while* preserving a reasonably low cpu consumption. However, my stuff does a lot of more or less intelligent work to avoid processing units that do not contribute to the audible sound. Hence, if I offered means to do anything that lets you add modulators or anything in an uneconomical fashion, you'll see the cpu friendlyness flow down the river.

Zebra 2 offers you somewhat like 30 audio modules, more than half of which are in the realm of cpu eaters (oscillators, filters) when accumulating too many. They're not meant to be used all at the same time (except for Biomechanoid patches, of course). Their existance is meant to let you work up patches from a wide range of sonical properties. Also, in Zebra 2 you'll have key/velocity splits/crossfades for all types of generators (oscillators, noises), in order to create highly virtuous patches. As shown in the audio examples in previous posts, a single oscillator can make a good sounding patch. Thus, I think that having more than 2 oscillators audible (hence processing, inaudible oscs do not cost cpu) at the same time is gonna be pure waste of cpu in most cases.

I have got many requests to add certain modules or functionality to Zebra 1.5. It's like more of this and more of that... I can only reiterate, Zebra is not meant to be an all-in-wonder synth. It's a synth that is very flexible in the things it's good at, but it won't replace Reaktor, eXT, Cameleon or whatever other great concepts there are.

I would even want to go a step further. When I worked on Podolski with the beta team, the somewhat limited feature set led to a remarkable explosion of unique patches that got the very most out of each single module. I'm convinced that this in turn led to a better understanding of FilterscapeVA and thus to the exciting range of patches for FilterscapeVA. I'm really tempted to create kinda nanoZebra with only one oscillator. Or better, I'm tempted to switch off the functionality for adding modules within the first two months after purchase. (I won't do that, but you get the point :hihi )

The real thing is, don't let yourself become lost in gearslutishness. Using all possibilities at once doesn't necessarily make for better patches, or better music. Don't confuse options with needs. Good patches can be made from scratch within minutes and for the sake of diversity, don't reuse the same settings again and again. Rather create something new than a derivate of the known. In terms of synth programming, convenience too oftenly is the enemy of the individual. As I said earlier, Fight the Zoyd! I think it's worth it.

Sorry, I got lost in the train of thoughts here, it mostly became kinda manifest for some concepts and to some extent an excuse for my own lazyness.

Cheers,

Urs

[Sascha Franck]

Yeah, I perfectly understand that "macro presets" (or whatever you may call them) would probably lead to what you described.
Still, for envelopes (mainly syncing multibreakpoint ones) and some things such as effects I really find presets to come in handy at times. And of course for any sort of arpeggiator too.

They're not meant to be used all at the same time (except for Biomechanoid patches, of course).

Or better, I'm tempted to switch off the functionality for adding modules within the first two months after purchase. (I won't do that, but you get the point :hihi )

Yeah, defenitely.
I mean, I still even use Logics ES1, which is like one of the most simple synths ever.

And of course Podolski is a very nice example, too.
You just have to look around at what it does, explore it as good as possible (and even with Podolski I still haven't managed yet) and forget about what it doesn't offer.
I even replaced some more complexed synths in my Autoload with Podolski (well, ok, lately it's been Filterscape instead). It's doing the job just fine for a whole buttload of tasks.

Sorry, I got lost in the train of thoughts here, it mostly became kinda manifest for some concepts and to some extent an excuse for my own lazyness.

Nah... some really interesting points.

[Derek up North]

I'm really tempted to create kinda nanoZebra with only one oscillator. Or better, I'm tempted to switch off the functionality for adding modules within the first two months after purchase.

I wonder whether it would make commercial sense to make and sell "nanoZebra" at a low price to bring new users in and then to sell add on modules to bring the user up to full functionality (and the full price too!). Obviously anyone wanting the full experience would still be able to buy the full product in one go.

I don't know enough about the buying habits of the "typical" customer to know whether this would be fun and worthwhile or commercial suicide!

Regards,

Derek.

[kuniklo]

Don't confuse options with needs. Good patches can be made from scratch within minutes and for the sake of diversity, don't reuse the same settings again and again. Rather create something new than a derivate of the known.

Of course I agree completely with this. A simple synth I can use to dial up an interesting patch on the fly is far more useful to me than a behemoth that can do anything if you're willing to spend half an hour flipping through all its pages.

Maybe it would be useful to have a sort of russian-doll synth collection. It starts with a very simple synth but you can export the patch into the next, slightly larger synth if you bump into the limits of the smaller one. There could be three or even four of these. Or I guess they could all be contained in the same UI even.

Anyway, Z2 is already sounding like a somewhat complex instrument so I appreciate your instinct to limit it somewhat.

[Urs]

I don't know enough about the buying habits of the "typical" customer to know whether this would be fun and worthwhile or commercial suicide!

Well, I'm keeping stuff like this in the back of my mind, but I'm not yet getting serious about it.

That nanoZebra idea was merely something like putting it on Computer Music CD. I currently have Podolski on German Keyboards Mag CD, it's a very stripped down FilterscapeVA that gives one a little "smell" of the real thing. The funny thing here is that you can load Podolski presets into FilterscapeVA. I have yet to feel any raise in Filterscape sales from Germany, but the summer months are weak for business anyway. But the exposure & feedback is so great that it's unthinkable that there will not be any positive effect in the long run.

The thing about Zebra 2.0 is the totally seamless integration of basically all known synthesis concepts* in an easy and consistent manner. A nanoZebra would hardly touch this. It would promote one synthesis method, but not more.

I think it wouldn't be bad for me to have something in the low cost area in my product range, especially if I can keep it compatible to one of the big products.

We'll see after Z2 is finished...

Cheers,

Urs


*Z2 does wavetable, additive, subtractive, FM, bits of PD and some stuff that sounds like physical modeling. It doesn't do sampling/resynthesis, nor granular although the inner workings are somehow related to granular synthesis, which sometimes becomes audible. Funnily, these are not totally optional concepts, it's more like they're all in there simultaneously.