Kyma Forum
  Kyma Support
  reset countTriggers

Post New Topic  Post A Reply
profile | register | preferences | faq | search

next newest topic | next oldest topic
Author Topic:   reset countTriggers
Phi Curtis
Member
posted 01 June 2008 15:00         Edit/Delete Message   Reply w/Quote
How would you reset a countTriggers expression?

The expression "(!Start bpm: !BPM) countTriggers" resumes the count every time the !Start is toggled on from where it last left off.

I would like to do this:
(!Start bpm: !BPM) countTriggers reset: !Start

Where toggling the reset to 1 would restart the count to 0 on the next trigger.

Currently, I have this arcane expression (whether I found it somewhere, or made it myself at some earlier point, I'm not sure...):

!Start of: #(
0
{((!Start bpm: !BPM) countTriggers - (!Start sampleAndHold: ((!Start bpm: !BPM) countTriggers + 1)) mod: 13)}
)

It kind of works, but not perfectly. Are there any better ways to do it?

thanks,
Phil

IP: Logged

pete
Member
posted 02 June 2008 15:57         Edit/Delete Message   Reply w/Quote
Hi Phi

I had a similar requirement the other day, but I needed mod type trigger.
The mod type with a very large mod is almost the same as the non mod type.

Any way I didn't think it would work but I made the mod go down to one and triggered it, so as to act as a reset. It worked to my surprise. When the mod went back back to a large number the counter carried on rising, starting from one again.


IP: Logged

Phi Curtis
Member
posted 02 June 2008 18:16         Edit/Delete Message   Reply w/Quote
Hi Pete,

Thanks for the tip.

My interpretation of what you are saying is this:

((!Start bpm: !BPM) + (1 - !Start)) countTriggersMod: ((1 - !Start) * -999999) + 1000000

This way the !Start toggle acts as the reset. Unfortunately, it seems to work only most of the time. I then thought that maybe I needed to insure that the (1 - !Start) expression on the left side of the countTriggersMod expression was arriving after the mod had been reset to 1, so I tried the following:

((!Start bpm: !BPM) + ((1 - !Start) ramp: 0.2 s)) countTriggersMod: ((1 - !Start) * -999999) + 1000000

I'm not sure why, but that didn't seem to help.

Finally, this worked every time:

((1 bpm: !BPM) + (1 - !Start)) countTriggersMod: ((1 - !Start) * -999999) + 1000000

But I wonder if it doesn't leave the capy doing unneccesary work, since it never turns off the bpm: expression (just curious, and also about why the others don't always work...).

cheers!
Phil

IP: Logged

pete
Member
posted 04 June 2008 17:50         Edit/Delete Message   Reply w/Quote
Hi Phil

I am without my Kyma at the mo, (it's out on hire) so I am guessing a bit at what I did and what will or won't work.

It may be that the reset worked if the mod value was set to zero instead of one but you'll have to test this out.

Adding (1-!Start) before the countTriggersMod would mean that you would reset only when you remove your finger from start (assuming start is a button). Maybe this is what you want. In my case the in coming triggeres were very sparse so the chances of a reset and a trigger happening at the same time would be unlikely. I did it like this.

[TRIGGER]L + !Reset countTriggersMod: 1+((1-!Reset)*100000)

In your case you want !Reset to double up as a turn on counting. I think?

As cappy talk is calculated on one millisecond the chances that a BPM pulse has happened
the tick just before you press reset is high. (If BPM amounted to 500hz the chances would be 50/50)

As you've worked out if a BPM pulse happens the tick before the reset it will amount to high value followed by high value and the reset will be missed.

The ramp Idea to hold off the reset until after the bpm: has stopped sending out ticks is spot on, but the problem is that the ramp is from zero to one, so there is no delay at the zero value point where the countTriggersMod: considers it as a change of state. If you instead offset the whole thing down by 0.5 then the ramp will cause a real delay in the reset.

So maybe this will work.

(((!Start bpm: !BPM) + ((1 - !Start) ramp: 0.01 s))-0.5) countTriggersMod: 1+(!Start*100000)

I don't know why your last example worked every time though. Is it because the value of !BPM was kept low? Maybe something odd happens to bpm: when it's turned off (leaves it at value one?)

I can't try any of this out, so forgive me if it ends up that I'm talking a load of rubbish.

Pete


IP: Logged

SSC
Administrator
posted 05 June 2008 15:49         Edit/Delete Message   Reply w/Quote
Phil, I think your sampleAndHold solution is the right idea. In essence, the idea is to subtract the current total from the count whenever !sw01 is switched on. For example:

(!Sw01 bpm: !BPM) countTriggers - (!Sw01 sampleAndHold: (!Sw01 bpm: !BPM) countTriggers)

Using a variable might make it look cleaner, for example:

code:

| curCount |
curCount := (!Sw01 bpm: !BPM) countTriggers.

curCount - (!Sw01 sampleAndHold: curCount)


[This message has been edited by SSC (edited 05 June 2008).]

IP: Logged

Phi Curtis
Member
posted 06 June 2008 15:15         Edit/Delete Message   Reply w/Quote
Thanks! That code seems to work the best, and has the added benefit of being pretty easy to understand.

For the record, here is my version which works like a countTriggersMod:

code:

| curCount |
curCount := (!Start bpm: !BPM) countTriggers.

(curCount - ((!Start sampleAndHold: curCount) + 1)) \\ !Mod + 1



IP: Logged

All times are CT (US)

next newest topic | next oldest topic

Administrative Options: Close Topic | Archive/Move | Delete Topic
Post New Topic  Post A Reply

Contact Us | Symbolic Sound Home

This forum is provided solely for the support and edification of the customers of Symbolic Sound Corporation.


Ultimate Bulletin Board 5.45c