DSP Robotics Support

trogluddite wrote: exact song position

Host is clocking at 8/4. I'm thinking to create my tempo's from this tick..........
This Arp Module is a real "tin of worms". So many different ways to go about it........
Lost with all the possibilites.

trogluddite wrote:Getting closer with the PPQ too

Keep going Trog - who knows where this going to end.....

OK, here's the next update in my little series of PPQ experiments...

This should fix the skipping of events where they match frame boundaries, and also removes "doubles" when host playback loops return to the start.
The PPQ sync is also a stage further to becoming a module in its own right - it now output a Ruby event rather than MIDI directly. I've fed it into a ridiculously basic "sequencer" module that just cycles around notes, and this hasn't reduced the accuracy in any way at all.
The Ruby output at the moment is a small hash with two values, which you can index by name using a symbol...
ppq[:beat} = the current beat.
ppq[:step} = then number of steps since the song start (one step = the note division)
(NB - don't miss the colon ':' at the start of the symbol names - they are not strings!)
The next test will be to do a pure MIDI plugin, and see if the host sync still stays solid even when the plugin is not processing any audio.

There is one slight problem that I can't resolve though...
To overcome the one frame delay of the mono->frame component, the module has to predict the PPQ signal slightly in advance, which means that the beat/step numbers 'skip' when the host jumps back to the start of a looped section. So long as the loop is quantised to the step boundaries, the timing stays spot on though, it's just the numbers that are out for that one event - so it won't be a problem if the Ruby link is used purely to trigger events.

Oh, and there are no nasty surprises with 100% CPU gobbling 'scopes this time!!

trogluddite wrote:There is one slight problem that I can't resolve though...

Aha, think I've got it.

The PPQ section now includes a VST "Delay Compensation" primitive to force the host to send the PPQ data earlier than usual, so that it can be read ahead of time. This also simplifies the code quite a bit, as the "look-ahead" doesn't need coding inside the algorithm.
This will need testing in a variety of hosts, as I am not certain if ALL hosts will read the compensation value or not - but in Reaper it is rock solid, and now gives correct beat positions even when looping playback. If you see any drift in your host, make sure that whatever latency compensation settings you have available are enabled before bug reporting.
The compensation is fixed at 512 samples at the moment to make the coding easy, and so that the value doesn't change after load time (I seem to recall that some hosts don't like that!). For the PPQ to work reliably, you must be using an ASIO buffer size no more than 512 samples otherwise the 'frames' will overlap with the compensation delay.

I also tried doing a couple of faster than real-time renders (also in Reaper) - and again, rock solid timing that lines up sample for sample with "live" playback.

Experiments with using this as a pure MIDI plugin for driving other VSTs have been a little more troublesome, though - I'm getting some slight timing variations, including hits which are a little early. Too soon to tell if this is a FS sync' problem, the slave VSTi, or just a quirk of Reaper's MIDI routing, so I won't pass judgement just yet.
Many more tests to do!!!

Version 10...

Aha - using plugin compensation really seems to have done the trick. Now that there's no "prediction guesswork" going on, I've been able to use a proper crossing detector to get the time intervals.
CPU load? Meh! Don't worry about it - I measure about 1-2% on my Q6700.
Testing in Reaper, I've managed some seriously swoopy tempo and time signature changes, and everything is bang on repeatable timing - for off-line renders too.

Also some other improvements...
- Bar start position is now added, so you can find which beat or subdivision you are on within the bar for different time signatures.
- There's a separate output for the current position that updates when the song isn't playing, so you can display the current position when editing.
- The output hash now has the following parameters...
ppq[:step] = the number of step divisions since song start.
ppq[:beat] = the number of beats since the song start
ppq[:division] = which step of the current beat when you use the divider
ppq[:bar_beat] = which beat of the current bar you are on
ppq[:bar_div] = which divided step of the current bar you are on
This data is the same for the main output and the display output - the only difference is that the main output sends an event only when playback steps up by a division (sample accurate); the display one updates any time the visible values change (i.e. moving the playback cursor when editing).

Oh yes - silly me, should have said before. The 1-2% CPU load, I mentioned - that was for my entire test rig; including the CPU load for Reaper too!

Bugs!
- Seems to be sometimes that the things doesn't start up at all - I think it may be if you load the host with the song cursor at certain positions somehow clashing with the saved values in the schematic. I've found I can usually fix it by moving the cursor to the song start, saving and re-loading.
- Sometimes doubled events if the note division is changed during playback. Might sound better if the changes only take effect at the next full beat,

