Using Poly~ as a player for 60 buffered files

Mar 28, 2013 at 7:05pm

Using Poly~ as a player for 60 buffered files

Hello, all.
I have read some poly~ instructions, but still having a hard time figuring things out.
Brief explanation:
I have to conjure up the impression of 60 mono audio files of the same length of 6 minutes running simultaneously.
Obviously there is a CPU issue if I really run them all together, so I am trying to buffer them all at the same time (no RAM issue there), but run them only selectively. The maximum number of actually simultaneously running audio files will be 30.
Execution plan:
To save some CPU, I am trying to use poly~ subpatch as my player, and all the other functionalities will go to its mother patch.
Questions:
1) I guess I can get by only with 30 instances of player as that is the maximum number of simultaneously running audio files. But how can I make the different instances read different buffers?
2) How can I turn the poly~player on and off while the music is playing? So the point is I should be able to turn on one buffer playing from the PRESENT point not from the beginning point of audio files.
Patches:
So, attached are largely incomplete patches: two Player patches (I am not sure whether to use sfplay~ or Groove~: which one would you recommend?) and their corresponding mother patches.

Could anybody please help? Any advice and suggestion will be much appreciated. If you could go step-by-step, even more so.
Thank you very much!
Best wishes,
J

Attachments:
  1. test2MOM.maxpat
#67383
Mar 29, 2013 at 12:49pm

sfplay~ reads from disk, so you can’t use it for playing buffers.

you should also check the polybuffer~ object whit which you can simply load and manage a folder of audio files.

lastly, you can control single instances of poly using the “target ” message.

– Pasted Max Patch, click to expand. –
#242426
Mar 29, 2013 at 1:17pm

Just another thought.. how large are the files?

If you use polybuffer~ you need to have enough ram to store them all. If they do all fit, playback shouldn’t be a problem though – I’ve got a patch using 100 instances of play~ in poly~ which only runs at about 5% of my I7 desktop.

#242427
Mar 29, 2013 at 2:40pm

the idea to put the play~ objects into a poly~ seems absolutely right, unless the scenario will include a limit to say 8 voices. in this case i would prefer to use 8 play~obejcts in the root level and use messages to change their buffer target.

#242428
Mar 29, 2013 at 3:41pm

@Mark your desktop is Mac or a PC ?
did you tried the same with groove ? if so then did you noticed some differences in resource hits ?

#242429
Mar 29, 2013 at 4:33pm

When I want to send data to specific instances of a poly~, I prefer to name a receive object within the poly~ with a different name in each instance according to the instance number. Therefore I do not have to deal with the target message and I can still send data to all instancess trough the regular inputs.

– Pasted Max Patch, click to expand. –

However you don’t need this I think . If you assign a different number to each buffer you may use the midinote message with the buffer number to play/stop followed by a 1 if you want to start playing and 0 if you want to stop it. The current position might be continuously transmitted as a signal to all voices. Using the midinote message helps to activate only the necessary voices. The velocity also allows to activate either a fade-in or a fade-out.

Hope this helps.

This is the main patcher :

– Pasted Max Patch, click to expand. –

Save this one as poly_player.maxpat:

– Pasted Max Patch, click to expand. –
#242430
Mar 29, 2013 at 5:40pm

@KrisW It’s a PC. There’s also loads of other stuff going on in the patch I mentioned so it’s not a serious measurement. I don’t think there should be much difference between play~ and groove~ though.

#242431
Mar 31, 2013 at 5:48pm

@ all
How generous and kind! You guys are amazing souls. I am very grateful of all your advices.
And many apologies for this delayed reply.

@ LSka
Thank you! Yes. I will use play~ object in poly_player then.

@ Mark Durham
I have 24GB RAM, and i7 processor. So the ram is not much of a problem, but polybuffer~ seems to operate a little unstably on my laptop. Also, the object seems to change the order of buffer as opposed to my intention of having buffer 1 to 60 as the order of the audio file names.
As for size, each file is about 30MB. All of them Mono WAV files running 6 minutes 5 seconds precisely.
Would you please show me a preliminary patch of how you’d tackle a similar task if you have time? I’d really appreciate it!

@ Roman Thilenius
Thank you for verifying! I will stick to the idea of fitting play~ in poly~ poly_player then.

@ Roald Baudoux
Thank you, Roald Baudoux. What a great help!!! Attached are the patches that I amended only slightly from you generously posted up. I have a couple of questions regarding your patch.
1) Is the line~ object in the mother patch is tracking the PRESENT point of audio files?
2) it seems my patch does not operate although buffers are all there…this is a very stupid question, but why would that be?
Again, thanks a million!

#242432
Apr 1, 2013 at 4:20pm

Hello JSY263,

Yes the line~ object constantly updates the playback position – it is a “natural” companion to play~ for linear sound playback.

Some of your buffers shared the same name so it could lead to problems. Also, the arguments of the sprintf object should match the buffer’s names. If your buffer are named “audio1″, “audio2″, etc then the sprintf should be like this: “sprintf set audio%i”. If you use a polybuffer~ named “audio” change the sprintf like this “sprintf set audio.%i” (notice the tiny difference). Note that the polybuffer~’s name does not have to include a dot but the dot must be used as a separator between polybuffer~’s name and the buffer number when you want to choose a specific buffer using an argument or a message to a playback object.

I don’t have a folder with 60 files of 6 minutes so I couldn’t test. So I added a few objects and messages to help you track possible bugs.

Let me know if it functions as expected.

#242433

You must be logged in to reply to this topic.