Bela (embedded music-centric hardware)

#1

Pretty exciting stuff:

Just wish there was an easier way to get Max-ish code on to it (other than gen-code exporting?).

11 Likes
DIY Project Recommendations
Reconfigurable sound synthesis HW
Kinda Frustrated with Apps? Anyone else?
Axoloti Core
#2

This looks pretty cool. I’m tempted to get one.

1 Like
#3

Looks like they are thinking mainly about Pd support.

There are some resources for converting max files to Pd here, but I’m guessing they probably don’t always work. https://puredata.info/docs/tutorials/PdForMaxUsers

I wonder what its power requirements are and what potential for eurorack packaging there may be.

#4

Yeah, touting Pd pretty strongly with code conversion.

Unfortunately for all the kind of Max-ing I do, it’s pretty heavy lifting (non-convertable to Pd).

It’s great to see something that’s focused on music specifically though, with built in audio/analog/digital I/O (even onboard powered speaker outputs!).

#5

looks like the pd->C code conversion itself is not open-source? Kind of tempted to order a cape to play around with, though also kind of unhappy if some of the money goes to a company piggybacking off free software & not releasing their source code…

#6

I wonder what its power requirements are and what potential for eurorack packaging there may be.

The beaglebone black runs on 5V and 2amps is recommended minimum when using capes -
according to ModMyPi. I couldn’t find the power specs on the official site but didn’t look too hard either.

#7

Welp, I ordered one. I generally avoid Kickstarters, but this one just hit too many “ooh” buttons for me.

#8

Hello,
I have been to one hacklab this summer at the Queen Mary Uni in London and I bought one of the earlier production cape, now sittign in my DIY elettronic box.
Unfortunately I have not been able to buy a beaglebone black to try it as it seems out of stock everywhere to buy for UK.

Regarding modular, I remember one of the participant at the hacklab presented a project for a Eurorack module.

#9

one question:
do you think we can load monome patches into it?

#10

That’s the question really. I would guess, at the moment, probably yes, but with difficulty. Much in the same way that you can load “monome” patches onto an Aleph. (not Max patches)

#11

thanks Rodrigo.
I assume that as PD vanilla do not have osc communications, we might not be able to use it…but you never know.

I shall find a beaglebone black.
Do you know where I can buy in UK?
Street retailers I guess as the distributors are all out of stock.

#12

I’m not seeing udpsend and udpreceive unfortunately. They are part of the mrpeach externals for Pd, so not part of vanilla.
https://enzienaudio.com/docs/pdobjects.html

#13

Crazy question: how hard/possible would it be to write alternative firmware for the monome grid? Been wondering a bit lately if OSC is really ideal for this kind of thing…

(so many situations where I wish USB MIDI was something monome could do)

1 Like
#14

Wow, amazing stuff, thanks for sharing !

#15

I’ve been thinking about how to get monome grid talking to common lisp on my beaglebone & came to conclusion that osc is the wrong glue for embedded device running a single application & better to address the serial port directly using ffi to a C library.

I checked out libmonome it seems to work but couldn’t get it to do varibright. Can’t be hard to add that feature to libmonome. Similarly never wrote a pd external myself but sounds like a libmonome external for pd would not be difficult…

EDIT also would like a pd external for bees - most of the code is there on aleph side (also working on serial callbacks from bees outs right now)

1 Like
#16

You could also try sticking an Arduino that has host and device USB ports in between the Monome and a computer to translate for you (or even run a simple app)

#17

Hmm I wonder will the proprietrary pd->C compiler even allow you to use ‘unsupported’ externals like native monome serial support or link with aleph? I’d guess not - they specifically say on the site ‘make sure you are not using any unsupported objects’.

Given that they got an EPSRC grant for “Hackable Instruments” making vanilla pd itself totally unhackable is pretty crass. But still intrigued by the Xenomai/coprocessor implementation - dang I’m so torn…

#18

I asked the Bela folks about UDP support and this was the response:

Hi Jason,
We may add support for UDP in the future, either using Pd Vanilla’s netsend/netreceive objects or using bespoke receive/send symbols (which is how we currently handle MIDI). In the meantime UDP networking is possible with Heavy by writing a custom C++ wrapper that interfaces with the compiled patch.
Thanks,
Chris from the Bela team

This sounds like a promising direction to investigate.

I agree that Enzein Audio’s repositories seem… incomplete.

1 Like
#19

He’s not going to release source any time soon:

http://lists.puredata.info/pipermail/pd-list/2014-03/106287.html

Heavy audio is obviously a Queen Mary’s spin-off so I would be digging around to find out how open is the rest of their stack before parting with my seventy quid. However since the hardware designers probably are heavy audio I potentially don’t see an issue supporting their organisation. I’ve been fretting over non-existance of this piece of hardware for years - only last friday I was sitting around poking an i2s bus into my beaglebone (& failing to hook it into alsa)…

We as a community could try to loudly & publicly boycott the non-free parts of their software toolchain to at least try to shame them into releasing source. There’s also this:

but, according to the author, “This is totally half-baked test code, if you couldn’t tell…” By the way anyone know the capabilities of libpd? I guess libpd allows dynamic loading, whereas the heavy-audio software statically compiles everything much as we were talking about for bees on modular firmware…

1 Like
#20

I’ll definitely be interested in exploring alternatives to Heavy once I get the board.