Aleph Testers Corner

[glia]

I dont object to any of that

Especially LINLIN if I understand it correctly

[ngwese]

I converted the list of documented ops to markdown some time back. I think the monome site docs are a copy of that plus maybe some additions. I looked and found this:

https://github.com/monome/aleph/tree/dev/apps/bees/docs…

[rick_monster]

but yeah, docs on monome.org are out of date, everythings out of date

hummm… my only strong feeling is not to change the format of any existing docs right now, just build on what’s already been done (if we can get away with it, anyway)

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

ok - so op_kria is huuuuuuge! We seem to be already up against a 640kb limit which can break the debug build (currently I basically omit the meat of kria op in debug builds). Is there anywhere else we could trim down a significant chunk of BEES program size so we can continue to add features for a while more?

I suggest nuking life_raw before tagging 0.8.0 - probably not musically useful. But iirc this still isn’t a big win on code size…

as for the new/amended utility ops…

LINLIN :

yeah, definitely - I was thinking about a ‘multiply-add’ operator - this seems like a better version of that!

TOG : change input STATE to BANG

agree with that

FLIP :

interesting! what’s it used for?

a monome grid operator for direct column manipulation.

yeah good one!

[zebra]

FLIP :

interesting! what’s it used for?

hm, i guess i just pretty often find myself using a switch input to toggle between two things, instead of just toggling one value. switching between different audio inputs. switching focus between two grid operators. over the years it’s felt common enough to arguably warrant a single operator (like, it’s my most common application of TOG), but i’m not dead set on it.

Is there anywhere else we could trim down a significant chunk of BEES program size so we can continue to add features for a while more?

hrrrm… can’t think of something off the top of my head, but will take a look…

i think everything i’m proposing (with the possible exception of ECA and CHAOS) is dang small in terms of code size.

I looked and found this:

https://github.com/monome/aleph/tree/dev/apps/bees/docs…

oh right! i should go to bed. but yeah thats the thing that needs update before merging to master. also aleph/docs/modules/. (and thanks!)

[rick_monster]

switching between different audio inputs. switching focus between two grid operators.

can this be achieved with presets now those are working better?

[zebra]

oh certainly!

i guess you’re right that anything the proposed FLIP could do, could also be accomplished by a LIST2 connected to PRESET - even with the half-functional, input-only presets . (which can of course, also do more.) but then requires you to set up the presets for it. which is actually my usual method.

i dunno… seemed like a worthwhile thing when i wrote it down. saves cognitive overhead in common situations.

actually what i wrote down was just to have TOG give two outputs, one equal to MUL, the other zero. maybe that in itself would solve many cases. the question that raises is: how likely is it to run out of output slots in the network? how often do you use TOG by itself?

[Yann_Coppier]

I am on the documentation for Operators, I am collecting everything we have so far and will bring it on for all of those that need more precision this week - with the good old format from the website, no need to change that. Also, as I asked before could we use HIST2 (mostly to compare the two last values coming in) and ROUTE2 (to save memory when building complex patches, and also as a logical correspondence to LIST2)? ROUTE 2 is somehow another version of FLIP I suppose, though.

By the way, I noticed in WAVES that dry0Slew, dry1Slew, wave0Slew and wave1Slew don’t seem to work. wm01Slew, wm10Slew, pm01Slew and pm10Slew seem to affect the sound quality (making for less distortion more than a slew, really, as if there was an added filter). I suggest correcting it for wave0Slew and wave1Slew eventually, and dump the others. Maybe we could get some kind of extra elements instead - something that would allow us to pan, maybe?

[Yann_Coppier]

All of those seem relevant to me I must say. Looking very much forward!

[rick_monster]

actually what i wrote down was just to have TOG give two outputs, one equal to MUL, the other zero. maybe that in itself would solve many cases

enough bikeshedding let’s just chuck it in there! It fits the two obvious uses of a toggling button better than anything else we have!

how likely is it to run out of output slots in the network?

hah, good point - in practice every scene will always max out inputs before outputs (right!?). Anything that saves inputs is a win…

i think everything i’m proposing (with the possible exception of ECA and CHAOS) is dang small in terms of code size.

yeah just wanted to flag the ‘running out of space’ issue really as it really threw me when I hit it developing kria itself…

[glia]

hey I am so new at this that I really dont know what I’m doing

