DSP Robotics Support

LOL you guys crack me up!

I dont think there is any smoke here guys, just a good simmer! Myco, to be honest its great to have you here & involved on this. If anything, we all learn from it so its all good in the end

this has turned into quite the discussion! 12 pages on billv's thread too! Nice

@MyCo

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

So I thought my timing WAS in Ruby which then passes the trigger to the graph. Doesnt the trigger from Ruby to the graph run on the gui/green thread?

MyCo wrote: What do you want to test with it?

This..the purpose for what it was designed...

MyCo wrote: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.

So it should not matter what we put there, counters or window's time module-
they are both still being tested by the same procedure.

Drnkhobo wrote:So I thought my timing WAS in Ruby which then passes the trigger to the graph.

You have to capture the stream data in Ruby, to stay accurate

Drnkhobo wrote:Doesnt the trigger from Ruby to the graph run on the gui/green thread?

Yeah, but this doesn't really matter, because when the data is capture you can display it anytime until the next capture happens.

billv wrote:So it should not matter what we put there, counters or window's time module-
they are both still being tested by the same procedure.

No they are not! You measure nothing, just because the trigger order is wrong. And if it would be right, you would always measure ZERO, because both counter will increment, and finally they'll get compared. So they'll allways count the same.

Listen to MyCo, trigger order can be a project killer!
I just spent a week on creating a calculator for 1/3-rd part of resonances.
Wrong trigger order - and you are in China.

MyCo speaks the absolute truth here about the way green & triggers work! these are all things that have been tested and spoken about, even by the Devs, many times over the years, it's just that a lot of you guys would not have been around then and will have missed a lot, Trogg also has some great tutorials on triggers as well on the SM forum!

good info MyCo! a lot of it I had forgotten myself!

well I don't yet understand the frames stuff yet, that's something I should go try to learn about! anyone any good examples of using the frames components?

Best Regards

MyCo wrote:just because the trigger order is wrong

I noticed that, cheers. Set it up right and still got 0, like you say.

MyCo wrote:So they'll allways count the same.

Exactly-therefore if you keep using this count, sample accuracy can be maintained
throughout the schematic. Proven fact.
My definition of "sample accuracy", being this...

It's FS now guys. Different Planet. No-one has explored the infinite possibilites....
When they built SM....do you think they tested it with a Synth if a Million parts.
Do you guys actually think, that DSPR know the limits of what they created...? No way.
In the space of time that FS has been available, has every creative possibility been
explored and done..... think about it guys......open your minds....let SM go.

Thats why I really don't think it's worthwhile for me to continue any timing discussion.
i have my version of sample accuracy as i know it, and the gurus, with all those mountains
of extra knoledge, nataually see it from a completly different perspective. All good.

tester wrote:Listen to MyCo

Allways do.

tester wrote: trigger order

Well aware...as my other post indicates..

Jay wrote:MyCo speaks the absolute truth here

Yeh I know, he's good value.
That's why I'm slowly removing all reference's to accuracy in my posts.
Thats how much respect i have for him.

As long as you don't give an example and tell me how you captured stuff in FLS (as I told you in another thread), your results and screenshots are completely meaningless.

This is the ultimate proof, that green isn't sample accurate...

Ok, while not in any way devaluing this current topic, can we get back to the orig topic?
I guess time will tell which way is best for timing (not taking sides) for the time being I want to get this scope sorted.

So as it stands the scope still bounces around. If 100000000% accurate timing was an issue, then WHY would it bounce around? Is it because the green thread it runs on is, as said, windows time. So each time its always different? Kinda like whenever windows feels like it? That would explain the bounces since each time the trig gets fired its different timing from the actual trig.

Look to the future. . . .

So what can we do to get this fixed? What about a Ruby module that determines beat (in itself or from another Ruby, passing Ruby Values) whilst reading mono2frame input, to then draw on a view. . ?

I though about some Ruby magic with Array's to post process the mono2float Array. But im not so sure about it anymore. Surely Ruby can do it all?

Oh and remember im not looking to get a realtime snapshot. a delay of 1 beat is fine

MyCo wrote:As long as you don't give an example and tell me how you captured stuff in FLS

No mate, None of these pics are from FLFS. Pointless testing. I went through that whole FLSM system
years ago with the XFL Series. Nothing to be gained testing in FLFS, unless your already working in there.

MyCo wrote:your results and screenshots are completely meaningless.

Thats why this timing disscusion is pretty much over.
Cleary I have NO IDEA as to what "sample accuracy " is?

MyCo wrote:This is the ultimate proof, that green isn't sample accurate...

No I don't get it.
This is Ruby up against Green. Of course Ruby will kill it
I showed that in very first post in Timing thread, that on it's own, ruby wins every time.
The circuit should be ruby to green and back to ruby.

But I don't know what I'm taking about yeh?
So don't worry about Myco. I'm wasting your time- it's all going in one ear and out the other.
You win..
I'm just gonna go back to building stuff...leave the tech stuff for the tech people.
Cheers mate.