Would it be possible to have the monome on eurorack work with a dynamic scripting language? I understand that one can develop new code via binary embedded dev kits, but it would be amazing to just be able to write in a higher level script language and that be loaded. There are so many possibilities on eurorack for the monome to be the control surface, but it’s not easily to develop for. For example the QuBit Nebulae runs CSound and Pure Data.
I feel like making it simpler to code your own interface on let’s say the White Whale using a scripting language would be amazing. I’d pay good money for that feature.
The monome 128 is a thing of beauty, it’s build quality, simplicity and everything about it are genius.
The QuBit Nebulae is, to be fair, an actual computer inside a rack module. The Raspberry Pi inside is crazy powerful compared to the microcontrollers inside the trilogy modules, and runs CSound and PD because it’s actually running Linux, first of all. And there’s an immediacy that might be lost when you make something that feels like ‘an instrument’ be more like ‘a comptuer’ internally: that module actually takes time to boot up (though I believe they’ve worked hard at minimising it).
The microcontrollers in the trilogy modules and the Teletype aren’t powerful enough to run an OS layer, really: they need to be coded against the metal. So you can’t run a high-level interpreter on them.
It might be possible to write code to generate appropriate C from higher-level code, on the computer side, before flashing it, but that’s not exactly simple either.
This is basically the hard thing about microcontrollers; they’re pretty powerful, especially the high-end Arm stuff (an M4 with floating point does all manner of impressive things in many modules out there right now) but there’s no easy way to simplify the work of getting code on there - unless somebody else does a lot of work first.
I forget if the Nebulae can be a USB host, now you mention it.
There were rumblings about an aleph forth interpreter at one point I guess that is still in the pipeline. Meanwhile I’m trying to overhaul BEES somewhat in order to clean things up & achieve some features we can’t currently support. An idea was floating round for a framework to statically compile small bees nets as standalone modular apps. Not fundamentally hard but needs someone to want it enough to write the necessary glue code I guess.
So yeah we have some interesting stuff on the go but work still ongoing to bring aleph & modular codebases close enough together for both sides to start seeing benefits…
i hate to make promises and tease new projects-- but i’ve been putting a lot of work into precisely this goal. circuits ordered, etc.
teletype represents a basic scripting solution for cv, triggers, and data-- but the grid requires something more sophisticated-- MP/WW/ES have a lot of code, but this can be abstracted in ways to make for manageable flexibility-- a combination of usability design and technical solutions.
in the meantime, the existing modules are pretty configurable with II commands. i’m open for ideas to extend the II command set.
that sounds excellent, tehn. I wasn’t presuming to say it’d never happen - just trying to illustrate that the fact only C tends to be used to code for microcontrollers isn’t because some cabal is trying to keep high-level programmers out!
As a fairly neophyte C coder (but very experienced high-level language programmer), this sounds like a wonderful idea. Greatly looking forward to see where you end up.
for these https://en.wikibooks.org/wiki/Mizar32
…and remembered this thread
can’t be much work to get picolisp running on aleph/eurorack - think they’re targetting the same cpu (just did a build for AT32UC3A0512 that’s the one right?).
Bees refactoring is getting a bit brutal and I’m somewhat worried:
A. that my attempt to refactor will become a complete rewrite (how will I ever get time to just get everything back to where it was after ‘fixing’ the things that seemed wrong to me)
B. that I will want more and more repl-style support for bees to make patching more like coding
C. that my attempts at smarter memory management will come unstuck
Going to down tools for a while from bees refactor to fiddle around with @zebra’s forth build and picolisp. Curiosity killed the cat but think I need to look around at some other ways to skin this particular kitty. At worst I can go back to improving BEES having silenced the voice saying ‘there has to be a better way’…
It’s no fun when each improvement you make results in another 5 changes needing to be made. I’ve had refactorings like that before. It’s especially depressing when the smallest atomic change you can make is larger in scope than you can comfortably fit in your brain.
I will say that even if it doesn’t come of, you’ll have learned an awful lot about how bees works, and hopefully that knowledge will be very useful.
hmm I’m more and more curious about picolisp - just finished another bit of horrendous refactoring at work (common lisp code to address a truly awful spaghetti-problem in a horribly mangled 30-year-old mudball). The relative ease of doing this has made my mind up - I have to at least try and get a lisp REPL on the aleph - my brain seems to work much better slinging parentheses & there’s a long weekend coming up…
So @zebra, @tehn what is the danger of flashing some random .hex file I have built from the hempl repository? (using avr32-objcopy to convert from the .elf). Remember reading somewhere that you guys went to great pains to ensure that it wasn’t possible to overwrite the bootloader with dodgy firmware? Does that come with the caveat that the hex is built against avr32lib? Only question to my mind is whether any difference the way usb UART is hooked up on the mizar32 boards compared to aleph. Well picolisp is like 5 .c files so maybe the easiest way is try to figure out how to hook it straight into avr32_lib…
Well I guess worst that happens is I have to get the jtagice programmer to get things back to working (which I should get anyway if I decide to finish the job on bees refactor).
sounds awesome, i would be very curious to know about runtime performance. i’m a little skeptical about that aspect. peter blasser’s shlisp is very cool because it compiles down to ASM opcodes…
(similar concerns about eLua - i’m sure we could get it running but not sure there would be headroom left to do many useful things.)
definitely gonna get the forth interpreter running on aleph and TT, one of these days (actually soon, i hope.) this isn’t exactly a ‘high-level’ environment but it is interpreted, mutable, and reflective. it would be a good tool for rolling your own scripting languages.
i totally understand not feeling like fixing bees because a more expressive coding environment seems more useful. the point of something like bees is to have an expressive environment for people who don’t want to code but do want to define their own instrument logic. of course there are other ways to acheive this but it would be a shame to totally lose sight of that goal.
haven’t given up on bees but need to beat a tactical retreat on the big changes - I’ve got
stale on the refactoring it needs attacking from a fresh running start. The build is fixed for beekeep & bees after rewriting most of net.c based around a central data structure that doesn’t repeat itself. That cleans things up a bit but fallout from that change is huge:
only four operators currently in the build - still need to run elisp refactor script over the rest and cross fingers
I don’t understand much about preset system so a bunch of that stuff is just commented on refactor branch
haven’t even started writing the memory management scheme we discussed on github
binary scene format is in pieces on the floor
op_dsp still an empty shell
none of the menus are updated for operator-wise indexing and op_dsp
kind of daunting! Hope I can get somewhere with picolisp on aleph this weekend, then assess whether the technology could even be used to rewrite bees UI, moving net.c & operators into platform-independent ‘control-block’. As far as I know lisp and forth are both high/low-level languages combining speed and power but I already know quite a bit of lisp. interpreted language running on the device circumvents the flash time bottleneck/fear-factor!
If I do eventually opt for a straight C approach, catching all the UI bugs without debugger and with the long flash cycle will be gruelling - need to get a jtagice dongle and hone my gdb chops to fix multiple segfaults in a single build cycle before attempting…
So discovering the existence of hempl was the thing that triggered my interest in picolisp, though reading more about it’s design philosophy made some sense to me as someone already heavily invested in (common) lisp.
last night I attempted to replace hempl’s ld script with the one from aleph & ‘fixed’ all the resultant linker errors by blindly adding lines back in. They already have the -nostartfiles in their linker stage. Successfully compiled something with the bastardised linker script before dozing off but didn’t get as far as inspecting the top of the .hex file to compare it with bees/mix build.
I was blissfully unaware of linker scripts until last night and guess I will have a bit of study ahead to figure out what it will really take to add an aleph build target to hempl. Comparing this line of the hempl linker script to aleph I thought maybe they use a different type of RAM to us or something (sram != sdram) dunno if that is significant for linking purposes…
Also there is the possibility of trying to make a miniPicolisp avr32lib app like the pforth one, but not obvious to me how to cast a repl that blocks on read into avr32lib event-loop. Or maybe I’m mis-understanding what this is doing…
Looked to me like pforth only got as far as compiling it into an aleph app, not actually hooking up a forth REPL to the serial port?
bahaha loving picolisp - I was able to read the source to miniPicoLisp enough to totally hack the implementation of main loop, then read, eval, print lisp expressions from in-memory buffer, rather than stdin. So that opens up a possible way to drive miniPicolisp repl through avr32lib event loop hurrah! (something’s weird though still some way to go before trying to jimmy the same code into an aleph app)
therein lies the problem hooking up picolisp. I’ve managed to get something will work as long as you don’t send any ill-formed s-expression to the interpreter. Trouble is if you send it any junk it blows up completely. It’s to do with the fact that a repl would normally block awaiting further input till EOF. If you’re sending the chars over an event loop the read function might get called on incomplete input then that needs to be handled correctly.