posted 18 January 2002 04:39            

I have spent the last two hours trying to come up with a sound that once triggered continues for some specified duration.

I thought that at one time an expression like (!Keydown :ramp 10 s) would give the full 10 s on a keydown event. But instead, I find that all of these "triggerable" items actually treat the left argument as more of a gate. That is, the ramp only lasts as long as the !Keydown event, or 10 s whichever is shorter.

This same behavior is exhibited by nearly everything else labeled "trigger". That holds for FunctionGenerators, Envelopes (which is actually reasonable), ramp:, gateWhen:, fullRamp:, etc.

I tried making a MemoryWriter feed back the ramp to a FunctionGenerator mixed with the trigger input, and using this mix to "trigger" (read "gate") a FunctionGenerator that generates a ramp of some duration. But this latches up and never resets.

I don't want to use a sample-hold because it would have a timebase quantization that is differently gridded compared to the timing of external asynchronous events.

So how do I make an actual triggered item that persists for its duration regardless of how short the trigger is?

Cheers,

posted 18 January 2002 05:01            

But my technique is to feed the trigger source into a 1 sample delay with feedback setting of (1 - FunctionGenerator). The output of this "integrator" gates a constant that runs (integrator ramp: !Duration s) and the output of this Constant block is used as the "gate" for the downstream sound blocks. The output of this Constant block is also fed to a MemoryWriter with a 1 sample cyclic recording which is picked up by that FunctionGenerator used in the integrator's Feedback expression. So now, when the ramp reaches its final value of +1, the feedback is cancelled and the delay line integrator resets itself, until there is another trigger available. This works, but there must be a better way....

posted 18 January 2002 06:04            

I finally stumbled onto the expression:

(1 - (triggerSource fullRamp: !Duration s))

- DM

[ (1 + (triggerSource fullRamp: !Duration s)) works too!
-- ahh, no it doesn't! ]

[This message has been edited by David McClain (edited 18 January 2002).]

posted 18 January 2002 06:48            

This does mean that the time doesn't start until the trigger returns to zero. If that is a problem ,then you could use the ADSR envelope module with the attack set to 0 s and the sustain set to zero, and both decay and release set to the same monostable time.

posted 18 January 2002 07:06            

What if you turned your formular upside down i.e. 1 - instead of 1 + and then dobbled the duration and then did a clip01.

I don't have a system in front of me so I can't try it out.

posted 18 January 2002 12:12            

Thanks for the suggestions, but I believe the AR and ADSR don't go in the release phase (R) until the gate disappears. What I need is a gate stretcher that ensures that the "trigger" lasts for a specified duration.

I'll double check this though... You might just be correct about this.

- DM

[ Oh!, The envelopes all retrigger if a gate arrives during the timeout interval too. That's what I was trying to avoid. The whole point of this is to "trigger" and event that lasts for a specified duration - regardless of incoming trigger activity. ]

posted 18 January 2002 12:23            

This is of course only if the sustain level is allways set to zero

posted 18 January 2002 12:40            

quote:

---

Originally posted by David McClain:
Hi,

But instead, I find that all of these "triggerable" items actually treat the left argument as more of a gate.

This same behavior is exhibited by nearly everything else labeled "trigger". That holds for FunctionGenerators, Envelopes (which is actually reasonable), ramp:, gateWhen:, fullRamp:, etc.

- DM

---

posted 18 January 2002 12:53            

!trigger-( [ADSR1]l * 10000000)

This is to avoid using a feedback system.

What was the results of your ramp formular ?
In what way did it not work ?

posted 18 January 2002 13:43            

lckramp.aif

The (1 - ramp: etc) (and its many variations) works well in expressions, though it can get pretty wicked-looking. I like to comment such obtuse expressions with "comment" strings (using the double-quote character).

The FunctionGenerator works well for me when I need sample rate accuracy. However, be careful with its trigger expression. Since it is hot parameter rather than a sample rate input, the trigger may experience down-sampling. Consequently, it may not trigger immediately (aka on the next sample tick) if you're triggering it with the output of another Sound.

Remember that both the ramp and FunctionGenerator have resting values of 1.0. Sometimes I find that inconvenient for producing fixed delays. As a handy "trick", I'll use my own ramp wavetable so that FunctionGenerator has a resting value of zero. It is especially handy in expressions like ([FunctionGenerator]: L) gt: 0.9). Thus, when triggered, you get a delay before the signal blips to 1.0 and back to 0.

posted 18 January 2002 15:58            

I have a whole bunch of goodies to try out now... What I found about the ramp expression was that the ramp is always retriggerable by the input trigger expression. What I wanted was a user specified 1-shot that would run its full period - no retriggering until that period expires. So the gate needs to lock out the trigger while it is active.

The ramp expression is retriggerable during its timeout period and so additional trigger inputs during that period cause the gate to be extended indefinitely.

I need to give Pete's idea a try here, and I just downloaded your wavetable. I'll have a look at what that does. But you are correct that the resting state of the ramp is +1. That wasn't immediately apparent on reading the technical documentation -- but in retrospect the technical documentation doesn't say anything inaccurately.

Spoken language is so fraught with ambiguity, isn't it. What the listener hears depends on his/her world experience and it frequently doesn't match your own. So you never know what you communicated to the other person...

Kind of like the question "what does it sound like?" I really want to find a way to quantify that question for myself so that I can tell when I am hearing what I should. But I'm afraid there really is no way to do that right now...

Thanks guys!

- DM

[ BTW what is this for? I am trying to trigger a percussive sound at some division of BPM, say 1/8th notes, based on the threshold crossings of changes in 1/F noise. Large changes occur less often than small changes. I want to enforce a BPM division separation in these triggered events so they don't get smeared together during a burst of threshold crossings. ]

[[ hmmm... and yes I just saw the folly in my approach... If I want a BPM division separation then I should use a BPM driven sample-hold, shouln't I. Otherwise, the separations would be just fine, but the starting times of these events would be all over the place... hmph! ]]