A new approach to trigger limiting

[tulamide]

While working on r2 of the True Vector Pad (yes, an update is coming soon!), I needed a trigger limiter for the preset parameters that are sent from the preset manager to the module. The limiter prim is bound to the redraw rate, so I thought a Ruby solution could work even when there are no redraw triggers.

I kind of was successful. Indeed my solution limits incoming triggers, but it is very inaccurate the higher the limit rate is set. For example, at 10 triggers per second the real output rate is around 9.6 tps which is ok. But at 30 tps the real output rate is around 23 tps, etc.

I've made a test schematic for all you Rubyists that you can play with and hopefully optimize!

[martinvicanek]

Here is an alternative. It has a queue with configurable length in case you don't want to lose triggers which come too fast. Set qSize = 0 if you don't care. qSize >= 1 will output the desired rate, qSize = 0 will result in less than that because no buffering takes place.

[tulamide]

Nice! A queue of course! Went into my toolbox. Thanks!

[Tronic]

I like to use this code for trigger limit, and also I can execute an block of code with it.

sorry only text editor avaible....
I think it work....

Code: Select all

def init
   @block_test = 0
end

def event i, v , t
   trigLimit(100) {
      watch "block_executed", @block_test+=1
      output 0, nil
   }
end

def trigLimit(d,&block)
   @i ||=0
   if @i<d
      @i+=1
   else
      yield if block_given?      
      @i=0
   end
end

Edit: make the example more clear, for block.