Build aleph-serial -> OSC bridge in pure C

[ghost]

Building an aleph -> OSC bridge should be straightforward!

Can start with the C blackfin serial loader (and of course the code in ser.c, since the framing is symmetrical between host & aleph): https://github.com/rick-monster/aleph/blob/net-use-malloc/utils/serial-com-proto/module-hotswap.c

Reference these sections of the lisp code to see the up-to-date serial protocol:

Sending messages: https://github.com/rick-monster/aleph/blob/net-use-malloc/utils/serial-com-proto/test-harness.lisp#L108-L198

Receiving messages: https://github.com/rick-monster/aleph/blob/net-use-malloc/utils/serial-com-proto/test-harness.lisp#L300-L340

[catfact]

minor question looking in the serial message types enum, what's the difference between e.g. 'eSerialMsg_dumpOps' and 'eSerialMsg_opsDump' ?

i can't find any uses of the latter (yet), is it redundant?

... ah, nevermind. looks like e.g. dumpOps is for host->aleph, requesting a dump of operators, and opsDump is for aleph->host, saying "here's the dump you asked for" .. right?

makes sense

[ghost]

yeah - naming is possibly a bit bad! Few comments wouldn't go amiss there...

... ah, nevermind. looks like e.g. dumpOps is for host->aleph, requesting a dump of operators, and opsDump is for aleph->host, saying "here's the dump you asked for" .. right?

exactly!

[catfact]

started things on branch catfact/bees-remote in aleph/utiles/serial-com-proto/bees-remote

sending stuff seems to work fine (e.g. i can trigger params) but can't for the life of me get any bytes back. surely it is something stupid, will try again tomorrow...

[ghost]

I'll double check the lisp host driver works in duplex against current dev branch (most recent round of testing was send-only). Guess you're familiar with all the gotchas to do with opening a tty as 'raw' device? (i.e disable all the flow control)

This sounds trivial but it seems to bite me in the ass anew every time I do the raw serial song & dance on linux... (midi-over-serial, native lisp monome grid driver, aleph host protocol - I got caught out every time)

[catfact]

thanks! yeah i think i have it almost sorted now. the terminal stuff is fine but i had indeed made some other dumb mistakes. and i think for anything useful to happen it has to be multithreaded.

agreed, seems like binary over serial on linux is always more painful than one suspects.

[catfact]

i (force) pushed to catfact/bees-remote, it's pretty clean if you happen to feel like taking a look. almost there but somethings not quite right with duplex i/o - it hangs on read(), even with all the usual suspects - raw mode, also setting timeout, min bytes=0, etc... i may or may not bang on it some more late tonight.

[ghost]

and i think for anything useful to happen it has to be multithreaded.

This is how I handle things on lisp. I make extensive use of a concurrency device called CSP channel (somewhat like a thread-safe pipe for in-process data).

But think more idiomatic C to use polling file descriptors instead! So writes shouldnever block - no problem there. But for receiving back from aleph on commands that trigger a reply (i.e making the code transactional) you have to introduce some maximum time window the aleph is given in order to reply. If it doesn't respond within that time, the function returns an error. Polling the FD to check for aleph reply is done in a tight loop up to a certain max timeout after sending some command which expects a reply.

Still think adding ack/nack handshaking to the serial protocol would be not a bad idea...

it hangs on read()

I'll try sending a packet with serial op directly from the aleph, both on the supposedly working lisp driver & your new code...

[catfact]

probalby just have to set NONBLOCK or something http://www.linux-mag.com/id/308/

[ghost]

yea that looks similar enough to some alsa midi code I hacked on using FDs & nonblocking reads. Interestingly, although I occasionally wax lyrical about all the awesome features of common lisp (and how those awesome ideas from the 80s are still just catching on in mainstream programming) it's 'streams' (covering all filesystem interaction) just don't do nonblocking reads!

So multithreading becomes somewhat of a default when you have multiple file descriptors being used for IPC or device drivers, unless you hook into UNIX-ey C filedescriptors through an FFI... Yup, lisp also sucks (I'd still argue the least)!

[ghost]

ok so firstly - the lisp version (using multithreading) still seems to work on my machine.

secondly....

serial-com-proto/bees-remote [bees-remote●] » make gcc bees-serial.c port.c test-main.c -I../../../apps/bees/src/ -g -o bees-remote-test -lncurses -lpthread In file included from bees-serial.c:2:0: bees-serial.h:26:19: fatal error: types.h: No such file or directory

include "types.h"

               ^

compilation terminated. In file included from port.c:8:0: port.h:10:19: fatal error: types.h: No such file or directory

include "types.h"

               ^

compilation terminated. In file included from test-main.c:8:0: bees-serial.h:26:19: fatal error: types.h: No such file or directory

include "types.h"

               ^

compilation terminated. make: *\ [Makefile:22: bees-remote-test] Error 1 serial-com-proto/bees-remote [bees-remote●] »

[catfact]

oop. added

all the terminal stuff is working now, made prettier windows to see the bytes coming in. will flesh out the protocol parser next.

got distracted by the depressing ascension of the clown king over here

[ghost]

got distracted by the depressing ascension of the clown king over here

Maybe if we all close our eyes and say "I don't believe in trump" he'll disappear in a puff of orange smoke... The world's running out of other options we might as well try it!