just tested in bees by sending cv-in/val0 to bignum/val and I get 3977 at 5.0V, my instrument clips at 5.1V so 4095 would be a just little bit over. from my point of view I prefer this to a 10V scale, after finding out that what I need to do is simply to study how to convert them to s32 and double formats :slight_smile:


ok so the sequencer works, it is a bit heavy on the Aleph but very much fun. The only thing I noticed though is that STEP is not getting initialized properly when loading the scene. I did notice how White Whale and Kria are loading properly now, so I thought maybe you’d know how to fix that? Also, it seems MEM1D does not keep all of its values when a session is saved and then reloaded: I used about 112, and after the 16 first ones I get somehow a lot of zeroes. Not during the session, but when I save it and load it again. Any idea?

By the way, including FOCUS on the input page of GRIDRAW was a great idea I must say. You have been solving some of my issues without me ever asking, and I am very thankful for that! Oh and I definitely think having the option to save the output visibility would be neat: I ran into a case or two where it does wonder and makes a whole patch way easier to play with.

Aleph Testers Corner

yea almost certainly an easy fix now.

again almost certainly a very easy fix.

this might be a tiny bit more work, but still do-able.

thanks for bug reports!


hah yeah, spotted it now - oops!


If I were to make a delay effect on aleph, in bees or otherwise, can you do really long delays? Like 30 seconds?

I’ve read a lot about mono synths, can you make polyphonic synths?

I’m looking at picking up an aleph, but don’t have one so that is why I’m asking some very basic questions. I want to see if some of my most basic ideas are in line with the possibilities of the aleph.


there is 64MB of SDRAM. the delay module i made (lines) has two buffers that are each 60s long and rather arbitrarily addressable. not sure about others.

there is no polysynth module implemented, but it can be done within CPU limitations (would have to be pretty minimal)

other important things to know:

  • aleph is not much like a “normal” computer, it is an MCU + DSP with no operating system

  • BEES is a program that runs on the MCU. it doesn’t implement audio DSP directly and runs on a 1ms tick. it is analogous to “Max” in Max/MSP or (loosely) to sclang in supercollider, though much more primitive than either. you don’t have to run this program, it is built on a version of libavr32 like the teletype firmware.

  • if you want to make your own audio DSP you have to implement it in C using fixed point math, this is not everyone’s idea of fun.

  • the whole experience is rather more “blank slate” than a lot of people would really want/need, compared to (say) a machine that runs linux.


Thanks for the detailed reply. You helped clarify some things and gave a small glimpse into the deep.

The ‘form factor’ of the aleph is the most intriguing element, to have all your ins and outs and the encoders and your processing in one small box is really amazing.

I’ve found myself further and further towards developer on the musician-developer spectrum in the last couple years, and I’ve been enjoying it more and more. While the C code is beyond my level as of now, I’ve progressed quite a bit with my knowledge of SuperCollider, which has been a big step in comparison to my fairly recent times using ableton and then max. I believe the aleph could, in time, offer a platform for learning low level coding.

Anyways thanks, and I’ll get out of the way until I’m a real “aleph user”!


Bug report:

ENC operator bangs it’s output when you change it’s min/max/val inputs.

I’m gonna go ahead & call this a bug because it breaks a canonical use-case for the preset system.

I’d expect encoder outputs to stay silent when you recall a preset for their inputs. My proposed change means you can assign a ‘bank’ of DSP parameters to the 4 encoders by recalling a preset. Then the DSP param will only get updated when you actually twist the encoder.

Maybe there’s some reason ENC operator was designed this way? If there is, I don’t see it!


there was definitely a reason but it surely can’t have been a good enough reason since i can’t remember it. you’re absolutely right that it’s a limitation more often than not.

maybe a compromise would be, “if the old value was outside of the new range, then constrain it and bang the new value.”


yea can see the logic there… Needs thinking about more as I play around.

Building a kind of scene where encoder param banks are selected from a grid. I keep getting stuck at the part where you use a ‘special’ preset to draw a glyph onto the grid, a visual aid to the function of these different ‘encoder banks’.

