DSP Robotics Support

MyCo wrote:Here is the FLP with the looppoints and the VSTi DLL

Too bad its pointless.
I got excited when i first heard it, i thought unreal. this could be a new method.
But i had a suspicion when i first opened the fl file that it was corrupted.
So i made a fresh vsti of 2.01v3 timer, and set up your test method on a brand new file
and it's perfect.

Why does the fl file open with this...

What sort of tampering did you do in buffer country?????
This area is untouched for testing. i only touch this area when then is an issue with the plug-in

Clearly were not on the same page Myco.
I'm running F11, with these settings

And using your test method....its f**king perfect.

If you don't like my settings, use the exact default settings that appears after install.
And don't muck around with the Fruity wrapper.

So either there's a problem with your settings or....
you have sabotaged the file on purpose to try and make me look like a dickhead.
You wanna start praying for your spirit that is not the latter.
We all answer to the same God... his name is Oxygen.

and mate the timer you used is a ppq timer, it does not have correct set up...there is no green
it's just "ruby to midi ruby"...so it's a false test anyway...were just testing ruby...
(which means there is definatly a fault in the fl file )
Those ppq timers were stripped down to take on the ppq issue properly.
Supergreen circuit is Ruby to Green to Ruby/Midi

Yeah I'm developing VST-Plugins and Hosts for 8 Years now, I'm a complete idiot... do what you want, I don't want to argue anymore. Either you don't read it or you ignore it... I tried to help you, but it looks like you don't want any help because you are the god of VST and know everything... bla bla.... bye!

BTW: I post real examples that everyone can try themself and you post Screenshots... Good proof!!!

MyCo wrote:I don't know what you mean. Timeless? Holes? No, triggers are placed one after another. And if one trigger triggers another trigger, those triggers are executed before the other triggers.

In large schematic, that is running - dozens of triggers are executed every second. So we can say, that this is an ongoing flow of triggers. Triggers are serialized, so this flow is happening on one "bus" (thread) so to speak. Now if we have an "event" (let say, user clicks, and this produces a trigger), then this trigger is added to the flow (between other triggers). But the flow isn't something timeless nor does not have regular/homogenic density.

MyCo - I understand what you are saying, so please - try to understand what I'm saying. It's just a different level of abstraction, but the rules are the same. What I'm trying to get, are the magnitudes within what you call randomness. If the tick100 was the maximum tick created for SM, then these magnitudes are not in nanoseconds. The reason I'm focused on this is something that attracts my attentnion - correlated behaviors (something that allows to shot triggers out of order, but in relation to the context).

p.s.: even if it's useless for you, it helps me to understand other things when they appear.

MyCo wrote: Either you don't read it or you ignore it...

I tried it, made a comparison to test it, and gave you the reults i got. best i can do.

MyCo wrote:because you are the god of VST and know everything

Rubbish.
Just calling it the way i see it.

MyCo wrote:I tried to help you

Thank you again for that.

MyCo wrote:I post real examples that everyone can try themself and you post Screenshots... Good proof!!!

That's perfect. i wouldn't want it any other way.

MyCo wrote:bye!

Have a nice day.

tester wrote:MyCo - I understand what you are saying, so please - try to understand what I'm saying. It's just a different level of abstraction, but the rules are the same. What I'm trying to get, are the magnitudes within what you call randomness.

It's not really randomness, but it can be unpredictable. It really depends on what else is going on in your schematic. eg. When a trigger executes thousands of other sub triggers, all of those sub triggers have to be done, before your next top level trigger can run.

Thanks MyCo, this is what I wanted to confirm.

*

related or unrelated:

@biliv - I don't follow your project from inside, but assuming that you don't have errors inside - here is my spooky/freaky explanation. Under heavier load (flow/amount of triggers above certain threshold per certain class of PC/performance) - your project just behaves stable. In any else situation - parts extracted and tested separately, very different machine configurations - stability goes down. Lucky you! It's like with integrity of airplanes or spacecrafts - they are not tight on the ground, but at high speeds - they become tight. Or like with these NASA baloons - on the ground they are small, but above the atmoshpere - they get big. Anyway if you don't find anything else - try to figure out what is the heart of your engine this way.