That'll be the next stuff to work on, then!

Hi Trog,
Sorry for the delay in sending this report, was busy with other stuff.
I having been testing your uploads along the way though.
Version 6 was 100%.(Fl + Abelton Live)
Version 7 & 10 100% in Abelton Live.

trogluddite wrote:If you see any drift in your host, make sure that whatever latency compensation settings you have available are enabled before bug reporting.

Version 7 & 10 fail in FL Studio- (tried a wide range of numbers for delay compensation)

I don't know Trog. In all my years recording I've never once had to adjust delay comp in a host.
This is a "murkey" area. I'm sort of hoping you can (get in & get out) of this area without
leaving a trace.
Ideally, it should somehow "calculate" whatever compensation is needed and automaticly provide it.
If that's possible.
Hope this helps.

Thanks billy,

That's a real bummer - it works so perfectly inside Reaper.

In what way are the v7 and 10 affected? Missing events, random timing, fixed delay?

billv wrote:Ideally, it should somehow "calculate" whatever compensation is needed and automaticly provide it.

That's kind of what the older versions do - could be why they work better for you. They use the 'slope' of the PPQ ramp to predict where the beats will hit - but there's no other info from the host to make this any more accurate.

I've sent an e-mail to Malc asking if a non-delayed frame for the PPQ data would be possible, as that would be the best solution - better than any of the workarounds that I've had to use so far. As I said to him; the Ruby timing is so awesome, it's a shame that there's just this one tiny detail that isn't quite right.
That extra buffer of delay from the mono->frame is the root of the problem - the host does send the data slightly in advance, but the extra delay cancels it out, and we're left trying to 'guess the future'.
Doesn't help that the VST spec's is so vague - it specifies a 'delay compensation' parameter, but no what (if anything) the host has to do with it. It seems that Reaper uses PDC on the PPQ signal, but I was worried that others might not.

I'm just downloading the FL and Ableton demos now, to have a tinker and see if I can figure out what the problem is - not used it before, so it might take a little while. I have a few test rigs I've been using to help analyse the timing, so I should at least be able to see if the problem is fixable or not.

Otherwise, maybe I should have a panel option for "simple" or "advanced" modes. The older versions work fine for most step sequencers etc. and also for other stuff when there's no looping or big tempo changes - but I really don't want to throw out the PDC versions completely - where the host does support it, it nails the timing problem to perfection from what I've seen inside Reaper.

V6,V7,V10 All good in Abelton.
V6 Was good in FL. So it's the change made between 6 & 7 is what FL dosn't like.....

trogluddite wrote:s fixed at 512 samples at the moment

Is that why I'm getting the above result?

That's great, thanks billy - just what every dev' needs - quality Beta testers!

Yes, that confirms exactly what I thought - v6->v7 was where I changed the code from "built-in" prediction to using the delay compensation. And I'd say, judging by eye, that those 'blips' are the default envelope settings, which would make that gap almost certainly the 512 samples of the delay compensation.

So Reaper, Ableton good - and Ijust tested on my old and dusty version of Cubase (yuck, how was that ever my favourite?!) - that has perfect timing too, all the way up to PPQ version 10.

So it seems that, so far, FL is the odd one out - all the others are using compensations on their PPQ clocks, but FL doesn't want to. I had a peek at it, but it was a bit baffling, so I need to RTFM before I start testing in there properly - even if there's a setting that can be changed, I wouldn't want to do anything that would mess up people's beautifully crafted projects!
At least we know PPQ v6 works well in there, so I can at least try to offer some kind of user setting to optimise it as much as possible.

Annoying, but not unusual I suppose - even Reaper has a page full of VST plugin optimisation options, including some that are specific to certain plugins "If you use UAD plugins, tick this box to make them work - Warning, may screw up every other plugin in your VST folder!!". So much for VST being a "standard" - meh!

Trog, I'm noticing while testing v10 in FL, that your drifts are not the same as mine.
My drifts only go in one direction or the other.....(another clue I can't seem to take advantage of)
v10 drifts like the old sm timers, all the hits are different...wierd.
I've been taking bits and pieces from both our timers, and creating new monstrosities.
No 'spot on" results yet.

Really not sure at the moment - I got as far as confirming what I had thought about the FL delay compensation, but I haven't really had time to sit down and get my head around a new sequencer enough to be sure what the results are really telling me.
My initial impression is that there is something different about the engine of the FL sequencer compared to the others (besides the delay compensation thing), but I can't quite put my finger on what it is just yet.