Rodrigo Cadiz

Hi, I need a way to play a soundfile and re-play it again and again before the first and subsequent playbacks have ended. In general, I don't know know the duration of the soundfile, how many times I will re-play it or the time delay between re-attacks. So, I need a general solution.

I have a working solution using poly~ and specifiying a fixed number of groove~ objects inside it. So, each time I re-attack the soundfile I use a different groove~ pointing to the same buffer and I just add all the audio signals together. This works, but it is very inefficient. It would be better to have a system where I can check if a groove~ object has finished playback and re-use it before using another, but as the number of groove~ objects I use is fixed anyway, I don't think I will save any computation time this way.

I have thought about doing this with delay lines, the problem is that I would need to create the size of the delay line on the fly and trigger copies of it using bangs and not a priori delay times.

I think a good solution would be to create objects on the fly if they are needed, something like use a groove~ first, if a playback request arrives and this groove~ is still playing then create another groove~ on the fly and use it, and so on. But I have no experience creating on the fly objects in Max.

Maybe I am missing something very basic in order to do this.

I have a working solution using poly~ and specifiying a fixed number of groove~ objects inside it. So, each time I re-attack the soundfile I use a different groove~ pointing to the same buffer and I just add all the audio signals together. This works, but it is very inefficient. It would be better to have a system where I can check if a groove~ object has finished playback and re-use it before using another, but as the number of groove~ objects I use is fixed anyway, I don't think I will save any computation time this way. 

re-attacking-a-sound-file-multiple-times

This is a case where something a little difficult in max/msp is trivial in another language. I don't even need to post a patch, just do this:

and use this script in the [rtcmix~] object:

and every time you hit the bang (random intervals even!) a new instantiation of the soundfile playback will happen. Duration of the soundfile is calculated on-the-fly.

(note: this is for mono playback, stereo is just as easy)

This is a case where something a little difficult in max/msp is trivial in another language.  I don't even need to post a patch, just do this:

   rtinput("/path/to/your/soundfile.aff")
   MIX(0, 0, DUR(), 1, 0)

and every time you hit the bang (random intervals even!) a new instantiation of the soundfile playback will happen.  Duration of the soundfile is calculated on-the-fly.

(note:  this is for mono playback, stereo is just as easy)

The rtcmix~ solution is certainly elegant, but if you want to stay within the Max/MSP distribution, it can be accomplished with poly~ without too much effort.

Thanks Chris, I tried your solution but I doesn't seem to work all the time. I assume the "start instance" bang is the way to re-attack the sound file multiple times. If that's the case, sometimes it does not trigger sounds at all, I believe this happens when the random number from the urn repeats itself (although it shouldn't, right?), then you can bang several times, without triggering any sound, until some number makes triggering work again.

What's the rationale behind using random numbers? Is is to use one channel of audio out of ten in a random fashion? If that's what it is, I don't think is what I need, as if I the urn gives me a number already in use, it won't work.

Thanks Chris, I tried your solution but I doesn't seem to work all the time. I assume the "start instance" bang is the way to re-attack the sound file multiple times. If that's the case, sometimes it does not trigger sounds at all, I believe this happens when the random number from the urn repeats itself (although it shouldn't, right?), then you can bang several times, without triggering any sound, until some number makes triggering work again. 

Hi Brad, I tried your solution, seems exactly what I need, except that I did exactly what you told me and each time I hit the bang I get the following error:

RTcmix: FATAL ERROR [MIX]: No input source open for this instrument!

I assume some configuration for the rtcmix~ object is missing.

Also, what happens when a soundfile playback instantation has finished? It is garbaged-collected somehow? Or each time I bang a new playback is added in top of the others and I keep incrementing the DSP usage with every new bang?

The error means you need to specify the full pathname to your soundfile in the

command. The easiest way to find this out is to go to /Applications/Utilities and start up the Terminal.app, and then drag the soundfile you want over to the Terminal window -- the full pathname will then be printed. Copy/Paste that into the rtinput("") and it should work.

Because all RTcmix instruments are scheduled (both start and end), they are deleted and garbage-collected when they complete. So the only DSP load will be the total number of soundfiles being played simultaneously.

command.  The easiest way to find this out is to go to /Applications/Utilities and start up the Terminal.app, and then drag the soundfile you want over to the Terminal window -- the full pathname will then be printed.  Copy/Paste that into the rtinput("") and it should work.

Because all RTcmix instruments are scheduled (both start and end), they are deleted and garbage-collected when they complete.  So the only DSP load will be the total number of soundfiles being played simultaneously.

The urn stuff came from the patch that this was extracted from. Here's a version of the top level patch that uses a counter instead. It also uses a keyslider to visualize how poly~ instances are used.

The urn stuff came from the patch that this was extracted from.  Here's a version of the top level patch that uses a counter instead. It also uses a keyslider to visualize how poly~ instances are used.


Ignore that last patch. Here's one that has a couple different ways to visualize, the keyslider to show busy/mute state, and a multislider to show progress through the file.

Re-attacking a sound file multiple times