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
Re: DSPplug tick100
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
The phrase "Godwin's Law, 2020 Edition" just jumped into my head for no apparent reason.tulamide wrote:OMG, I just realized, this forum now has its own little Trump!
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
deraudrl wrote:The phrase "Godwin's Law, 2020 Edition" just jumped into my head for no apparent reason.tulamide wrote:OMG, I just realized, this forum now has its own little Trump!
...other than trying to outsmart me. And you succeeded. But the fact remains
"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
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!
In fact I've used it in several schematics - looks as it should, works as it should, sounds as it should.
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
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!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1727
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
Re: DSPplug tick100
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.
-
wlangfor@uoguelph.ca - Posts: 912
- Joined: Tue Apr 03, 2018 5:50 pm
- Location: North Bay, Ontario, Canada
Re: DSPplug tick100
tulamide wrote:deraudrl wrote:The phrase "Godwin's Law, 2020 Edition" just jumped into my head for no apparent reason.tulamide wrote:OMG, I just realized, this forum now has its own little Trump!
...other than trying to outsmart me. And you succeeded. But the fact remains
Ah, but that's the game we love, in the end old friend, lol. You'll outsmart Me soon, I'm sure.
-
wlangfor@uoguelph.ca - Posts: 912
- Joined: Tue Apr 03, 2018 5:50 pm
- Location: North Bay, Ontario, Canada
Re: DSPplug tick100
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!
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!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1727
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
Re: DSPplug tick100
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!
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.
-
wlangfor@uoguelph.ca - Posts: 912
- Joined: Tue Apr 03, 2018 5:50 pm
- Location: North Bay, Ontario, Canada
Who is online
Users browsing this forum: Google [Bot] and 33 guests