Connector APP mode in Studio One, failing ports & delay compensation

[kidslow]

Trying to use Connector on a Mac, in App mode, where I have a SEND instance as the first insert of one track in Studio One and a RECEIVE instance on another track in the same session. What I'm trying to do is create a send before the inserts. Afaik, Studio One allows send before fader, but not send before insert Fx, so Connector came to mind as a possible solution. I'm starting to think Connector is ill-suited to the task.

If I use the default port 8080, it will connect, for some temporary period of time, and then fail to connect. Nothing I did was able to resolve the problem using the first set of ports, but I did not go deep. I'm sure a reboot would fix it. Maybe a DAW restart. I just changed the port (e.g. to 8081) on both instances, and it linked up, until it didn't. Incremented again to 8082, and rinse and repeat. I didn't look into what was going on with these network ports. I assume they are TCP and not UDP. Either the SEND or RCV instance is failing, or maybe both, but is there a way for me to diagnose this further on my own? I assume netstat will show me an open TCP port on the OS side. Are there any further diagnostics available inside Connector or can I network connect to the port and handshake using something like netcat to further diagnose?

The second issue I ran into was delay compensation. I thought Connector compensated for any delay it introduces, no? I tried various packet sizes and buffering to no good effect. I tried both Waves InPhase and Melda MUtility to compensate manually. That became an exercise in frustration. Perhaps I'm missing some clear way to measure the delay so I can just type in a number into MUtility and then be done. Any suggestions?

I guess I could try the same setup in Reaper, but there I can just send pre-FX and be done with it.

[Blue Cat Audio]

Hi,

If you are using the Connector plug-in in App mode, it does not use TCP but an internal routing scheme, so there should not be any particular issue unless yo are using several instances with the same port number to communicate. So maybe there is another problem here.

Regarding latency, Connector does not add any latency in app mode, but, depending on how the host processes audio in multithreaded mode and the type of routing you are doing, you may get one buffer of latency (which typically happens if doing feedback for example). But it is a tough problem to detect it (given that Connector can be used for any kind of routing), so it is currently not capable of reporting it.

[kidslow]

Thank you for the help. Just to clarify:

If you are using the Connector plug-in in App mode, it does not use TCP but an internal routing scheme, so there should not be any particular issue unless yo are using several instances with the same port number to communicate. So maybe there is another problem here.

What does the port number indicate then when using App mode? Just some internal differentiator when using multiple instances? There clearly is another problem here. In app mode on Studio One, with a single Sender and Receiver (1 instance of each) the connection will stop working for no apparent reason and the only way I found to clear it up was to change the port number. Then it will work for awhile and then stop. How can I help troubleshoot to better determine what the problem might be?

Let me check this assumption, can I have multiple Senders all Sending to a single Receiver? That was one thing I was messing with that maybe could have caused the issue, but I'd have to go back and see if those were even enabled. None would have any audio to send overlapping, they could be considered serial in that sense.

Regarding latency, Connector does not add any latency in app mode, but, depending on how the host processes audio in multithreaded mode and the type of routing you are doing, you may get one buffer of latency (which typically happens if doing feedback for example). But it is a tough problem to detect it (given that Connector can be used for any kind of routing), so it is currently not capable of reporting it.

Very simple routing, as described above. Connector as the first Fx insert on track A, sending the audio to another track B in App mode. It's a very easy problem to detect because I can hear a slight echo. I will add that Track A and Track B are the same audio, recorded through different microphones but in sync until I start using Connector. Maybe you meant something different, like it's tough to automatically detect inside Connector?

So if I add a single buffer worth of delay to the incoming track (without reporting to the DAW) before the Connector in Receive mode, you think this might add sufficient latency to solve the problem? I couldn't figure out how much latency to add or subtract, and fiddling was not getting me closer. Thank you.

[Blue Cat Audio]

In App mode the port number is just a reference to be able to connect two end point together (like in network ode (but it has no physical meaning). if you try to connect several sources to a single destination you will indeed end up with disconnection problems.

regarding the latency compensation, that's indeed what I meant: Connector cannot do it automatically. In your case 0 or 1 buffer length should indeed work (meaning the buffer length used by the app, provided that you do not have extra buffering in Connector).

I hope this clarifies!

[kidslow]

Hi Blue Cat, that did clarify things. Thank you. I think I found a different solution to the problem I was trying to solve.

Just to further clarify, in App mode there is a one to one mapping of source to destination? One single source to one single destination, right. Is that universally true? e.g. in network mode, can I have multiple sources feeding a single destination?

[Blue Cat Audio]

Yes it is always a one-to-one connection. It is the only way to reduce latency to its minimum and properly identify the source and destination.