yes, that seems to be the case, but pretty sure there’s a bug… If you include an input/output in a preset, then subsequently exclude it, & re-write the preset, that input/output doesn’t get deactivated.

That’s why I got confused about the original design intent.

also another bug where presets get mangled by arbitrary op deletion

fixes for both problems seem ok so far!

think old lines will work just fine with updated BEES - might be a good idea to make a new module for the varispeed version, preserving ‘lines classic’ to avoid confusion & maybe even allow loading your old scenes rather than having to rebuild everything. Scene backward-compatibility should only be broken for certain grid ops & I don’t remember seeing a monome in any of your videos…


Ah you might be right there. Would explain some weirdness that I’d always attributed to op deletion.[quote=“skektek, post:102, topic:177”]
also another bug where presets get mangled by arbitrary op deletion

fixes for both problems seem ok so far!
Oh boy yes… I very often have to reassign half of my preset destinations if I delete any opp (even on I have just added and haven’t used!) [quote=“skektek, post:102, topic:177”]
think old lines will work just fine with updated BEES - might be a good idea to make a new module for the varispeed version, preserving ‘lines classic’ to avoid confusion

In terms of making a new lines module can I just copy old one, rename it and throw in the folder? Or do I have to do some makefile stuff[quote=“skektek, post:102, topic:177”]
Scene backward-compatibility should only be broken for certain grid ops & I don’t remember seeing a monome in any of your videos…

I have. Gs64 tucked away but haven’t used it in a while…(just for Parc on my laptop mainly. Prob my favourite sequencer ever) Your new opps are tempting me to dig it out!


think that would work! Let me know if not…


Another ‘non-release’ of aleph firmware - this fixes two bugs in the preset system. Here’s the patched code & an updated sdcard image (only aleph-bees.hex has changed)

Aleph release zip 0.7.1 cannot load scenes

That looks fantastic, will try it as soon as possible!


just to let you know that my old scenes (from Bees 0.7) seem to be working fine in your new version (and i can delete ops without screwing everything up!! ) and it was also possible to load both versions of lines (haven’t fully roadtested that yet)


given the number of existing scenes for ‘classic’ lines, (and the incompatible parameters) I think it’s best for a ‘stable’ release that the two versions should both be available in the source code under two different module names - e.g lines (for backward scene compatibility) & varilines would be the new varispeed version.


@skektek hi… wondering if you could give us a bit of help/info on how the MEM operators are supposed to work ? i’m assuming i should be able to store values in them but maybe that’s not the intention as I can’t seem to get that to happen? thanks!


So @dspk the mem operators absolutely are designed to store values. To use a MEM0D:


Then should be able to display the visibility of output MEM0D/VAL on play screen. this patch will store the last value output by encoder1 in MEM0D, and recall it when you bang MEM0D/READ with a button press.

Another use for MEM0D is to always output a particular number (call it n) whenever any number bangs read. Prior to MEM0D the only way I knew how to do this was MUL(0) -> ADD(n).

Here’s a recipe using MEM1D:

  • set the range of ENC2 from 0->16 in increments of 1
  • ensure MEM1D/TOG is 0
    ENC2/VAL -> MEM1D/N
  • enable play-screen visibility of output MEM1D/VAL & input MEM1D/N to test this patch.
  • ENC2 selects the memory index
  • twisting ENC1 will write a value to the currently indexed memory location
  • pressing SW1 will recall the last value written with ENC1 to the slot indexed by ENC2.

MEM2D is identical to MEM1D, except it’s memory is a 2D array, indexed by the inputs X & Y. You’ll see that the operator GRIDRAW outputs in the following order:
so the functionality of MEM operators is pragmatically designed to play well with GRIDRAW. For example store the Y value of grid button presses in a MEM1D, indexed by the X value:

Please let me know if any problem or bug when setting up the patches described above. Hope you find this dark magic useful & powerful once mastered!


ok great. i was struggling with the recall. sorted now… but what’s the significance of the TOG ?


Haven’t had a moment to load this into my Aleph - but I just wanted to say how much I appreciate all the hard work that went into this. There is so much potential in that little box; it is nice to see more of it unlocked!!

Thank you!


it toggles the indexed memory element on/off when banged with a number greater than 0. Similar to WRITE, it doesn’t trigger an output. Again a pragmatic design so that you can achieve a toggling memory like the toggle mode of GRID using a GRIDRAW & a MEM2D.