As an example from my project. I have a part there, that is responsible for generating random multiple frequencies. And they are irregular by all means. But after I added a module, that makes on the fly (via switcher/selector) some calculations on all these values (in other words - it adds some load) - this randomness/irregularity I had there - changed it's nature (and what more interesting - in similar way on very 2 different PCs in the same way). Paradoxically - that change brought some audible "harmony" to generated results. Generated frequencies are still random (irregular results), but as a whole - it just sounds better. I probably just add a switch there for turning on/off that background calculations, but the result itself - guided me to the question about fuzzy order of higher hierarchy within this wavering sea of triggers. And somewhat it leads me to conclusion, that it has to do with ruby, because none of previous "mass additions" (which also each time added a lot of calculations and triggers) - did give that direction of audible effect.

If this is your case bill, then all you can do, is to describe it as a "developer edition with no guarantee that it will always work".

It's like seeing it in a 2D matrix. Horizontal serial bus is responsible for serialized flow of triggers and sub-triggers, and vertical connections come from few FS hearts (I suppose, ruby is one of them); they regulate which triggers go first, if there is no direct logical connection between them (user-event/time based separation).

MyCo wrote:all of those sub triggers have to be done, before your next top level trigger can run

just going back to my question for a minute, if it's better to use ruby with multi-green outs instead
green link with heaps of triggers........
Myco, I know you said FS is faster as Ruby has to parse the info. I'm curious as to what this "parse"
speed is...any idea of the top of your head?.......but it's not really important....

tester wrote:In any else situation - parts extracted and tested separately, very different machine configurations - stability goes down

I know, i kept seeing this all the time testing timers on there own..
Quite often, I get this crap...and then slap 1 million parts on it and there's no such error.

tester wrote:It's like with integrity of airplanes or spacecrafts - they are not tight on the ground, but at high speeds - they become tight.

That's why i came up with that stupid "friction" theory.....

tester wrote:Anyway if you don't find anything else - try to figure out what is the heart of your engine this way.

I've got a few suspicion's here.... but not really relating to supergreen midi timing.....
First is the sneaky fact that the clock time, which is being pushed in green throughout the schematic,
is derived from supergreen...so everything getting the clock signal is locked into the "Events"system.
Next thought is that there is about 12 timers in the schematic, controlling thier own section.
Seeing as the timers are all built the same.....I'm thinking its got to helping with general stability,
and further locking everything in to the events system.....

tester wrote:If this is your case bill, then all you can do, is to describe it as a "developer edition with no guarantee that it will always work"

Thats why I want to leave it as
"S/R Accuracy in Green is possible, but NOT RECOMMENDED"
"And for some things(eg:graph) NOT POSSIBLE"

And i need to explain something.
X11 is still under development. FS has blown all the work I did in SM to pieces.
I know the timing system has to be should be in full ruby...but i'm a long way from that part of X11
production. The 2.0 update was just a 'quicky" to see what I'm dealing with....
In a way, my initial question to Myco was probably more to determine weather i can get away with
leaving the "full ruby timing fix" till much later, when I understand better what the hell Ruby is capable of,
so i can do implement it properly. in the meantime i can just chip away at other stuff.
The X11 2.01 update is almost ready.....and I barley touched the timing sysytem.
One great thing is this....a new Seq I put in, kept failing with the count, tried for days, couldn't get it,
had no choice but to give that seq it's own timer ... which means yes, I definatly found
there is a limit to supergreen, and how far ruby's power is extending in such circumstances.

So to clear this issue up for new-comers and people who are still not sure what this all means.....
For Timing accuracy in FS, the general "rule" seems to be this...
"use ruby timing throughtout the schematic, either count in ruby or use trog's Ruby counter
and then deliver to green at the very last moment"

@Myco,
Forgive me for my attitude during this discussion but
It's just that you had me on the ropes there, many times, hurling those massive "textbook" punches..
In such cases your not going to get anything but the "real me"..so i can't apologize for being
a smartarse . If you watch that cooking crap on TV.....most chef's are arseholes anyway.
I'm no different.
No hard feeling's bro.
I hope you and tester keep nutting out the finer points in guru.
I need to get this 2.01 update up.....never had a "dud" X11 version online for so long!!!
Later

S/R Accuracy in Green is IMPOSSIBLE, AND UNTHINKABLE
just my opinion.

digitalwhitebyte wrote:just my opinion.

Yeh, all good.
My view is that all it needs to do is achieve it once!!!
Think boolean...click... light goes on.... statement becomes fact with just one successfull hit.
Weather it's maintained...blah blah...is a COMPLETLY different issue.
therefore stuff like "Screenshot 214" is absolute concrete evidence,
That it is possible....but still not recommended for the obvious reasons.