Orca op -- aleph bees?

Really exciting to see the orca firmware. Has any of the aleph owners built your own bees ops? With aleph’s arc support, in the latest build, it would be fantastic to see an orca op. Anyone have interest in this? …bees skills to make it happen?

i think it should be doable
cant recall if @scanner_darkly has an aleph

i’ll peruse the code but i never set up the toolchain for aleph op dev
it would be nice to compare MP + WW firmware to their aleph counterparts

or better yet hack the WW op to behave like Orca if possible

/ comparing these right now…


sold my aleph a while ago unfortunately, didn’t think i had the time for development…

looking at the ops source code porting orca to aleph should be pretty straight forward. i think it’d be easier to start with the arc op though and then transfer the appropriate bits from orca, looks like bees uses the skeleton framework as well, or something very similar, so shouldn’t require too many modifications.

you could even make an orca op that wouldn’t require having an arc, it would just have INPUTS for the parameters and then you could route aleph encoders to it, for instance, but probably makes sense to just have it use arc if you have one plugged in and still expose INPUTS so you could control it with other ops too. i guess that’s how whitewhale op works? things could get really interesting if you modulated orca parameters with CVs or LFOs or whatever…

i might try porting it at some point, just won’t be able to test it, but will be happy to help if anybody else wants to try it. what i can do in the meantime is add more comments in orca code - will work on it!


yeah i thought that might be better option if WW’s op is basically a grid op with various tweaks…ARC op would probably be a better springboard for this project

i just want to see how much changed between the euro and aleph code cause i figured that might make it easier to understand.

might mess with it in a few weeks when i have time but if you get around to porting Orca
i could definitely test the op

i’ll take a look, just need to set up the toolchain for aleph (and try a couple of ideas i have for whitewhale first…)


btw i like your idea about leaving the inputs open in a generalized op…

i wonder what would be best for i/o routing tho since aleph doesnt have 6 voltage outs (conversely there are several cv ins, which i know you were interested in for the euro hack)

this could really be a unique sequencing solution

yeah, i thought the op could still provide full set of OUTPUTS, and then you just choose which ones you want to route to the CV outs, or a combination of those, so, for instance, you could output CV A, CV B, trigger1 || trigger2, trigger3 || trigger4, something like that.

and yeah, i think things will get really interesting if you start modulating parameters with one of the outputs! say, use CV A to modulate divisions…


this is getting exciting. the possibilities opened up to white whale on the aleph, because of the INPUTS, is pretty amazing. a similar approach utilizing an orca / arc combo seems very flexible and unique as well.

glad to see others interested in this discussion… and thank you for your efforts @scanner_darkly and @glia

1 Like

excellent idea

i’m conceptually close-minded at times and hadnt even thought of that as a possibility with a software system underpinning the i/o

Sorry to bother but any news on this thread? It sounds just too exciting to let it go…

1 Like

i’m afraid i’ve put this plan on hold for now for several reasons. the fact i don’t have an aleph makes things difficult - my initial plan was to “blind” code basically making sure it compiles and hoping there are no bugs. also the CV control was something that i thought would be an interesting feature to warrant another version but now it’s possible via the teletype.

also, in its latest version Orca is quite a bit complex now and wouldn’t fit well within the bees environment - i think simpler operators work better. a simpler version could still be built though.

i’ve got quite a list of things i need/want to get to soon, including finishing testing Orca/Teletype integration which is almost done, using MIDI controllers with nw2s::b and teletype and and a couple of really cool - i hope! - ideas i don’t want to reveal just yet. i might give this idea another try once these are done. i’m really hoping though that somebody else would be interested in porting Orca code to aleph - if anybody is thinking about it i will be very happy to help in any way to make it happen!

I totally understand man, no worries. I won’t be able to help you with the coding as it is way too advanced for me, but will follow what you are doing for sure - thanks for the hard work and the sharing!!

1 Like


sorry if this is a very dumb question, but: do you have the orca code online? i couldn’t find it in a quick github search.

sorry to revive an old thread. but i have recently become interested in unifying the aleph/eurorack codebases. it’s not very difficult to port module code to aleph, and some of the new aleph firmware i’m working on would be a good fit for modular as well… so anyways i’d be happy to do an ORCA port if it’s wanted.


that would be totally awesome. will be glad to help in any way.
i should probably clean it up / comment on the code a bit more, perhaps some optimization will be required too. but most things should be easy to port, i hope. will post more thoughts once i sleep on this!

1 Like

well looking at the source, orca is kind of enormous for a BEES operator.

so this fits more with the overall plan i had to make a general code layer for adapting TT and module firmware to aleph. basically just a way to map triggers/cv to DSP parameters (or to CV out, of course) and to change the running DSP module. it seems silly to not be able to bring new code for modulars back to the aleph.

i’m not seeing any differences between skeleton, system and the aleph avr32 lib that can’t be factored out into application code.

1 Like

yeah, i was thinking as a bee operator it would probably make more sense not to do a direct port as there is quite a bit and it’s so tied to grid/arc, but to port the concept as a simpler note[s] generating operator. so, still 4 tracks, controllable via bee parameters, which would output up to 4 notes (not sure if triggers would be that interesting).

so within the bee ecosystem does it make sense to have tight integration between certain operators and grid/arc or does it go against the idea of using the control network? it seems it would be difficult to have a complex ui without ‘native’ operator grid/arc integration. but then how would it work with multiple grid operators, for instance?

another thing to consider is presets - do operators have a way to store their state?

and yeah, it seems silly not to be able to share code easily. for future firmwares i’m going to try and keep logic separate from the presentation / controller layers. teletype integration is actually a good incentive for this too.

