DSP Robotics Support

trogluddite wrote:Before you go blaming your timer

Well we got to blame something here, cause somethings not right.

So I get up this morning, first test is to test the test unit/theory "itself"
Load two identical synths-sure enough, the whole output diss-appears when ploarity button pressed.
Awesome. I'm just loving this method now, as I have just seen how perfectly it works.
After some time tinkering/ experimenting I found the reason why I'm getting an issue with this method.
I noticed the 2 initial tracks were not the same.
The Host synth was drifting...... : WTF....
So I shut down, re-start and test the timing of the host synth


Drifting after one minute..
I cannot explain this at the moment. Host synth is just stock vsti....
How can i generate a timing error from the host seq.......
How, is a result like this possible???????? Hullo, you dumb-ass CPU-what are you doing to me
Ok, so the test result is pointless in the previous post, untill I get this host synth right, or find out why
I'm getting a reading like that...Could it be the Edison recorder......
This is going to be a stupid day....... ...testing timing of host

Whoa, that is bizarre - so the supplied FL synths are just free running possibly!?

Well, look on the bright side - you could now have a stunning career making FL plugins that have better timing than the stock ones!

trogluddite wrote:Whoa, that is bizarre

Jeez, it's getting worse!!
I thought my error must of been the un-connected midi/timer, that was left in the FSM,
and was causing a conflict somehow. But I deleted it altogether, and the stock vsti
still drifts. Amazing stuff!!!!!! never seen anything like this before.
It's drifting repeatedly. No timer. Just stock vsti
There's no timer here, so now I'm questioning the Midi to Poly module now, and how it's
processing the incoming data..........stupid day......
So someone please prove that I am stupid by doing the following...
make vst plug with just the stock vsti
load into FL and fill each 2nd step in host seq
route to mixer channel and load edison into the slot, then select record "on play"
hit play,go for a min. Send the audio to playlist and stretch the viewing resolution all the way.
Check the first bar or two, focus first on black b/g host marker, then fold the wave into vision
Find another black b/g host marke near the end and do the same.
What is your assessment.?? Please share...
I'm repeatedly seeing drift here...

billv wrote:I'm repeatedly seeing drift here...

Again and again.
Opening another thread to sort this "stock vsti" issue out, and have
another go at that cool polarity test.
viewtopic.php?f=2&t=1360#p5012

Polarity test cannot be done effectively cause of the stock VSTi issue.
So Until that's sorted out, I figure keep moving on with the tweaking.
Second opinion(s) required.
been playing around with the "sample position" primative

Do those two blue streams need some math before they hit the mono to frame?
Is better to re-write this picture in ruby???

billv, I honestly do not understand your timer.
first of all even if you MonotoFrame you set the buffer with the size of the sample rate,
it will still be synchronized with a tick every few sample buffer according to the audio drivers, for example,
every 512 samples, you'll have an update, even if you put 44100 samples, it will be divided into 4 ticks of 512 samples.
then you actually do not use the data for the PPQ or SamplePosition to calculate and send the midi to start,
so do not just simply connect the primitive Framesync, to the module ruby midi ?
So who makes the clock in your case is just that .... but maybe I'm wrong.

Tronic wrote:billv, I honestly do not understand your timer.

You can see by how I'm now fiddling around with the "sample pos" primative,
in the last post, shows clearly that I don't understand my timer either.
But I do know, that the circuit is giving me by far the best results so far.
That's pretty much how I work, trial and error till i get a result.

billv wrote:Is better to re-write this picture in ruby???

Anyway. did the Polarity test again using the updated Stock VSTi module.
I just love the testing method, because I failed again.


And today, several times, I got some dodgy results from the timer.
So if not consistant, then is not accurate.

yeh, so at the moment, the X11 2.01 Timer is not accurate.
it must give the same result everytime tested.

So were back again to the 99.9999999 rubbish again.....

Note polarity test picture in last post.
My question is obvious.

Why is the timer 100% accurate on the first bar of every measure?

Please note that i did not ask 'Why is the timer not accurate in those other places "
i need to keep the two questions seperate.

So again,
Why is the timer 100% accurate on the first bar of every measure?
I'm thinking that whatever it is,in the circuit, that is responsible for this accuracy,
is a big clue.

Ouch....
My testing methods have proven to be inaccurate. Please check post
viewtopic.php?f=2&t=1360&p=5048#p5048

So, because of this, the X11 2.01 Timer is back on the table, until i can prove,
using accurate methods, that it is not accurate.

Ok. So this is the first test using "accurate methods" as prescribed by FL Support staff.

Using X11 2.01(v2) Timer

This first test, at 3 min, is a failure, because my timer failed to show drift in the playlist.



CONTINUED NEXT POST........