DSP Robotics Support

Nubeat7 wrote:furthermore i would assume to use a 25 tick or 100 tick with dividing for different rates for the global redraw ticker, like you know it from some examples in the SM forum, simply because the 25 tick and the 100 tick have much better performance then the ruby ticker!

Absolutely. It's just as I mentioned that you're so limited in options, and the tickers use the lousy windows timer, so I wanted to make something that gave you more control. The fact that it's stuck in slow Ruby is unfortunate, especially for something that's intended to be for optimization, but it is a solution nonetheless.

I get the feeling that Malc could very easily create a fast ticker prim that is much better than the ones we have now though...

Nubeat7 wrote:on my very slow testnotebook the ruby ticker shows 4% cpu with 50 ticks /sec and 0.4% when stopped while the 25 or the 100 ticker doesn't affect the cpu at all!

One of the things that annoys me about working with Flowstone in FL is that they don't give you the CPU meter. You have FL's internal meter but that's for the whole project and isn't very precise. So I appreciate it when people test and report on things like this, as you have. Thanks.

I had a look at your updated example Nubeat, and while it seems to work there is a problem with that solution. You're sending a ton of triggers into the first input, which is triggering the "when 0" event over and over, and switching it on and off. It ends up being rather inaccurate in the total number of triggers it ends up passing through, presumably because it's messing up the function of the timer. That was why I didn't go that particular route in my design, and just wrote a timeout into the ruby code instead.

Perfect Human Interface wrote: You're sending a ton of triggers into the first input, which is triggering the "when 0" event over and over, and switching it on and off

true, but its not a big difference to your solution...which is also the 'original' change trigger rate...

as i mentioned in my post above a design like this is optimal used with a global clock ticker.

when you feed the value into the ruby code anyway you can do it much easier and output the value directly instead of outputting a trigger to some sample and holds...