certainly, operators can store their state. each operator provides “pickle/unpickle” functions that are called when building/parsing a scene binary blob. typically these are used for input values, but they could store whatever else is necessary for the op to function consistently.

the MP, WW, LIFE and STEP operators are all more-or-less complex programs integrated tightly to grids. which is to say, they manipulate LED buffers directly, and they receive input directly from grid event handlers and not from the bees network. we decided that was ok- a lot of aleph users are also grid users and it seems good to give them some high-level functionality that can be further customized with other bees objects as glue.

bees has some special mechanisms for multiple grid operators. an op that wants to talk to grids “inherits” from op_monome_t and sets the eOpFlagMonomeGrid type flag at init. this means that it has a flag for focus, provides a handler for grid input events, and is registered by the network as something that needs to be notified when grid input arrives. these operators all have a focus input which calls net_monome_set_focus(); when set, this tells the network to use this operator’s handler, and de-focus any others.

grid output is comparatively simple - the led buffers can be set from anywhere, and will be sent to the device on the refresh timer.

now, i do have some issues with how these operators were written:

  • they don’t take advantage of the pickle/unpickle functions to store state. only focus.

  • relatedly, WW and MP keep most of their state in a large collection of static variables. i guess the reasoning is that otherwise they would take up space in the op memory pool, and you’ll never want multiple instances of these, so, fair enough. but at least wrap all the static vars in a struct so i can see just how much code space these guys are using without picking through tons of entries in the .bss disassembly.

  • i don’t actually see what’s so hard about refactoring any of these for arbitrary input and output. there are only three values coming in for key press/lifts (x, y, val) and only three coming out for LEDs (x, y, val.) i think they would behave exactly the same if connected to a raw GRID operator. it would be a considerate gesture for non-grid users.

this is very helpful - thank you! i wondered whether there was something like focus - makes a lot of sense, and the implementation looks very straight forward.

re: arbitrary inputs/outputs - this could be done in addition to supporting inputs/outputs that are meaningful to a particular operator (so, in case of orca, track parameters, scale, clock and reset inputs etc). but why would you ever want to use raw key press/lift or led other than connecting it to a grid operator? i guess one case would be supporting non grid controllers but even with those it’d be probably easier to map controls to specific parameters rather than key presses. also, for led output it would definitely require some refactoring as it’s just so easy to take advantage of being able to refresh the whole matrix at once rather than updating individual leds (unless it outputs every led on each refresh, probably not a good idea).

one application i see for raw inputs/outputs though is having a grid operator that would scale/map/combine several operators, so you could split a grid between multiple operators and be able to select which part exactly maps to which operator.

but why would you ever want to use raw key press/lift or led other than connecting it to a grid operator? i guess one case would be supporting non grid controllers

that’s why. maybe i want to use input from a HID device and output to screen drawing operators, or use midi. i don’t know about ORCA but for example STEP and LIFE aren’t really very grid specific.

it doesn’t really seem like a big deal to me to accept three arbitrary numbers (or two, if preferable) as standard operator inputs, instead of from a lower-level handler. but this is just a thought.

for led output it would definitely require some refactoring as it’s just so easy to take advantage of being able to refresh the whole matrix at once rather than updating individual leds (unless it outputs every led on each refresh, probably not a good idea).

hm, i’m not sure i get what you mean. i’m looking here:
[ https://github.com/scanner-darkly/monome-mods/blob/master/orca/main.c#L378 ]

and saying, i dunno, turn this:

for (u8 i = 0; i < 4; i++)
    for (u8 led = 0; led < 16; led++)
        monomeLedBuffer[64+(i<<4)+led] = led < (counter[i] & 15) ? 15 : 0

into, like:
for (u8 i = 0; i < 4; i++) {
    for (u8 pix = 0; pix < 16; pix++) {
        net_activate(INDEX_OUT, 64+(i<<4)+pix);
        net_activate(VALUE_OUT, pix < (counter[i] & 15) ? 15 : 0);
you see? there is an output that indicates a pixel index, and one that indicates the value at that pixel. now i can plug this into a SCREEN operator. (well, with some tweaks.) i would also tweak the GRID operator to accept the same input format. now the op doesn't have to care what kind of display its talking to. (assuming of course that all operators respect the L->R convention for update order.)

likewise i can make an op that produces (x, y, press/lift), or even just (index, press/lift) when i bang on my HID keyboard or midi thing or whatever.

i'm just brainstorming though,  don't worry about it.

> (unless it outputs every led on each refresh, probably not a good idea).

hm, not sure what you mean. the monome driver in aleph/system/skeleton only uses quad refreshes. you change the pixel buffer whenver you want, and when the refresh timer comes around those get packed into quads. that's probably not what you mean though. you mean it would be too much overhead for an op to activate the network every time a pixel changes? that could be true, but it would totally depend on the downstream connections.

my thinking was if you set leds individually that would result in separate commands issued for each led - just seeing your update as i’m typing this, sounds like this might be the case… so one thing for refactoring for aleph specifically would be optimizing how leds are updated. but then quite often you’d want to update every led anyway, so maybe not a big deal.

but yeah, plugging into SCREEN is a really good example. and could be interesting using HID for input. i still think that well thought through inputs/outputs are probably easier to use and could include not just something that affects operation but the UI specific stuff, such as “selected page” input which would switch between different editing modes. supporting both raw and regular inputs/outputs should be easy though, and can make it possible to do certain things that wouldn’t be doable otherwise, you could really hack into the UI this way. but then you’d probably want some sort of event processor / message translator operator as well, to program gestures and such. or something like a ‘teletype’ operator. does SCREEN also provide outputs?