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
Connecting to Serial Devices with SuperCollider
a month later
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!
@LFSaw are those quarks available?
a year later
a year later
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.
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..
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.
7 days later
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.
giuliomoro I wouldn't say large chunks.. but there is a non-trivial number of OSC messages going between sclang and sc-server ...
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 ?
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 I think that would be the best.
Actually I think I had something like that working done with @crosswick : see here
11 days later
- Edited
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
14 days later
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?
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.targetthen 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 serialoscUltimately, I just realised that the serialosc daemon used for the monome may already do all you need ... see here
giuliomoro perfect! thank you :-)
2 months later
@spencer that'll be interesting to see!
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. :-)