So, as well as the being the most important thing in comedy, timing is also the most important thing in a loop playback engine that is using some sort of sequencing to get “cool” things done. Well any kind of sequencing thing really, and Orbiter wasn’t playing nicely. It seemed to be speeding up – which was truly odd.
When you are writing real-time, re-entrant, parallel code in any product (and that’s what I’m doing here) you need to have a mental model of what is happening under the hood, and according to my model for Kontakt KSP any timing errors should all be about showing up late not early. I ran some tests. I ran some more tests. I went and had a lie down. It seemed that Orbiter was glitching somehow when the Repeat effect was used in a loop, but only when the repeat effect was applied in adjacent slices. Turn off repeats and apply any number of any other slice effects to any or all of the 4 playing loops and it seems rock solid.
So I’m a bit stuck. Right now I think I might have to refactor the play_a_note routine again, taking out all the sequential bits, make those happen, well, sequentially and then deal with the wait_states in the repeat section. I get the feeling it will get worse here before it gets better. Current thinking? There are a lot of listener call backs (24 per beat) so they might be making things “queue badly”, or the tasKfunc has some waits in it(otherwise what’s the point in using it) but maybe the unload/reload of state based values is also clogging the wheels somehow – can you see I’m really casting around for answers here?
I realise this is all getting very technical very fast, but if you get no other idea from this you should take away that I don’t know why its doing it and I’m trying a bunch of “stuff” to get it to stop. This “stuff” has in no way been identified as a solution to some defined problem – cause I don’t know what the root-problem is. What I suspect is happening is that tcm.wait(some period) cant interrupt and get back in to its correct slot as another taskfunc is still doing something, but this would make the “failing” wait show up late not early… mystified.
These are the dark and ugly hours of product development, when the temptation to leave this all behind and go back to being a failed musician is most demanding.
Meanwhile as a small aside(well it’s timing related really..): I’d been playing the instrument a fair amount, and the one thing I was struggling with a bit (as a novice on this thing, as we all will be at the start) is getting the timing right for retriggering pattern steps, so for instance I might want to move the pattern to pad 9 every 4 beats, so as the pattern plays…: 1,2,3,4 <click on pad 9>, 9,10,11,12<click on pad 9>, 9,10,11,12, etc. which means timing these clicks AFTER pad 12 has played but BEFORE pad 13, and sometimes I miss it. So I added the ability for Orbiter to accept quantised events. If you set Event Quantise(in the settings page) to (say) 4 then Orbiter will accept your “event”(say a pad click, or a resync etc.) anytime but will only act on it every 4 beats. So the interactive stuff above is easy now: 1,2<click on pad 9 say now>,3,4 , 9,10,11,<click on pad 9 somewhere here>,12, 9,10,11,12 etc.
Here’s a picture of a genius of timing, started out as a musician, no surprises there.
