"Supergreen" theory

[billv]

And he is right. "Supergreen" is a metaphor

Then they can throw it in the bin. It's just an attempt to explain what's going on inside X11.
Pick another theory.......won't change X11 behaviour....problem remains the same....

Fustrating me now......
Giving the test fsm with trog counters another round of testing this morning....
I can't re-create the error I got yesterday....

[stw]

[tester]

And he is right. "Supergreen" is a metaphor

Then they can throw it in the bin. It's just an attempt to explain what's going on inside X11.
Pick another theory.......won't change X11 behaviour....problem remains the same....

Fustrating me now......
Giving the test fsm with trog counters another round of testing this morning....
I can't re-create the error I got yesterday....
Still at 100 000 parts........too many variables.

Going back now to stuff like "Seq System 1.fsm", replace green count with trog count....
Isolate trog's counter some more and check it's impact.

Metaphors usually refer to "fuzzy logic" and "quantum statistics". That is - "works almost" and "sometimes does not works". Question. How to make the problem less important from practical point of view? Or how to take advantage of it?

I know how you feel, and I know how frustrating it can be.
In my projects I also have at least one unsolved issue.
At some point you need to take a rest for few weeks or months.

[billv]

At some point you need to take a rest for few weeks or months.

Yeh, the "timing" brick wall has always been like that.....
Only so much you can take before it does your head in....

[tester]

I see Trog just woke up, so there is a chance he will give a few words.

[billv]

I can't re-create the error I got yesterday....

Na, error back again in test unit.
Definatly in-consistant.

Tested "seq system 1. fsm" to see what it was doing......then changed green counters
with ruby counters, also changed green connections to ruby where possible.
Didn't get a result. it was actually more accurate in green....weird

[trogluddite]

... 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!

Interesting little chat you've been having while I had my little break (I had a little taste of being Malc, while we got our next big project finished at work - every time I tried to log in, the pixels were swimming in front of my eyes, so I thought I'd better take a rest!).

In general, I'm pretty much in agreement with MyCo (about FS's inner workings) and tester (how do we test these things properly without reference to 'special cases').
Is "supergreen" real? In a sense, it may be - it is entirely possible that 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".

First, let's examine what we means by "sample accurate". The CPU clock has very little to do with this beyond "faster is better" - the clock inside the soundcard determines the sample rate, and send requests to the software to grab samples as and when it needs them. So long as the CPU can complete all of the tasks that it needs to do before it gets another buffer request, and each data point is somehow 'tagged' with it position within the buffer, we can call that 'sample accurate'. But no maths or CPU opcode actually happens at precise sample boundaries except by pure conicidence - the FS 'one sample at a time' model of DSP is just a very clever illusion to make our lives easier as developers.

Unlike green, Ruby is told when these buffer requests happen, and uses them to regulate the flow of data - Ruby doesn't really care about timing, only about the sample 'position' within the buffer (an array index), and that there is a "boss" out there (driver/host) that at some point is going to ask "where are those samples you promised me?!".
And it is not predicting the future either - it just processes as fast as it can, and then waits for the soundcard to tell it when the appropriate moment is to release the data (and the soundcard's latency is what gives it the time to do this).

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 to say which sample within the buffer it was associated with, and all such events could be collected and sorted before the next buffer request, they would, to all intents and purposes appear "sample accurate". This certainly seems to be how MIDI events work, as MyCo pointed out earlier.

In fact, we could already see this with SM - the Windows clocks were terrible for scheduling accurate events, but MIDI events coming in from outside the schematic were able to generate green events more rapidly and accurately (again, so long as the trigger and all it's 'descendents' were able to be processed quickly enough).

But that is a pretty big IF - 'green' (and presumably Ruby) have lower thread priority than streams and the ASIO/DS components - 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.

Can this be relied upon? Certainly not! - but it gets more likely the faster your CPU runs, and with schematics that are better optimised to reduce unnecessary triggers.

So it may be that there are beneficial side effects of Ruby due to, for example, the CPU load being spread more evenly with fewer big "spikes", or the Ruby/ASIO combination might be causing threads to talk to each other at more regular intervals. But, once a high-priority thread has possession of a piece of data, no other thread is allowed to change its value, and must wait its turn. If that high-priority event happens to be an audio buffer request, then the data has 'missed the boat', and won't even be in the same buffer, let alone at the same sample

Can working the CPU harder make things work better, as billy seems to see in X11?
This is not impossible either. Most PC's use all sorts of weird and wonderful technology to try an reduce power consumption etc. - for example, by lowering the CPU clock speed and voltages when there is low load - or by buffering data saved to disk so that it can all be dumped in one big chunk.
CPU "throttling" can be a bit of a pain in this respect sometimes, as switching between "normal" and "power saving" modes can take quite a bit of messing around. When the CPU is well loaded, that switching won't happen, and the CPU runs constantly at full power with no chance of "glitches".
Similarly, in day gone by, it used to be recommended to turn off "write behind caching" for hard drives, because the HDD buffer would sit there doing nothing until there was a shed-load of data, and then attempt to dump it all at once right in the middle of a really good recording - better to have it saving small chunks more regularly.
I'm not saying that is definitely either of those things that cause billy's observations, but they are typical of the kind of things that modern PC's do to keep power consumption/temperature etc. down - so there is a precedent for that kind of anomalous behaviour.

[tester]

In other words: "X11 - Quantum Fuzzy Edition"
(QFE 2.0 - sounds good?)

[trogluddite]

Not non-deterministic, just a simple case of a...
Machine Antagonistic to Generally Intuitive Comprehension (MAGIC!).

[tester]

Not non-deterministic, just a simple case of a...
Machine Antagonistic to Generally Intuitive Comprehension (MAGIC!).

No, no, no, it's Probabilistic Interdeterministic Transmorphing Aggregate (PITA)... or else.

Is there in FS an error called "Guru Meditiation"?
I remember one from C64/Amiga (or somewhere around).