?

Log in

No account? Create an account
Finally succeeded in a bit of refactoring to the synth backend that… - Notes from a Medium-Sized Island [entries|archive|friends|userinfo]
Jason

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Dec. 27th, 2015|03:55 pm]
Jason
[Tags|, ]

Finally succeeded in a bit of refactoring to the synth backend that lets me dlopen in unit generators without restarting the program serving up audio. This recording is a bit of a regression in terms of filtering being missing, but I'm just using the goal of "get things to a point where I can post a recording on soundcloud" as a forcing function to keep me coding. This should be a step in the right direction. Soon should be able to try hooking up beepbox as a frontend.

Long ago I once had a similar architecture (i.e. javascript generates C, compiles it to a .so, and signals a server to dlopen-load it) working, but because the server was written in C, doing live communication with a js frontend (and also initialization of audio and midi libraries) was kind of a pain in the ass. Go may not be the holy grail of low-level programming languages, but it does at least give me (a) json parsing (b) http and websocket serving (c) nicely wrapped libraries for portaudio and portmidi, and (d) enough syntactic sugar for basic data structures like hashes that I don't want to stab myself implementing polyphony and sustain-pedal semantics.
LinkReply

Comments:
From: eub
2015-12-28 07:58 am (UTC)
Now is it JS generates Go and sends it to a Go server that loads it? Or is there still C in the mix?

I'm curious how Go does at DSP, performance-wise, compared roughly to C or to Javascript.
(Reply) (Thread)
[User Picture]From: jcreed
2015-12-28 05:00 pm (UTC)
No, still generating C, since I don't know of any way to dynamically load go, which seems to be entirely on purpose, in line with the general "just compile a static binary that has all the stuff" philosophy. The go-to-C FFI is pretty easy to use, though, so I'm just calling dlopen like normal from C. (and besides that there's already a call back into go (my loop iterating over the hashmap of currently active unit generators) from C (portaudio))

And as for performance, it seems like (for now, since I'm not doing anything terrifically complicated) passing across the FFI itself is dominating the inner loop. Even when I was doing the audio processing only in go, it seemed plenty speedy. Only took about 1-2 samples at 44.1kHz to render all the polyphony I could care for. So I would say it compares roughly to C.
(Reply) (Parent) (Thread)
From: eub
2016-01-02 10:04 am (UTC)
Neat trickery! Thanks.

Go has plentiful opinions, it does.
(Reply) (Parent) (Thread)