How is it possible that some RE on Bypass won't bypass the audio signal?

[Marco Raaphorst]

Try this:
- you need at least one channel in your song which produces sound
- create a parallel channel from that channel
- set INV (phase invertion) of the parallel channel to ON
- this will mute the original signal because the phase is INVERTED
- now drag an effect to the parallel channel
- Audiomatic, put it on bypass: no sound which is ok because the bypassed signal is INVERTED, perfect phase cancelation 'cause of bypass
- now drag Softube Saturation Knob as effect insert to the parallel channel and put it on bypass
- you will hear sound coming through! so even on bypass Saturation Knob simply processes sound!!!
- Softube Amp: same thing, bypass will process sound!!!
- Softube Bass Amp: same thing, bypass will process sound!!!
- Kilohertz Distortion: same thing, bypass will process sound!!!
- Kilohertz Limiter: same thing, bypass will process sound!!!
- Kilohertz Pitch Shifter: same thing, bypass will process sound!!!

Shouldn't the SDK protect this from happening? Bypass should never ever proces sound. I also notice that many device on OFF are still using CPU cycles. Seems to be related to this issue.

[Ottostrom]

Yeah, this is something that should NOT be happening. Having to worry about latency issues when devices are bypassed is not something I want to be doing

[selig]

one word: latency.


Sent from my iPad using Tapatalk

[Ottostrom]

one word: latency.

But even though the M-class maximizer causes latency when you have 4ms look ahead on it nulls when in bypass.
That is how other devices should work aswell in my opinion.

[selig]

This is timely because I've been making repeated posts saying you simply can NOT make any assumptions when a null fails. Your assumption in this case is it MUST mean these devices are still "processing sound". But there are many other reasons a null test can fail, such as a minute level difference or (as in this case) a delay.


Sent from my iPad using Tapatalk

[selig]

one word: latency.

But even though the M-class maximizer causes latency when you have 4ms look ahead on it nulls when in bypass.
That is how other devices should work aswell in my opinion.

Sure, but then you'll break something else which is the option of putting a bypassed version of the same RE on the other parallel channel without having to calculate latency or purchase other REs.


Sent from my iPad using Tapatalk

[Ottostrom]

Sure, but then you'll break something else which is the option of putting a bypassed version of the same RE on the other parallel channel without having to calculate latency or purchase other REs.

Sorry if I sound naive but, wouldn't the factor of having to calculate latency disappear completely if both devices made no change to the original sound while bypassed?

[selig]

Sure, but then you'll break something else which is the option of putting a bypassed version of the same RE on the other parallel channel without having to calculate latency or purchase other REs.

Sorry if I sound naive but, wouldn't the factor of having to calculate latency disappear completely if both devices made no change to the original sound while bypassed?

They already work that way - NO device makes changes to the sound when bypassed. That's what I'm trying to say here!

[EDIT- put a VMG-01 on the other channel with the correct delay and it WILL null, proving these devices do NOT change the sound when bypassed.]


Sent from my iPad using Tapatalk

[kloeckno]

Sure, but then you'll break something else which is the option of putting a bypassed version of the same RE on the other parallel channel without having to calculate latency or purchase other REs.

Sorry if I sound naive but, wouldn't the factor of having to calculate latency disappear completely if both devices made no change to the original sound while bypassed?

The idea is you have one bypassed and one processing the sound for parallel processing.

[Ottostrom]

Sure, but then you'll break something else which is the option of putting a bypassed version of the same RE on the other parallel channel without having to calculate latency or purchase other REs.

Sorry if I sound naive but, wouldn't the factor of having to calculate latency disappear completely if both devices made no change to the original sound while bypassed?

They already work that way - NO device makes changes to the sound when bypassed. That's what I'm trying to say here!

[EDIT- put a VMG-01 on the other channel with the correct delay and it WILL null, proving these devices do NOT change the sound when bypassed.]


Sent from my iPad using Tapatalk

But if they don't null when bypassed then SOMETHING must be happening right? Even if it's only a really small change in volume or something else.

[selig]

Sure, but then you'll break something else which is the option of putting a bypassed version of the same RE on the other parallel channel without having to calculate latency or purchase other REs.

Sorry if I sound naive but, wouldn't the factor of having to calculate latency disappear completely if both devices made no change to the original sound while bypassed?

They already work that way - NO device makes changes to the sound when bypassed. That's what I'm trying to say here!

[EDIT- put a VMG-01 on the other channel with the correct delay and it WILL null, proving these devices do NOT change the sound when bypassed.]


Sent from my iPad using Tapatalk

But if they don't null when bypassed then SOMETHING must be happening right? Even if it's only a really small change in volume or something else.

Yes, something IS happening, and I've already said it - LATENCY.


Sent from my iPad using Tapatalk

[unisyn]

um latency or not, if it changes something in the signal chain, than that's not bypass

[Ottostrom]

Sure, but then you'll break something else which is the option of putting a bypassed version of the same RE on the other parallel channel without having to calculate latency or purchase other REs.

Sorry if I sound naive but, wouldn't the factor of having to calculate latency disappear completely if both devices made no change to the original sound while bypassed?

The idea is you have one bypassed and one processing the sound for parallel processing.

