That Spider Audio Splitter bug

[EdGrip]

I've seen it mentioned from time to time but... What actually is the bug?

[Loque]

AFAIR it is a constant 64 sample delay.

[AuroraNovalis]

Do the Blamsoft Polymodular splitters have less delay?
What about the Jiggery Pokery super-spiders?

[Loque]

Do the Blamsoft Polymodular splitters have less delay?
What about the Jiggery Pokery super-spiders?

I think they do not introduce a delay. You can measure it with this one here:
https://www.reasonstudios.com/shop/rack ... ple-delay/

[AuroraNovalis]

Just ran some tests with the VMG-01 on the Spider Audio Splitter, Polymodular Audio Splitter, and Shelob Audio Bypass Splitter.
All three introduce either no delay or multiples of 64 samples of delay depending on how many chains of cables you go through.

The stock spider seems weirdly inconsistent. Sometimes I could chain the splitters and mergers of one device and get a readout of zero delay, other times the expected 64 shows up on the VMG-01. For instance going from merger>splitter>merger>VMG-01 all with one spider gives 64 samples of delay, but if I move the jack on the input of second merger's first input to its second input I get no delay.

Polymodular Merger adds 64 samples of delay with every intra-device chain beyond the first input. However if you make inter-device chains of Polymodular mergers and/or splitters you get 0 delay.
Behavior identical to the Polymodulars was observed with Mordred and Shelob.

I ponder whether differing audio on the inputs of mergers may also contribute some delay, but I was unsure of how to test such a thing.

[selig]

IIRC, the spider bug involves a batch delay on only one channel (right?), and only occurs with specific routing (outside of a Combinator/Insert?). I can't remember exactly the conditions for this bug to be present, all I can say is in all my routing experiments over the past almost 20 odd years using Reason I've never ran into it myself. I heard about it years ago and helped identify exactly what was going on, but cannot remember any details including exactly how to reproduce it (it's totally predictable once you understand the conditions)
I'm guessing that because it's so rare for me I've not bother to consider it something needing to be remembered?!? Or maybe I'm just getting old…

[challism]

I've often times thought about this bug, too, but I've never encountered it, myself.... or I didn't notice it if it was happening.

IIRC, the spider bug involves a batch delay on only one channel (right?), and only occurs with specific routing (outside of a Combinator/Insert?). I can't remember exactly the conditions for this bug to be present, all I can say is in all my routing experiments over the past almost 20 odd years using Reason I've never ran into it myself. I heard about it years ago and helped identify exactly what was going on, but cannot remember any details including exactly how to reproduce it (it's totally predictable once you understand the conditions)
I'm guessing that because it's so rare for me I've not bother to consider it something needing to be remembered?!? Or maybe I'm just getting old…

So when you need to split an audio signal in one of your own projects, do you reach for the stock Reason spiders or Blamsoft's or Jiggery Pokery's?

Just ran some tests with the VMG-01 on the Spider Audio Splitter, Polymodular Audio Splitter, and Shelob Audio Bypass Splitter.
All three introduce either no delay or multiples of 64 samples of delay depending on how many chains of cables you go through.

The stock spider seems weirdly inconsistent. Sometimes I could chain the spliiters and mergers of one device and get a readout of zero delay, other times the expected 64 shows up on the VMG-01. For instance going from merger>splitter>merger>VMG-01 all with one spider gives 64 samples of delay, but if I move the jack on the input of second merger's first input to its second input I get no delay.

Polymodular Merger adds 64 samples of delay with every intra-device chain beyond the first input. However if you make inter-device chains of Polymodular mergers and/or splitters you get 0 delay.
Behavior identical to the Polymodulars was observed with Mordred and Shelob.

I ponder whether differing audio on the inputs of mergers may also contribute some delay, but I was unsure of how to test such a thing.

Thanks for doing these tests and sharing the results with us.

[Billy+]

Am I missing something or doesn't delay compensation negate this issue? And or not using external routing?

[selig]

Am I missing something or doesn't delay compensation negate this issue? And or not using external routing?

The bug delays only one channel, and of course this delay is not reported so it cannot be compensated.

[EdGrip]

Is there a simple maths/laws of space-time reason DAWs don't just precisely measure the delay in a chain, like Norman's delay probe, rather than relying on plugins reporting their delay?

[buddard]

Is there a simple maths/laws of space-time reason DAWs don't just precisely measure the delay in a chain, like Norman's delay probe, rather than relying on plugins reporting their delay?

Probably because it doesn't know for sure if the delay is on purpose, for example a delay plugin that's fully wet.

[selig]

Is there a simple maths/laws of space-time reason DAWs don't just precisely measure the delay in a chain, like Norman's delay probe, rather than relying on plugins reporting their delay?

Probably because it doesn't know for sure if the delay is on purpose, for example a delay plugin that's fully wet.

Also, you can easily observe that even slight LP filtering removes the leading edge of the pulse signal used by VMG-01 to measure delay which causes readings to vary (become longer) because of the sloped response vs stepped response.