DSP Robotics Support

Edison has zoom to the point of samples.
I would look at the samples,
they are marked with circles if u zoom right in

nix wrote:Edison has zoom to the point of samples.

Yes, that's been fustrating me. There's no host marker anywhere when I go to sample stage.
How do I continue test at that point?
Currently, i always "test" at first zoom level past sample stage.

Tested another 3 times.
Stock vsti in-consistant in all three attempts.

So where is the error here?
Is it the step sequencer in FL or the Stock VSTi or edison or the FL Enviroment itself?

My timer still hits the host marker every time

I will try sticking a ppq up the Stock VSTi's anal passage once more.
I'm pretty sure it will fail again.

billv wrote:

nix wrote:Edison has zoom to the point of samples.

Yes, that's been fustrating me. There's no host marker anywhere when I go to sample stage.
How do I continue test at that point?
Currently, i always "test" at first zoom level past sample stage.

Not sure what you mean exactly. Are you looking for vertical lines and not finding them around the start of notes? If so you probably don't have tempo sync enabled in Edison.

I recall there is an "impulse" component... I'm not sure if you can make it generate an impulse at will since it only has an output, but perhaps if you created an impulse wavetable and then played that back (without interpolation) instead of synth notes it would be more useful for testing.

Perfect Human Interface wrote:probably don't have tempo sync enabled in Edison.

Cheers, i forgot that. all good.

Did find something great though.
If you zoom right in, and click on the wave, you can use page/up-page/down buttons to get
further in.
So here is the real story.
this is my timer at the very last sample before display dissappears

And here it is all the way


And here is Stock VSTi. Look how far out it is...

Previous post re-tested and confirmed again.

Just a hunch...
Is that delay pretty much the same every time?
Is your soundcard set to use a 64 sample buffer?

trogluddite wrote:s that delay pretty much the same every time

No, the drift amounts are always different.

trogluddite wrote:Is your soundcard set to use a 64 sample buffer

Tried pushing the slider to min, gets me 94.
Do I have to be at 64?
What are the ramifications here?

Using the voices module in FL FS, instead of the midi to poly...
all good, definate movement at the very start.

So again, this is telling me the "Midi to poly" module is faulty and
Needs to be fixed to get an accurate Polarity test result....

To clarify,
Using Voices module in FLFS is picture above...
Using Midi to Poly picture below...


My cowboy fix attempts are not fixing the issue.
EDIT:
If my timer is ok ..and
The FL FS Voices is ok......this means a "true" polarity test might be viable.
But is this cheating???????????
Must both test devices be exported from FS???
So no FLFS allowed for testing.......????..... please advise.....

billv wrote:Do I have to be at 64?

No, it was just that I counted the number of samples, and there seemed to be 64 of them - powers of two always look a little suspect in cases like this.

Why did I count them? (besides geek OCD! )
...When I was doing my PPQ things, you might remember that I was having trouble with FL's PPQ signal because of the latency compensation thing - the PPQ signal was exactly one buffer later than in other sequencers (or rather, the other sequencers were able to send it one buffer early)
So I was wondering whether this was a related problem - easy to fix by reading the Ruby 'frame' size. But sadly not it seems.

billv wrote:So again, this is telling me the "Midi to poly" module is faulty.

I'm not so sure about that.
My PPQ module test rig uses just a simple synth using stock MIDI-to-Poly, ADSR etc.
It has perfect timing inside every sequencer tested - except FL
My PPQ signal and latency compensation code work perfectly inside every sequencer tested - except FL.

There are plenty more tests that you and I need to do to prove things conclusively, but my gut feeling is that FL is doing several things in non-standard ways - quite possibly with good reason (low CPU for example), but in terms of VST timing, it has already proved itself the 'odd-man-out' by not dealing with delay compensation correctly for the PPQ signal.

The explanation about 'visual quantising' of the display from GoI has been bothering me too...
Getting audio timing bang on is hard to do - it has to be done in real time. Drawing a wave display? That's a piece of cake, the CPU has all the time in the world to do it - the individual cycles of waves are displayed without any distortion - it shows the bar/beat lines in the right place - so why show the wave start points on screen in the 'wrong' location?
Hardcore coders would call that a "code smell" - not a bug exactly, but a sign that something has been bodged together somewhere along the line and left a faint trace in the code's behaviour.

I could well be wrong - but it has me intrigued enough to have another go firing up the FL demo and comparing alongside my other sequencers At the very least it would act as a 'control sample' to eliminate a few of the many variables in the timing equation.