brendan mccloskey

I have a Control Structure question. I would like to vary the delay time of [tapout~] (randomly, within bounds), but the new value should only be passed to the delay line between repeats. This seems trivial, so I tried this (below):

And I'm not entirely convinced this is the solution. I'll be moving it over to gen~ once I'm happy with the prototype. Any suggestions on how to fix/improve the above example?

Hi Maxers
I have a Control Structure question. I would like to vary the delay time of [tapout~] (randomly, within bounds), but the new value should only be passed to the delay line between repeats. This seems trivial, so I tried this (below):

change-delay-time-only-between-repeats

Do I need to offset the sah~ trigger by half its period?

vb.phasor0~ — a phasor that changes its frequency only at the beginning of a new ramp

Yep. I inserted another [sah~ 0] at the Hz inlet to the phasor (driven by itself via feedback), and seems to work as expected, thanks.

I'll be putting this into a gen~ patch asap - it's for an auto-melody generator, based on [ffb~] and random delay times. Might add some user-variable syncing and diatonicism.

The problem persists, and the behaviour is as follows: when the delay time jumps (over a large range) 'instantaneously', there will be a distorted click. I am not mystified by this of course, it is the result of a very sudden pitch change in the delay line. If we change the delay time smoothly then a glissando occurs, what I am trying to do is 'hide' the glissando. I made my own version of vb.phasor0, which changes frequency only upon negative delta, and when delay times are longer than c.100ms and the range of change is small (try *~ 100 and +~ 300, above) clicks are not heard, but when the range is large, jumping from small to large values and vv, then the clicks obviously appear. My question is: how do I mask or even possibly avoid these clicks? I suspect the gen~ domain might hold the key, but if I can't even attempt it in MSP then I've no hope.

I am building a random melody/rhythm generator, and yes I could use coll + noteout but I'd like to do this in the signal/sample domain. Some clues would be nice.

Doing it in signal domain with delay does bring a problem with it,

one can try to optimise the control when the delay time changes, but the big unknown is the audio

allready held in feedback path and delay memory.

It will probably allways sound the way it sounds, when delay time changes by a large ammount.

There were examples for delays using 2 tapouts and crossfading them,

to mask the change, would You try that path ?

Doing it in signal domain with delay does bring a problem with it,
one can try to optimise the control when the delay time changes, but the big unknown is the audio
allready held in feedback path and delay memory.
It will probably allways sound the way it sounds, when delay time changes by a large ammount.
There were examples for delays using 2 tapouts and crossfading them,
to mask the change, would You try that path ?
just an idea.


Once again mate, thanks for your input. I've actually decided to try a different route, by going back to my original intention (randomised rhythms). It didn't take me long to see that "the big unknown is the audio already held in feedback path and delay memory". I even tried an envelope follower on the output, and derived a delta trigger from there, but as you say, once the repeats build up - unpredictability ensues! It kind of works with very short noise bursts, but a sound with any decay portion produces clicks/gliss. By the way there's a great little example in the [tapout~] helpfile; send it the 'vibes.aif' audio file, and sweep the delay time. Lovely. Sunday morning church bells.

So I've opted for a single repeat multi-tap delay (for a single randomised rhythmic motif) then feeding that into a single-tap feedback delay (to repeat the motif). Please consider this thread closed, and apologies for the noise everyone. I'll post my random rhythm and melody maker when it's finished. As usual, it's for disabled musicians' music performance.

in theory it is simple, you hide unwanted audio moments by fade in fade out and you hide the fade by using windowing.

but in practice it is always a mess to find the perfect solution and if you have one, it will always be very specific for only this situation.

what could eventually be done is to use different tapping buffers for the different speeds in parallel - and then a "speed change" could be easily performend by routing the material into a certain delay line. in my opinion this makes more sense than trying to do it at the output side, not to speak of changing the delay time.

Yes, more than one delay line is the better solution. And I also agree that MY solution/compromise will be very Brendan-centric

change delay time *only* between repeats

change delay time only between repeats