That would be really sick

Now that I’m used to teletype I might actually prefer that over anything else

This system (or the pd-wrapper mentioned above) would be really fun tools when away from the aleph itself


I really like the grid focus-swapping paradigm on most recent firmware & this also works in the pd wrapper. Think the way this now hangs together is true to brian/ezra’s original vision for aleph as grid host.

Would be cool to make that focus-swapping somehow work outside of the pd BEES wrapper - standalone PD grid apps as C language PD externals which nonetheless can grid-swap between one another by ‘stealing focus’.


Ok now I am in there, and I must say this is absolutely brilliant!
Now I have so many questions I’ll have to try it all first, spend some time and find out about the obvious first.
Just to know, there is no documentation whatsoever about the new modules (fmsynth, acid) or the new ops, right? Wouldn’t it make sense to build some and integrate them in the existing?
Again, the Aleph’s potential just exploded and I am ever so grateful for it!


Very interesting, man I missed all of what happened within a year, or so it seems! Still, I have been making a lot of music but I only tried the fmsynth module 10 minutes ago. Lots of potential, although it gets messy super fast! I of course noticed that the lfo wasn’t implemented yet, but I suppose you’d use it as an extra source of modulation, right? Or maybe just on the filtering part? It’s crazy with the Aleph, that so few people have it but still it remains such a great source of inspiration. I did play a gig last week in Norway, at Punkt Festival, live remixing a rather free jazz band with the Grains module. And it worked wonders!


grains is still a challenge for me to understand cause it can do so much!

I need to sit down and patiently tackle each section to properly utilize it


Yes I know, but once you figure out how to use your grid as a matrix it becomes easier. Without this it might feel like a mess I suppose, I am quite used to it now. But true, some things remain challenging. If you get into it as well we might be able to discuss more (along with @rick_monster), but maybe I should send some of my sessions first?

Unfortunately I have made those with a custom version of Bees, in which I have added a couple of modified operators in order to use less memory on some patches (HIST2, ROUTE2 mostly now). Maybe we could have them added as well in the version of Bees @skektek put out, so I could share more stuff? Otherwise I keep making my own compiled versions, which makes them difficult to share… What do you guys think?

Oh and I have to get back to the Loom stuff by the way, now that we have extra elements to work on the Grid!


you on git?

I’d be willing to compile your modified BEES to try some of your scenes (if/when they get folded into the non-release skektek put out…great!)


Hello again,

So I am actually looking into fmsynth, with one year of delay I know!
Very interesting but still, I have found a few bugs - unless they are intended, you will tell me.

  • There seem to be quite some entanglement between Op2 and Op3. Basically I think they are addressed as one and only operator, with op2 not working at all (no pan, no envelope, no tuning, no modulations). Only its volume, which logically conflicts with op3Vol. On the other hand, op2’s envelope works when op1 is modulated by it.
  • The waveshape parameters don’t seem to work.
  • Not a bug in itself, but the envelope parameters go from 1 (long) to 150 (short), which is a bit strange. Furthermore, the long ones are still pretty short considering we are doing FM synthesis. Maybe they could be extended quite a lot?
  • Finally for now, the intermodulations are great but they tend to jump at some undefinite points, where the sound disappears (not always at the same point) or jumps suddenly to seemingly different values. Without getting into the jumping and all (it is difficult to quantify at this stage, as I just tried it), some Slew parameters in there, although that might bring quite a few, would be great. At least for the tuning. Also, and even though it is surely not the point of FM synthesis, a filter (or 4) could make the sound more flexible… but that’s mainly my point of view, and you are welcome to disagree.

Alright, time to sleep. Again, thanks for this great job!


Hello there, is it just me or the Alt button (last one on the last row of my 128) gets stuck as soon as you press it, using the KRIA operator (which is extremely cool, by the way)? As soon as I touch it there is no way for me to remove it, and on the tutorial video it seems like this specific button is temporary… Any clue?

In all cases, thank you so much for this. It is already more than I could hope for!


wow, kind of a lot going on in here! Many interesting ideas, few tricky questions etc… the fmsynth was pretty much a 1 day hack, haven’t played with it much or given it much thought. Very probable your bug reports are accurate - linux-hosted dev tools have improved again. Straightening this module out should be pretty straightforward…


Nice to hear! Also, I noticed that in the Bees version @skektek there are two Grid operators now. Would it be fair to say Grid is the old one and Gridraw is the one you made?


grid is the old op w/ fixed focus-swapping, gridraw is a dumb ‘buttons & lights’ version, leaving all grid logic to the patch.

indeed, adsr envelopes themselves are a weird choice of restriction - the original waves/BEES adsr-less philosophy is perhaps more interesting for a monophonic 4-op FM - shifting FM soundscapes, tweaked using BEES patching & presets or more algorithmic less ‘performance’ approach.

