That Spider Audio Splitter bug

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
EdGrip
Posts: 1945
Joined: 03 Jun 2016

Post 13 Sep 2020

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

User avatar
Loque
Posts: 7767
Joined: 28 Dec 2015

Post 13 Sep 2020

AFAIR it is a constant 64 sample delay.
:reason: 11, Win10 64Bit.

User avatar
AuroraNovalis
Posts: 10
Joined: 17 Nov 2018

Post 14 Sep 2020

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

User avatar
Loque
Posts: 7767
Joined: 28 Dec 2015

Post 14 Sep 2020

AuroraNovalis wrote:
14 Sep 2020
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/
:reason: 11, Win10 64Bit.

User avatar
AuroraNovalis
Posts: 10
Joined: 17 Nov 2018

Post 14 Sep 2020

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.
Last edited by AuroraNovalis on 14 Sep 2020, edited 1 time in total.

User avatar
selig
RE Developer
Posts: 8775
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

Post 14 Sep 2020

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… ;)
Selig Audio, LLC

User avatar
challism
Moderator
Posts: 1975
Joined: 17 Jan 2015

Post 14 Sep 2020

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.
selig wrote:
14 Sep 2020
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?
AuroraNovalis wrote:
14 Sep 2020
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.
Reason 2.5, Windows 95, 4MB RAM, 133Mhz CPU, integrated soundblaster 14.4k dial-up modem

:rt: :reason: :rt: :reason: :rt: :reason: :rt: :reason: :rt: :reason: :rt:
ReasonTalk Rules and Guidelines

Billy
Posts: 326
Joined: 09 Dec 2016

Post 15 Sep 2020

Am I missing something or doesn't delay compensation negate this issue? And or not using external routing?
:ignition: :reason: :refill: :re: :rebirth: :PUF_figure: :nektar: :mac: :EiEPro: :Alesis Mk2:

User avatar
selig
RE Developer
Posts: 8775
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

Post 15 Sep 2020

Billy wrote:
15 Sep 2020
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.
Selig Audio, LLC

EdGrip
Posts: 1945
Joined: 03 Jun 2016

Post 15 Sep 2020

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?

User avatar
buddard
RE Developer
Posts: 841
Joined: 17 Jan 2015
Location: Stockholm

Post 16 Sep 2020

EdGrip wrote:
15 Sep 2020
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.

User avatar
selig
RE Developer
Posts: 8775
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

Post 16 Sep 2020

buddard wrote:
16 Sep 2020
EdGrip wrote:
15 Sep 2020
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.
Selig Audio, LLC

  • Information
  • Who is online

    Users browsing this forum: CommonCrawl [Bot], polysix, Wee Joe and 2 guests