Sample Accurate Triggers: Holy Grail? Or...

[trogluddite]

In a recent thread, the age old debate about synchronisation between 'green', Ruby, and audio streams has once again been visited. And anyone who's been around FlowStone for very long will no doubt be aware that, since the earliest days of SynthMaker, there has been an almost Arthurian (or Pythonesque) quest for 'green' triggers which can be placed more rapidly and precisely than usual (ideally with single-sample precision).

After my 15-odd years of using this software, and some rather useless attempts at making plugins using conventional code, I have a pretty firm hypothesis about sample-accurate triggers, and I thought I'd post it just to see what anyone thinks (maybe nothing! - I totally understand that a lot of people have no interest or time for musings about FlowStone's inner workings - the whole point of FS is that you shouldn't really need to know!)

So here's my hypothesis, and we'll see if anyone bites!:

Sample-precise triggers are not a myth; they have existed since the very beginning of SynthMaker; they are all around us and are essential to nearly every schematic. However; they live only in the shadows, or disguise themselves as run-of-the-mill sluggish triggers. Apparatus could be devised by which FlowStoners might access their power, but DSPr have judged that we should "be careful what we wish for" - for the consequences of using them recklessly or without the requisite training could be dire. Thus we are forbidden from explicitly conjuring them up.

"From whence do I derive such conspiracy theories?", I hear you ask. [auditory hallucinations can be very confrontational sometimes!]

Well, there are certainly some technical details which can be, indeed have been, empirically tested. Other parts can be deduced from the way that VST works and general software engineering principles. However; DSPr restraining us from shooting off our own feet? - that's rather more conjectural, though with some basis in dealings that I had with the dev's when I was a SynthMaker beta-tester many years ago.

In any case, I am confident that the current limitations of triggers are not something that can ever be overcome by any kind of clever building, coding, or hacking on our part (and nor does Ruby live up to its hype in this regard). FWIW, I think that most of the use-cases for sample-precise triggers could be implemented with only a handful of new primitives (and extremely careful use of them!) - but either DSPr let us into the magic or they don't, and I think that's all there is to it.

[adamszabo]

Hi Trog, its great to have you back! Yes I agree, there are no sample accurate green triggers, one has to do them in dsp form for that.

[Spogg]

... However; DSPr restraining us from shooting off our own feet? - that's rather more conjectural, though with some basis in dealings that I had with the dev's when I was a SynthMaker beta-tester many years ago. ...

I’m also not totally convinced that it’s for our safety that DSPR have denied access to possible features. I say this because we are warned in the manual that ASM could wreak havoc if used without due care and attention.

I’m completely guessing that any conscious denial of a requested feature might involve a huge amount of code re-working, effort and time which would be of little benefit to the “average user”, whoever that might be.

[tulamide]

FWIW, I think that most of the use-cases for sample-precise triggers could be implemented with only a handful of new primitives (and extremely careful use of them!) - but either DSPr let us into the magic or they don't, and I think that's all there is to it.

I think so too. To get "sample accurate", we need access to buffers, either directly or -as you proposed- via primitives. I can't imagine any useful implementation of direct buffer access (see Ruby Frames), and it also defeats the purpose of Flowstone's "one sample at a time" layout. So primitives would be the only way, that makes sense.

[billv]

FlowStone's inner workings

Ahh..the Land of Shadow...where malcolm lives...as a International man of Mystery...

[nix]

all we need to do is poll the samplerate at more than samplerate,
then maybe?

[tulamide]

all we need to do is poll the samplerate at more than samplerate,
then maybe?

And that's exactly, why you need (direct or indirect) access to the buffer. It is the only way to poll faster than sample rate in DSP.

[trogluddite]

Hi again, everyone. This is just a quick post to say: (a) I haven't run away again; (b) Some interesting replies so far; and (c) Sorry about being slow to respond, but I have few urgent IRL things to attend to, and will post more when I reach calmer waters.

[nix]

if that sounds like the way to do it fellas,
in a crude way the analyzer prim could approach that possibly

-we could also request it of Ruby, like it could be commanded,
the cpu is still not negotiable though even in my 20 core 4.5ghz afaik