All the building blocks are now there for a module which emulates in some sense a patchable virtual modular. Some module examples could be, e.g VCA, filter, env, pitch detection, mixer, varispeed tape loop. I’d hope to set it so the user can actually customise which & how many ‘submodules’ are in their blackfin module by modifying the header & recompiling (check the sourcecode for acid, you’ll see a proof of principle) The patching would be controlled via labelled patchpoints like the grains module.

also something combining part of the ‘acid’ DSP with one ‘line’ would be cool, so you could do some kria/WW sequencing sync-ed to a hack-able looper without carting multiple electronic gadgets around. That’s an interesting concept to me - the line could be used for resampling/mangling bfin-generated sounds as well as a looper for external instrument. Needs some thought/planning & a clear shot at the coding.


cool to see a different approach to patching, I’m totally in on the module “patchability” idea.

on a side note I recently got hung up on a possibly silly idea to use the bfin for graphics/video. notably I have yet to find out if this is something worth pursuing considering that it would “divert” from the original idea/design etc, but I would be up to discuss possibilities.


[quote=“skektek, post:97, topic:177”]
With no grid, this should work:

  • first set SIZE to 6
  • then set 2 encoder ranges both 0-6
  • connect those to X & Y
  • connect sw1 to BONK
  • hook up Hz to a Hz input on, e.g waves.
  • set play screen visibility on X & Y to see where you are on the square
  • tap SW1 to emit a Hz value

with a grid, create a GRIDRAW & a HARRY:
X -> X
Y -> Y
[/quote]Searching here on the forum aint bad but I’d like a hub for referencing all updated features/ops/etc

It would be awesome if the docs were refined to include updated “studies” (and more generally reflect the staggering progress in development since the last update)


btw…@skektek thank you for the incredible work recently

not sure if the ops for grid patching were inspired by @rick_monster @Yann_Coppier ideas from last yr


Hello hello… Just saying, but I have been using Grains a lot more in the past months. I can honestly say I have enough good material to make a record now, and a lot of it comes from that sweet module! An incredible lot can be done, and I have made some scenes to make things easier to control. Will be back shortly to explain what I did and share. In the meantime, I’ll have to ckeck all the new stuff that has come for the Aleph recently, which seems rather crazy! By the way I was wondering if, for instance, the MEM0D and such (from @stektek) were the same as yours, of some new versions?


Diving back into this update again tonight and will post a scene. Really been pleasantly surprised by the drum sounds aleph is capable of by tweaking the acid app. Scary good and definitely grittier than most would expect from pure dsp.

Finally put down acid long enough to test my old scenes this week and none are working :frowning:

Don’t really mind rebuilding em but…is anybody else having the same issue?


@skektek @tehn its long overdue but i think we should just roll these changes into the upstream.

the main thing the aleph needs is still a better UI / patching language for constructing scenes offline / over socket. it should not be hard, we just need to get it done…

Aleph wobbliness (and emulation)

maybe we could write a script to parse pd scenes containing the BEES_PD objects into working BEES patches? This might still be quite a bit of work!

With the arbitrary op insertion/deletion & properly working preset system I’ve found building scenes on the device to be satisfying & productive (though definitely still somewhat ‘write-only’). Think there’s a PD scene for the ‘marimba’ patch in the snapshot I released. I find it nearly equally fiendish to construct brain-melting tangle of PD wires on computer screen as a huge BEES netlist constructed piecemeal on the aleph.

‘patch language’ as in text/code representation of BEES netlist? cool!


I thought this would interesting the more I looked at pd but figured everybody would ridicule the idea…wasn’t smart enough to implement it myself last year


that would be cool, similar to shlisp. there is already the JSON serializer, which really does kinda work

simplest step i had in mind was just a command syntax for live-patching over socket, commands corresponding to patching actions on the aleph UI. would have terminal feedback too

(i dunno, just making this up)

NEW DIVR - replies with 14.DIVR or something
INS 14 replies A B B_TRIG ?
OUTS 14 replies VAL R ?
SHOW OP 13 replies (say) 13.FADE [A B X] [VAL] ?
SET 13.B_TRIG 1 ?
INC 13.A 1- include input node in preset 1?
INC 13.VAL 2 - include output target in preset 2?

i mean this is all pretty doable given that everything is bees functions plus a simple parser.