GetTimingInfo().blockStartBeat issue

I finally figured out the issue I was having regarding my ChordArp scripter.

Apparently GetTimingInfo().blockStartBeat gets reset properly but after 3 recycles on my computer.

Is this normal?

Saw this too.

https://support.apple.com/kb/PH27270?locale=en_US&viewlocale=en_US

Even if I use event.beatPos the result is the same in that it'll get reset properly after 3 times on my computer.

_blockStartBeat [1]

_blockStartBeat [16.999999992052715]

_blockStartBeat [16.999999992052715]

_blockStartBeat [16.999999992052715]

_blockStartBeat [1]

_blockStartBeat [16.999999992052715]

_blockStartBeat [16.999999992052715]

_blockStartBeat [16.999999992052715]

_blockStartBeat [1]

Not 100% clear on what you’re trying to do but gettiminginfo.blockstartbeat does not refer to actual events it refers to the process block that an event is found in. There is no guarantee that during looping the process block will always land on exactly the same point in time.

For events look at the Beatpos property of the event itself.

I can write a little more at my computer now...

Basically you need to understand that midi is processed by Scripter in blocks of time, called "processing blocks". These processing blocks are not related to tempo or meter or anything at all like that, they are very short blocks of time, most likely relating to the audio buffer size you have configured at the time.

So during each processing block, Scripter gets a chance to prepare midi that corresponds to that length of time. You have a start beat, which is a decimal value corresponding to the exact start of the process block, and and end beat value, which is the exact end. Then each event has a beatPOS property which defines exactly where in time that event will be.

Scripter gives you the opportunity to process midi events with callback functions HandleMIDI() and ProcessMIDI(). In the HandleMIDI() case, it is called for each event in a process block. If you have 3 midi events that all happen to be occurring within a process block, HandleMIDI() will get called 3 times and each time its called for those, you will see the same start and end beats for the block...but the actual events have their own beatpos property that indicates that exact position of the midi event within that process block.

processMIDI() is basically called back once per process block and in there you can schedule any events you want that start no sooner then the start beat of that process block.

the process block may or may not start exactly on a beat boundary. Makes sense that it would sometimes land on exactly beat 1, certainly for the first time through, but there is no garauntee that the process block will always line up on bar lines that way, its most likely more related to the audio buffer, but we don't really know, and it should not matter.

The video shows what's happening but here's a simple picture that describes the issue.

It’s not wrong info. In that case the process block starts just before the loop point and wraps around into the start

Huh?

Look at the picture, it says it's all the way to the right (16.999999992052715) which is wrong.

It should be "1" because that's the starting point for the note. The note doesn't play all the way to the right at 16.999999992052715.

Let me be clear too, the note plays just fine but the information passed back is wrong.

At this point I already have a workaround for this anyways so it's really no big deal.