Ticker Timing-- Ruby better?

[Perfect Human Interface]

TL/DR: Is the Ruby custom ticker more consistent in terms of timing than the ticker prims?


I know green timing isn't accurate in general. But Nucleon from the IL forums mentioned to me that he found the PPQ prim output more consistent triggers than the ticker prims. He mentioned moving windows around could cause the tickers to be more jittery and such. He also mentioned he wasn't sure whether Ruby based tickers were any better.

I'd rather not use PPQ since it requires the project to be playing. Does anyone know if the Ruby tickers are more consistent than the ticker prims? Looking at just timing, not efficiency.

Thanks.

[Perfect Human Interface]

Ok, answering my own question here (sorry for being so scatterbrained guys, really).

Had a bit of a laugh-out-loud moment with this. I can hear my clock ticking in my kitchen from here, so I just rigged this up and clicked start on the tick, then without looking counted 60 ticks, then clicked off, and this was the result.

1 min.PNG (21.46 KiB) Viewed 15890 times

[tulamide]

Ok, answering my own question here (sorry for being so scatterbrained guys, really).

Had a bit of a laugh-out-loud moment with this. I can hear my clock ticking in my kitchen from here, so I just rigged this up and clicked start on the tick, then without looking counted 60 ticks, then clicked off, and this was the result.

1 min.PNG

Now that will make DSPr proud! It's exactly what they promised in the user guide. The schematic timer used for ruby (green uses windows timer) runs at 100 Hz, is much more stable and locks to asio if present.

[Nowhk]

What does exactly means that schematic runs at 100 hz? Does it process every single operation (such as send a trigger) every 10 ms? Or schedule the whole task?

Or this is just limited to Ruby events scheduling?

I believe Flowstone can do more than 100 triggers in a second, for example

[nix]

I'm not sure what gets refreshed every tick,
but maybe only the Ruby operation?
1000hz Ruby is as fast as it gets before cpu is unmanageable, and 1000 is heavy anyway.
It depends on your system , just a rule of thumb

[Nowhk]

I'm not sure what gets refreshed every tick,
but maybe only the Ruby operation?
1000hz Ruby is as fast as it gets before cpu is unmanageable, and 1000 is heavy anyway.
It depends on your system , just a rule of thumb

As tulamide said, it seems that green use windows timer (not accurate) while Ruby a specific (more accurate) timer that runs at 100 Hz (even if manual is confusing about this).

Basically, Ruby should runs faster and accurate then native primitives, even if using prim directly it seems to me lighter and faster (maybe changing the context between FlowStone (C++) and Ruby introduce an overhead that is huge calling many times per seconds).

But my question is: what does it means run at "window timer clock" within FlowStone? For example for triggers: if I have a chain of Triggers (A->B-C), this means that it needs 2 ticks (A->B and B->C) or that the whole chain is executed at fixed tick and ends depending by the power/busy of the CPU?

Because in the case of first case, this means that in one second I can do very few operations (~60, if we are lucky).
I don't think so. I think it schedule a task every tick and complete it as fast as it can (the same for ruby: it execute the event method at tick and finish it asap).

A confirm would be nice

[tulamide]

Things are about to be confused here.

The schematic clocks are used by the user (= us). They come into play whenever time is relevant. We can use them to measure time, to repeatingly send triggers, schedule events or methods, etc.

This has nothing to do with the execution speed of the schematic.

If you try to call a method at a fixed interval, then the Ruby clock guarantees accuracy down to an interval of 10 ms. If you try to call it faster than that, it becomes unreliable and may even generate errors.

If Flowstone calls methods (for example drawing routines, or a prim), they are called as fast as possible.

[Nowhk]

The schematic clocks are used by the user (= us). They come into play whenever time is relevant. We can use them to measure time, to repeatingly send triggers, schedule events or methods, etc.

So the 100Hz has nothing to do with schematic in general: its only for Ruby and how it schedule events.
And inside FlowStone in general there is not that timing: if I trigger a prim, it try to send the trigger as fast as possible (without any clock/tick related). Yes, very confusing...