Connecting to Serial Devices with SuperCollider

jonathan

Dear Bela team & Community,

I'm just curious if anyone has had any success connecting devices to the Bela using the built-in UARTs on the BeagleBoneBlack - and accessing them via SuperCollider?

I've got a little external sensor device with an Arduino (pro mini) at its core. I want to have this device send data to the Bela and intercept this data in sclang to trigger some synths. Normally SuperCollider has the SerialPort class to handle this kind of thing - but I've never used it on the Bela.

Right now I'm waiting for a 3.3V Arduino Pro Mini to arrive to begin testing (rather than try level-converting a 5V board) --- but it would be great to hear any success or failure stories from the community.

best wishes,

Jonathan

rytrose

giuliomoro / jonathan have either of you ran this successfully? Till's post says it relies on a class extension CapSerial that he "will make available soon via the SuperCollider Quarks system" (in 2016), but nothing of that name exists as a Quark. Thanks for any info!

giuliomoro

There is a tutorial by Till Boverman about Serial in supercollider on Bela, see if this helps:
http://tai-studio.org/2016/08/12/bela-capsense.html

jonathan

rytrose I got something working without CapSerial ~~~ will post my results soon!

giuliomoro

@LFSaw are those quarks available?

spencer

jonathan Did you get something working? Do you have an example? Please share!

Also to @giuliomoro, if the quarks are floating out there for CapSerial would be helpful.

jonathan

spencer yes! I've successfully gotten serial data going into SuperCollider via the built-in UARTS. Although I have to say that reading serial data in and out in this way (using sclang's SerialPort class) is buggy and seems to be causing audio glitches at times. I'm not really sure why this is... maybe @giuliomoro has some hunches?

More recently I was able to develop an I2C UGen to support Trill sensors. This has been much less error-prone than doing serial communication via SC lang. My hunch is that for most cases this is the approach to take... (i.e. building a UGen that does the specific low-level sensor communication via serial or I2C and packages it up into a nice format on the server) .... and my hunch as to why is that everything on Bela is based on the audio thread having high priority, and so having a process that is not being supervised by the audio thread (sclang) launching low-level system calls causes issues..

Another possible approach, that I have not yet tried, is to have a stand-alone C++ program that handles serial communications and pipes it into sclang via OSC. This would provide at least a less arduous approach than writing low-level UGens..

giuliomoro

jonathan Although I have to say that reading serial data in and out in this way (using sclang's SerialPort class) is buggy and seems to be causing audio glitches at times.

Anything you do on sclang shouldn't cause any audio glitches on the server. Is it possible that you may be sending large chunks of data to the server? I see how parsing a long message on the server could cause a glitch.

argl

jonathan That is very interesting to hear, do you plan to open the I2C UGen? Does it work bi-directional, so that we could control tiny displays from SC? I gather that having it inside scsynth as a UGen, not in sclang (like the serial stuff) is probably a bit awkward w.r.t. string processing for a display. For things like Trill, a UGen is certainly perfect.

Other that that, I have used the UART with the plain serial class in sclang without much problems, interfacing with an arduino keyboard/display combination. Looking at the code, I used /dev/ttyS4, but I probably had to enable it via a dtb overlay first.

spencer

jonathan

We ended up using CAN bus to get thing working, with input messages to supercollider. When we get a chance, we'll share code and methods for folks to use.

jonathan

giuliomoro I wouldn't say large chunks.. but there is a non-trivial number of OSC messages going between sclang and sc-server ...

jonathan

argl My trill ugens are public: here https://github.com/jreus/Trill_SC
I think for the screen you would ideally make a little C++ utility that connects to the screen and pipes OSC to sclang.. what do you think @giuliomoro ?

giuliomoro

jonathan I think for the screen you would ideally make a little C++ utility that connects to the screen and pipes OSC to sclang.. what do you think @giuliomoro ?

I think that would be the best. I have done something like that for Trill that can work as a general template see here

jonathan My trill ugens are public: here https://github.com/jreus/Trill_SC

You will need my Pull Request for it to work with the released Trill!

giuliomoro

giuliomoro I think that would be the best.

Actually I think I had something like that working done with @crosswick : see here

jonathan

Hey all
I've been making some progress building a stand-alone serial utility on the Bela that converts incoming serial data to OSC (see code here)

I would like this little utility to run when the Bela boots up, and to have it quit when the halt switch on the Bela is triggered. Just curious... giuliomoro ...do you have any best practice way of accomplishing this?

spencer

Just following up now. This is helpful, thanks guys! I'll post some code examples that utilize either or both approaches later this week/early next. I2C might be outside our application space, but I'll talk to the UX/UI team.
@giuliomoro @jonathan

giuliomoro

you'll need a systemd service.

Create a file following this template in /lib/systemd/system/serialosc.service:

[Unit]
Description=serialosc daemon
[Service]
Type=simple
ExecStart=/usr/local/bin/serialoscd
PIDFile=/var/run/serialoscd.pid
RemainAfterExit=no
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target

then edit the ExecStart line to match your executable file path.

Then execute
- to start the service:

systemctl start serialosc

- to stop the service:

systemctl stop serialosc

- to look at the output:

journalctl -fu serialosc

- to enable it at startup

systemctl enable serialosc

- to disable it at startup

systemctl disable serialosc

Ultimately, I just realised that the serialosc daemon used for the monome may already do all you need ... see here

jonathan

giuliomoro perfect! thank you :-)

jonathan

giuliomoro interestingly enough, I accidentally found a more elegant way of launching the serial2osc utility with SuperCollider. I now launch the script from SClang when the SC patch loads using unixCmd.

~spid = "/root/BelaUtils/serial2osc --port /dev/ttyS5 --baud 115200 --remote localhost:57120".unixCmd({|ec, pid| postln("serial2osc (pid %) exited with code %".format(pid, ec)) }, true);

Magically, when SC crashes or quits.. so does the serial2osc script. :-)

jonathan

spencer ooh, super cool! I'm very curious to see this as well :-)

giuliomoro

@spencer that'll be interesting to see!