Have you guys decided what to write the audio code in? C++/Faust/PD?
I’ve been having fun with Axoloti, Reaktor and Max in the past.
But I’m not decide with Bela which way to go…
Im a C++ developer by trade, but I’m not sure what suitable c++ ‘object libraries’ are around for things like oscillators, filters etc. also perhaps this is not the best way to build patches etc.
PD - after using Max, it just felt ‘unfinished’, and not too inviting as an option (though perhaps i need to give it a better run!) , but frankly I think Id quite like to use a text based language.
Prior to Bela Id started looking at things like SonicPI, extempore… or possibly supercollider, hard to know which was to jump so many choices, Id stumbled on Faust, but not really done much research on it.
my basic goal is to use something which has a reasonable set of objects to experiment with, that is efficient, and that i can link to my controllers and also diy hardware via the digital and analogue io of bela/
Surprisingly I’ve not seen much discussion on the bela forum on this side, over and above PD.
I have similar thoughts but no conclusions. Need to do some exploratory coding.
Right now I guess I’d rank my interest level like this:
While acknowledging that thanks to organelle and other devices embedding Pd there is a growing body of prior art from that world.
ok apologies to hijack the bela thread when I’ve no intention of jumping on that particular bandwagon but loving the DSP chatter in here…
Faust is definitely hitting the spot for me, and fairly heavy DSP prototyping going on here at work. I was also fiddling with extempore - promising but the setup/compile is horribly fiddly, compile times are very slow and the whole thing felt a little shaky somehow. The interactive coding in extempore is ok, but it somehow felt light years behind common lisp. Emacs/slime probably just ruins you for any more spartan dev environment!
A colleague pointed this out to me the other day https://github.com/carp-lang/Carp haven’t played around with it, maybe interesting/useful.
And I tried many things to make common lisp useable for dsp prototyping (e.g https://github.com/rick-monster/cl-jack) but end of the day it’s always going to gc unpredictably and blow up in your face at lower latencies… There’s always incudine, though it squawks & belches fire as you recompile your dsp on the fly (because sbcl gcs like hell when you compile anything). Oh and you don’t really get to code in a garbage-collected lispy language but in a non-consing subset (as I understand it - hopefully not talking crap here). Didn’t get on so well with it though, either.
Faust seems rock-solid, very fast & I almost prefer prefer functional coding to sample-by-sample processing with let-over-lambda. The function combination algebra ( : , <: :> ~ operators) & partial function application syntax are just awesomely powerful features for trying out DSP ideas & hacking together more intensely complex ‘circuits’ using code.
Plus you can ‘debug’ the program by looking at a block diagram of your code. Faust is basically super fun I love it…
I will keep looking but initial search for c++ DSP library led me here:
And from the Pd side of the world:
Exploring Bela more deeply is going to get pushed down a level on my stack of things to do but in terms of how I was envisioning attacking the DSP bits it was:
- then possibly attempting to port sporth and soundpipe
…there is evidence that people have supercollider running on it to some degree but it seems like that would be too heavy an environment to use in the long run.
It’s pretty reasonable to; MIDI is a dumb-as-a-sack-of-hammers protocol.
MIDI out from a digital pin just requires a resistor; it’s only MIDI inputs that need to be opto-isolated. So if there’s not a MIDI library available but you’ve got access to digital pins, you can almost certainly implement MIDI output.
EDIT: it looks to me like bela does expose the same UART pins I’m using
can confirm from an experiment hooking up midi to one of the dedicated uart pins is trivial when you know how. As @infovore says, just a couple of resistors & the right kind of optocoupler - trivial to put on a piece of protoboard…
bbb hardware & kernel handle buffering, then you can hand-roll a sack-of-hammers midi-packetiser/de-packetiser in userspace via classic unix file-as-device (fun). The only ‘magic’ is setting the weird midi baud rate on the raw file handle, and I know the spells - happy to post the ~50 lines of C here but need to dig it off the beaglebone at home first. Oh, and you have to cat some secret words to another special super-magic file to tell beaglebone kernel you want to use the UART feature on that particular i/o.
Don’t know whether there are extra complications following this recipe with xenomai.
This thread gives me the impression that nothing special is happening with MIDI as a result of xenomai.
Indeed it’s just reading /dev/midi1 ( and in dev is now
configurable) , so you wouldn’t need to write a parser etc. should be noted it does this in a separate thread , I think to ensure the audio thread doesn’t lose it’s real time status.
important to note that doing midi using bbb uart is subtley different & a little trickier than with a usb midi dongle, but once the file-descriptor is correctly tweaked you’re good to go, then it’s the same! Of course if you’re using usb midi & writing in C/C++ anyway, might as well hook into alsa sequencer to handle raw midi, rather than rolling your own…
urgh. yeah, the timing horridness was not a thing I was thinking of - I was hoping there’d be some kind of UART serial or something. I am not super-knowledgeable here, but given the crappy microcontrollers I’ve blasted MIDI out of, it felt likely.
I re-read the pinout for bela & edited my original reply to your post. BBB does have dedicated UART pins like any self-respecting microcontroller and don’t see any reason the same couple of uart->midi hacks I use on ‘bare’ BBB won’t work on top of bela.
Circuits & code to follow for a multi-midi setup without multiple usb-midi dongles hanging off a hub flapping in the wind without any obvious way to tell which is which…
umm yea no circuits or code drawn up yet, and be warned this is gonna be a little off-topic. But since it’s all dimly beaglebone black related I figure why not sound off in here. At some point in the not-too-distant a useable open source performance sequencer should emerge that runs on bbb and talks monome (probably powered by lisp)…
have been monkeying a bit with libmonome, wrote some bindings and now have my monome grid hooked up to common lisp inside linux. Need to have a little rethink how I’ll represent the different types of event flowing in/out of the whole system:
- boomerang sysex
- monome buttons 'n lights
- aleph bees bangs
- midi packets
- buttons 'n lights hooked straight up to bbb i/o
- sequencer control events
I can feel the latenight coding fever coming on!!! (not tonight, mind…)
Finally ready to start moving sguenz software over to beaglebone - hurrah! (actually software is still a dogs dinner, but what the heck) So I had to hack a bit more on the output driver - some midi devices may not have the proper optocoupler input, so it’s not possible to use the BBB 3V outputs if input is actually 5V logic. Pretty sure this is the case with mfb522, as the 2-transistor output driver works with that device, where using the bbb output pins directly fails…
planning to start a tech blog with better instructions to deploy my lisp BBB controller framework eventually. But for now:
also, on arch linux for BBB I add the following string to /boot/uEnv.txt:
then I also have to perform this UNIX incantation to enable the 2 UARTs on pins 21, 22, 24 & 26 of P9:
echo BB-UART2 > /sys/devices/platform/bone_capemgr/slots
echo BB-UART1 > /sys/devices/platform/bone_capemgr/slots
The next eye-of-newt is:
sudo stty -F /dev/ttyS1 115200 sane -brkint -icrnl -opost -onlcr -isig -icanon -iexten -echo -echoe
sudo stty -F /dev/ttyS2 115200 sane -brkint -icrnl -opost -onlcr -isig -icanon -iexten -echo -echoe
then finally to write a midi packet to one or other of those devices on loop you can hack on this a bit:
Bela are now ‘generally’ available, well for pre-order (December shipping)
(you can also order the audio and io expanders there too)
also they’ve also got an updated firmware (0.2.0), many improvements, but one I like alot is they have added supercollider support ‘out of the box’ , this includes not only low latency audio support but also digital and analogue io.
Hi all (especially @rick_monster)
I saw that you got your monome grid working on bela a while ago… I’m having difficulty getting everything installed
I got libmonome and serialosc compiled and installed (i think- followed the guide), but kindof stuck here as I can’t start running serialosc? it says command doesn’t exist.
I also suspect there’s something strange about the usb hotplugging on the bela currently. I have a powered hub with the monome going in… it flashes lights as if initializing but lsusb never detects anything new?
Also Bela’s suggested USB device detection method of powering on with the monome plugged in results in the bela hanging and never initializing. Maybe it’s trying to boot off of whatever is connected through USB? Unsure
Anyways, whatever help you can give to getting this running would be very appreciated. I just want to have fun controlling libpd from my grid, the Bela IDE makes it so easy to get sound coming out.