Mono To Float bad timing/trigger limited

[Perfect Human Interface]

I just put together a triggers per second counter and now I'm finding out interesting things. Like the Mono to Float prim is very limited in trigger output and timing. Put 100 triggers per second through it via Ruby ticker and I'm getting around 65/second out of it (which interestingly is exactly what I get out of the tick100 prim too). Crank the Ruby ticker up to 1000/sec (which apparently is actually 1024) and M2F outputs triggers fluctuating between around 70 and 125 (it hit 148 once).

So apparently M2F is pretty inaccurate timing-wise. It may use the same timers as the tickers somehow and fluctuates a lot, even with moving windows around the screen and such. And I thought my plugin was running at 100 ticks per second, but it's actually at around 65. The more you know.

[KG_is_back]

I may not be correct, but green ruby and stream run on separate threads, which also means, they are executed on different times. Stream calculation takes place in buffers (which are provided by our soundcard/DAW in regular intervals, in case of ruby they are called frames). Everything else (green/ruby/recompilation) takes place in between the buffers.
So I assume that mono to float is actually a simple variable that keeps the last value, that was given to it in last buffer calculation. In green you then simply read the value the variable has. If you set the input triggers to higher rate then the buffers come in, then you would read the same value several times all over again. So there may be a limit, that if multiple triggers are received to read mono value in the same buffer only one is send out with the value.
Anaways Green triggers are limited to cca.100Hz so you can' send (much) more than 100triggers can be send via the same wire per second.
To read values at such high rates use mono to frame and extract the values in ruby directly. It is relatively easy to make a custom mono to float prim with ruby with sample-precision

[Perfect Human Interface]

Green triggers are limited to cca.100Hz so you can' send (much) more than 100triggers can be send via the same wire per second.

My testing shows otherwise. I can count well beyond 100 triggers being sent on one wire in a second.
If some kind of a rate limit does exist as you say, are they perhaps being doubled up (i.e. more than one being sent simultaneously)?

To read values at such high rates use mono to frame and extract the values in ruby directly. It is relatively easy to make a custom mono to float prim with ruby with sample-precision

This is good to know.

Edit: The behavior of the ticker 100 and the Mono to Float are extremely similar. If you put the tick100 into the Mono to Float, there's no discrepancies in the trigger rates (they're measuring exactly the same on both the ticker output and the M2F output). If you put a Ruby ticker on the M2F at 100/sec, the trigger output rates fluctuate between the same values, and if you move the window around the trigger rates tank by the same amounts (down to 20 or so) on both the tick100 and M2F, even though the Ruby ticker does not exhibit this behavior. It can't be coincidence.