DSP Robotics Support

trogluddite wrote:

RJHollins wrote: ... but sure hope we get a TROG sighting !

Caeful what you wish for - I get a "Trog Sighting" every day, first thing in the morning in the bathroom mirror - not a pretty sight!

Yes. My concern comes at 'shaving time' ...

would You trust THAT person .... with a razor.

Thanks Trog....was hoping you'd shine a torch on the situation...
but as usual, you've turned on the 'floodlights".. ...
Good to hear X11 behaviour using ruby can be accounted for in "guru-land". Too hard for me...

tester wrote:In other words: "X11 - Quantum Fuzzy Edition"

How about a name change from X11 to "WTF".
Or yeh....create a new X12....
We could sweep X11 under the carpet, forget it every happened...ha ha.

well ... not to make lite of all the work that went in ...

but you are using an 'X'-perimental naming scheme.

Although us 'watchers from the sideline' are trying to learn from this thread ... maybe it also points
to the nature of designing a 'programming language'. The myriad ways that design, component, and code
are brought together could be infinite.

I know I'm not providing any hint of answers to help. I wish that I could, and hope that a revelation develops.

RJHollins wrote:hope that a revelation develops

Yeh well I'm on the sidelines too mate, I know what you mean.
There are many many questions here left un-answered and every time we get an answer-
it creates more questions.
If we could identify the 'threshold point' where this "magic" starts to occur...would help.
Maybe as more large SM projects get ported over to FS, we might see more examples of this,
and we can get a better insight.
Try re-reading trog's post again and again.....there's some rippers in there

trogluddite wrote:introducing a Ruby section changes the way that FS's various threads interact with each other, and that in certain cases it causes 'green' sections to be scheduled in a slightly different way that has a positive side-effect not accounted for in the "theory"

trogluddite wrote:But no maths or CPU opcode actually happens at precise sample boundaries except by pure conicidence

trogluddite wrote:Ruby doesn't really care about timing, only about the sample 'position' within the buffer

trogluddite wrote:Now, if a Ruby event in turn creates a green event - will the green event be "sample accurate". It is possible. If the green event were in some way "timestamped" by Ruby

trogluddite wrote:if those parts need to do something, and the CPU cycles are running low, the triggers will go into "suspended animation" while the more important stuff gets done, and they might miss the next buffer request and be held over to be done later.

trogluddite wrote:or the Ruby/ASIO combination might be causing threads to talk to each other at more regular intervals

trogluddite wrote:so there is a precedent for that kind of anomalous behaviour.

Making unexpected = getting unexpected.

Question. Is it doable to make some simple test designs to verify Trogs "statements of possibility"? That would/should help a little bit.

tester wrote: Is it doable to make some simple test designs to verify Trogs "statements of possibility"

Very.
Thats the plan...heaps of different ideas or ways to go about it as you suggested....
Still lots to think about....maybe a good idea to let the brain keep processing it
Busy with 2.01 update/work stuff....won't start anything here for at least a week....
Have to keep stirring this pot in "theory" at my end....maybe sneaking in a quick test here or there.

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 don't know what the issue is, but sometimes I use afterload with whatever-delay (usually 1-10ms; timer just gives separation from logic/order), to provide correct order of things. For non-whatever-delays I usually give 500-1500ms, to allow things to reset and set back (usually streams related).

Wow, so you collectively piss everybody right off in the next sentence.
Moving phased in bullying/sweet talking. While actually using "static" to phase out a forum.
No wonder why most the community members are gone. And were left with your rediculous posts.
Just a thought..

MH - it is YOU who killed SM forum. Not others. Don't try it here.