DSP Robotics Support

Jay wrote:ppq ticks being much higher than 96

But if done according to the VST spec, they are - in fact the "PPQ" name is rather misleading, something like "Beat Position" would be more appropriate.
The PPQ signal isn't a series of discrete ticks - it is a continuous ramp signal. The integer part of the ramp is the current beat, and the fractional part is the position within that beat. If done according to the spec's the value will be correct for any sample point within the beat - so 1/3 of the way through beat seven, the value would be 7.3333 - up to the precision of 32bit floats, anyway.
Now it could be that there are hosts which don't do it this way, and only update the PPQ value at discrete intervals, but I have not ever seen this in practice - FL's PPQ signal does seem to be standard in this respect when I have 'scoped' it.

Nubeat7 wrote:serios problem not related to the ruby pp

Cheers - I have not seen that problem, so thanks for reporting, I'll see if I can replicate it in the FL demo.

Perfect Human Interface wrote:et some answers about the FL thing

Well, I think the first thing is to establish whether there is a real problem, or if we have jumped the gun. Billy was saying that re-intalling had reset some host settings that might have been altered by accident.
So, I think we should double check our results on a nice clean setup first - I may have some criticisms of some aspects of FL, but I wouldn't want to sow bad feelings among their user base due to a false alarm.

@ trog: ok, after updating my zed r16 audio drivers it works well, looks like something was fucking up the old drivers luckely it was solved pretty fast, sorry for the wrong alarm tested on cubase and renoise, and your ppq ruby module (version 10) runs exactly on the original ppq!

never used FL and i also donthave any version of it so i cannot tell something about that

Thanks for explaining that Trogg i think i understand that! RE- my impaired ability to absorb! ( how my school teachers must have despised teaching me! ha ha) So if i get you right ppq is like a seconds hand (INT) ticking round the beats with the milliseconds sweep (float) ticking in the space between beats? lol em is that close?

thought i just ask you, what are these higher resolutions for? and would flowstone be able to produce that kind of resolution if we wanted it? just wondering!

I have bee a commercial studio owner for quite a few years now and have never really thought about this sort of thing and tbh non of my patrons have mentioned anything like it to me

Best Regards

P.S soz for the stupid questions in your thread guys, i know you are all busy with this!

Jay wrote:i have a pdf somewhere that goes on about ppq tick rates

Thanks for that mate ...interesting -will come in very handy

Nubeat7 wrote:(version 10) runs exactly on the original ppq!

Yeh, its all good there. Glad you sorted the issue and got it running.
He's just got to work out how to fix the general timing.
I re-tested in FL. It's always drifting, and the drift is not consistant.
This is the closest it gets on my CPU, sometimes it's 2 to 3 times this distance away from the mark.

Note:
this "reading" is with Timer delay Compensation set to 0, and host delay Compensation un-touched.
Tried lots of different combinations here, both on timer and host, and the above settings giving me the
best result you see above

Jay wrote: would flowstone be able to produce that kind of resolution

.
I think we can. When you first mentioned "seq's running at higher tick rates, the first thing
i did was try it.
All I did was increase the speed of the ticker to a disgusting amount, then spent some time
adjusting the numbers to get the tempo's right. It was looking ok there for a while, I think I had it up
to about 400/500 ticks per quarter, or something like that-but had trouble firing the notes of
at that speed accurately in green. probably have to do it in ruby.....?... something to try again one day....
But that's a just "my" attempt. I don't know. There's no doubt a proper way to do it
EDIT:
I found it....
Bear in mind it's just a "rough sketch" of something I havn't tried...it's wrong here and there-
probably why i stopped this attempt.

smashing billv!

being a hoarder of all things has its merits ha ha, glad that was of some use to ya! right im away to play with this

Best regards

Jay wrote:thought i just ask you, what are these higher resolutions for?

Well, I think it has to do with different applications of a sequencer.
The case of wanting a MIDI event precisely every 1/4 beat or whatever from a step sequencer is only the most simple case - as you say, that could be created quite easily by a system with very few "events" (like the electrical pulses that were once used for syncing drum machines etc. back in analogue days).
For example, think of adding a "swing" slider to your sequencer for some nice jazzy syncopation - every other note would now need generating at an arbitrary point relative to its neighbours, depending how much you moved that 'swing' control. Having a "per sample" PPQ means that you don't have to "quantise" the swing amount - it can truly be any value you like.
An even more complex case would be recording and playing back a MIDI sequence played in by a musician. If they have a good sense of "groove", they probably push and pull notes either side of the "mathematical" beats. If the "groove" really gives your song a great feel, you would want to preserve those small timing differences - so again, events are needed at totally arbitrary point in the bar.

Seems that all the recent testing I've done was a trip to nowhere.
Have been repeatedly testing the X11 2.0 update.
All the time, it's like this...

Don't forget this timer(like all the ones I've posted)
relies on the X11 Automation System for PPQ Accuracy.
Which means if your building a VST, my timers are next to useless for your needs.
Go here for accurate PPQ Timing.
viewtopic.php?f=3&t=1267#p4306

hmm , have something to test for you, i have a ppq ticker here with which i have really good results triggering a repeat fx sounds like there is just a very tiny drift but i`m not a testerlike you and you already have a good method doing this, the trick is to get a mono ppq step position signal and round it to int (in mono) and just read out the first index of each frame, there is a a detailed information inside the modules, it would be interesting how accurate this really is and if it makes sense to follow this method further

Nubeat7 wrote:i have a ppq ticker here

Thanks mate. Off to work will try tonight.
Looks good. I recognize some of it, from the "round down.fsm" that some of the boys
were working on a while back.

Nubeat7 wrote:and just read out the first index

yeh, in the past I' would always just mono to float then change to int. But your method
looks a little different.....cool.
This comment from Trog has been interesting for me.

trogluddite wrote:The integer part of the ramp is the current beat, and the fractional part is the position within that beat.

If you stick a mono readout on the PPQ, you can see both those numbers.
Have been thinking a lot weather just to split that number, and create a circuit that uses
this fractional part, as I havn't tried that before.
Look forward to testing your FSM.
Cheers.

Nubeat7 wrote:have something to test for you

You'd probably get better test results from someone who knows what there doing.
For starters, I coudn't get a FS exported version working in host, even after several attempts.
I don't get that at all, so I must have missed something crucial in the FSM maybe...
Loaded the FSM into FLFS, and it works, but i couldn't really create a accurate start/stop
circuit, and without that, it's just wasn't happening.
Listening to the tick with my ears, it didn't seem really "solid".
Don't know....have to spent more time with it one day.
Trog's got this "PPQ" thing covered at the moment,so in general, it's all good.