DSP Robotics Support

Drnkhobo wrote:ok, so will it be accurate if the timing & drawing is all in Ruby?

The drawing doesn't has to be done in Ruby, but the timing and capturing of the array data, that'll be drawn.

MyCo wrote:No, sample accuracy isn't maintained. As soon as your timing path relates on a green connection, your sample accuracy is gone.

//You know i love you man,but, ....you got to be kidding
OK........
Forget all the uploaded FSM's I have uploaded in last few months which show otherwise.

I'll just use one example to state my case.

The X11Synth.
Close to a million parts inside.
This is the Scale Seq
( 6 green notes on a green counter fed by green tick supplied by ruby)[/b]

Here's a small snapshot of X11 "engine room".....

MyCo wrote:When you use something else, your accuracy is depending on Windows and CPU usage.

So according to your theory, the X11 is achieving this "Impossible" result by...Windows and CPU usage???
Well, Bill Gates must be pure genius with his design of Windows, because I'm running a 2.33 Quad core CPU that's the slowest version ever made, and is about 4/5 years old now.

So No.... I got to dis-agree completly at the moment Myco.
Will be happy to change my mind If someone can "explain" the above.

I've heard this type of theory a few times over the last few months....

MyCo wrote:As soon as your timing path relates on a green connection, your sample accuracy is gone

Yet at every turn, I keep making a "mockery" of it.
How long will guru's maintain this?.......and for what purpose?

billv wrote:So according to your theory, the X11 is achieving this "Impossible" result by...

When there is no load, it's possible, but it's not stable. And it's not a theory, it's how the stuff is build... Green Data flows in the GUI Thread, this means it's not depending on the audio processing at all.

Just to prove this, I've attached a schematic that demonstrates that there can be a time difference in triggers that were generated by the same event, even when they come from the same output.

MyCo wrote:Just to prove this, I've attached a schematic that demonstrates that there can be a time difference

Thanks for that mate. Will tinker with it tomorrow when more time.
Yes, the circuit in the FSM proves it as you say.....but
Unfortunatly at the moment, the circuit dosn't apply.
Why is the ticker routed through a windows time module???
Only a lunatic(like me:remember my first attempts about 6 years ago ) would punch his
timing tick directly through a windows time module, and expect any sort of accuracy.


Anyway, your going to love this.......

About a week ago I posted a new thread called "Ruby performance", which I quickly deleted
after about half an hour, for lots of little reasons.
Here's what i was questioning...
Is it better off to take something like this...

And turn it into this....

So who's faster..Ruby or (insert the launguage FS is built on here)????

Anyway, back to your post.....

MyCo wrote:When there is no load, it's possible,

But there's a million parts in the X11, and I test it most of the time under full load.
The audio is getting smashed, GUI is going nuts, I've actually grabbed the plug in, and twirled it
around the screen rapidly in circles and stuff ----damn thing still nails it.
I couldn't believe it.

Could there be a "co-hesion" type of thing happening because of its size,
where a "tightening" occurs caused by friction within???. causing all circuitry to "gel"..so to speak?

Also, thanks for sorting that graph thing out. Just couldn't work it out.
It sort of make sense. Some things just require that "higher level" of programming.
Much like the "I'm not allowed to use the note event anymore"
..got to use ruby to deliver the goods, type of scenario.

Hey, what if we compromised and said something like...
"S/R Accuracy in Green is possible, but NOT RECOMMENDED"
"And for some things(eg:graph) NOT POSSIBLE"
"SEE YOUR RUBY DOCTOR FOR ADVICE"
Or we could directly hassle DSPR about it????

MyCo wrote:Green Data flows in the GUI Thread

True. But if Ruby has direct control of the Green data, its not green data anymore.
It's "Supergreen"(or insert some other stupid name for it here).

EDIT:

MyCo wrote:Just to prove this,

EDIT AGAIN:
Something weird about this Trigger accuracy circuit Myco....high step rates crash it everytime..
Look forward to mucking around with it.
Cheers.

