Polysymphony with more than 350samples, is groove + buffer the best method?

    Oct 30 2014 | 6:56 pm
    Hello there, I am working at realising a poly symphony where a set of 11 main samples of recorded voices are being played. Each one of the set of samples comes with a good deal of variations and this makes up for a total that goes above 350 samples; each one of them is less than 5-6secs long.
    When a particular action happens (on a connected Arduino) Max plays 5 of the above samples almost at the same time, in a very tightly arranged sequence.
    At the moment I am using a series of groove + buffer objects, one for each one of the samples. I notice that this tends to work hard on my CPU (MacBook Pro late 2011 or MacMini late 2012) As a solution I am thinking of only having one set of 11 grooves and buffers (each one for each of the sets) and then using 'replace' message to load a file each time this needs to be played. Would this be the right move? Should I stick with the original method? I have started looking at the poly~ object but before changing everything I was wondering if I could have your opinion on this.
    Many thanks in advance for your help

    • Oct 30 2014 | 9:13 pm
      So just to be clear, you actually have 350 groove objects and 350 buffers loaded at the same time right now?
      If you only ever play five sounds at once then I'd say you could use, say, ten groove objects and buffers, and then alternate, five play, the other five are loading sounds. That way you'll never have choppy sounds if the files don't load fast enough.
    • Oct 30 2014 | 9:45 pm
      Or if all the samples fit into RAM easily, then Polybuffer~ is good for this sort of thing. You can then use the 'set' message to change sample on your groove~(s) without worrying about stuff loading from disk.
    • Oct 30 2014 | 10:19 pm
      Thank you guys for your very quick reply! Yes, Wettwnberg, that's pretty much what I have. They play in a sequence and definitively overlap, that's why I thought of using groove and buffers in conjunction. Thanks for your idea, I will give it a go immediately. That way the files that will be loaded in the RAM will only be 10 at times am I right? I am just a bit concerned about having to hardcode each buffer for each one of the samples and then finding out that it was too heavy o the RAM :)
      MarK Durham, thanks for the Polybuffer~ suggestion, I will go through the reference file, I must say I haven't used it yet.
    • Oct 30 2014 | 11:26 pm
      yeah, definitely try out both polybuffer~  and my suggestion. I know stretta made good use of a poly buffer loading mechanism that would take a stack of samples and auto-load them in buffers. Have a look at the stuff he built for Livid, if you get a chance.
    • Oct 31 2014 | 2:13 pm
      Hi, tried the polybuffer~ it is a very nice object indeed, but it seems to be that it cannot play its samples (the ones that it contains) at the same time, am I wrong? If I try playing more than one sample at time through groove, the newer will take over the old one. I downloaded Livid'd GitHub and will play with it later on this eve. Stretta's theory sounds very cool! Thanks for your help!
    • Nov 01 2014 | 8:26 am
      You will need multiple groove~s to play back more than one sample. Polybuffer~ works as if you had x number of buffer~ objects, but doesn't take care of polyphonic playback. One way to do this is to use poly~, the other is to just have more groove~s than you need and cycle through them, as Wetterberg mentioned.
      Here's a related patch I made using Polybuffer~ and play~ (I think) in a poly~: http://sounddesignwithmax.blogspot.co.uk/2014/08/sound-design-toolbox-pt1-random.html it lets you drop a folder of sounds onto it and then plays back random samples. You may be able to hack it to your needs. Happy to answer any questions on it.
    • Nov 01 2014 | 5:04 pm
      uhm mark... I really love your blog! Oh man, the work you've done! How did I only just notice this!?
    • Nov 03 2014 | 8:12 am
      Thanks! Always nice to hear people are finding it interesting.
      About your request... email me here:
    • Nov 03 2014 | 7:13 pm
      lolpatch. Thanks, Mark.
    • Nov 03 2014 | 7:37 pm
      Thank you Mark! Really nice stuff on your site btw, many thanks for the link, and yes the patch is a really nice idea too :)