Aleph Testers Corner


I was actually thinking about a SEED input, which would be very nice indeed. Thanks for the clear answer!


this bugged me too last time I used RAND - quick hack using BEES/pd to debug - boom!

the obvious deficiency of the approach ezra described is that if you desire a range which is not a power of 2 & bitshift to the smallest power of 2 greater than that number, subsequent application of the modulo operator will tend to skew the distribution toward the lower end of the desired range.

Therefore I’m shifting the 32 bit number right by 25 - bitwidth(range) (as opposed to 32 - bitwidth(range)) before applying modulo. I think this will tend to reduce of skew by a factor of ~ 2^7 for most numbers.
(and there’s nothing special about 7 I picked it… randomly!)

added that feature - again pd/BEES helped me catch a dumb typo using gdb…


I just tried to compile using the corrected STEP operator but got a bug in line 105. Will get back to it later, right now I have to try a lot of stuff. You are on a roll!


Ok I might have made a mistake, but after compiling the Aleph freezes each time I trigger a RANDOM operator. Also, can’t see any SEED input there. What did I do wrong, I wonder?


I just made new midi program change operator - now my behringer fcb1010 can talk to grains! Totally horrible FM guitar sounds & silly pitch-bend guitar pedal fun…

sounds like it didn’t work, could be any of a number of things depending on what codebase you’re starting from… I’ve lost track of what features from skektek & boqs have/haven’t been merged.

Working towards testing all my recent changes enough for a merge into monome/dev then I think it’s time for release 0.8.0 !!!


Yes, you are most likely right! Also, I just tried to add one operator in the middle of a scene that uses two presets and still got an issue… but this time it is something like a mix of the two presets appearing, with the elements included in both presets appearing on top of each other. Anyway I’ll wait until 0.8.0 to say more unless you have a whole version I can compile and test now, mostly because I suspect my mashup to be quite a mess right now! Oh, and fantastic with the new op, I just saw it a few minutes ago!


I’ve just raised a pull-request from the aleph boqs/dev branch into monome/dev. If you can manage to get a clean checkout of boqs/dev & test a bit from that, it’d be super-helpful towards the 0.8.0 release!


Ok, I had to download separately the libavr32 content, without which I couldn’t compile. Done now, will begin testing!


hey yeah, did you get libavr32 from monome’s github or boqs? boqs aleph dev branch should be built against the boqs dev branch of libavr32:

alternatively you can do the git submodule song & dance:

git submodule init
git submodule update

those commands (when executed from a fresh checkout of boqs/aleph/dev) should grab the appropriate version of libavr32


Thanks, I now have incorporated this version.
Then my first test with RANDOM has shown a bug, as can be witnessed in this scene: Random_test1.scn (256.1 KB)

The tempo of the RANDOM triggers is fixed, and you get 3 BIGNUM on the screen.
ENC0 (0-15) is changing RAND/MIN (result on the upper left BIGNUM).
ENC2 (0-15) is changing RAND/MAX (result on the upper right BIGNUM).
The lower BIGNUM shows the results from RAND/VAL.

It seems to be working fine, except you can’t ever access the upper limit, so that if you choose MIN=0 and MAX=1 you will only get 0, for instance. And if you use MIN = MAX then the values triggered explode and go from 0 to 140 or something like that, although MIN and MAX are still equal on the INPUT page.

Some more to come soon!


bug easily reproduced & fixed, posted to boqs/dev. Thanks!


Good news, STEP is so far behaving perfectly, and so is RANDOM.
Same with op deletion and insertion, so far no issue that I could put my hands on.
I will of course test some more, but are there some specific things you’d like me to focus on?


preset system, maybe? load/save of large scenes?

Just all round really I want to know if there are any stability issues or specific bugs. the best form of testing at this stage could be just playing the device & reporting back if any more bugs surface!


Got my aleph this week and so far I’m loving it. Just got done doing a performance with a lines scene earlier and it went very well (using bees 0.7.1 release). I saw the big merge from boqs dev branch and am going to try to get that running tonight! Thanks to everyone from the past for bringing the aleph to this point and I’m looking forward to the future.


All good so far, I have made 3 big scenes and no problem really. I noticed my Aleph took longer to start, showing a blank screen to start with, but that’s mostly it for now. Ah yes, a detail: when using several RANDOM operators, even with different seeds I get the exact same patterns when I recall a scene. Then if I go modify the seeds it works again, which tends to show the seeds are not initialized properly. Anyway I have played a concert this Saturday with the scenes I made, mostly because I found them stable enough.


i also played a little set on saturday making extensive use of varilines and focus-swapping between gridraw and kria ops. noticed some glitches in output connection menu and in grid LED updating, but no regressions

spectacular work, mysterious alchemist.

have merged to monome/dev branch on github, so please, everyone go ahead and test the heck out of that.

would like to get a bit more documentation in before we put v0.8.0 on it and throw the alchemist a party. :tada:


let’s do it! (how do we do it?)


ha. ahhahaha! i don’t know, i guess we should have markdown in the git that documents every op and every DSP param. right? like grown ups.

then i guess we should use some fancy comment fomatting to generate the markdown automatically. like all the cool kids do. ahahahaaha.

so i guess tomorrow i will sit down and write many words.



Look, docs!

is the source for those pages html/css? I could just update to include at least the new ops.

heh, kinda! - needs updating though…

I’d also like to get a bit more done on the midi side (assuming it doesn’t turn into a white elephant) before tagging 0.8.0. Just because I feel like there should be some scene-breaking changes & we should aim for a period of stability after 0.8.0. Ditto for some tweaks I want for whitewhale & kria - these ops could use some extra inputs to switch between patterns when a midi interface hogs the USB slot…


yes yes - excellent!

but yeah, docs on are out of date, everythings out of date, best practice says we should keep some kinda doc in the repo (html or md or whatever) - agree / disagree? can take from git, no problem (i would hazard to state)

i’d also like to add a couple utility operators, if no-one objects:

  • LINLIN : inputs IMIN, IMAX, OMIN, OMAX, outputs VAL.
    makes a linear mapping from an input range to an output range. (replacing combinations of MUL/ADD/DIV in many situations)

  • FLIP : inputs BANG and MUL, outputs A and B (POS and NEG? ON and OFF?). (replacing TOG + SPLIT + SUB (B=1, B_TRIG=1) and more MULs or whatever)
    (that is: when an input to BANG is applied that is >0, A puts out the value at MUL [default 1] and B puts out 0. the next positive input to BANG reverses that state, putting out MUL at B and 0 at A. &c.)

  • TOG : change input STATE to BANG (cosmetic only. more obvious i think - i’m always forgetting whether it bangs the toggle or actually sets the state)

and am considering more elaborate operators:

  • ECA : an elementary (1d binary) cellular automaton

  • GRIDCOL: inputs X and COL, outputs X and COL.
    a monome grid operator for direct column manipulation.

  • HIST8: output the last 8 values in a circular buffer (8 outputs)

  • HIST16: output the last 16 values in a circular buffer (16 outputs)

  • HIST should be renamed to MEAN or AVG. or maybe HISTX should also have mean/median outputs. or should be rolled into more general STATS op.

  • CHAOS: equivalent to CHAOS module discussed for teletype.

and, i dunno how to do it exactly, but something like GRIDHIST or GRIDSCROLL: i want to be able to make scrolling displays on a grid controller (arbitrary number of quads, but mostly considering m128), and also make arbitrary use of presses.