Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

proper resync plus offset?

For general discussion related FlowStone

Re: proper resync plus offset?

Postby tester » Wed Apr 27, 2022 12:51 pm

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.
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
tester
 
Posts: 1786
Joined: Wed Jan 18, 2012 10:52 pm
Location: Poland, internet

Re: proper resync plus offset?

Postby tester » Wed Apr 27, 2022 6:15 pm

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?
Attachments
Ramp resync+offsetv2b.fsm
(32.7 KiB) Downloaded 314 times
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
tester
 
Posts: 1786
Joined: Wed Jan 18, 2012 10:52 pm
Location: Poland, internet

Re: proper resync plus offset?

Postby trogluddite » Wed Apr 27, 2022 8:07 pm

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

Yes - they can and do!
Tepeix wrote: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!
Tepeix wrote:I suppose it's machine dependent.

Yes - also (hint!) ASIO/DS buffer size dependent.
tester wrote:Anyone any idea why this is happening?

Yes. ;) :ugeek:

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.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: proper resync plus offset?

Postby Tepeix » Wed Apr 27, 2022 9:59 pm

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.
Attachments
Ramp resync+offsetv2c.fsm
(89.37 KiB) Downloaded 332 times
Tepeix
 
Posts: 350
Joined: Sat Oct 16, 2021 3:11 pm

Re: proper resync plus offset?

Postby trogluddite » Thu Apr 28, 2022 4:03 am

Tepeix wrote: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.

Tepeix wrote:But who know.

Grizzled old-timers like me, mostly! :lol: 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.

Tepeix wrote:the modified version will always be true for 1 sample.

You discovered the perfect solution in any case! :D

** 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!
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: proper resync plus offset?

Postby trogluddite » Thu Apr 28, 2022 3:40 pm

[Mod Note] Off-topic ("Hi Trog") posts moved here.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: proper resync plus offset?

Postby Spogg » Fri Apr 29, 2022 10:09 am

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…
Attachments
tick to blue spogg's .fsm
3.06
(25.64 KiB) Downloaded 336 times
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: proper resync plus offset?

Postby trogluddite » Fri Apr 29, 2022 3:17 pm

Spogg wrote: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!
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: proper resync plus offset?

Postby tulamide » Fri Apr 29, 2022 3:39 pm

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.
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: proper resync plus offset?

Postby trogluddite » Fri Apr 29, 2022 4:11 pm

tulamide wrote: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!
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

PreviousNext

Return to General

Who is online

Users browsing this forum: Google [Bot] and 32 guests