Pretty exciting stuff:
Just wish there was an easier way to get Max-ish code on to it (other than gen-code exporting?).
Pretty exciting stuff:
Just wish there was an easier way to get Max-ish code on to it (other than gen-code exporting?).
This looks pretty cool. Iām tempted to get one.
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.
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!).
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ā¦
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.
Welp, I ordered one. I generally avoid Kickstarters, but this one just hit too many āoohā buttons for me.
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.
one question:
do you think we can load monome patches into it?
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)
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.
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
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)
Wow, amazing stuff, thanks for sharing !
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)
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)
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ā¦
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.
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ā¦
Iāll definitely be interested in exploring alternatives to Heavy once I get the board.