< Back to IRCAM Forum

Spat~ and poly~

Cross-posting to see if there is any Spat~ specific wisdom for my problem! I know there are many spat specific utilities and perhaps there is one that fits my needs.

original post: https://cycling74.com/forums/topic/many-outputs-for-poly-alternative-to-send-and-receive-for-poly/#post-364008

code attached

I’m trying to put together a spatial granular synthesizer using Max and Spat~. I would like to use all 250 possible inputs in Spat~.

I have tried a few different approaches but I haven’t been so successful with getting even 100 sounds at a time out of this setup.

Essentially, I have my spat.spat object which accepts signal inputs. My first attempt (attached) was to create a receive~ object for each input, and use the incoming message to the poly~ object to set the output of a send~ object. Performance-wise this worked great, but unfortunately it seems that poly~ changes the value for all send~ objects in each instance, and after some research I found that these are not compatible.

I next tried to create 250 out~ objects in my poly patch and use gate~ to select the output, but I can’t get more than 20 or so voices with this approach. I also tried the CNMAT poly.send and poly.receive objects but they appear to be broken and don’t support 64 bit which is a problem.

Any recommended approaches for this? I’ve been considering using an external routing program like Jack send the buffers along but I would like to know if there’s a better way to do this in Max. Anything that supports the parallel function in poly~ is a huge plus.

max_forum.zip (12.6 KB)

So - I’ve gone with the suggestion of Philippe Roger in the Max forums thread, and put a spat.spat~ in the poly~ patcher with source = 1. I’ll upload something soon, I’m very curious to hear if anyone has better recommendations or any thoughts on this.

Hi,

I would maybe suggest an approach with gating the output of the poly~ as you mentioned.

  1. However I have the impression (not 100% sure about that) that gate~ is not properly muted in the poly~.
    I replaced it with spat.matrix~, acting similarly (but being correctly muted).

  2. I think there was yet another bug in spat.spat~ where the automute attribute was not working properly.
    (see the spat.spat~ help patch for details about ‘automute’).
    Hence I send you another update of this object.

  3. With these modifications, I can render a reasonable amount of voices on my computer.

  4. Nonetheless, you’ll face CPU issues if you really try to spatialize 250 binaural sources at once.
    My advice would be to reduce that number i.e. you could still have a large number of grains (250 or more), but spatialize them with only, say, 32 or 64 sources.
    I think this would still create some sort of spatial-granular effect. You dont really need to spatialize each grain independently.

  5. Better running Max in 64 bit for such intense computing.
    The patch frequently crashes when running in 32-bit. (seems like a Cycling bug)

  6. Including spat.spat~ inside the poly~ (as suggested) might not the best choice: you would have one reverb for each poly voice,
    and the reverb processing is somewhat CPU intensive. Also the RAM usage would be much higher.

  7. I dont see how external routing like Jack would help. It’s just gonna add some extra CPU overhead and latency.

Modified patchers + fix spat.spat~ object :
Adresse: http://echanges.ircam.fr/filez/download.php?ad=7170CmwpKF
Taille du fichier :5.86 Mo

Thanks for all your advice. However I am on windows! Is it possible to send the windows compiled extension as well?

I’ve tested the version you sent and it still doesn’t perform as well as the version with individual spat~ in each poly~. Perhaps this has to do with threading? It does seem counter intuitive.

Do you think it would be possible to build my own spat.spat~ from components to allow poly~ to be better supported? Perhaps something like “spat.tut.09-PatchingSpat”? Any thoughts on this would be appreciated…

Thanks,
Seth

Hi Seth,

The external rebuilt for Windows is here :
Adresse: http://echanges.ircam.fr/filez/download.php?ad=7177GuwYt5
Taille du fichier :5.32 Mo

(I havent tested it)

I dont think that “building your own spat.spat~ from components to allow poly~ to be better supported” would work.

One (possibly) viable solution is to include only the panning (spat.pan~) in the poly~
(including the full spat.spat~ is very unlikely to work. As I said, including spat.spat~ would instantiate one reverb for each poly voice which is clearly inefficient).

Attached is probably the best option cpu-wise (but without reverb) :
each poly~ voice has a spat.pan~ which encodes the sound in ambisonic (in this example, 3rd order);
then, outside of the poly~, the ambisonic signals are decoded and rendered over binaural.

max_forum_4.zip (7.61 KB)