DSP Robotics Support

Tested my last post again in FL with the same results. Spot on.
Tested in Live and reaper, same thing, with the reaper test stretching to 7minutes



Make your own assessment.


If anyone could test this in hosts i don't own, like
Orion
Sonar
cubase ect ect......that would be great.

If you can this get timer to make an error(without modyfing), please report back your results

Unreal. Reaper test at a whopping 42 minutes-still looks perfect.

for now it looks good.
but this is a test, performed without ever moving any control, on the vst?
a good test would be to check if moving some control
the threads of the graphics cause some latency or hole,
and also carry out tests with the automation of controls.

Tronic wrote:but this is a test, performed without ever moving any control, on the vst?

Correct. Moving controls is another "section" of testing.

Tronic wrote:a good test would be to check if moving some control
the threads of the graphics cause some latency or hole,
and also carry out tests with the automation of controls.

My X11 Synth has got that area covered-graphics/automation-perfect test weapon for this stuff
man, have you seen what the X11 interface does when started????
Can't i just let the X11 go nuts doing the test or Do i have to physicaly move something???

Nix sort of questioned the same thing, when I started doing the drifting tests,
that the size of the synth could be an issue.
So I tested the X11 at 5 minutes, Using the Arp seq and the scale seq, and they both showed
the same drift as this tiny test unit i'm using!!
Test synth: 7000 primitives
X11: Million +
So I'm really confident size is not an issue, either.

I'm still working in pieces outside the main X11 FSM, hope to go back in soon,
cut a vst and do "the test that hopefully ends all tests", for the time being.
Will be fun, either way

Small update to design. Extra glue. No issues yet.

EDIT:
WOW!
Dropped this tiny fix into the X11 2.0, for quick "full" road test.
Used the scale seq,
10 triggers in matrix on(no pm),
Automated the random triggers on finish, and for tempo as well,So it was all happening, more or less.
No issues found with Graphics and automation.
The reactions to tempo changes were all spot on.
The actual timing seems spot on, but I really think can't be judged by this method,
because the audio is getting changed so much all the time, every "hit" has a different
visual personality, making it bloody hard to tell the difference

Brilliant work men!

though i was thinking earlier tonight "what a state of affairs" after all the ear chewing we had to give the devs to get to the bold statement of "accurate timing in ruby" why we were never presented with a working solution for timing? instead we were offered an arp that keeps the timing of a drunk man! history repeats!

anyway, if we can thanks to you chaps now get accurate timing, how do we now get resolution? like most midi sequencers havef 96 ticks per quarter note but many professional ones are at 480 up to 1680 ticks per quarter note allowing for very precise quantization

or do i understand that all wrong ha ha

Jay wrote:why we were never presented with a working solution for timing? instead we were offered an arp

Maybe the arp was there solution. Or maybe it was the Custom ticker.....don't know
You would think, from a business perspective, that they would have built a timing package that
was "Military" grade, so it would not turn off perspective buyers from areas like "Military" or "Medical"
for example, who require absolute precision and no less.
It's not just for Music lovers anymore- Robotics cover a very, very wide area...............
So Yeh jay, it's a bit odd.....

Jay wrote:how do we now get resolution? like most midi sequencers have 96 ticks per quarter note but many professional ones are at 480 up to 1680 ticks per quarter note allowing for very precise quantization

Now that's really interesting! Never looked at it like that.......
I think Nix is your man for that, he knows that side of things really well.

billv wrote:My X11 Synth has got that area covered-graphics/automation-perfect test weapon for this stuff
man, have you seen what the X11 interface does when started????
Can't i just let the X11 go nuts doing the test or Do i have to physicaly move something???

I mean for automation, that are controlled by the host, and human interactions on the controls.

however, by some experiments made ​​by me,
I notice that there is a difference between using the Mono to Frame single primitive,
and that with the entry of the sample can be set.

a simple experiment you can do is subtract the two different primitives,
Mono to Frame, the result is not always zero.

work differently?

the other thought that comes and that we should have the primitive
PPQ, Bar Start Position, Sample Position, Tempo, etc.. already converted to V data, such as Is Playing.

In fact, your workaround and do just that.

and in any case the ASIO driver buffer is set by the host,
some hosts in the value can be differentiated between the card's buffer and the buffer passed to the plugin,
and I think the exact value that is extracted from the primitive, Frame Sync.

is no difference between us convert them, or have them already converted from the primitive?
this I could say the developer.

Tronic wrote:I mean for automation, that are controlled by the host

Yeh, good point. Unfortunatly I can't help with this particular "issue" as the current
platform I'm working on (X11), is not designed for Host automation. It has it's own systems.
No doubt will look into that in the future, but for now it's staying on my backburner,
only cause for me, at the moment, it's not relevent.
Maybe someone can have a dig at that, and give us a hand at taking it off the stove.

Tronic wrote:however, by some experiments made ​​by me,
I notice that there is a difference between using the Mono to Frame single primitive,
and that with the entry of the sample can be set.

a simple experiment you can do is subtract the two different primitives,
Mono to Frame, the result is not always zero.

work differently?

I figured because the host is setting the S/R via that primitive, I wouldn't have to worry about it.
You know, just let the host decide......????????

Tronic wrote:the other thought that comes and that we should have the primitive
PPQ, Bar Start Position, Sample Position, Tempo, etc.. already converted to V data, such as Is Playing.

Trog has already done this in his "Guru" version. Check out his work ....
viewtopic.php?f=3&t=1267#p4306
he's got it working spot on in lots of hosts, except FL. I once tested the version 6 as accurate in FL
But can't repeat the result, and because its in "Guru" language-I couldn't modify-so had to keep
going with my "cowboy" designs.
Trog did mention, in that link above, that he was nutting the PPQ thing out with malc-
which by far is the best thing for all of us.

Tronic wrote:is no difference between us convert them, or have them already converted from the primitive?
this I could say the developer.

I don't know mate. Like i said earlier in the thread, this whole things got to end with Trog( and
hopefully malc + DSPR) as well. I want a timing system that NASA would be happy to use.
Not sure if i can just "cowboy" this to the finish line.
Those "gurus" will have to "sign off" on the whole concept, before anyone's really happy.

Another test in FL and reaper. This time highspeed 1/16, over 5 minutes.
There's still no error anywhere.
Note:
Has also tested with no errors in host "Podium Free".
Fl/Live/Reaper/Podium tested now all good.
Looking forward to test results from other users and other hosts..