So even if you don't want (for example) a Softube Saturation Knob on the original sound and only on the parallel track you would still put one on the original track but bypassed to compensate the latency?

[kloeckno]

So even if you don't want (for example) a Softube Saturation Knob on the original sound and only on the parallel track you would still put one on the original track but bypassed to compensate the latency?

Yes, or you have to use the VMG-01 to compensate. The saturation knob has 4 samples of latency at 44.1kHz, so to avoid phasing you have to use the bypassed effect or the VMG-01 in a parallel configuration.

[selig]

um latency or not, if it changes something in the signal chain, than that's not bypass

Still, it's not processing the sound and it's not changing the sound in any way.

And some find this behavior to be an advantage rather than a liability. How would this functionality negatively affect your workflow?


Sent from my iPad using Tapatalk

[Ottostrom]

So even if you don't want (for example) a Softube Saturation Knob on the original sound and only on the parallel track you would still put one on the original track but bypassed to compensate the latency?

Yes, or you have to use the VMG-01 to compensate. The saturation knob has 4 samples of latency at 44.1kHz, so to avoid phasing you have to use the bypassed effect or the VMG-01 in a parallel configuration.

I had never thought about doing the bypass thing (mainly because I thought there weren't any latency when a device was bypassed) so this could definitely come in handy since I don't own the VMG. Thanks!

[Marco Raaphorst]

one word: latency.


Sent from my iPad using Tapatalk

Pulveriser for example will produce Tremor and Follower output even when in OFF mode. Same as for Alligator which processes many things even in OFF mode. Which is considered as "Just one of many quirks in the Reason rack!"

[selig]

one word: latency.


Sent from my iPad using Tapatalk

Pulveriser for example will produce Tremor and Follower output even when in OFF mode. Same as for Alligator which processes many things even in OFF mode. Which is considered as "Just one of many quirks in the Reason rack!"

But still, they are not processing the main audio path, which was what I thought was your original point, right?

[Marco Raaphorst]

one word: latency.


Sent from my iPad using Tapatalk

Pulveriser for example will produce Tremor and Follower output even when in OFF mode. Same as for Alligator which processes many things even in OFF mode. Which is considered as "Just one of many quirks in the Reason rack!"

But still, they are not processing the main audio path, which was what I thought was your original point, right?

It IS audio processing. Check it. The Follower is reacting to input and outputing CV even in OFF mode. Same for the Tremor which is still working even in OFF mode. It generates CV.

[Noplan]

Still, it's not processing the sound and it's not changing the sound in any way.

Bypass adds a tiny delay to the source. That's per definition an effect no matter how small the change is or how relevant it is.

[selig]

Still, it's not processing the sound and it's not changing the sound in any way.

Bypass adds a tiny delay to the source. That's per definition an effect no matter how small the change is or how relevant it is.

Argue semantics all you want, I call an effect something that changes the sound, you call it whatever you want.
That's why, for example, VMG-01 is not an "effect", it's a "utility".

I will suggest Softube knows what they're doing here because their devices would be LESS useful if it didn't do what it does. Meaning, if it didn't do this, then when you bypassed the effect in Parallel you would get comb filtering, making the bypass USELESS in that case.

Again, if anyone can tell me why this is a BAD idea, or what use cases you can think of were it causes a problem, I'm all ears - and that's my point. I gave a use case where NOT doing this would cause serious problems. Anyone?

[Noplan]

VMG-01 is not an "effect", it's a "utility".

It is a an utility because Norman has designed it for a specific purpose. technically you can do more with it. Anyway this is hair-splitting.

[selig]

VMG-01 is not an "effect", it's a "utility".

It is a an utility because Norman has designed it for a specific purpose. technically you can do more with it. Anyway this is hair-splitting.

I thought we already established that?

[selig]

one word: latency.


Sent from my iPad using Tapatalk

Pulveriser for example will produce Tremor and Follower output even when in OFF mode. Same as for Alligator which processes many things even in OFF mode. Which is considered as "Just one of many quirks in the Reason rack!"

But still, they are not processing the main audio path, which was what I thought was your original point, right?

It IS audio processing. Check it. The Follower is reacting to input and outputing CV even in OFF mode. Same for the Tremor which is still working even in OFF mode. It generates CV.

This isn't the original point, right?
We are speaking past each other: You are saying "it's processing" and I'm saying it's not passing the processed audio through to the output. We are both correct, so I'm not sure your point here?

[valankar]

Still, it's not processing the sound and it's not changing the sound in any way.

Bypass adds a tiny delay to the source. That's per definition an effect no matter how small the change is or how relevant it is.

Argue semantics all you want, I call an effect something that changes the sound, you call it whatever you want.
That's why, for example, VMG-01 is not an "effect", it's a "utility".

I will suggest Softube knows what they're doing here because their devices would be LESS useful if it didn't do what it does. Meaning, if it didn't do this, then when you bypassed the effect in Parallel you would get comb filtering, making the bypass USELESS in that case.

Again, if anyone can tell me why this is a BAD idea, or what use cases you can think of were it causes a problem, I'm all ears - and that's my point. I gave a use case where NOT doing this would cause serious problems. Anyone?

Just trying to understand your point about comb filtering. Why would it be such? I would think the parallel channel would just add volume with the effect bypassed.