DSP Robotics Support

OMG, I just realized, this forum now has its own little Trump!

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.

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.

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

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.

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".

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.

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.

...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 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").

...

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.