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 tulamide » Sat Apr 30, 2022 9:55 pm

trogluddite wrote:
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!

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.
"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 » Mon May 02, 2022 1:01 am

tulamide wrote: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!

tulamide wrote: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.
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 » Mon May 02, 2022 7:11 pm

trogluddite wrote:
tulamide wrote: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!

tulamide wrote: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.
"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 » Mon May 02, 2022 10:23 pm

tulamide wrote: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! :oops:

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! :lol:
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

Previous

Return to General

Who is online

Users browsing this forum: Majestic-12 [Bot] and 55 guests