#1

I was thinking that maybe i should write a class that allows direct communication between SuperCollider and my Monome using SerialPort, bypassing serialosc. Am i right in thinking that this would be a little bit more efficient and faster? Is it worth it? Or maybe someone already did it?
The reason i’m thinking along these lines is that i’ve had some issues with serialosc when using my Monome together with a Manta and a custom built Arduino controller at the same time.

Any thoughts about this?

#2

the newest serialosc fixes the FTDI clash problem with arduinome/etc.

i’d highly suggest simply getting the update. we’ve put a lot of work into simplifying serial communication, which is much more difficult to do direct.

#3

Ok. Sounds reasonable to me. Thanks for the update! Looks promising.
But just out of curiosity, if one did this, would there be a noticeable difference in speed?

#4

There’s really no speed bottleneck in the serialosc process. I’ve built a number of applications that update the whole led grid (8x16) at 60fps with no lag or other issues. The most important thing in terms of speed / refresh rate is using the led macro commands (eg /led/map) rather than updating individual leds.

The communication of button presses has incredibly low latency, the majority of which is in the USB driver handler i believe, so direct serial comm’s won’t improve it there.

Much better to focus efforts on the software ideas!

1 Like
#5

i would actually be quite surprised if you could match serialosc’s performance, let alone surpass it. if that sounds like a challenge, i encourage you to interpret it as one, because writing my own implementations for the monome serial protocols is what sent me down the path of low-level software in the first place :wink:

in all seriousness, though. it’s definitely possible to overwhelm serialosc with OSC messages, but it’s not serialosc itself that gets bogged down. it’s the write buffer on the serial device that gets backed up, and then serialosc starts dropping OSC messages to compensate. it’s easy to reproduce, too: the libmonome example programs all read/write from the serial device directly, and the conway’s game of life app will overwhelm the serial device easily.

the bottleneck i think you’d run into in supercollider is the assembly of the raw serial messages themselves. because interpreted languages usually aren’t super fast at string operations, and serialosc avoids this by using fixed-size buffers for serial i/o. in fact, the serial protocol code doesn’t allocate any memory at all.

but, again, if you’re curious, don’t let me discourage you. low-level coding can be tons of fun :slight_smile:

1 Like
#6

Hehe. Point taken. :sunglasses:
But, really, thanks for sharing your knowledge . It’s a great answer to my initial question of whether it would be worth it or not. :wink:

#7

i don’t know why this old topic just popped up, but i was looking at SerialPort and string building perofmrance, so…

for what it’s worth:

  • Strings in SuperCollider are raw character arrays. they are fast unless you are constantly reallocating and garbage colelcting them. so use .format to build them:
// 10000 pairs of random integers formatted as strings
~values = Array.fill(10000, { [1024.rand, 1024.rand] });
{
	~strings = ~values.collect({|v| "set % %".format(v[0], v[1]) });
}.bench;

// time to run: 0.042151639998337 seconds.

(i’m too lazy to benchmark the equivalent C code: exercise for reader.)

if you build strings in some other way, like adding one character at a time, it could get hella slow because you are really allocating new strings and having the GC pick up after you.

and anyways, you don’t striclty need to build strings at all; you can use pre-allocated raw bytes just like serialosc does, and send them straight to SerialPort.

but i agree with the other answers that it doesn’t seem particularly fruitful to rebuild serialosc in supercollider. IMHO it will be comparable in speed (string handling will be a little slower; OTOH it doesn’t have to go through a UDP port or whatever.) if you particularly want your SC app to be totally self-contained, and also want to learn the monome serial protocol really well, and generally want to learn how to do low-level things efficiently in SC, then it could be a fun exercise.

1 Like