ValliSoftware Posted August 30, 2018 Share Posted August 30, 2018 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? Quote Link to comment Share on other sites More sharing options...
ValliSoftware Posted August 30, 2018 Author Share Posted August 30, 2018 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] Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted August 30, 2018 Share Posted August 30, 2018 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. Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted August 30, 2018 Share Posted August 30, 2018 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. Quote Link to comment Share on other sites More sharing options...
ValliSoftware Posted August 31, 2018 Author Share Posted August 31, 2018 The video shows what's happening but here's a simple picture that describes the issue. Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted August 31, 2018 Share Posted August 31, 2018 It’s not wrong info. In that case the process block starts just before the loop point and wraps around into the start Quote Link to comment Share on other sites More sharing options...
ValliSoftware Posted August 31, 2018 Author Share Posted August 31, 2018 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. Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted August 31, 2018 Share Posted August 31, 2018 Please read my longer post above. The process block does not correspond to the start of a note except for maybe the very first beat. Quote Link to comment Share on other sites More sharing options...
Dewdman42 Posted August 31, 2018 Share Posted August 31, 2018 You need to use the event.beatPos attribute. Nothing is wrong with LPX here Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.