Light & heavy operators

  • Hi, after reaching some limits in the amount of operators I couId use use in a single scene I was rightfully told the limit was NOT in the number of operators as such, but somehow in the number of entries. I then asked myself some questions in order to enhance my patching. For instance, does a SPLIT4 take twice as much as a regular SPLIT? What about a LIST16 compared to a LIST8? And which operators will take most processing power in the end?

    Sooo I made a test, which will definitely not give you some correct figures but might help comparing the various operators in terms of "weight". I have to say the results depend very much of what you put in there to start with, but so far in my experience the relative values still show correctly which operators are heavier than the others.

    About the method now. Here I simply put as many SPLIT operators (one of the lightest ones, clearly) as I could until I saturated the ALEPH, using the WAVES module. I went up to number 127 (which corresponds to the 11 operators that are used as a startup + 116 SPLIT). Then, as I noticed LIST16 is the heaviest of them all I removed the SPLIT one by one until I could put one single instance of it... which showed that 19 SPLIT were equivalent to just one LIST16 (kind of makes sense, right?).

    I then tried to see how much of each operator I could add from that exact same place (startup + 97 SPLIT operators), and here's what I got:

    ACCUM -> 3
    ADD -> 6
    BARS -> 2
    BIGNUM -> 3
    BITS -> 2
    DELAY -> 6
    DIV -> 6
    GATE -> 6
    GRID -> 6
    HISTORY -> 19
    IS -> 4
    LIFE -> 2
    LIST2 -> 6
    LIST8 -> 2
    LIST16 -> 1
    LOGIC -> 3
    METRO -> 6
    MP -> 6
    MIDICC -> 9
    MININOTE -> 19
    M_OUTNOTE -> 6
    MOD -> 6
    MUL -> 6
    RAND -> 6
    ROUTE4 -> 9
    ROUTE8 -> 9
    SCREEN -> 3
    SPLIT -> 19
    SPLIT4 -> 19
    STEP -> 6
    SUB -> 6
    THRESH -> 9
    TIMER -> 19
    TOG -> 9

    Although imperfect, this simple test shows that a SPLIT4 doesn't use more space than a simple SPLIT. Same with ROUTE8 compared to ROUTE4, whereas LIST16 takes double as LIST8. I thought that could be useful to know and so I decided to share, although the method can again be discussed: for instance I tried to put only LIST16 operators from the startup point, and got 13 of them... which doesn't give us the same results at all (that's a ratio of 1 to 9 compared to the amount of SPLIT I could put, whereas with the previous setup the ratio was of 1 to 19). No big deal, as I stated previously in terms of "who's heavier than who" the order stays about the same.

  • how long did this take you and what happened when you reached the upper thresholds of the alephs limitations?

  • i'm guessing the mysterious electricity blackout across most of the northern hemisphere was probably around the same time as the 'upper thresholds' ;)

  • Haha well it didn't take so long actually, less than an hour including other tests. When you reach the upper thresholds then nothing special happens, the Aleph simply won't accept any new operator you try to create. I usually would arrive there with around 80 operators on the whole, knowing I usually can build some rather complex stuff with 60 and quite a few presets. Still, now when I design a new patch I don't hesitate and put some SPLIT4 instead of SPLIT whenever in doubt: you never know, and deleting one operator in the middle of a clean patch is simply impossible, so...

  • this is useful (I think). thanks!

    although i've definitely crashed the aleph trying to do weird things with a very small amount of ops

  • this is from the top of aleph/apps/bees/src/net.h ...

    anything could be changed if needed.

    any increases to any quota propagates to preset size. so there is a hard limit based on available memory.

    we have dynamically allocated SRAM now, which we didn't in first firmware revs, so we could do a (labor-intensive) memory optimization pass and save lots of room for bigger scenes.

    on the other hand, i would really like to re-instate the feature of storing a scene to internal flash and bypassing the sdcard. this means that scenes have to be dyanmically sized though! (right now each one is a uniformly structured serial blob.)

    so, lots of tricky considerations, but this is the current state of things:

    // maximum allocated parameters, connections, and operators
    //// FIXME: need to fix malloc(),
    // and also stream scene data to the card rather than having a huge serial blob.
    // max operator inputs
    #define NET_INS_MAX 256
    // max operator outputs
    #define NET_OUTS_MAX 256
    // max operators
    #define NET_OPS_MAX 128
    // max DSP parameter inputs
    #define NET_PARAMS_MAX 256
    // max presets
    #define NET_PRESETS_MAX 32