new ops

  • just noticed:


    allows input from monome arc devices. provides rudimentary led feedback for further expansion. all outputs occur for any arc movement.


    FOCUS: when 1 operator is active. when 0 operator ignores arc.

    LOOP: loopback mode. when set, rotating the encoder will set and display an internal value [0, 255]. when disabled, the leds and encoders are decoupled.

    RING: input selects which ring to send led data to [0, 2/4].

    POS: input selects which led to address in the selected ring [0, 63].

    VAL: input sends brightness value to selected led [0, 15].


    NUM: outputs which ring has been rotated.

    DELTA: rotation amount for input to an ACCUM op.

    VAL: internally stored value between 0 and 255.


    crossfades between inputs A and B according to input X using a linear curve. all inputs cause output to be updated.


    A: sets the A input value.

    B: sets the B input value.

    X: fades between input A (X=0) and input B (X=128). values outside the 0-128 range are clamped to the range.


    VAL: the output of the crossfader.


    connect a Human Interface Device over USB. multiple operators are required to monitor different bytes. connect a gamepad, shnth or manta.


    BYTES: sets which HID byte to monitor

    SIZE: sets the bytesize of the parameter to 8/16 bits.


    VAL: the output value received from the HID.


    white whale, for grid. see white whale


    FOCUS: when 1, operator is active. when 0, operator ignores grid

    CLOCK: advances the step clock by 1. expects alternating 0/1 from a METRO op.

    PARAM: input parameter for setting CV values; range [0,4095].


    TR0-TR3: trigger or gate outputs from the sequencer; [0,1].

    CVA-CVB: continuous outputs. for map mode MUL by 8 for CV output. for waves, MUL by 15, then DIV by 2.

  • oi but you missed DIVr (a combination of DIV and MOD, really good for note quantizing) and SERIAL (i have no idea how this works!), plus ENC now has /DELTA and works great with ROUTE8 which now has 8 outputs .. hah!

    why do you torment me by making me second-guess any time i try and make behind-the-scenes changes before an announcment! hahah...

  • lol

    cant contain my excitement
    saw em earlier and thought maybe the announcement was imminent

    this is pretty massive

  • also the list is getting more and more elegant...i like the distinction between FS and regular SW (or was that there before?)

  • it's new! also the SW and FS are now numbered 1-4 and 1-2 respectively to aide in selecting them in a list.

  • the shnthing is forthcoming
    this makes me want an aleph more

  • all good news!... I really need to get a grid. FADE will be fun in the meantime :)

    @wednesdayayay shnthing? that just means shnth support right? I know there was some talk on muffs of porting shlisp to run on the aleph, but that's too huge a project to be "forthcoming"

  • indeed shlisp would be a substantial porting effort and more than any of us is intending presently. @wednesdayayay is likely referring to the HID object which will allow you to attach a shnth over USB to use as a controller – ie. having squish input to the bees operator network.

    we're almost there on the update & documentation. aiming for a monday release!

  • make that wednesday!

  • hell yes!

  • out of interest in this update has anyone managed to check out the timing issues in Bees? i.e. that neither 1000 or 1024 setting for metro period doesn't actually seem to run at 1000ms
    (see this thread - )

  • honestly I'm not that interested in porting shlisp mostly because I wouldn't even know where to start.

    after having used Max/msp to interface the shnth's controller surface with aalto I can imagine extending that with the aleph would be a dream to program.

    This also would I imagine allow you to play the shnths internal sounds use the control surface within an aleph patch and potentially also send the bars from the shnth to the 4 CV outs to control something else. Then of course you just pull some of the modular sound being driven by the aleph CV outs to the shnths input

    oh boy I think I'll re watch all the aleph videos now

  • @duncan_speakman thanks for reminding me and i'll look at it again.

    but my (old) past experience is that the core timing is fairly accurate (to within <1us), so that 1000ms period metro = 1000ms output, both in bees and in standalone sequencers, though it is always possbile to *slow* things further, it's never possible to speed them. <br />
    i carefully and specifically tuned the core app timer to be 1ms, in the init code referenced in other thread. that is really the only line of code that could cause the reported effect. i suppose there could have been some crazy regression on it...?

    again, i'll look at it, but i'd rather someone else did since my test cases now are limited to a prototype (which could behave differently in such matters; it's a different avr32 part model) and the rather broken unit i swapped from you in belgium. so i'd love more feedback from others please. metro running at 70% of its reported period is a huge error that should be instantly noticeable.

    anyways i promise i'll do a timing test later today.

  • this thing with the number 1024 having anything to do with metro period, is totally bogus, please remove it from the mind.

    the origniating data is that currently the control value 1024 translates to 1s in time-based parameters for aleph-lines; this is pure coincidence and subject to change.

  • @duncan_speakman
    ok, looking at this particular proto unit i am also seeing a timing discrepancy. following up in the other thread.