can't export to Raspberry Pi
After some succeful exports of a RNBO patch to a Raspberry Pi I now get this message during export:
Back in the target list under "Devices" where previously I could select the Raspberry Pi as a target device there is now "No devices connected". But the Rapsberry Pi is connected via cat6 cable to my PC and is still accessible via SSH.
It seems like, this behaviour started after I was adjusting the buffersize of the PiSound from 256 samples down to 32 samples. When I tryied to export with 32 samples I got this error:
After that I tried setting it back to 256 samples but always get the first mentioned message
It's working for now after flashing the micro SD again. But I don't dare to change the buffer size, which is a bummer.
JOHANN, I'm curious, what version of the runner/RNBO are you using?
RNBO is 1.2.6, Runner RNBO Version also 1.2.6
It's a RPi 4b with a Pisound. Also ran Update/Upgrade via SSH
dang, well... we are releasing RNBO 1.3 very soon, it will require a new image download, hopefully this is resolved there.. let us know if you continue to see that once you upgrade.
Hi . .
I am having this same problem using RNBO 1.3.2. I suddenly can not transfer anything new to a Raspberry Pi 5. I get the "Loading config" error as mentioned at the top of this thread and as shown below. When that error shows the current patch on the Pi stops playing for a bit and then it restarts. After the message below shows for about 5 seconds, the target window appears like it might be working but hangs forever on Sending Config.
The runner and rnbo version are the same. I can open the web interface for the one patch that is running on the Pi. When I try to unload the instance it looses connection and the patch starts again.
Can you share the patch that you last sent before you saw this issue?
Do you happen to be doing OSC mapping?
Hi Alex . .
I actually don't remember. However, I did ssh in to the Pi and deleted everything in the /Documents/rnbo/cache/so and /Documents/rnbo/cache/src folders. I then rebooted and could send patches again. ??
I am mapping OSC messages to parameters via hardware connected to the Pi and a series of python scripts and systemd service. Is there anything OSC related i should be aware of that might be causing the previous issue? The parameters in the patch are using the @meta option.
for now it is working again and i should report that this is the first compiling / transferring issue i have encountered. it seemed out of nowhere. anyway, I'll try and keep track of what patch is last loaded in case it acts up.
Thanks!
Cheers,
Clay
Yeah so RE OSC.. avoid mapping into the /rnbo/ namespace,
if you want to connect params, inports, outports together, use some other prefix on both ends.. something like /rnboparam/ should be fine.
basically, you could do [inport /rnboparam/foo] and [outport /rnboparam/foo] and [param foo @meta osc:'/rnboparam/foo']
Hi all,
Alex, can you elaborate on the OSC issues and the namespace? I'm working on something for an installation that basically involves playing audio files on a rpi4 and I had many strange behaviours. Right now it works, but I swear I saw something like the above error at some point, and I had trouble with OSC in general.
In RNBO 1.3.x we added the ability to map inport, outport and param objects to OSC in the runner via metadata. We didn't protect against mapping those objects to the internals of the runner's OSC namespace, things like /rnbo/inst/control/load and /rnbo/inst/0/params/foo but it looks like mapping to those sometimes cause odd behavior, which I have a bug ticket for.. the result of which might be to simply disallow those mappings.
In the mean time, instead of mapping something like [outport /rnbo/inst/0/params/foo] to control param "foo" with an outport value, I recommend you do something like [outport /myparam/foo] and then on the param you want to control [param foo @meta osc:'/myparam/foo']
where "/myparam/" is the namespace I'm talking about, could be "/rnboparam/".. just something other than plain "/rnbo/".
It takes a little bit more metadata work on your end but one benefit of this is that you're no longer tied to the instance index "0" for param foo.. so you don't have to be careful about how you set up your graph in that regard.