Multiple delay times from a single [delay]
Hi everyone
Sorry if this is something really simple, but I'm a bit lost with this. I have a list of cue times that are used to populate [delay] objects that come from markers within aiff files (using [sfmarkers~]. I'm having success with making individual [delay]s and then sending them the times before a loop starts but as each sound I'm using has a different number of markers this isn't really practical for what I'm trying to do. Ideally I'd like to have a single [delay] for each sound (and set of markers) that automatically updates to the next point in time to delay the original bang from. I've tried creating loops using [transport] and [timepoint] but have had little success. Ideally I'd like to have a [delay] that will accept a list of delay times and output a bang for each one- does anyone know if such a thing exists (tried maxobjects.com), or of an alternative solution?
Thanks
James
Things that store data with the point in time at which they are triggered are generally called sequencers .
You could take a look at the [seq~] object. I don't understand it myself, but it can do what you want. I see you're using [coll] in your patch too, you can use that with [cpuclock] to build your own simple sequencer as well. Pretty sure there are examples of that lying around somewhere...
Bas van der Graaff wrote on Tue, 18 August 2009 11:25Things that store data with the point in time at which they are triggered are generally called sequencers .
which doesnt mean there are no sequencers which work differently.
for his delay question: one could build a delay loop by feeding
a bang coming from a delay back into the delay again, each time
with a different setting for the delay time.
for a higher accuracy in a music context i would recommend to create
the initial starting bang by a metro.
"1,0"
[metro]
[delay 0.]
[t b b] (back to delay, next time value)
Thanks for you responses
The cues I have are points in time from the initial bang (the point at which a loop starts). Ideally these cue points would be sent from the coll to update the delay time after the previous value has been reached, or delay would already know a list of delay points. If I was to bang the delay with the new value it would delay that bang from that time instead of the initial bang... unless I deducted the previous time from it, which might work.
It seems like something that should be really simple.
Currently I'm using a delay for each cue, which will start to be impractical when I load up files with 50 or more markers. Is there a solution using poly~?
It's not very convenient to have the times compared to the starting point, then use a delay from the previous event. Subtracting is possible, but it's easier to just compare to the starting point and not use a (single) delay.
So here's a very simple sequencer, which Mattijs Kneppers built for the project we work(ed) on. I guess you should change around the data, but apart from that, it should work like a charm for you. We still use modified versions of this to control movie players, as it's lightweight and reasonably precise.
Hope it's clear enough to use, else let me know..:
There's also [qlist], or you could use [pipe] with multiple arguments. However, a [coll] with the durations which gets banged via a [counter] is probably the way to go unless you use a pre-made sequencer of some sort (which the [coll] basically would act as in this setup). If you want the values visible, look to jit.cellblock too, which you can edit in-place and select cells as needed for their duration values.
I'm kinda in a similar rut with a device I've been working on.
My process is to sequence velocity values on an Elektron Rytm:
Velocity values trigger the output of lists stored in a coll. These lists comprise notes in a chord. I have a uzi + zl group combo that spit out lists of values corresponding with each for giving each note its own identity in time, duration, and velocity.
For the time based identifiers (coming out as milliseconds), I've been sending to a [del], but since they don't work with lists, I've been just letting each subsequent note choke the last, which isn't nice if I wanted them to play altogether, or have decays that extend past the next.
I appreciate @Bas Van Der Graaff's sequencer, but I don't see a need for the bars/ beats to be looped. My use case is generating new data as you proceed thru rhythmic structures that diverge in meter.
tl:dr - could someone explain to me why it'd be unreasonable to ask that [del] work with a list of delay times?
setting delay time using list turns it into
you can make your own delay-time-respond to list
using few max objects
If you want to delay lists, look at the [pipe] object. But you can't set up a schedule of different delay times with that either.
As others have said: If the goal is to set a few different periods into the future where events will happen, then what's really needed here is not a delay, but a (one-shot) sequencer. You might want to look at the help files for sequencer objects like [mtr], [seq], or [seq~].
...in particular, for [mtr] look at the help file's "editing" tab.