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

DSPplug tick100

Post any examples or modules that you want to share here

Re: DSPplug tick100

Postby tulamide » Mon Jun 08, 2020 2:48 pm

OMG, I just realized, this forum now has its own little Trump!
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: DSPplug tick100

Postby deraudrl » Mon Jun 08, 2020 3:07 pm

tulamide wrote:OMG, I just realized, this forum now has its own little Trump!
The phrase "Godwin's Law, 2020 Edition" just jumped into my head for no apparent reason. 8-)
I keep a pair of oven mitts next to my computer so I don't get a concussion from slapping my forehead while I'm reading the responses to my questions.
deraudrl
 
Posts: 236
Joined: Thu Nov 28, 2019 9:12 pm
Location: SoCal

Re: DSPplug tick100

Postby tulamide » Mon Jun 08, 2020 4:21 pm

deraudrl wrote:
tulamide wrote:OMG, I just realized, this forum now has its own little Trump!
The phrase "Godwin's Law, 2020 Edition" just jumped into my head for no apparent reason. 8-)

...other than trying to outsmart me. And you succeeded. But the fact remains :P
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: DSPplug tick100

Postby k brown » Mon Jun 08, 2020 4:39 pm

Why do you think the toolbox Parametric EQ jerks around as shown in his video - it doesn't do that on my computer, and it's a 20-year old ThinkPad? - perfectly smooth. I fact nothing in FS works like that on my cobweb machine! :shock: :?:

In fact I've used it in several schematics - looks as it should, works as it should, sounds as it should.
Website for the plugins : http://kbrownsynthplugins.weebly.com/
k brown
 
Posts: 1198
Joined: Tue Aug 16, 2016 7:10 pm
Location: San Francisco, CA USA

Re: DSPplug tick100

Postby trogluddite » Mon Jun 08, 2020 5:36 pm

wlangfor@uoguelph.ca wrote:Look inside this new schematic and you'll see...


98.1 Hz after allowing a little settling time and with FS the only open application. I can force it lower very easily by stressing the CPU with another application. I can force it slightly higher by removing the bizarre triple-parallel trigger arrangement from the S&H (which otherwise has no effect, as it's connected to an input which doesn't pass triggers).

My analysis: Primitives have been added/removed by trial and error to tweak the CPU load such that 100Hz gets hit within the margin of error of the readouts - but only reliably on the developer's own computer system. The tick rate is both system and CPU load dependent, as would be expected, since the time-base is still a Windows timer. Behaviour would be more stable if audio were running (as it would make the Ruby ticker sample-rate locked), in which case the triple-parallel trigger section would be a completely redundant use of CPU power. Does nothing to overcome issues due to Ruby, "green" and "blue" operating asynchronously (e.g. high "clock jitter" if triggers are driving DSP audio components).

My verdict: "imperfect".
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: DSPplug tick100

Postby wlangfor@uoguelph.ca » Mon Jun 08, 2020 6:14 pm

trogluddite wrote:
wlangfor@uoguelph.ca wrote:Look inside this new schematic and you'll see...


98.1 Hz after allowing a little settling time and with FS the only open application. I can force it lower very easily by stressing the CPU with another application. I can force it slightly higher by removing the bizarre triple-parallel trigger arrangement from the S&H (which otherwise has no effect, as it's connected to an input which doesn't pass triggers).

My analysis: Primitives have been added/removed by trial and error to tweak the CPU load such that 100Hz gets hit within the margin of error of the readouts - but only reliably on the developer's own computer system. The tick rate is both system and CPU load dependent, as would be expected, since the time-base is still a Windows timer. Behaviour would be more stable if audio were running (as it would make the Ruby ticker sample-rate locked), in which case the triple-parallel trigger section would be a completely redundant use of CPU power. Does nothing to overcome issues due to Ruby, "green" and "blue" operating asynchronously (e.g. high "clock jitter" if triggers are driving DSP audio components).

My verdict: "imperfect".


but it relies on ruby for the timing?

Maybe you're meaning the old version. because the main goal was to take the load off of ruby and to stop it from being affected by the connectivity, especially during which time when ruby will go over 100hz slightly. It's during those spikes that when connected to a cpu draining resource, that ruby can cause a cpu drain of 2% or even more.

