monome modular apps on aleph

[catfact]

• [x] refactor grid app operators (e.g. WW, LIFE) to not use the monome driver directly. (maybe each op gets outputs [x,y,ledState] and inputs [x,y,buttonState] ?)
• [x] create glue operators (or refactor GRID, ARC) to talk to the monome driver. this way, for example, two apps can share one device by offseting thir I/O signals.
• [ ] build a minimal ctl network app (where you can statically create ops and hardwire them)... this would still be against the aleph avr32_lib.
• [ ] refactor aleph app code (and probably module avr32_lib) such that aleph can build with module lib, included as submodule.

feel free to create separate issues for these tasks if you feel like approaching them specifically, or discuss the general strategy here.

[ghost]

So w.r.t the simulator for avr32_lib I came round to @tehn's point of view that expanding beekeep into a full aleph emulator may be too much of a tangent.

Let's downscale the proposal for 'app-emulator' to 'op-emulator' - sounds like only a session or 2 to hook up some of the trivial ops to liblo, then get hacking on a version of a module firmware where all calls to/from grid are abstracted via bees. Any op which calls or is called by hardware directly (i.e grid) must be re-written for the host.

So in fact the 'op-emulator' proposal is simply a quick way to cleanly cross-compile a single op to OSC-linux target, with OSC urls for input/output hard-coded (one op-emulator main.c per op) until that becomes a bore. Complex patching would be nigh-on impossible but setting up a quick testbench hooking up one app to one grid is fine - same idea as @catfact's 'minimal ctl network app'

Only potential problem - will we have performance issues routing all monome communication through bees bangs? My feeling is no need to worry about this - bees bangs don't pass through the event loop IIRC - it's a call to function pointer, right? Don't care if performance on host sucks it's just dev tooling...

What are the implications of cross-compiling bees-ops for eurorack target platform with hardware abstracted as described? Eurorack modules don't even run bees, right!?

[ghost]

Ok so I just hacked together the minimal glue operator for grid, overwriting the old grid operator (off on a new feature branch in case this experiment blows up in my face)

https://github.com/rick-monster/aleph/commit/b5dd9b91e60647f782eb585a920cc46916c3c634

Going to plough ahead & try to refactor op_life to interface the hardware via that new grid op. If I run into anything hairy will resort to the op-emulator described above to debug...

[catfact]

Might want to check out the beekeep_juce project if you want an emulator, it compiles all the ops in c++ and juce has OSC classes built in....

[ghost]

alright - is there currently enough machinery in there to actually run a bees net on host? I'm having trouble building beekeep against your most recent head - looks like because of some updates to HID code. Also spotted new forth app when I fetched new branches - exciting!!!

[catfact]

yes, pretty much. there are no timers, peripheral I/O, or screen. and the patching GUI is embryonic. but you can create operators, patch them together, bang their inputs, etc.

i thought having it in juce might just be a relatively painless way to build stuff out, since it gives you a lot of nice platform-independent abstraction of stuff like timers, midi, painting, etc...

and yeah i'm have some strange compilation issues too, with a fresh checkout, looking into it...

[catfact]

and yeah: the pforth app is actually gonna be pretty easy i think! very excited about that one.

[ghost]

Just fixed the compilation issues I'll push to my dev branch in a sec...

EDIT: hmph no regular beekeep compiling but not beekeep juce

[catfact]

i dunno, i have something very odd happening with gcc, i think it's this system (not the one i usually use.) gcc 4.8 is complaining about definitions with leading underscores..?? blech

[catfact]

nevermind, got it

[darrengit]

pforth!! excellent!

On Feb 20, 2016, at 12:17 PM, ezra buchla notifications@github.com wrote:

and yeah: the pforth app is actually gonna be pretty easy i think! very excited about that one.

— Reply to this email directly or view it on GitHub.

[ghost]

ok still can't compile against @catfact's dev - seems to be missing the dir beekeep_juce/src - tried replacing that with beekeep/Source in the makefile but then throws some other errors - did something not get checked in?

[catfact]

@rick-monster: ok, i think my dev branch is ok now. had actually been building this on a mac and hadn't got the linux build set up properly.

maybe i'll spend a little time on the GUI now.

@darrengit : heh, yeah, finally getting around to it! i might have some questions for you in a bit...

[catfact]

@rick-monster huh, i don't see how, i'm using a fresh clone...

[ghost]

how odd - bunch of stuff broken with your dev head on a pretty up-to-date arch linux install the makefile appears to be pretty out-of-date or something. Making progress but can't fathom how moving to mac would fix the build...

[catfact]

oh well... i guess ignore this whole mess for now.. i'm actually getting a segfault on linux now from deep in the JUCE message queue structure - some problem with select() and x11? so, it needs work.

the mac project is totally different, doesn't use makefiles at all, is the thing.

now i'm just curious, are you definitely using aleph/utils/beekeep_juce/Builds/LinuxMakefile/Makefile ?

[ghost]

nope - trying to use aleph/utils/beekeep_juce/Makefile !

[catfact]

oh-- -sorrry.......

[ghost]

that looks more plausible - crunching now...

[ghost]

segfault yeah! Oh well...

[catfact]

ok well that's good to know anyway...

[ghost]

So the methodology routing all monome communication on aleph via bees bangs seems to work well, at least for refactored op_life:

https://github.com/rick-monster/aleph/commit/95445211e4c60020015ae7b170bcb42026138601

debugging on the aleph with looooong flash cycle wasn't quite annoying enough to motivate any progress on the emulator.

Of course the more dev we can get 'in the box' the more people can get done whilst 'away from the device', if you catch my drift - this is part of the reason I'm somewhat fixated on linux emulation (as well as catching dumb runtime errors with gdb)...