Also I think there might still be a remaining bug in preset system when you insert/delete operators into the netlist ‘under’ nodes included in presets, so that’s not helping…


There is a confirmed bug there indeed: I just rebuilt an old scene for compatibility purposes, and inserting or deleting an operator after some elements included in already existing presets makes the whole OUTPUT page wrong from that point on and downwards, everything getting moved one line up or down. Weird, I was pretty sure everything was working there!


yeah me too - haven’t seen anything of this sort! If you could find time to reduce to a minimal test case that would be helpful!


I was just browsing thru the dev dsp library, is there an aleph version of the lowpass 2 pole filter somewhere, or a reference describing it’s algorithm?


So my filter theory is a little shaky but as I understand it the following filters all have 2 poles:

  • the state-variable filter in lowpass mode (filter_svf.c)
  • the biquad filter (biquad.c)
  • the ladder filter (filter_ladder.c)

all available in dev branch for github user boqs, just fished out the ladder filter code from an orphaned year-old blob with blackbelt gitfu:

git log -g --grep=“ladder”

thanks, git!


true, it’s just that I tried the hi-pass and that got me intrigued about testing it’s sibling algorithm too.


looking briefly, seems like my implementation of the highpass in dsp/filter_2p is direct form I biquad, with some kind of funky refactoring to save a multiply when in highpass configuration (b2 == b0, b1 == -2*b0, using the a/b notation from biquad.c. (NB: the posts below from earlevel use the opposite convention: a for numerators/zeroes/feedforward, b for denomiators/poles/feedback; there is no historical agreement on this but the convention in biquad.c has been dominant in recent years.)

and it looks like the implementation in dsp/biquad is also DF1, however the update function is generic, and conversely only the lowpass form of coefficient calculation is provided.

this could all be cleaned up and made more consistent. e.g. by just adding the other coefficient formulas to biquad and ditching filter_2p. the nice thnig about the generic form is it can change modes on the fly. but could also have a separate update func for each mode to save a multiply or at least replace a mult with a shift.

another thing is that biquad.c uses 8.24 coefficients, which is smart and saves some scaling gymnastics. i’d be curious to look at disassembly for both these implementations. has good rundowns of biquad formulas:

and structures:
though for blackfin i think sticking to DF1 is the right choice.

also might be worth trying out the fract16 IIR functions from the blackfin DSP library:

void iirdf1_fr16 (const fract16 input[], fract16 output[], int length, iirdf1_fr16_state *filter_state)


i think if you poke around in the toolchain headers you can find some more description in the comments…


I didn’t dare going into 8.24 territory so I started out with filter_2p anyway, with invert and sum :blush: the purpose now is to add a fixed input filter to a delay line and it sounds totally fine so far. will need some more time to digest that link, but it was a good one, thanks!


Here is a beginner question and issue:

I’ve been working on building a simple cv sequencer. The idea is to have cv0 output frequency and cv1 output an “envelope” for a vca.

I’ve essentially made the frequency sequencer like in the tutorials: A metro increments an accum which runs through the index of a list and the list values get output to cv0.

To do the vca envelope I’ve tried this: split-4 the metro tick, one stays on the accum, one turns a toggle to on, and one goes to a delay, which then turns the toggle back off (I’ve made sure delay < metro both manually and using a div object). The value from the toggle goes out cv1.

So first a bees question: is there a better way to do this or is this an ok solution?

Second, and way more troubling, every time I do this, it seems to function well, except that I get these random high and low values that happen on the freq channel (cv0). I tried to isolate the issue like this: I simply set enc 0 value out cv0, and enc 1 out cv1. When I move them both around at the same time, I get those random jumps on cv0. If I only move one or the other however, it does not happen.

I’ve had the same issue with both the current release binaries and the newest master branch I installed last night.


ok i’ve had a chance to sit down at a bench and reproduce this. opened up a GH issue with more details:

[ ]

(i’m also going to delete some of the noisy back-and-forth here)


ok, after a long hairy night i think we might have finally nailed this issue

@Andrew_Sblendorio, see if these new builds of lines and waves behave better for you, if you like
mod-cv-fix.tar.gz (47.6 KB)