Zebra 2.6 - a few arcane pan/width bugs

[EdHarvey]

Over time I've noticed some arcane little bugs (features?) in zebra2 that I've never got around to documenting/reporting....

Here's some patches I made to demo the bugs
EH Zebra2 Bug demo patches.zip


OSC Width 100% in 'Dual' mode (OSC Dual crosstalk.h2p)

• Set OSC to 'Dual' voice mode
• Set Width to 100%, Pan to 0
• Add some detune.
  
  If you examine the output on a scope (or sensitive VU meters), you can see some amplitude variation.
  This is caused by a small amount of crosstalk between the channels - the 'width' is not fully 100%

FMO Width 100% in 'Stereo' mode (FMO Dual crosstalk.h2p)

• Set FMO to 'Stereo' mode
• Set Width to 100%, Pan to 0
• Add some detune.
  
  If you examine the output on a scope (or sensitive VU meters), you can see some amplitude variation.
  This is caused by a small amount of crosstalk between the channels - the 'width' is not fully 100%
  (essentially the same problem as the OSCs)

FMO hard pan in 'Mono' mode (FMO pan.h2p)

• Set FMO to 'Mono' mode
• Set Pan to 100% (hard right)
  
  If you examine the output, you can see that some signal still exists in the left channel (about 30 dB down).
  The same problem occurs on the reverse 0% pan.
  
  [OSCs in 'dual' mode exhibit the same behaviour when width is set to 0% and they are hard panned]

OK, given that these are very small bugs, why do they matter?

In a word (?) FM...
FM is extremely sensitive to small changes in modulator amplitudes.


Load up the patch - FM crosstalk bug demo.

The first lane demonstrates the correct (simulated) behaviour.
Note that there is a sense of width, but very little timbral shifting (there should be none, but the simulation isn't perfect)

Now, mute the first lane and unmute the second. You should easily hear the sound varying because of the 'ripple' in the modulators amplitude....

[trance_lucent]

Great research!
There are some people who stated that the width of Zebra stacked oscillators is narrower than, for example, Sylenth1's.

[Urs]

Yeah...

This is a relic from the past. Before SSE and when PowerPC still had to be supported, there was a performance problem that mainly occurred when filters were fed with silence. This is known as the Denormals processing problem, where numbers get so small that the CPU needs to switch into a slower mode.

A typical way to prevent this from happening was to feed a tiny amount of noise to every algorithm in the signal chain. In Zebra I solved this rather elegantly by making it "not quite fully stereo", so a nearly inaudible amount of oscillator is always also fed to the right channel even if it's fully panned left.

Nowadays we don't need that anymore, because Denormal processing can be switched off on the CPU directly, and our stuff does so.

However, I never dared to "fix" the oscillators for this, in case existing presets would sound too different.

[EdHarvey]

Interestingly, single mode OSCs operate over the full pan range; it's only the 'stacked' ones (and FMOs) that implement the 0.2/99.8 range clamp on pan.
This was why I wasn't sure if it was a feature or bug...

...
However, I never dared to "fix" the oscillators for this, in case existing presets would sound too different.

It's a pity that you don't have a zebra version number in the preset files that could be used to conditionally enable this behaviour for older presets


[ I understand that this would be a very low priority to fix, but it really does limit the usefulness of the FMOs ]

[EvilDragon]

However, I never dared to "fix" the oscillators for this, in case existing presets would sound too different.

You have 2.3 and 2.5 mode, why not add a 2.6 mode that would fix those bugs, yet retain patch compatibility with patches created in older versions?

[Urs]

However, I never dared to "fix" the oscillators for this, in case existing presets would sound too different.

You have 2.3 and 2.5 mode, why not add a 2.6 mode that would fix those bugs, yet retain patch compatibility with patches created in older versions?

This might be possible, but I'm a little afraid of the added risks.

Sometimes we get bug reports of something that the 2.3 vs 2.5 modes were meant to fix. Someone sends two mp3s saying "here, it sounds different, something is wrong". And then we spend two or three days trying to find the issue. And then it turns out, one is in 2.3 mode, the other is in 2.5 mode.

The most useless problems come about with "smart" changes that are somewhat hidden from the users. In theory they're cool, but every now and then they fire back on us and cost us a lot of time, for literally nothing. Because it so happens that those changes are also somewhat hidden from us. There's no support guy at u-he who was present during the time of transition, all they have is the current version.

Thankfully we save revision numbers in the presets, but if a preset sounds wrong and is saved with the latest version, we still don't know what revision it was originally used with in a song/project.

Thus I think we would create switches and knobs that are in your face rather than versionised upgrades that hide the difference.

As such, if anything, we could change the panning behaviour globally, for every revision and mode, and then we could change the preset if it loads from an older revision. However, if anyone uses the modulation on Osc pan, then this would be very tricky, if not impossile to do without adding more ModMappers.

There's a lot to be considered... and I guess there are a bunch of additional aspects to be reviewed for a change like that.

[EvilDragon]

Understood - you make a lot of valid points.