billv wrote:So who's faster..Ruby or (insert the launguage FS is built on here)????

The FS version is faster, because every trigger on a Ruby input invokes the Ruby parser/interpreter, which is slower than native machine code.

billv wrote:But there's a million parts in the X11, and I test it most of the time under full load.
The audio is getting smashed, GUI is going nuts, I've actually grabbed the plug in, and twirled it
around the screen rapidly in circles and stuff ----damn thing still nails it.
I couldn't believe it.

Just change your audio buffer size upward, and the whole thing is going wild. Or just use the song rendering methods of the host, the green triggers couldn't get send as fast as the audio is grabbed. This could also lead to heavy crashing because of accumulation of millions of triggers.

billv wrote:"S/R Accuracy in Green is possible, but NOT RECOMMENDED"

No it's impossible in green. It might look like it's working in some very rare cases, but most of the time it is not.

billv wrote:But if Ruby has direct control of the Green data, its not green data anymore.

No, Green data coming into Ruby is converted from triggered data into timestamped event data. And Green data coming out of Ruby is converted from timestamped event data into triggers. Have a look in the user Guide, the difference is pretty well documented there Chapter 5:

...there are two important differences. First
the Event carries data with it. The Trigger system only signals that a change has occurred,
components then call back (to the left) to calculate their values. Events carry data with them. Once an
event arrives at a component there is no calling back.
The second difference is that Events are scheduled. When an event is first created it is given a time
stamp and will only be executed when that time is reached. This means that you can specify exactly
when you want an event to occur. This timing integrates fully with the stream data so that you can
schedule events to occur at a precise sample.

To clarify that: green is running in the GUI thread, completely independend. Events are synchronized with the audio processing in the bufferswitch of the host. What this means: Event Datas max. accuracy on audio processing is 1 sample. Green datas maximum accuracy on audio processing is 1 buffersize.

billv wrote:TriggerAccuracy_BV.fsm

No this is completely useless. The counters are both incremented before they are compared. But The first counter is incremented 11ms (on my machine) before the second counter is incremented (that's what my example above has proven).

Here is another proof

MyCo wrote:Just change your audio buffer size upward

Will try that for fun, make it crash via audio buffer abuse is something I never looked at.

MyCo wrote:The FS version is faster

Thanks for the tip..will bear in mind..

MyCo wrote:No it's impossible in green

Yeh, well i can't argue cause i don't have the tech brain to nut through fine print.
So I'm probably wasting your time.
All I know is stuff like this, and what i can hear.

But I can remove any traces of accuracy from my posts so as not to "mis-lead" anyone,
and stay out of any future timing/accuracy discussions as well...

MyCo wrote:No this is completely useless

No, that was your FSM. Now it's suitable for "ruby to green" tests.
Your "Triggers when there's a time difference" string is always "0" on my machine.
I think I'll use this a lot. need to figure out why it crashes at high speeds though..

billv wrote:No, that was your FSM. Now it's suitable for "ruby to green" tests.

heee? What do you want to test with it? It's useless, because the counter are always incrementing at the closest possible time. The trigger order is completely wrong!!! The trigger counter at the end never gets fired, because the trigger that should be passed through the trigger switch is fired, before the switch is changed! The "Some Random processing" Module is triggered before the counters, so there is nothing that you can measure.

I don't want to go into the details, but you should read how green triggers (and especially trigger orders) work. Unless you do understand that, I don't want to argue anymore.

wow ... what a thread of information.

I've been following billv's threads since I joined ... hoping to get some kind of understanding.
And MyCo's posts, all the way back in the SM forum, are always leaning 'Gems'.
Just wanted to say thanks to both !

I like such conversations too, because they show on practical side what and why works or not. Sure, they not always end with consensus, but they help to determine practical needs, and solutions good enough to fit them - even if they are not the best ones (I will not mention my entanglements here ). Like me earlier - bill is probably processing a lot of data now, and I can understand him - he want to make his things works.