Trigger Timer (debug)

[Perfect Human Interface]

Here's a little tool I made that spits out a set number of triggers at a set rate and then stops.

The second output blocks triggers but can be used to switch selectors if they receive other triggers (I was using this to test my Trigger Limiter and didn't want to add the trigger to the counter).

TriggerTimer.PNG (5.27 KiB) Viewed 23303 times

[billv]

Not sure if its important to you, but the Custom
Ticker still has not been fixed and does not
output the first trigger.
See it better by setting module to 1 trigger per second,
you'll be waiting a full second before 1st trigger happens.
Fix by adding. .
output 0, t....in the 'When 0' section...or something like that.
Handy module..thanks for sharing

[Nubeat7]

Not sure if its important to you, but the Custom
Ticker still has not been fixed and does not
output the first trigger.
See it better by setting module to 1 trigger per second,
you'll be waiting a full second before 1st trigger happens.
Fix by adding. .
output 0, t....in the 'When 0' section...or something like that.

Code: Select all

   when 0
      if !@ticking && @state
          @ticking = true
          output 0 
          input 100,nil,t+@step
      end

yes you just need to include a tick to the output when state changes to true, to get the first tick when set the ticker to 'on'

[billv]

Thanks nubeat7...that's a better way to phrase it.
And also, this is wrong..

Ticker still has not been fixed and does not
output the first trigger.

It does output the first trigger. According to it's design.
Apologies to DSPR for using the word "Fixed".
I've only just worked this out, but the default behaviour is right,
cause say, if you set interval to 1 sec, shouldn't you expect the first trigger
to arrive after 1 sec...

Note:
I have noted this tendency of mine of "bad phrasing"/"unclear advice" for a while now.
So I have been making a conscious effort not to get involved, and hope to eventually
dissappear behind my dodgy releases .

[Perfect Human Interface]

I've only just worked this out, but the default behaviour is right,
cause say, if you set interval to 1 sec, shouldn't you expect the first trigger
to arrive after 1 sec...

Hmm, I suppose this is right. Honestly I never even considered whether the timing of the first trigger was right or anything so it's not bad that you brought it up.

I see all my time on the DSP forums as a learning process and I'm sure my posts have exemplified that as much as anyone.

[Nubeat7]

this depends on the case what the ticker is used for,..

for example, if you use it to trigger notesequences it needs to trigger also the first note when the sequence is started (if a note is on position 0)... so if it is right or not depends on the usecase.

you can easily implement a properties condition that the first trigger (when setting state to on) is sent or not...

[Perfect Human Interface]

Minor update; just added a bit of spaghetti so the switch turns itself off when the maximum value is reached, for convenience.

[billv]

that spits out a set number of triggers at a set rate

This was a great little idea P.H.I.
Needed the technique recently, but was in ruby, and ended up with this
"no-frills" version of your module. No spaghetti..just the sauce!

Code: Select all

def event i,v,t
    @times = 16
    @step = 0.125
    @a=Array.new(@times){|x|x=x*@step}
    @times.times do |x|
    output 0,t,t + @a[x]
    end
end

Adding this line will output the current step at the same time...

Code: Select all

output 1,@a[x],t + @a[x]

Or, my favourite ATM,

Code: Select all

output 1,@count=@count.succ,time + @a[x]

This turns it into a "Loop" int type of module, like the Green prim.
Big difference being with this, is the timing of the iterations can be controlled.
This is something I've needed several times in the past...