Carla icon indicating copy to clipboard operation
Carla copied to clipboard

Carla control does not work when hosted on raspberry pi?

Open 0xFEEDC0DE64 opened this issue 3 years ago • 1 comments

I am running carla with a static patch configuration on a raspberry pi to sample audio and do some frequency filtering and output to two separate amplifiers for bass and treble.

carla is running on a raspberry pi 3 (aarch64; archlinux),

and I try to connect with carla control on my laptop (amd64; archlinux).

When connecting the first time I can at least see the racks but no patchset, and I cannot change any parameters.

When I reconnect I cannot even connect, and carla on the pi shows this log output:

[carla] CarlaEngineOsc::sendCallback(5:ENGINE_CALLBACK_PARAMETER_VALUE_CHANGED, 1, -4, 0, 0, 0,200867, "(null)")
[carla] CarlaEngineOsc::sendCallback(5:ENGINE_CALLBACK_PARAMETER_VALUE_CHANGED, 1, -4, 0, 0, 0,248321, "(null)")
[carla] CarlaEngineOsc::sendCallback(5:ENGINE_CALLBACK_PARAMETER_VALUE_CHANGED, 1, -4, 0, 0, 0,254800, "(null)")
[carla] CarlaEngineOsc::sendCallback(5:ENGINE_CALLBACK_PARAMETER_VALUE_CHANGED, 1, -4, 0, 0, 0,264139, "(null)")
[carla] CarlaEngineOsc::sendCallback(5:ENGINE_CALLBACK_PARAMETER_VALUE_CHANGED, 1, -4, 0, 0, 0,254800, "(null)")
[carla] CarlaEngineOsc::sendCallback(5:ENGINE_CALLBACK_PARAMETER_VALUE_CHANGED, 1, -4, 0, 0, 0,188670, "(null)")
[carla] OSC backend already registered to 192.168.1.163
[carla] OSC backend already registered to 192.168.1.163
[carla] OSC backend unregister failed, current owner 192.168.1.163 does not match requested osc.tcp://ruezn:15915/ctrl
[carla] OSC backend already registered to 192.168.1.163
[carla] OSC backend unregister failed, current owner 192.168.1.163 does not match requested osc.udp://ruezn:17418/ctrl
[carla] OSC backend already registered to 192.168.1.163
[carla] OSC backend already registered to 192.168.1.163
[carla] OSC backend unregister failed, current owner 192.168.1.163 does not match requested osc.tcp://ruezn:19315/ctrl
[carla] OSC backend unregister failed, current owner 192.168.1.163 does not match requested osc.udp://ruezn:13453/ctrl
[carla] OSC backend already registered to 192.168.1.163

The IP mentioned in the log is the IP of my laptop (ruezn is the hostname), what is going wrong here? Audio is processed fine, I just want to have control over the parameters

0xFEEDC0DE64 avatar Jun 21 '22 13:06 0xFEEDC0DE64

I would like to add myself to the list of users bugged by this. I want to keep a Carla instance running in the background, only opening the GUI whenever needed. After some experimenting, I inferred that I need to connect to a running instance like this:

carla-control 'osc.udp://127.0.0.1:22752/ctrl'

(By the way, is there a manual explaining it? carla-control --help merely states that a URL is needed, but it never explains what it should look like.)

I can do this at most once. After terminating the carla-control process and running it again, the interesting part of the log output produced by the background carla process reads:

[carla] OSC UDP backend registered to osc.udp://mylocalhostnamehere:16406/ctrl, path: /ctrl, target: osc.udp://127.0.0.1:16406/ (host: 127.0.0.1, port: 16406)
[carla] OSC backend unregister failed, current owner 127.0.0.1 does not match requested osc.tcp://mylocalhostnamehere:12724/ctrl
[carla] OSC backend unregister failed, current owner 127.0.0.1 does not match requested osc.udp://mylocalhostnamehere:16406/ctrl
[carla] OSC backend already registered to 127.0.0.1
[carla] OSC backend already registered to 127.0.0.1

And the interesting part of the carla-control process reads:

ControlServerUDP::fallback("/ctrl/exit-error") - unknown message, args = ['OSC already registered to another client']

Also, the GUI opened by carla-control looks as if it has been openend without any arguments, with no indication that it does not work as intended. (This is different from when you try to connect to a closed port, in which case it will show an error message.)

If I were to make a guess, carla and/or carla-control confuse themselves and/or each other by resolving and/or reverse-resolving IPs and hostnames, instead of just using the the names and/or IPs as given.

bergfried avatar May 22 '23 17:05 bergfried