proper resync plus offset?

[tulamide]

Isn't blue always in sync?

All of the blue parts are always in sync with each other, yes. The problem was with reliably getting the blue parts to recognise the button press: In the original version, the blue parts were looking for 'true' from the button, but the original button could potentially change 'false->true->false' so quickly that the brief 'true' state would get lost in the time interval between two ASIO/DS buffer requests. Thankfully, FS spares us from worrying about these kind of concurrency problems in all but rare cases like this one!

Ruby could be the answer, if it just had a RubyValue to Blue connection pre-built in a prim, or the editor would allow RubyValue inputs. I couldn't find a way. Which is a shame, because Ruby is also synced to blue.

[trogluddite]

RubyValue to Blue connection pre-built in a prim

There is - Frame to Mono! Which in principle does allow these sample-accurate things to be done - but it makes the whole buffer-sync problem one for us to solve rather than one which DSPr has made easy for us!

editor would allow RubyValue inputs

You want to pass the DSP/ASM editor an arbitrary Ruby object's instance ID (in effect, a pointer to the object's binary structure)? Are you quite sure about that?

In the general case, there is much more that could be said about the "sample-accurate trigger" issue (including why Ruby has failed to make it much easier) - something for a dedicated thread, maybe. For the original problem here, I think the guys have converged on pretty much the best solution. Mouse-clicks are low-priority anyway, so will only be read from the OS in-between audio buffers - a truly "sample-accurate" version would just waste CPU for no good reason.

[tulamide]

RubyValue to Blue connection pre-built in a prim

There is - Frame to Mono! Which in principle does allow these sample-accurate things to be done - but it makes the whole buffer-sync problem one for us to solve rather than one which DSPr has made easy for us!

editor would allow RubyValue inputs

You want to pass the DSP/ASM editor an arbitrary Ruby object's instance ID (in effect, a pointer to the object's binary structure)? Are you quite sure about that?

In the general case, there is much more that could be said about the "sample-accurate trigger" issue (including why Ruby has failed to make it much easier) - something for a dedicated thread, maybe. For the original problem here, I think the guys have converged on pretty much the best solution. Mouse-clicks are low-priority anyway, so will only be read from the OS in-between audio buffers - a truly "sample-accurate" version would just waste CPU for no good reason.

I know of frame to mono, but that is not what I meant. And that plays into the second of your answers. No, I don't want a Ruby class instance to DSP/ASM. That's also not what happens, when you push a Ruby class into green. Instead, Flowstone does the conversion to a value in compiled C, and that is what I would have loved to see with the editor. So, basically, a :to_f or similar method, but on Flowstone's compiled C side. The user, as with prims, doesn't get to see it. He just sees a RubyValue input. But we could be sure to have the value in immediately, opposed to converting to green and then relying on unpredictable timing. Frame to mono, to pick it up again, deals with arrays, which makes it very demanding on the CPU side and therefore isn't a suitable replacement.

But yes, the guys already solved it, so this was more of a thought process, rather than a concrete suggestion.

[trogluddite]

That's also not what happens, when you push a Ruby class into green...

I know, I know! I was being unreasonably pedantic in a pathetic attempt at humour - my apologies!

The only slightly serious part was that, because RubyValue links can carry a reference to ANY kind of Ruby object, it requires more care than usual to pass only objects that the receiver can use - not everything has a working "to_f" method; and as we all know, any time that we can make bugs, we will make bugs!