posted 29 June 2006 03:26            

---

Support.kym

Hi,

imagine you have a new kind of acoustical 'pulse-instrument', that generates various decaying pulses at various speeds, and you want to enrich that electronically with a (multiple) delay.
To really perfectionize this and adapt the delay to every single pulse of the instrument, I'd have to track the pulse frequency first and use that as my basic delay-time; which you then in a next step can
sub- or supradivide.
You'll find attached a simple basic example utilizing amp tracking, threshold and then the 'DurationBetweenTriggers' operation to accomplish this. As you can imagine the resulting tracked pulse
varies slightly in time too.
for this application (delay) this is problematic. Here I only need
one value because i don't want to hear pitch mod. (SmoothDelayChanges checked) or zipper noise, clicks etc. (SmoothDelayChanges unchecked). How can I just use the first value of the DurationBetweenTriggers
operation? Or, maybe even better, an average of the first few durations?
Best, flo

IP: Logged

posted 29 June 2006 04:32            

---

Apropos adaptive delay: imagine you intentionally do want these kind of abrupt changes in your delay, in your delay-time.
I tested this with samples, and it can have a quite beautiful random release or random rhythm character, with higher feedback values; and this without clicking. But with live sources, using condenser microphones, it seems to be impossible to do this without clicks. Is this because of the much higher dynamical resolution, of a condenser mic signal, compared to a dynamical reduced encoded wav file for example?

Are there ways to prevent or to reduce these kind of things in a live-situation, maybe just attenuation, compression, also gating (to remove performance noises, which are amplified of course when you use a delay with a high feedback value) already does a good job? Other hints, tips?

IP: Logged

posted 29 June 2006 08:40            

---

"How can I just use the first value of the DurationBetweenTriggers operation? "

You could sampleAndHold the value of durationBetweenTriggers when it reaches the value you want to keep (or perhaps use one of the pulse triggers to trigger the sampleAndHold), for example

!Trig sampleAndHold: [aSound] L durationBetweenTriggers

IP: Logged

posted 29 June 2006 23:42            

---

But it is not clear to me how I can use exactly the first
incoming pulse for this (as a trigger)? Moreover they are
almost never the same, vary every time in amp and freq.
I tried things with a trigger mask - masking, not letting through
triggers anymore after a certain duration. But in essence the problem
remains the same: how can I make this more flexible, depending on the
live-input?

IP: Logged

posted 30 June 2006 08:26            

---

Have you tried using CrossFilter? You could capture a "frame" of incoming pulses as the Response while also feeding the live pulses (delayed by a small, constant offset) into the Input. The "frame" length could be a constant size and you could recapture periodically using
<framelength> s tick

The spaceing between the pulses would result in different delay times.

IP: Logged

posted 30 June 2006 10:04            

---

You could try:

([aSound] L countTriggers - 1) sampleAndHold: [aSound] L durationBetweenTriggers

IP: Logged

posted 30 June 2006 11:42            

---

Is it right to count the triggers when a sound is "pasted", ie running at control-rate? I mean, isn't there a chance to "miss" some triggers in the end? Because here [aSound] doesn't seem compatible as it is running at sample rate. I think I've come across this kind of problem before.

I am curious to know if I am wrong or right, because working on a design at sample is much more difficult than working at control rate with nifty Capytalk expressions ...

[Cam] L

IP: Logged

posted 30 June 2006 14:27            

---

If durationBetweenTriggers was working then this should work too. The width of a trigger would have to be slightly larger than 1 ms (same for the "off" time in between triggers)

IP: Logged

posted 01 July 2006 11:40            

---

one little thing regarding the cross-filter approach:
why is it necessary to delay the live pulses by a small constant
offset, and what is the recommended delay-time?

IP: Logged

posted 01 July 2006 21:03            

---

Try experimenting with that....I'm not sure whether the delay is needed. It was just a brainstorm(!)

IP: Logged

All times are CT (US)