proper resync plus offset?

[tester]

Spogg, if you wish, I can include you in the beta testing program for the project I am working on.

I'm slowly approaching the moment, when I will know whether there is anything to betatest (building an interface can be a consuming process...), but then I may need some help in trying to "break" the app I do.

Apart from that - the ramp above, may be useful, when someone attempts to do a DAW-like wave view routine. In old days, when I didn't knew yet, the reset comes from resetting audio buffer, but this type of resync should be better. Puff... Yet another old project to revisit.

[tester]

At the moment this is something like this.

Quick question - how to move this 1sample delay to the code, so that resync node can be converted to uniform streamboolin?

[trogluddite]

blue components [...] shouldn't miss any green value

Yes - they can and do!

Normally 1 ms is supposed to stay 44 sample.

Yes - this is a strict requirement for the (hint!) A-to-D and D-to-A convertors of the soundcard!

I suppose it's machine dependent.

Yes - also (hint!) ASIO/DS buffer size dependent.

Anyone any idea why this is happening?

Yes.

P.S.: Unlike 'green', streambool does not represent true with integer 1 nor float 1.0, nor any other number - it should be an all-bits-set bitmask (like the result of an ASM/DSP comparison operation). Some components will read other non-zero streambool values as true; but this is by chance rather than by design, so be wary of relying upon it.

[Tepeix]

Yep, for streambool you have to make a condition and output it like boolout = (X==1);

Here's a way to do.
I also make a copy of the button. The original use 10ms of green.
I suppose 10ms must never miss a sample. But who know.
But this way the time of the reset could vary making a little different sound.

the modified version will always be true for 1 sample.
But there's a optional timer that would always reset the same given amount of time.

[trogluddite]

I suppose 10ms must never miss a sample.

The approximate rule is this: Green value changes (not triggers, strictly speaking) at blue/white inputs can be missed whenever the time interval between changes is smaller than the audio latency time (DS/ASIO buffer size). Below this time, shorter intervals make misses more likely, though exactly what (if anything) gets missed is subject to 'green' timing randomness. As you found, "splitting" and "merging" a trigger, so that it hits the same component more than once, is the worst - in effect, that's no delay at all, so can cause misses on any system.

Explanation: Audio drivers and VST hosts always request whole buffers full of samples, and it's essential that these are delivered as quickly as possible to avoid nasty audio snap, crackle, pop! So audio is deemed "high priority" and 'green' is deemed "low priority". But this raises a problem - how can a "low priority" triggered green event (or worse, an unpredictably branching cascade of triggers) affect a specific sample within a "high priority" buffer-filling routine? Either the "low priority" work must interrupt and slow down the "high priority" work (snap, crackle, pop!), or the sharing of data between them must be limited somehow (sacrifice timing precision).

So, the FS "one sample at a time" ethos is only really a facade for coding convenience. When the soundcard/host wants a new buffer full of samples; green processing is stopped; a new buffer is filled with audio samples and delivered; and then 'green' processing resumes. This has two main consequences**...

1) All of the audio samples in the same soundcard buffer will "see" the same 'green' input values.
2) 'Green' values can change multiple times in-between buffer requests, so that the audio streams miss them.

Note that this is certainly a huge simplification: for example; sample-accurate MIDI events (e.g. poly notes) are treated differently (also some Ruby stuff, maybe?). No doubt only MyCo and Malc know all of the finer details.

But who know.

Grizzled old-timers like me, mostly! In ye olden days of SynthMaker, soundcard latencies were often HUGE compared to nowadays, so; (a) misses were a much bigger problem back then, and (b) it was much easier to diagnose.

the modified version will always be true for 1 sample.

You discovered the perfect solution in any case!

** There are actually three main consequences: The third is that many sensible persons (and some insensible ones like me) might now finally be freed from the perennial quest for the much-sought and long-fabled Sample-Accurate Kilohertz Green Super-Trigger. I have so much more time for my unicorn hunting now!

[trogluddite]

[Mod Note] Off-topic ("Hi Trog") posts moved here.

[Spogg]

I think I’ve reduced the triggers in the module that flips between 1 and 0 when triggered, with my Simple flipper.

Maybe trog will mark my homework…

[trogluddite]

Maybe trog will mark my homework…

That's an A! So long as the actual value at the output doesn't matter, only the fact that it changes, that's as minimal as a toggle will ever be, AFAIK.

Another common solution in this "changes only" case is just to use a simple Counter primitive without any reset logic - which might be infinitesimally more efficient because it's just a single primitive. However, that can potentially fail if the count gets high enough (due to loss of precision when converting integer to float) - though if starting from zero at load-time, I'd be a trifle concerned about any user who could provoke that problem just with their button pressing!

[tulamide]

I still don't see exactly why there's so much ado about it? Isn't blue always in sync? So, when a resync request is triggered, you just count to the next cycle (of whatever kind) and voila - resynced. But I probably miss something important.

[trogluddite]

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!