Detecting I/O cable loop in RE

This forum is for developers of Rack Extensions to discuss the RE SDK, share code, and offer tips to other developers.
Post Reply
User avatar
Murf
RE Developer
Posts: 656
Joined: 21 Jun 2019
Location: Brisbane, Australia
Contact:

18 Mar 2023

Hi All, does anyone know of a way of detecting if an RE has an audio output plugged back into an input of the same instance of the RE?
Other than sending some codes out the AU output and detecting then on the AU input (which I dont think is acceptable) I was wondering if there was a way of doing it with the SDK?
Murf.

User avatar
Enlightenspeed
RE Developer
Posts: 1103
Joined: 03 Jan 2019

19 Mar 2023

The short answer is -

If it's CV then yes, set up a short handshake signal at the start of the connection using data that would be otherwise out of range for the receiving port. You need to get the device to generate a small unique ID upon creation (you'll have to store this as a realtime string), and it tests this against the port of the receiving device. If the receiving device recognises the ID then it's coming from the same device. If the receiving port doesn't recognise it at all, then it will just ignore it.

If it's audio then not really, as all you can send out are audio buffers. There's nothing to stop you from having the above protocol modified a bit to do it with an audio signal, but it will be within an audio pathway. While I can think of ways around this, there is no way to get it to run silently in the background with no disruption to the audio path, and the receiving port will have no way of knowing that it is being tested unless it tests on every call until it gets switched off. The fix to this is to make sure that the test is instigated at the point of connection, and this is where you need to do a bit of testing yourself to find out at which packet the connection actually goes live, because it can't be the first one and it might not be a constant static amount of packets before it broadcasts. Ultimately it's very open to a potentially loud click/pop if it is done in an audio path.

It's a good one to send to RS as a feature suggestion, because allowing the SDK to have a "get_connected_port_info()" method could be a lot of use in any complex routing device.

Hope this helps,
B

User avatar
Murf
RE Developer
Posts: 656
Joined: 21 Jun 2019
Location: Brisbane, Australia
Contact:

19 Mar 2023

Enlightenspeed wrote:
19 Mar 2023
The short answer is -

If it's CV then yes, set up a short handshake signal at the start of the connection using data that would be otherwise out of range for the receiving port. You need to get the device to generate a small unique ID upon creation (you'll have to store this as a realtime string), and it tests this against the port of the receiving device. If the receiving device recognises the ID then it's coming from the same device. If the receiving port doesn't recognise it at all, then it will just ignore it.

If it's audio then not really, as all you can send out are audio buffers. There's nothing to stop you from having the above protocol modified a bit to do it with an audio signal, but it will be within an audio pathway. While I can think of ways around this, there is no way to get it to run silently in the background with no disruption to the audio path, and the receiving port will have no way of knowing that it is being tested unless it tests on every call until it gets switched off. The fix to this is to make sure that the test is instigated at the point of connection, and this is where you need to do a bit of testing yourself to find out at which packet the connection actually goes live, because it can't be the first one and it might not be a constant static amount of packets before it broadcasts. Ultimately it's very open to a potentially loud click/pop if it is done in an audio path.

It's a good one to send to RS as a feature suggestion, because allowing the SDK to have a "get_connected_port_info()" method could be a lot of use in any complex routing device.

Hope this helps,
B
Thanks, that is pretty much as I expected.

I am trying to make an "all in one" version of my MODRACK synth module range, without going to the complexity (no pun intended) of doing front panel i/o routing, so am relying on being able to just "jumper" across back panel I/O between the modules.
Only problem is.. of course.. the delay between each module passing a batch from one to the next.
If I could 'detect" what was plugged where I could handle it internally and get rid of the latency.

oh well.
Murf.

User avatar
Enlightenspeed
RE Developer
Posts: 1103
Joined: 03 Jan 2019

19 Mar 2023

Murf wrote:
19 Mar 2023
Thanks, that is pretty much as I expected.

I am trying to make an "all in one" version of my MODRACK synth module range, without going to the complexity (no pun intended) of doing front panel i/o routing, so am relying on being able to just "jumper" across back panel I/O between the modules.
Only problem is.. of course.. the delay between each module passing a batch from one to the next.
If I could 'detect" what was plugged where I could handle it internally and get rid of the latency.

oh well.
Murf.
No worries.

FWIW I'd go with the front panel idea, because if you do get a connection from the rear and use the internal realtime values then it is essentially ignoring the CV port for the duration of that connection; so what happens when someone uses it for an external connection? You would need another boolean and process path for it.

In a front panel solution you can just use custom displays to set up the link and then they can just go dormant safely. Obviously you don't need to go as far as Complex-1 in terms of graphics. So basically there's less aggro, and it's missing out a process step. Plus this allows you multiple connections while the rear panel version leaves you with the possibility of someone trying to sum an internal output with an external LFO, or similar, and getting unexpected results.

If you're determined to go back panel, perhaps you could use a rear panel switch per port to govern the connection type?

User avatar
Murf
RE Developer
Posts: 656
Joined: 21 Jun 2019
Location: Brisbane, Australia
Contact:

20 Mar 2023

Enlightenspeed wrote:
19 Mar 2023
Murf wrote:
19 Mar 2023
Thanks, that is pretty much as I expected.

I am trying to make an "all in one" version of my MODRACK synth module range, without going to the complexity (no pun intended) of doing front panel i/o routing, so am relying on being able to just "jumper" across back panel I/O between the modules.
Only problem is.. of course.. the delay between each module passing a batch from one to the next.
If I could 'detect" what was plugged where I could handle it internally and get rid of the latency.

oh well.
Murf.
.....

If you're determined to go back panel, perhaps you could use a rear panel switch per port to govern the connection type?
Yes I had considered this, and you would only need to do it IF the latency was an issue.
Murf

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 0 guests