DSP Robotics Support

See this thread for Prelude....
http://www.dsprobotics.com/support/viewtopic.php?f=2&t=1426#p5660

Myco, I think i found a way to explain this in your language.

First, The user guide.....
Clock Accuracy
The schematic clock runs at 100 Hz. Unlike the Tick components which are not time precise due to
their use of Windows timers, the Events system uses a different timer which is much more accurate so
each 10 millisecond tick should occur precisely on time.
If you have any of the DirectSound or ASIO primitives in your schematic and these are switched on
then the clock will automatically switch to run in sync with the audio processing. You can then schedule
events to occur with sample precise timing within any audio frame.

it's this Events system part Im focusing on....
You said
Green data coming into Ruby is converted from triggered data into timestamped event data"
This means to me whatever green crap I throw into my Ruby Midi/Timer it is going to spit out
Sample Accurate, just like DSPR claim.
Now lets take a look at the other side of the Loop
You said,
And Green data coming out of Ruby is converted from timestamped event data into triggers
Ok, now the signal has turned into green piece of crap again, where Bill Gates and his windows
rubbish, steps in and manages to keep the signal accurate till ruby decides to
recieve/call it's next parameter.

I know i'm using green, but I think the looped circuit is locking the green data into the events
system. It's got no-where to run....it's bound by ruby.
Thus we have a "Supergreen" circuit where sample accuracy is maintained.

basically you understand the trigger / event system, but your assumption is wrong.

Think of it this way:
Any green connection line in a Schematic, is a delay line. And the delay of any of these delay lines is completely random.

So if you manage to send a precise timed trigger from Ruby into a green output, this output can be in sync. But the connection of this output to another input adds a random delay. So nomatter what is connected, it's automatically out of Sync.

...oh, and bill - the lenght of that random delay - does not depends on the lenght of the green cable in your schematic!

What sounds like a good joke, has a psychological background too. In real life we use tools, to which we have certain thinking habits. If in virtual world we start use similar visual tools - sometimes, subconsciously - we start to expect that these virtual tools behave like real ones. It is not logical reaction, but it pushes our thinking onto wrong ways. So it's a small side effect of visual programming.

MyCo wrote: but your assumption is wrong.

yeh I know in theory its all wrong.
But it still works in the host.

Anyway, i punched "definition of sample accuracy" into google for fun" .
Lots of different meanings for it in different fields..insteresting stuff...
I found this one relating to audio.
http://www.harmonycentral.com/t5/Lessons-Theory/So-What-Does-quot-Sample-Accurate-quot-Mean-Anyway/ba-p/34653258

What are thoughts about the part that says "while in a host users can edit with "sample accuracy"....

If the "ruby to green to ruby/midi" lands on the money in the host, how can you say that sample accuracy
is not achieved?

Just dosn't add up.

billv wrote:If the "ruby to green to ruby/midi" lands on the money in the host, how can you say that sample accuracy
is not achieved?

No you can't because if you test a special case (which in your case is FL-Studio) then it doesn't mean that it'll work on other hosts. FL-Studio uses some advanced (and actually uncommon) technics in their VST wrappers. Other hosts don't care that much about it and use standard technics and in all of these Hosts, your plugin is going to fail horrible. You can actually test that even with FL-Studio, if you disable the advance features.

The most important thing that you have to test, is what happens when you change the VST processing block size from variable to fixed. This option is in the VST-Wrapper Windows under "Wrapping settings" -> "Processing" -> "Use fixed size buffers" You have to enable that and on the right of that, click on "Options" and check "Use host block size".

Even without testing that, I prophesy your "claimed" accuracy will go to hell!

G'day mate...jesus I'm glad its the w/end.....been a "heavy" week

