DSP Robotics Support

Oh im around for years buddy
Really.. after any post explaining the problem, a derogatory post of your camp.
Just saying because you managed to piss off a lot of people in this topic.
Holding hands and stuff

billv wrote:Guys, I got an issue with the test unit with ruby counters.
Concerns that "consistancy" problem.....

3 Times now, I've cut a new vst, tested it, and its spot on everywhere.
Shut the host down and try again, then they fail.
So there's a big clue there.....

I think its something about how ruby is re-setting itself..don't know how ruby works there...
Or is the host saying"hey plug-in, I already know you...I'm not paying attention"..somehow??

But i have seen a similar problem in the X11.....and the bug is still there if you want to see.
Notice when you start the X11, the clock jumps straight to "1" and in sync with the host clock...
But not the very first time the synth is played after being loaded...it counts at "0" first .
After the next stop/re-start...bug dissappears forever....
This seems to be an afterload issue.....not sure.....probably un-related to above issue..??

I thought I read that 'RUBY' state is 'remembered' ?!?

RJHollins wrote:I thought I read that 'RUBY' state is 'remembered' ?!?

maybe it does.....not sure...will have to search user guide.......
My question was probably a bit silly......it's just seems like strange behaviour.
If I got bad result on the first test run's...I'd leave it there and move on....
But when i works the first time, everytime.....then fails after re-load...something weird there..

After reload schematic in flowstone or reload whole flowstone?

MegaHurtz wrote:Wow, so you collectively piss everybody right off in the next sentence.

MHz, will you please just give it a rest.
Some folks may have disagreed with some of tester's points in the past, just as he may have disagreed with theirs, same as for any other forum user - what a boring world it would be if that were not the case. But I don't see any "collective" exodus of people all claiming that his behaviour has made life on the forums intolerable. (I certainly know for sure who amongst us has received more moderator warnings and post edits back at the SM forum!)
I don't perceive anything "derogatory" about anyone having a different perception of a problem than the way I might explain it - I might disagree with their "model" of how things work, or even find it frustrating if my posts are misunderstood or fall on deaf ears, but so what? Since when was any of us always right about everything all the time?!
And where, may I ask, is your all-encompassing explanation for the unusual results that billy et al. are seeing? So far, even the most experienced of us have only been able to point towards general "good practice", and make very tentative suggestions about the unexpected stuff. I guess you must want to keep us all in suspense about whatever amazing insight you have that you are too selfish to share with us.
If this thread, or the FS forum in general, are not to your taste, it is very simple - go find one you do like - the internet has no shortage of websites where childish tittle-tattle and unfriendly sarcasm will find a happy home.

Back on topic...
...that's enough "Troll Food"...

Regarding doing some tests of how 'green', 'Ruby', 'MIDI' are interacting - it seems to me, that the crucial point to test in my "hypothesis" is this...

Do green events created by Ruby receive some kind of "time stamp" as for MIDI (or maybe, just end up sharing the same thread). This is the one thing that would be essential to have tighter green timing that was deliberately designed into the system rather than just a fluke.

Without checking for "sample accuracy" specifically, it seems that this should be easy to test - send a MIDI event from Ruby on a known MIDI channel. Then take a 'green' path from a second Ruby output that is triggered at the same time - pass it through a few primitives - create a MIDI note from that trigger using the standard primitives on a different channel to the Ruby MIDI event. Then merge the two MIDI links.

If Ruby does indeed tag green events with a sample buffer "index", then we should be able to record those two events inside the host, and show them arriving at exactly the same time - precsiely WHEN in time is not crucial to this test, only that the events are simultaneous. Whatever absolute timing problems the VST interface or host might cause will be the same for both events, eliminating many variables from the experiment, and revealing whether there really is any "non-SM" behaviour going on when we mix green with Ruby.
It might also show us whether the "special relationship" between FS and FL gives different results than in other hosts.

trogluddite wrote:Regarding doing some tests of how 'green', 'Ruby', 'MIDI' are interacting - it seems to me, that the crucial point to test in my "hypothesis" is this...

Do green events created by Ruby receive some kind of "time stamp" as for MIDI (or maybe, just end up sharing the same thread). This is the one thing that would be essential to have tighter green timing that was deliberately designed into the system rather than just a fluke.

Green runs in the GUI Thread, Ruby runs in a seperate thread. And nothing has changed on the green system with the introduction of Ruby in FS. Beside the general Green side effects like unstable timings, there is a penalty when crossing over from Green to Ruby and from Ruby to Green. This is because the data has to cross Thread boundaries, which have to be synchronized. Malc said that this takes +/- 1ms... But I guess this really depends on what is going on in the threads... so this can be even worse than the Green management itself.

trogluddite wrote:Without checking for "sample accuracy" specifically, it seems that this should be easy to test - send a MIDI event from Ruby on a known MIDI channel. Then take a 'green' path from a second Ruby output that is triggered at the same time - pass it through a few primitives - create a MIDI note from that trigger using the standard primitives on a different channel to the Ruby MIDI event. Then merge the two MIDI links.

That's what I've done to proof that this green timing discussion is completely bullshit.
viewtopic.php?f=2&t=1426&start=20#p5704

But hey... I'm not trog, so who cares about facts that don't come from the master of long texts.

"He's not the Messiah, he's a very naughty boy!"

MyCo wrote:That's what I've done

Sorry, MyCo, missed that one while I was away - exactly what I was meaning, and exactly the result I would have expected!

MyCo - you are just too good.

But telling others "that's bullshit" - will not solve the problems nor explain them in understandable/acceptable way. One part of a genius is knowledge, but the other part - is the expression of it (or at least understanding, that not everyone is in the same language, even if both are english).

Did you noticed, that biliv (probably) literally did not perceived what you told/showed him? It's not that he ignored you or did not understood. He literally did not saw your point, watching directly at it. No grounded reference points, no response.

You are the smart guy here, but it was Trog, who explained/unfolded some details on a level that stupid me could understand or confirm my own suspicions. You don't need to be like Trog, but accept, that me or biliv - are not like you. Yet.

Hehe, you'd be supprised about the 1 moderation I've got so far.
You must admit even I shaped your syntax quite a bit, but you musthave forgotten it all.

The dark and dubious reasons to me are stall and buffering. What else?

MegaHurtz wrote:Hehe, you'd be supprised about the 1 moderation I've got so far.
You must admit even I shaped your syntax quite a bit, but you musthave forgotten it all.

Yeah, OK, over-reaction on my part a there - guilty as charged!
And I never implied that you know nothing - far from it, I'm well aware of your knowledge of DSP etc. Stall and buffering, yes, of course - I don't disagree with you (or MyCo) about any of that - the intent of the "though experiment" was just to try and help explain those things to folks with no experience what threads are or what they do.
But why post only to snitch at people - that's what I don't get - getting a good universal PPQ lock that we can all use from the new timing system is eluding us still, why not use your obvious intelligence to help out?