It was the whole point of it, to reduce the load on CPU by ruby but to still gain the precision of timing that ruby provides.
My youtube channel: DSPplug
My Websites: www.dspplug.com KVRaudio flowstone products
User avatar
wlangfor@uoguelph.ca
 
Posts: 912
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

Re: DSPplug tick100

Postby wlangfor@uoguelph.ca » Mon Jun 08, 2020 6:32 pm

tulamide wrote:
deraudrl wrote:
tulamide wrote:OMG, I just realized, this forum now has its own little Trump!
The phrase "Godwin's Law, 2020 Edition" just jumped into my head for no apparent reason. 8-)

...other than trying to outsmart me. And you succeeded. But the fact remains :P


Ah, but that's the game we love, in the end old friend, lol. You'll outsmart Me soon, I'm sure.
My youtube channel: DSPplug
My Websites: www.dspplug.com KVRaudio flowstone products
User avatar
wlangfor@uoguelph.ca
 
Posts: 912
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

Re: DSPplug tick100

Postby trogluddite » Mon Jun 08, 2020 7:05 pm

wlangfor@uoguelph.ca wrote:but it relies on ruby for the timing?

Yes, of course it does. You're using a sample-and-hold. Only the bottom input of a sample-and-hold passes triggers to the output, and that's the input where you have a Ruby custom ticker connected. The triggers to the upper connector do nothing except occupy a little CPU time.

The float input of a sample-and-hold doesn't even react to incoming triggers. When the lower input is triggered, the schematic will do a right-to-left "reverse trigger" from the upper connector to obtain the float value for passing through (this is the non-intuitive, and far less obvious, element of how triggers work - but yes, they go "backwards" sometimes).

wlangfor@uoguelph.ca wrote wrote:It was the whole point of it, to reduce the load on CPU by ruby

That wasn't your original claim - you previously said...
wlangfor@uoguelph.ca wrote wrote:you'll see that it gets exactly to 100 each second

If you change the definition of "perfection" every time you get caught out, then you're not playing fair! :lol:

Here's a riddle for you. For the sake of argument, take it as given that my "different" readings are accurately reported. Were my readings different to yours because your timer went at a different rate, or because the "average frequency" measurer had more error? How could you tell which it was? How accurate is the measurer, anyway? (PS: I haven't any definite answers myself for this - but they do matter if you are claiming "perfection").
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: DSPplug tick100

Postby lalalandsynth » Mon Jun 08, 2020 8:35 pm

...
User avatar
lalalandsynth
 
Posts: 600
Joined: Sat Oct 01, 2016 12:48 pm

Re: DSPplug tick100

Postby wlangfor@uoguelph.ca » Mon Jun 08, 2020 9:28 pm

trogluddite wrote:
wlangfor@uoguelph.ca wrote:but it relies on ruby for the timing?

Yes, of course it does. You're using a sample-and-hold. Only the bottom input of a sample-and-hold passes triggers to the output, and that's the input where you have a Ruby custom ticker connected. The triggers to the upper connector do nothing except occupy a little CPU time.

The float input of a sample-and-hold doesn't even react to incoming triggers. When the lower input is triggered, the schematic will do a right-to-left "reverse trigger" from the upper connector to obtain the float value for passing through (this is the non-intuitive, and far less obvious, element of how triggers work - but yes, they go "backwards" sometimes).

wlangfor@uoguelph.ca wrote wrote:It was the whole point of it, to reduce the load on CPU by ruby

That wasn't your original claim - you previously said...
wlangfor@uoguelph.ca wrote wrote:you'll see that it gets exactly to 100 each second

If you change the definition of "perfection" every time you get caught out, then you're not playing fair! :lol:

Here's a riddle for you. For the sake of argument, take it as given that my "different" readings are accurately reported. Were my readings different to yours because your timer went at a different rate, or because the "average frequency" measurer had more error? How could you tell which it was? How accurate is the measurer, anyway? (PS: I haven't any definite answers myself for this - but they do matter if you are claiming "perfection").


prove it with My schematic and OBS, lol.
My youtube channel: DSPplug
My Websites: www.dspplug.com KVRaudio flowstone products
User avatar
wlangfor@uoguelph.ca
 
Posts: 912
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

PreviousNext

Return to User Examples

Who is online

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