MyCo wrote:if you test a special case (which in your case is FL-Studio

Mate I got to stop you right there.
The Supergreen test has nothing to do with FL studio.
When i say host-that means any VST Host on the planet.
if half of them nail it, and the other stuff it up....mate that just means
DSPR have re-shuffled the cards, a new hand has been delt and we have no-choice but
look down at our new cards and see where we stand, and start calculating our next stategy.
If its crap results everywhere, then we know straight up that we must use ruby timing throughtout
the schematic, and then deliver to green at the very last moment, avoiding, or rather
minimizing the delay issue Tester and Yourself pointed out earlier.
If, on the other hand "Supergreen" gets greenlighted.....it's the same deal.
DSPR re-shuffles the cards, but this time it's different, the cards are all face up.
Then we have to test the behavior of the green tick at heaps of different points
throught schematic, to see where it's breaking down and how far the power of ruby will extend.
How much influence does Ruby exert apon different threads?
Under what conditions does it fail?

MyCo wrote:The most important thing that you have to test, is what happens when you change the VST processing block size from variable to fixed. This option is in the VST-Wrapper Windows under "Wrapping settings" -> "Processing" -> "Use fixed size buffers" You have to enable that and on the right of that, click on "Options" and check "Use host block size".

...more smoke and mirrors.....
......maybe a straight flush.....

MyCo wrote:Even without testing that

Not a time for parley or prophesy....
All a human being has to do is generate an error of more than 1 sample. Not a big ask.
I just wanna see how powerful this Ruby Beast is.
The Best way is to add one dodgy element a time test it, then make an assessment.
Com on bro, get the ball rolling. Humor me.
Come down to my level, all way down to the bottom till you see a guy sitting in a studio four about 20
years cranking out track after track. he dosn't read music and is self-taught.
And he only plays 7 notes(blues scale) and almost never plays in flat/sharp keys.
Myco, that guy is not interested in facts/theroies when he's making music.
if it sounds and feels right...it is right... and he's then moved on to the next track or issue at hand.

You know what I mean bro, you keep hitting me with all these jazz chords and i can't solo over that,
I just fold every time you hit a flat key

Myco, can you provide your "definition" of sample accuracy.

2 defintions from me are......
a. That "ugly" screenshot I keep posting that you hate so much(so I won't post it)...."screenshot 214"
b. The Loop creation method that yields a sample that is "sample accurate" as discribed in
the link I posted earlier in thread , the one relating to audio.

You will also need to explain, how these two defintions are false.

Remember I did not create FS. It's not my fault we have all this power now in Ruby.
In other words.....
How long are you going to make me sit here, holding this stupid "Royal flush"......
S**t mate, I wanna move on to the next hand.
Bartender...give me another shot of bailey's.......

This whole discussion leads me to a question. If in the schematic a lot of triggers are wandering in "paralel" threads (independent: common starting point ends via stream/other-non-green, or separated by time/user based events), then - is there a hidden rule that decides which triggers have greater priority than the others?

Now - I ask this question, because many times earlier - Trog suggested that there is "backward sucking" (some sort of backward logic) of triggers. If so, then maybe (just maybe) - there is something, that bonds certain types of primitives in terms of greater priority? That would/could explain, why in certain around-green situations - delays are smaller and acceptable.

I can imagine, that some primitives are guided from their common "core", and thus - triggers between them - are forced to go first (renderer dependent priority).

tester wrote:is there a hidden rule that decides which triggers have greater priority than the others?

great question....guru stuff......pass

tester wrote:Trog suggested that there is "backward sucking"

Thats basicly my first post in this thread.....but written in guru...from a slightly different angle.
Thanks for that. clarifies the idea a bit more.

At the moment as well, maybe it's a option to stop practical testing and continue in theory.
Will move faster then.

billv wrote:Myco, can you provide your "definition" of sample accuracy.

When I output an event at a given time into an audio stream (which get back into the host) then it should get in the hosts audio buffer at the same position where all other hosts events for that given time are. Or simplified: When I output a sample at a time 123 which corresponds to the sample position 234 of the current buffer, then the host recieves that at exactly this position.

tester wrote:If in the schematic a lot of triggers are wandering in "paralel" threads

No, all triggers run in the same Thread! They are serialized. So there are never 2 or more triggers at the same time!

tester wrote:is there a hidden rule that decides which triggers have greater priority than the others?

The rule isn't hidden, it's called trigger order. That are those gray markers, that you can see on connections.

tester wrote:Trog suggested that there is "backward sucking" (some sort of backward logic) of triggers. If so, then maybe (just maybe) - there is something, that bonds certain types of primitives in terms of greater priority?

No, all primitives inputs/outputs have the same priority. The backward triggers happen on all normal triggers, they are invisible and only request the current value of an output. This is explained in details in the "User Guide" section "Triggered Data".

tester wrote:I can imagine, that some primitives are guided from their common "core", and thus - triggers between them - are forced to go first (renderer dependent priority).

No, there aren't higher priority triggers. But there is one special case: The triggers from primitives that convert Midi into green. Those come from a different thread, they have the same priority, but they need a special care.

billv wrote:At the moment as well, maybe it's a option to stop practical testing and continue in theory.

You've done "practical tests"? Really?