pretty much into waves territory, no? don’t know how much it adds having something halfway between fmsynth & waves… unless you approach the design for some specific musical usage… & btw waves was optimised as part of the release, eliminating annoying glitching on certain param changes…


thank you :100: !! !!!


I have a question about delay buffers, failing to get a 100% wet delay output. this is the algorithm I’m using:

fract32 pf_dly(prgmChn *c) {

c->head[0].end = c->time;
c->head[1].end = c->time;

c->head[0].idx += 1;
c->head[1].idx += 1;
if (c->head[1].idx >= c->head[1].end)
    c->head[0].idx = c->head[0].start;
    c->head[1].idx = c->head[1].start;

buffer_head_mix(&(c->head[0]), c->input(c), c->feedback);
return buffer_head_play(&(c->head[1]));


should I try to move the play- and record head index out-of-sync or is there a better way?!


i’m not sure i totally get it, but seems like head[0] is the write head and head[1] is the read head.

then yeah, to actually hear a delay, the read head position must be behind the write head position.

re: feedback

i had to look up buffer_head_mix in your repo. for the benefit of others, it is

void buffer_head_mix(bufferHead *head, fract32 sample, fract32 preLevel) {
    head->buf->data[head->idx] = add_fr1x32(mult_fr1x32x32(head->buf->data[head->idx], preLevel), sample);

so, you are implementing the form of feedback known as overdubbing or “sound on sound,” mixing the new input with the signal from the previous pass. this makes most sense in a “looping” application where the read/write heads aren’t constantly moving in a fixed relationship; instead you might have the read head always/arbitrarily running, and then do “one-shot” passes of the write head to overlay new signal (or punch in/out on the current read head position, whatever)

when you do SOS and also have moving read/write heads, you get some strange timing effects; the interval at which old signals recur is a more complex function of both the delay time (distance between heads) and the start/end points of the buffer. this can be interesting, and it’s fun to make use of it (in aleph-lines, say, or using looping RecordBuf and PlayBuf in supercollider,) but it might not be what you are after.

(in fact you have opened up even more weird territory by allowing the read/write heads to have separate endpoints!)

to me, “feedback” (vs. “sos” or “overdub”) implies the kind of literal feedback algorithm you would see in an analog delay pedal - mixing some of the output from the read head with the input, like so:

// showing more steps for clarity
bufferHead *writeHead = &(c->head[0]);
bufferHead *readHead = &(c->head[1]);
fract32 *pWrite = &(writeHead->buf->data[writeHead->idx]);
fract32 read = readHead->buf->data[readHead->idx];

*pWrite = add_fr1x32(mult_fr1x32x32(read, c->feedback), sample);

to set the delay time, simply place the read head index behind the write head index:

set_delay_time_samples(prgmChn *c, int delayTimeSamples) { 
  c->head[1].idx = c->head[0].idx - delayTimeSamples;
  // ... OMITTED: wrap the read head index to the buffer start/end points... 

and update the indices as you’re doing

you should then have 100% wet output plus feedback.


thanks so much for helping out, I’m getting a classic sweet delay line now :slight_smile:

    writeHead->idx += 1;
    if (writeHead->idx >= writeHead->end)
        writeHead->idx = writeHead->start;
        readHead->idx = writeHead->end - dly[0]->time;
    else if (writeHead->idx >= dly[0]->time)
        readHead->idx = writeHead->idx - dly[0]->time;
        readHead->idx = writeHead->end - (dly[0]->time - writeHead->idx);

if there are any other ideas out there on how to do the syncing, please do share!


Hello all, using WW with @skektek 's version of Bees and trying to get the trigs to function I used the good old Metro -> Tog (32767) -> WW, which was the only way to get anything else than 1 all the way, but was surprised to find out it didn’t work anymore: no matter what I do I only get values of 1, which never go back to 0. The only difference is that the tempo gets divided by 2, but apart from that… Has WW been updated with a bug at some point or could anyone else check it up? I am joining @tehn because he might have a clue.

I have to add that it is not the case with earlier versions of Bees. I only tried an old one from October 2015, before v0.7 and it did work fine. I guess I could try and find out at what point it stopped working, if it even makes sense. Still, I suppose it should be addressed, right?


For clarity

You’re using the WW op within bees not the external eurorack module, right? Seems silly to ask but just making sure

I’ll try to test this weekend if I have time


Yes, with the Aleph. I have no clue as to why it behaves this way now, otherwise it is fantastic. You can even save your presets now, which makes it a totally different tool, and you can switch between WW and Kria without any problem… Oh and the possibility to include elements from the Output page on the display while performing is just great.


Note that this feature is somewhat incomplete - the output visibility doesn’t get saved to scenes. I find it most useful for debugging & reminding myself how operators work without having to jump on a distracting email/interwebs machine to rtfm…