Zebra2: Module placement within the (main) grid - some questions

[DynaMoHum]

I continue to be utterly amazed by Z2 - and after 7-8 months as an owner, I'm still really "swimming."

In looking at many patches - by many designers - sometimes there are 'gaps' (vertically) in the lanes - sometimes not. In Howard's patches, many times it's clear that it's for visual clarity to see which lane's module is modulating another - because there won't be anything else above/below, in the lanes left and right. Only the input/output modulation connections. Other times/designers - not so much. Case in point example, with Ed Harvey's recent 'demo pack' gift to us recently (THANK you!) - "EH Pluck That" - there appears (graphically):

Lane1 Lane2
------- -------
Noise1
Comb1 Comb2

**** VCF1
FMO1 FMO2

Now, I can see in the "output grid" below in this patch (e.g.), a bunch of things going on. I'm disregarding that. What I'm referring to is depicted by the 'spaces' above in the main grid - where there are 'blanks' and modules are not adjacent to each other (vertically). I can't see any sidebands, nothing in 'global' or 'matrix' that explains the 'reason' for the placement thus.

I seem to remember Urs stating that "OSC's add" and "filters replace" - and I assume he's referring to the 'order' in which the 'rendering' takes place. Does it matter where in the lane each module is? In the example above - even though it's on a different lane - does VCF1 'rendering' take place before FMO1?

Any light you masters can shed on this is much appreciated!

[Howard]

Ed's placement of modules in that preset is just fine, it makes sense. He simply put the Combs and FMOs next to each other.

[DynaMoHum]

Thanks, Howard.

I just used that preset as an example, because that was one of the ones I "landed on" that happened to have a lot of 'space' in the grid.

What I was driving at, is that I know that the order, vertically, matters - as to how modules interact. E.g., an OSC before an FMO (vertically) is a very different thing, than an FMO before an OSC (vertically).

Laterally, does it matter whether VCF2 - in lane2 - is 2 'lane slots' lower (in lane 2), than VCF1 (in lane1)? This is assuming no modulation at all between the 2 lanes - they are distinct signal paths.

I think I've answered my question perhaps. It doesn't matter whether one has an OSC1 in 'slot 1' at the top of 'lane 1,' and a VCF1 right below it. And then an OSC2 at the top of 'lane 2' and a VCF2 at the bottom 'slot' of 'lane 2.' It seems that the 'processing order' will be the same, even though VCF1 (lane 1) is "higher" within it's lane, than the VCF2, at the bottom of lane 2. Components/routing are the same, within each lane. Correct?

[bmrzycki]

What I'm referring to is depicted by the 'spaces' above in the main grid - where there are 'blanks' and modules are not adjacent to each other (vertically). I can't see any sidebands, nothing in 'global' or 'matrix' that explains the 'reason' for the placement thus.

I can see why you are bit confused. It took me a while to start to understand the audio signal flow in Zebra's grid.

As you said, gaps between devices vertically are strictly a visual preference and don't change the sound of a lane at all. However, if a device A is before device B vertically in the same lane then one of two things can happen. Devices in different lanes do not interact unless you see specific wires to modules across lanes.

Scenario 1: Device B does not process audio input.
This case happens all the time when someone does things like:

Code: Select all

[OSC1]
[OSC2]

or:

Code: Select all

[FMO1]
[Noise1]

In both of these cases neither of the device B modules (OSC2 or Noise1) take audio as input. They are purely a sound source. Stacking them like this sums the signal in the lane. It's (mostly) functionally equivalent to:

Code: Select all

[OSC1][OSC2]
  |   /
[Mix1]

However, the next example is ambiguous and you'll have to examine the settings of FMO1 to determine if the output of OSC1 is used as an audio input to FMO1 (check the FMO mode to see if the word "self" is in it. If it is then it's not using OSC1's audio input:

Code: Select all

[OSC1]
[FMO1]

Scenario 2: Device B always processes audio input (or a device configured to process input)
This scenario is quite common when using subtractive synthesis with Zebra: place a filter after a sound source and remove/alter signal. Here's the most common example:

Code: Select all

[OSC1]
[VCF1]

Osc1 is the sound source and is being fed into filter 1 and the filter is altering the sound generated by Osc1.

These two scenarios are often used in conjunction with each other:

Code: Select all

[OSC1]
[OSC2]
[OSC3]
[VCF1]
[Noise1]

In this example the audio generated by Osc1,2,3 are fed into filter 1 and modified. Output of the filter and the noise module are summed together. If this is the entire chain the resultant signal is fed to the FX unit.

I'd read Ed's patch in the following manner. The sound contains 2 layers represented by lane 1 and lane 2. Lane 1 prefills the comb module with Noise and then uses that input into an FMO. Lane 2 generates its own sound from the comb module (no prefill) but some post filtering is being done with vcf2 on the second lane. Finally, I don't know what's happening with the FMOs unless I can look at the settings of each FMO to determine if it's Scenario 1 or Scenario 2 mentioned above.

I seem to remember Urs stating that "OSC's add" and "filters replace" - and I assume he's referring to the 'order' in which the 'rendering' takes place. Does it matter where in the lane each module is? In the example above - even though it's on a different lane - does VCF1 'rendering' take place before FMO1?

Be careful with such a simplistic definition of filters in Zebra. The different filter modes can do drastically different things. EQ peaking vs Formant vs LP Vintage2 do vastly different things with the input. Things get even more subtle when you realize that most of the filter types can self-oscillate at high resonance settings. Combined with keytracking and a tiny input sound you can "play" the filter like another oscillator...

Finally, the order of the modules matters only in Scenario 2 above.

Code: Select all

[OSC1]
[OSC2]
[OSC3]

is identical to:

Code: Select all

[OSC2]
[OSC3]
[OSC1]

However, this:

Code: Select all

[OSC1]
[VCF1]
[OSC2]

is different from:

Code: Select all

[OSC2]
[VCF1]
[OSC1]

and is different still from:

Code: Select all

[OSC1]
[OSC2]
[VCF1]

It's easiest to learn which modules can't take audio as input: OSC and Noise. Next, learn which modules are "sometimes modules" and need to be examined for their settings: FMO and Comb. All other modules always respond to audio input from previous modules in the chain!

I hope this helps.

[EdHarvey]

To be honest, providing you remember that the signal flow is top-to-bottom within a lane, the module placement is pretty much ad-hoc (usually which ever slot happens to be under my mouse when I want a new module! ).

The only times I have to think about things are FMOs, or when there are cross-lane patches ( but then the visual 'wires' helps one to make sure the routing is correct).

[DynaMoHum]

Thanks, Brian and Ed!

All the information you gents amplified above, was as I understood it. On the "filters replace" bit, a better explanation would be (in the case of OSC1 > VCF1 > OSC2 > VCF2) that "VCF2 processes the input of whatever signals/filtering that has already preceded it, and further processes the input it receives according to filter type/amount/params attributed to VCF2."

It's easiest to learn which modules can't take audio as input: OSC and Noise.

Unless we're talking about Bazille...

[bmrzycki]

Thanks, Brian and Ed!

You're quite welcome.

(in the case of OSC1 > VCF1 > OSC2 > VCF2) that "VCF2 processes the input of whatever signals/filtering that has already preceded it, and further processes the input it receives according to filter type/amount/params attributed to VCF2."

Sounds good to me. I'm pretty sure you understand this but don't forget VCF1 only processes OSC1 in your example.

It's easiest to learn which modules can't take audio as input: OSC and Noise.

Unless we're talking about Bazille...

Now that is a completely different (and wonderful) beast...