Hi, I've tried with "T00" but it's reset to zero at every access, "PO" AND'ed with 0xFFFF always gives me 0x7C when the host (AUM) is stopped and 0x7A when transport is running and I haven't found any other option in the manual... Also, how can I execute a loop continuously (without breaking after 128 iterations)? And can I have more than one loop being executed simultaneously? Any help is very welcome.
> I've tried with "T00" but it's reset to zero at every access
Accumulate a timer variable, like so:
MAT P1 = P1 + T0
P1 will increase each time that rule is evaluated.
> "PO" AND'ed with 0xFFFF always gives me 0x7C when the host (AUM) is stopped and 0x7A when transport is running and I haven't found any other option in the manual...
'POS' should return the number of ms elapsed since transport start if transport is running. If not running, it should return 0. Maybe I have a bug here...
> Also, how can I execute a loop continuously (without breaking after 128 iterations)? And can I have more than one loop being executed simultaneously?
If you want to bypass the 128 max loop iteration safety net, then you can run concentric loops.
It is not possible to run a while loop continuously since in AUv3 we get called back by the host in fast render cycles.
You can however, run an inject loop (which is how Nimble Looper works for example), where you inject some sort of trigger event into the script with a delay and then when that event is seen inject another trigger.
Simple example to do something every second:
if load define loop_trigger F0 12 34 56
# start inject loop send loop_trigger F7 +inject end
# loop trigger handler if M0 == loop_trigger .. loop body here
# schedule another loop trigger send loop_trigger F7 +inject +D1000 end
As for the bad values in PO, I now cannot reproduce this myself. After Streambyter crashed when installing the modified rules while AUM transport was running, I've started from scratch and now PO contains the milliseconds since start like it should.
I have yet to find a way to build a beat-synced LFO though. Taking PO and BP into account does not seem to be accurate enough and will drift away sooner or later. Any ideas?
StreamByter's event accuracy is only down to the millisecond, but when performing calculations on ms numbers you are likely to suffer from integer truncation.
Your calcs are best done using the 'P' array (precision) say using microseconds (multiply inputs by 1000 before multiply/divide) and then on the final calc of the value you are going to set in a delay divide by 1000. That should push/pull so that it won't drift - if you get my drift.
If you want to post a snippet of code where you are calculating events delays, I can suggest changes to increase accuracy and resolution of calcs.