DSPplug tick100

[trogluddite]

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

[wlangfor@uoguelph.ca]

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]

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.

[trogluddite]

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

It was the whole point of it, to reduce the load on CPU by ruby

That wasn't your original claim - you previously said...

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

[lalalandsynth]

...

[wlangfor@uoguelph.ca]

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

It was the whole point of it, to reduce the load on CPU by ruby

That wasn't your original claim - you previously said...

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.

[trogluddite]

If you mean about the "backwards" triggers etc. - the basics are on pg. 97 of the User Guide. The proof is easy enough - just stick a trigger blocker primitive between the trigger combiner and the sample-and-hold. That will block any of those triggers from reaching the sample-and-hold float input, making the trigger behaviour of the top input immaterial.

There is also a more comprehensive tutorial on triggers downloadable here (admittedly, this is chest-beating - I wrote it! )

[pshannon]

There is also a more comprehensive tutorial on triggers downloadable here (admittedly, this is chest-beating - I wrote it! )

I totally forgot about your tutorial, thanks for bringing this back to light. I just had to attach an image.

[ChrisHooker]

To further Trog's example:

The proof is easy enough - just stick a trigger blocker primitive between the trigger combiner and the sample-and-hold.

...You can in fact remove the connection altogether. The only thing running the counter is the ruby ticker. In effect, there is no additional funcionality at all. Actually, because of the upstream ticks and the extra primitives and connections, it runs a little slower than if you just connect a ruby ticker directly to the monitoring modules. Try it, the Hz readout will be a bit faster. ...It is on my computer (you may need to intentionally bog the system down a bit with a scope or readout to see a drastic difference). What's misleading you into thinking this Rube Goldberg contraption is better than a plain ruby ticker is in how you are monitoring it in this schematic.

Here is your signal flow:
Take an inaccurate Tick100, split and recombine so that each tick is now three ticks at the same time. (actually green seems to work in serial, like MIDI, so they are as close together as the system allows).
Now, only pass through those ticks at the "instant" a slightly less inaccurate ruby ticker says so.

Now to measure those ticks, take the same ruby timing reference (in the case of your schematic, just out of a different module) and only look at the time span of your desired goal. Since the time references are the same, the measurement comes out as expected.

What happens when you replace your "Perfect" solution with just the old ruby ticker? (See attached schematic) You get the exact same results. But according to your monitoring here, that would imply that the ruby ticker was perfect all along... when we know it is not.

[wlangfor@uoguelph.ca]

To further Trog's example:

The proof is easy enough - just stick a trigger blocker primitive between the trigger combiner and the sample-and-hold.

...You can in fact remove the connection altogether. The only thing running the counter is the ruby ticker. In effect, there is no additional funcionality at all. Actually, because of the upstream ticks and the extra primitives and connections, it runs a little slower than if you just connect a ruby ticker directly to the monitoring modules. Try it, the Hz readout will be a bit faster. ...It is on my computer (you may need to intentionally bog the system down a bit with a scope or readout to see a drastic difference). What's misleading you into thinking this Rube Goldberg contraption is better than a plain ruby ticker is in how you are monitoring it in this schematic.

Here is your signal flow:
Take an inaccurate Tick100, split and recombine so that each tick is now three ticks at the same time. (actually green seems to work in serial, like MIDI, so they are as close together as the system allows).
Now, only pass through those ticks at the "instant" a slightly less inaccurate ruby ticker says so.

Now to measure those ticks, take the same ruby timing reference (in the case of your schematic, just out of a different module) and only look at the time span of your desired goal. Since the time references are the same, the measurement comes out as expected.

What happens when you replace your "Perfect" solution with just the old ruby ticker? (See attached schematic) You get the exact same results. But according to your monitoring here, that would imply that the ruby ticker was perfect all along... when we know it is not.

Yes, perfect is undoubtedly an objective word and I feel that there is nothing perfect, but I really wanted to help and make something that uses less CPU ultimately.

Thanks for feedback everybody, but please don't take My lack of low self esteem and faith in My own skillset as rudeness. I try to solve something and I'm actually on a deadline for one of My best customers that I need to impress and fast. Redraw rate was one of the things holding Me back. A true 100hz is obviously better.

In regards to Trog's earlier post, I did not have the time to add that I was referring to My new testing method rather than AronB's. I agree that Aron B's is sound but maybe a little off. It had been the main argument of people throughout this post which was why I investigated and came up with a new method.

Glad to be over the hump.