#21

so one thing for refactoring for aleph specifically would be optimizing how leds are updated

to be clear: skeleton/system are copied from the aleph codebase. the monome driver is identical and monomeLedBuffer[idx] = val is exactly how aleph grid ops update their leds. wouldn’t really take any refactoring to run your code on aleph. if it’s an operator, you have to add outputs for triggers and the usual op management boilerplate. if it’s a standlone, you have to add some UI to map triggers to DSP params. that’s it.

i’m just thinking it might be nice to make these big heavy grid ops (and they are the biggest and heaviest in the lineup, by far) more generally useful. calling net_activate() per update is not, in itself, a significant overhead.

SCREEN doesn’t have outputs but you can always SPLIT its inputs.

1 Like
#22

yeah, i was more referring to minimizing on trips through the control network when updating individual leds, and you said it depends on what’s downstream, so this part might become slow? ha, you’re answering questions as i type : -) so, even easier, no refactoring.

SCREEN outputs - i was thinking about being able to check the current state of a led. but probably not that needed.

would be also interesting in addition to ‘heavy’ ops to have mini versions of them which would require smaller footprints to operate, and then assigning, say, 8 mini ops to share a 128 grid in 4x4 squares, being able to control all 8 simultaneously. or use heavy versions but use grid to control multiple selected parameters on multiple operators.

#23

well, some things to think about.

the big job that seems most helpful is to work out a general-purpose UI for mapping module outputs to aleph DSP. then you have one little wrapper for each module, and that module’s code can be flashed to aleph.

obviously there are differences in the libs due to hardware but this is not a big deal. i dread the UI work the most.

by the way, this sed script seems to work for that refactor:

sed -r 's/monomeLedBuffer(.*)=(.*);/net_activate\(IDX_OUT, \1\); net_activate\(VAL_OUT, \2\);/'
#24

not sure what you mean by mapping module outputs to aleph DSP? wouldn’t it simply be the case of updating operator outputs instead of module DAC? in case of orca it’d be as simple as changing updateCVOutputs and updateTriggerOutputs functions.

having a better idea of how things are set up i think it’s actually should be pretty straighforward to port without any major refactoring. i have aleph toolchain set up, will give this a try in a couple of weeks (need to finish another mod), won’t be able to test but can at least try to get it to compile.

#25

i’m talking about porting module code to aleph standalone apps. which is otherwise super straightforward because they basically use the aleph app framework (set timers, check event queue, etc), just with everything jammed into main.c

bees is a lot of overhead and glue to do arbitrary things. module firmwares can be pretty heavy and are designed to do one thing well. running them right on top of avr32 lib means they should work basically the same on aleph as on eurorack.

i dunno. ideally both would be nice. (sorry to be discussing two different things in this confusing fashion.)

Monome modular firmware on aleph
#26

Did anything ever come of this?

#27

in terms of having orca running on aleph - no… but we did start a good discussion on how to get to a place where we could write code once and have it run on multiple platforms with minimal modifications required. still not quite there yet, but an important milestone was achieved by combining the skeleton and system libraries (thanks to a major effort from @sam).

2 Likes
#28

Well thats good news. Thanks for the reply.