after avr32 toolchain is installed how do I make the files needed to load on my sd? I feel like there have been a million people asking this same question at various times for eurorack dev as well

using terminal on mac and hoping to try the new stuff in the dev branch

if there is a link to instructions for the next step that’s all the nudging I need…about to try checking youtube after lunch and might figure it out myself

[rick_monster]

https://monome.org/docs/aleph/dev/ has some clues…

PM me if you’re struggling & are worried about cluttering the thread, more than happy to try & help (but I don’t have a mac!). In a nutshell:

test avr32-gcc is installed & paths setup correctly by typing avr32-gcc at terminal. It should reply with avr32-gcc: no input files assuming all is well. If it says command not found or similar, make sure the installation directory for avr32-gcc is in your PATH. Then once that’s set up right check out the aleph repository from monome/dev, cd into that directory, then:

git checkout dev
git submodule init
git submodule update
cd apps/bees
make clean
make R=1

This will create a file aleph-bees.hex - copy that to the sdcard’s app directory, then reflash the new BEES.

[Yann_Coppier]

While trying to make SHL and SHR to function, in order to add some elements to the documentation I noticed that the BITS operator has an issue: it is sending only one value out of two! So that if I send an encoder with a value of 15 to BITS/IN (which converts decimal to binary) I get a binary result of 0111 (7 in decimal). Basically all odd values are ignored at this stage, which I guess should be corrected.

Here is a patch reproducing it: bit_test.scn (256.1 KB)

The BIGNUM on top shows the decimal value, between 0 and 15, modified by ENC0.
The 4 bignums below show the 4 last bit. I added a MUL (2) so you can try it working as it should by modifying this:
013.Y/A -> 014.BITS/IN
into this:
013.Y/A -> 012.MUL/VAL (in case you want an accurate result for any scene you’d built now)

Then again, I was wondering about the SHL and SHR purpose, as they basically consist of multiplying and dividing by multiples of 2. Are they really useful (my only guess is if you want to dynamically change the number of bit to shift, in which case you’d have to use a LIST and a MUL or DIV), or should we just skip them if we need some space for BEES 0.8?

[Yann_Coppier]

Shouldn’t we remove any duplicates like GRID, as GRIDRAW exists and has way more functionalities, for instance? Same with LIFE, for instance… In most cases the backwards compatibility will be broken when Bees 0.8 comes out, so maybe it is time for everyone to do the jump?

[glia]

Also I’ve been wondering…are there any tools to address arc as freely as GRIDRAW allows for grid devices?

Not really important since so few probably have both

[Yann_Coppier]

VERY good point. I did try to work with an ARC and the Aleph, but really the way the operator works it makes no sense for now. An ARC_RAW would be awesome!

[rick_monster]

Shouldn’t we remove any duplicates like GRID, as GRIDRAW exists and has way more functionalities, for instance? Same with LIFE, for instance… In most cases the backwards compatibility will be broken when Bees 0.8 comes out, so maybe it is time for everyone to do the jump?

I’ve nuked LIFERAW on my active branch - is anyone ever going to use it!? Interesting experiment, but ultimately probably not musically useful imo. I think we should leave the ‘classic’ GRID op where it is. The real space hog is kria, but I use it a lot! if we dial the compiler optimisation of BEES back a bit, we lose some speed but gain a lot of program space.

are there any tools to address arc as freely as GRIDRAW allows for grid devices?

nope, probably won’t happen unless someone with an arc becomes an active developer, (or vice-versa one of the active developers ends up owning an arc!).

An ARC_RAW would be awesome!

don’t be scared to get stuck in! It’s a steep learning curb for sure, but ARC_RAW is one of the most manageable things one could try & work on… You could start with the existing ARC op & try to remove all the internal logic!

[rick_monster]

@Yann_Coppier, @glia had a quick look at the arc operator - started ‘looking’ with my typing paw… Untested obviously seeing as I don’t have an arc! https://github.com/boqs/aleph/tree/arc_raw

[glia]

I look fwd to testing this! Thanks @rick_monster

[rick_monster]

Here is a patch reproducing it: bit_test.scn (256.1 KB)

well spotted - just fixed that & included the patch in my pull-request for new midi ops…

[lazzarello]

I’ve been thinking about implementing the arc OSC namespace in my Midi to Monome adapter. I have one rotary encoder on an APC40 that outputs Deltas as a CC value each tick.

This is another compelling reason to work on a hardware MIDI to Monome serial adapter.