help me with maths lessons - bees talking to lines

  • Ok, so I'm really struggling with some number issues here and wondered if anyone already has a good formula.
    What Im trying to do is use TIMER op values to set values in the LINES module, essentially for some tap tempo and other slicing projects.
    here's the problem i'm stuck with -

    - the pos_read value of a delay goes from 0 - 63.99822 (which is puzzling to start with)
    - values in LINES are in seconds with a decimal place
    - the TIMER op in Bees gives an output in miliseconds, but you can't get decimal places in BEES,

    - so if i have for example a value of 1500ms out of a TIMER, how do i get this to be 1.5s in a LINES value?

    my thinking (but it's not working so probably wrong and long winded)
    - an ENC going from 0 - 32767 translates to 0 - 63.9982 in LINES
    - and an ENC set to 1 gives you 0.00190 in LINES
    - so 1 sec as a pos_read in LINES should be 526.315 in BEES?
    - so 1000 needs to divided by 1.9 to get 526.315 but you can't get decimals, soooo
    - I multiply my TIMER value by 10, and divide by 19 and send it to LINES

    there must be a better and more accurate way surely?
    [EDIT - i realise that the buffer is supposed to go 0 - 60, and that would make 512 the right number, but that's still impossible to work with if you want to set accurate time positions from BEES > LINES .. I'm sure brian/ezra have some trick for the integer>fraction communication that i just can't work out yet)

  • see here for discussion of timebase issues. The root cause of the problem is that whilst 32 bit numbers are unwieldy for making parameter adjustments in bees, 16 bit numbers are insufficient to index longer time intervals. So it needs some attention from the programming side. You can do the multiply, divide trick (multiply first of course) but you'll only be able to index like 6 or 3 seconds or something before the 16 bit number saturates at the multiply stage.

    Meanwhile I've been dreaming up a new module which will come at this problem from a different angle. When I was trying to hook up tap-tempo to loop length I was trying to make a crude sampler. So my current thinking is build a module which can be hooked up *statically* via bees for echo, chorus/flange, sampler and pitch shift duties. (for sampler there'd have to be boolean inputs 'start sampling' 'stop sampling') The thinking behind this is that there may be new sounds to be had once you add a dynamic network into the equation.

    So I think there's room for a new delay module which abstracts away the 'tape' from lines. Maybe today's the day I actually make a proper start on this. I got as far as building a crude pitch shifter (which runs 8 'echoTap' grains) then got distracted and started working on other (non-aleph) things. Some un-resolved questions in my head about how to expose enough module signal routing to bees without blowing all the blackfin cpu cycles on mixing. Hoping initially to achieve 8 autonomous echo 'grains' before attempting any non-trivial optimisation...

  • the solution you want is simply to divide your 'tempo' by 2, and send that to delay0 or whichever buffer param you want.

    now to explain (as best i can)...

    i'm not sure where you got the "buffer is supposed to go 0-60" as i thought the param display of 0-64 was correct (ie. 64 second buffer). this means that for every increment of 512 you add 1 second to the buffer time.

    this aligns well with the bees way of handling timing as it operates on 1024 ticks per second. i believe this is an optimization issue where the 2.4% error was thought preferable to using a huge amount more processing doing the math to make each second 1000 ticks long.

    the benefit is it makes math inside of bees more consistently focussed on base 2 (ie 2x2x2 etc.) rather than 10.

    the result is that if you tap a tempo into a TIMER op once per second it will respond with '1024' which you divide by 2 to get 512, which send to delay0 is 1.000000 seconds.

    i'm aware of some time-base issues that perhaps make the accuracy of all this slightly dubious (rick probably knows far more than me), but i think a DIV 2 will get you pretttttty close to a solid tap tempo.

    an alternative is the 'trigger from bees' approach where you rely on bees for the actual loop timing and retrigger the pos_read and _write each cycle.

  • ** this makes me think we need to make a sort of explanation of how to interface bees & the different modules, but i'm at a loss to the best way of expressing these finer details. do you have any suggestions?

    ** and regarding fractional math on the aleph we obviously need some smarter way of managing such things. my intuitive response though is that when dealing with large numbers, rather than multiplying up to the next integer (usually means x10) it would be safer to try and find the remainder, rather than compute the whole thing.

    eg. to multiply 1000 by 1.9
    (the direct way) ( 1000 * 19 ) / 10 = 19000 / 10 = 1900
    (the remainder way) (1000 * 2) - (1000 / 10) = 2000 - 100 = 1900

    this second way is rounding up to the nearest integer (2), then subtracting the difference (0.1) by a division of 10. this approach avoids 16bit saturation for much larger numbers. it will become less accurate with smaller numbers though

    (a 3rd approach) (1000 * 1) + ((1000 / 10) * 9) = 1000 + (100 * 9) = 1000 + 900 = 1900

    this last approach will avoid saturation altogether (if the answer is itself in range) but is only preferable if the input value is very close to saturation.

    ** sorry that was kinda super off topic. i'm gonna drop this into a wiki page now..

  • @galapagoose @rick_monster thanks for all the info!
    hmmm, ok i see the problems!
    what i'm trying to do (which may explain why i need greater accuracy) is make a simple slicing tool.
    I want to record a loop, using a TIMER to measure the whole length. Then I want to be able to slice this either across a monome grid or a pad controller (e.g. 8 or 16 slices) and then jump to those positions within the buffer. This means I can't use the 'trigger from bees' approach (which i used for the looper video i posted) because i need to choose position within the buffer, but also the accuracy seems to be way off when working with smaller numbers as you mention.

    @rick_monster phew, i looked through that github thread, a lot of it goes over my head but i sort of get the gist. It seems you and @zebra have some plans up your sleeves so I'll hold tight and see what develops in terms of accuracy between bees and the blackfin :)

  • @galapagoose 0 - 60 is what you can set the pos_read and loop paramters to if you set them directly from the INPUTS page, but if you control them via bees (e.g. with an encoder) you can get them up to 64? is this a bug?

  • maybe a math operator, e.g. like a bignum with number conditioning could be useful?!

  • oooo, i just had a thought (which is probably a feature request actually) for an addition to the Lines module that would give it some MLR type functionality. Could it have some internal slice parameters.. e.g. you turn slice mode 'on' and set a division (e.g. 16/32 or arbitary) and then you can tell the pos_read to jump to specific slices. That way Lines would handle the accuracy of the playhead position.
    but i guess setting the overall loop and/or buffer length to divide would still be fiddly to do with accuracy from BEES?

  • Would it be useful to have a communal BEES math spreadsheet?

    I still need to figure out stuff like the 1v/per octave scale in Aleph encoder values.

  • Can someone make one of those awesome circular rulers with all OPS and how to scale them properly?


  • @emergencyofstate that would be awesome!

  • @analogue01 heh, I was half kidding but I do love those things. Like you mentioned, a spreadsheet -at the very least- would be helpful and a good starting point. Maybe a google doc or something similar?

    -- if we get a good robust spreadsheet going, maybe I or someone else will get adventurous and try to make an OP value calculator/converter app or something.

  • Hey buddy. Didn't I say "I or someone else.." ? Also I didn't suggest the spreadsheet (analogue01 did).

    anyway, why the insults? I'm aware of what analog to digital conversion is and vice versa, I was just confused in a thread regarding op names.

    Anyway, Go ahead and fuck off (all of your personalities)

  • that was unnecessary @raja

    @eos i'm curious to see how this scaling reference develops...keep us posted

  • You said you would fuck off. I'm seeing you add shit to your post. Dude, please let it go. I know you have this huge resentment towards to community and maybe the western world but it really comes across as trolling, passive aggressive, egotistical bullshit.

    We know you're smart. I am dumb. We don't appreciate you. I've never contributed anything and expect everyone else to do the work but me. Better? Will you let people be instead of stirring the pot for your own enjoyment?

  • @raja i've got no problem with your feelings about the scaling spreadsheet
    if thats all you wrote, mr.eos probably couldve laughed that off or ignored the veiled barb :)

    however, dredging up stuff from the old adc/dac thread was off-topic and a shade too personal

    regardless of the veracity

  • I absolutley should have ignored it, sorry for the pointless spectacle everyone.

  • not at all

    i mightve done the same

  • for oscillator hz:

    1 semitone = 256 steps in BEES.
    1 octave = 256 * 12 = 3072 steps.

    so this is linear pitch, exponential frequency, just like a 1v/octave interface. [ 1.2v/octave in BuchlaLand ;) ]

    for time base:
    1 step = 1/512 seconds. (sorry, i know it's pretty awful.)

    if you don't want to read the long discussion above, here's the summary:

    i'm going to revise lines so that there are actually *three* time inputs:

    - a coarse input in millseconds
    - a fine input in samples
    - a scaling parameter (maybe a global for all time params in the module) for e.g. halving the resolution, allowing >32s addressing.

  • another option, BTW, is to actually make the application tick of BEES run at 1/1024s rather than 1ms period. then TIMER would map exactly. you still need a solution to scale the resolution of the controller so that you can address more than 32k seconds.

    this is appealing to me, but i thought it would suck for everyone else to have to always work in this power-of-two time unit, instead of the familiar millisecond time base. this would go for all operators that deal with units of time in any way. so i made the application tick as close to 1ms as possible.

  • oh, i hadn't read it closely enough, but @galapagoose above is not quite right. in fact: TIMER actually emits milliseconds, just like METRO accurately accepts them. the problem arises

    at the very least, i need to change the declared parameter type for "seconds" parameters to something new. then they can be more easily targeted for customization.