Poly~ and Individually Routed Buffers
Can anyone help with this?
I am working on a large scale project that requires the use of multiple audio files ( 24 for each sound "scene" with 5/6 altogether). I currently using the polybuffer object to load the sound files into one object and am then routing every sound file within the polybuffer to its own seperate outlet to then be sent into a player abstraction for viewing/editing/playing back - it's landing itself into a waveform~ object specifically.
The problem is I don't know how to tell poly~ to send a specific sound file to a specific instance of poly~. Everything I have tried just causes a single sound file to be loaded across all 24 instances of the object, even with the use of the target message. I'm relatively new to max so if anyone has any suggestions or can take a look at my patch below it would be much appreciated :)
No takers then? :(
You can change the target buffer~ for groove~ via the "set" message. (e.g. "set scene-1.2")
If you loadbang the thispoly~ object it will give you the specific instance number of that voice. You could use that in conjunction with combine (as in your master patch)
You could also look into sfplay~ and sflist~ as an alternative means of doing this. Sflist~ stores up to 250-some numbered cues for use with sfplay~. Then it's just a matter of asking for the right cue number.
Some other minor points:
- You don't need to use rslider, since waveform~ already has the same functionality. (check the helpfile for more info)
- It's easier to have your loop message explicitly turn looping on or off, rather than toggling it. (imagine that you were recalling presets and wanted the loop state included)
- You need to use a loadmess to send the message "stop" into groove~, otherwise all voices will play their soundfile at load time.
- check out thispoly~, since it will allow you to do muting and tell if a voice is busy or not.
- You could route the output via send~ (use the set message to change destination) instead of out~, though that might make the poly~ run in one thread and consume more CPU. Alternatively, you could use gate~ 24 and the instance number from thispoly~ to route the output to one of 24 outputs.
- If your configuration is fixed and having access to the controls for each voice is important, you could do this as 24 bpatchers. (though poly~ is nice since it makes it easier to expand)
Thanks for the response Peter, I've checked out the sflist and sfplay and they look like a much easier alternative that I can use.
In regards to the other points I have tried to make use of the combine object but the outcoming message has no spaces between them and just creates an error i.e target1setscene1.1 - I'm going to try using sprintf to see if that works.
Also I'm not sure how to do what you were suggesting with send~ and gate~ 24 - do you have any examples? And yes control over each voice is what I'm looking for, is that still possible to do for each poly through the use of target messaging?
D= I've tried using the thispoly to loadbang its instance numbering, using a target and $1 message followed by the set scene-1.1 and it still allocates a single sound file coming from polybuffer across all twenty instances of poly... I've done it through having it as one list and even splitting the messages.
Maybe I'm doing something completely stupid here but I can't figure out how it can be done - I've tried everything and more. :'(
Here's how to get each poly~ voice set to a specific buffer~.
I haven't looked at Peter's patch, so this may be redundant,
Here's your player patch for poly~
And here's your soundsystem patch that uses the new player
Thanks guys, turns out the issue I had was incredibly stupid - I forgot to attach a comma to the list so the messages were not being recognised by the poly player abstracion >: ( II've completely scrapped that player patch now and made a much simpler one based on what you've said Peter. (Couldn't get your posted patch to work btw, just came up blank when copied in but thanks for helping :) )
Chris, didn't realise I could use that attribute with poly, saves me alot of legwork with loading buffers, cheers!