DSP Robotics Support

isnt the problem with your ticker, that when it starts with playing from host at the beginning it ticks sampleaccurate at the right position from the moment of start but when changing the tick resolution from 1/8 to 1/4 or whatever it should wait to change on a full note on the next 1/4 in this case, to get the tick exactly on every quater and not on every 2nd 1/8 in the middle of the quater (please tell me if i`m wrong) also when i start playing somwhere on a position between 2/8 and 3/8 i cant get a right positioned tick with quaters..., so at the end i think there is no way around to extract from ppq at the end, trogs solution also was not working well for me, i used it 2 times in my scematic and it needed 6% cpu when ticking at 1/64, thats to much just for ticking + the dalay compensation "just" for proper ticking ,

i followed your experiments the last days and for me it really looks frustrating i experimented too with all the solutions around here, but sadly at the end there is no easy solution to get a ppq ticker or different position readouts which used in step lfos or seqenzers or other things which needs host position

Well, so long as PPQ is properly delay compensated, PPQ works perfectly with the design that I've been working on - through tempo ramps; manually moving the playback cursor, time signature changes - even off-line rendering seems good so far in most hosts.
When combined with the 'Bar position' signal this gives something that does know exactly which beat and sub-division of the bar it is on.
CPU load does need looking at (converting Ruby frames is rather greedy) - but the FS readout is very arcane and unreliable and I have yet to see anything which stands out as particularly high in a host once the load of the test synth is accounted for. If you have a schematic example that you used for testing it, I'd be glad to take a look - just PM me if you'd rather not make your design public. (NB - except for the early versions, PDC is done entirely by the host, just as for audio signals. i'm just passing the host a parameter value to use, so that aspect should have no bearing on CPU load)

Of course, this may all depend on how hosts implement their PPQ signals - but it's a defined part of the VST spec' - and even billy's troubles with PPQ in FL may yet turn out to be some host 'advanced settings' that had been accidentally changed in his previous installation.
So, I am pretty confident that we can make something that will be robust in the vast majority of cases - and certainly something that will be way more accurate than anything possible before using SM.

Nubeat7 wrote:(please tell me if i`m wrong)

No your not wrong.
At the monent, I am getting around this in the X11 because the the main clock,
which is locked to host time, is controlling the tempo switching, so every change is sweet.
The problem is when the user manually switches tempo,while the synth is running,
yes... the result is very different. At the moment, for my set-up, i like this. i think if the
user chooses to interrupt the timing flow by changing tempo, then go for it.
That's where the tempo in the matrix comes in. This is where you normaly select your
tempo changes when synth is running .And then the Host clock delivers on time.

But that's X11 system at the moment. Might not suit you.
Might not even suit me...still toying with it....

The answer is in the ticker/midi timer.
At the moment, we have the ticker delivering the note timing. Yes?.....
So only solution here is to(I think)
a:get the PPQ to deliver the note via PPQ or
b:get the PPQ to deliver the note with ticker's help

The Custom ticker "tick" and PPQ "tick" must be combined somehow, but I havn't got the ruby
skills to pull it off. So that whole deal is on a backburner untill I work it out.
I think Trog's taking another look at the issue again,.....so there's some "hope" there.

I said it before--- the holy grail of VST Timing is loitering around Trog like a bad smell .
Could be wrong........but that's how I'm seeing it.

billv wrote:I am getting around this

There's is another way, come to think of it. I'm sure i did this why one of the systems
I've built recently. Not sure where though...dosn't matter...it's easy to re-do.

The fix was
tempo selector/when changed/trigger counter re-set.
Worked every time I think.
So Your counting gets locked back into the s/r, and PPQ is maintained.
I didn't keep it, because I was using the fix to troubleshoot another bug.
Had this issue on a backburner. thanks for bringing the issue up.
Still need to experiment with it again
Hope this helps

EDIT/UPDATE:
Here's the Fl clock running with a PPQ Timing circuit for VST.
The fix I quoted above tried/but not working in this example.
It's the ticker that needs the re-set also....I'm really thinking that's the only thing we have to do.
Reset the ticker, but from within ruby, not after. Create an input to access and trigger it.

This is the PPQ Timer.


Yeh, so how do we reset the ruby ticker in ruby........ and I think that's it.

after some testing around with trogs tool, i think i have some serios problem not related to the ruby ppq, because after loading the only the ruby ppq as vst fx and start playing nothing happens but after clicking the surfaceof the plug it starts running for 1 second and stops again after clicking again it runs for a sec again and so on, also when counting the triggers in FS ist fucks up when using 1/8 or 1/16 but doing all this stuff on my supercheap laptop it works fine so i`m more frustrated now , because it looks like some computer issue i think it will be also the reason why trogs tool didn`t work well, need to dig deeper to find the real bug here,

Nubeat7 wrote:i think it will be [*]also the reason why trogs tool didn`t work well

Trogs system seems to work perfectly. Spot on in reaper and Live, to name a few.
It's just that at the moment, it's not compatible with FL.
Are you using FL?

PS:

Nubeat7 wrote:trogs tool

Thanks for reminding me. Now that i have an initialized version of FL running, I can re-test
it.

You... what?

Hey Trog, I know you kind of already said you didn't care that much, but if you're registered on the IL forums and want to try to get some answers about the FL thing now's the time to do it.
http://forum.image-line.com/viewtopic.p ... 0&t=108376

Billv posted a question about settings in FL without any sort of explanation; I tried to explain what was going on and mentioned FL being the odd one out with your timing doodads, but they're pretty much "what the flip are you talking about?" I don't know enough about this to say anything more.

Perfect Human Interface wrote:Billv posted a question about settings in FL without any sort of explanation

What is there to explain? ...I thought the question was perfectly clear.
Quote:
How do I set up FL for "Presicion Timing tests" using VST Plug ins
What are the proper settings, for audio, VST PLug -in wrapper, and Edison?

QUOTE :Image Line
"While a sequencer can sequence files with sub-sample accuracy".

billv wrote:It's not our fault Trog, that there is another type of "100%", that exists within the current 100%
accuracy we have for VST.

yup i think this is down to what i was saying about ppq ticks being much higher than 96 to get the resolution you require for that kind of precision quantization like here http://en.wikipedia.org/wiki/Pulses_Per_Quarter

i have a pdf somewhere that goes on about ppq tick rates of 96, 240, 480, 960, 1680 per quarter note for midi resolution! will have to look it out

edit* here it is