Many outputs for poly~ / alternative to send~ and receive~ for poly~?
Hi all.
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.
Hello Seth,
I don't really understand what you are trying to achieve when looking at the patch, but for me, both approachs are wrong. You should configure your spat.spat~ object with "@numsources 1" and include it in the poly. So when you instantiate 100 polys for examples, you will have 100 spat.spat~: source 1 will be in poly~ 1, source 2 in poly~ 2 etc...
Then in order to send a message to a particular spat~, you just have to use the source number as the target, like in the following exemple:
I hope it helps.
Thanks Philipe. I'll try this out but I'm not confident that you can use more than one Spat~ object when trying to include multiple objects. Sorry to question you - but are you certain this works correctly before I spend time trying to implement it? Every spat example I have seen uses just one spat.spat~ object. Just wondering if you could clarify a bit more.
One thing I may also try is building a small system for each poly object to write to a buffer, than having the buffers read into one spat~ object.
Well... I'll be damned. I'm pretty sure this is working. It just seemed counter intuitive that you could simply calculate the spatialization separately for each source and then sum them at the end but I suppose that gives a good approximation? Thanks for the tip!
I reached out to the most helpful Mr Sam Tarakajian and he in turn reached out to David Zicarelli and Joshua Kit Clayton. If anyone else is looking to do something similar this is pretty enlightening. I've attached the attachments from the email as well - it seems that Joshua recommends using buffers just as I was considering.
I've also received an update on the Spat forum here http://forumnet.ircam.fr/user-groups/spat/forum/topic/spat-and-poly/#post-18841
---------- Forwarded message ----------
From: Joshua kit Clayton
Date: Fri, Aug 19, 2016 at 3:22 PM
Subject: Re: send~ and set
To: "David D. Zicarelli"
Yeah, without examining your example, that was the first thought that occurred to me. However, Maybe part of it also is to support feedback, which won't work with matrix~ without adding something like tapin/tapout to escape the infinite recursion in the signal compiler.
If there is no feedback, then you should be all set just with matrix~.
Basically, beyond send~/receive~ potentially being more expensive, it introduces potentially arbitrary latency....
shuffle shuffle...looking at the example, your friend is using send~ from within poly~ to receive~ outside. Yeah, this is fraught with problems I don't really want to get into.
Someday we should make the variants of poly~ we've imagined to have parallel outputs rather than summed outputs which would hopefully facilitate this kind of thing. I think Alex Harker has tried to do something along these lines.
I can think of a few different hacks around this using buffer or gen or whatever. I've attached a quick and dirty usage of buffer to this end which doesn't support multiple senders to a single receive, but shows some concepts of how to overcome the intelligence/stupidity/overhead of send/receive inside poly.
I'd personally use this to get the channel output poly~ and then do any complex routing with matrix~ for dynamic routing and channel summing to different outputs, blablabla.
Hope it helps.
On Thu, Aug 18, 2016 at 9:48 AM, David D. Zicarelli wrote:
I’ll let Joshua go into more detail if he wants but send~ and receive~ are a bad practice and should be avoided at all costs. If the person wants some kind of signal routing, matrix~ is preferable.
David Z.
On Aug 18, 2016, at 6:59 AM, Sam Tarakajian wrote:
Hi all,
I have a quick question about send~. A friend is trying to make a patch with many, many receive~'s, 250 to be exact. He's using one send~, a counter, some string formatting and the set message to have the send~ point to each of the receive~ objects, one after the other.
When he starts to add more and more send~ objects, audio starts to click and drop. My question is this: is sending set to send~ really inefficient? In my mind, it would be equivalent, internally, to destroying and creating a DSP patchcord, which would mean a change to the audio graph. Is that correct?
If you want to see the patch, which has 10 receive~ instead of 250, you can grab it here. It won't work if you don't have spat~, but you shouldn't need that to see the problem.
Thanks for your help!
-S
I wonder if this silly trick could help you:
@Philippe Roger. I'm also trying to find a way to use poly~ in combination with spat. But it seems the above mentioned method is outdated. Is there a way to send audio to a particular spat input from within poly~ with spat5.spat~?
Crossing the [poly~] frontier with [send~]/[receive~] instead of through inputs/outputs is not advised. Patch cords are a safe bet.
@AJREIJN I am successfully using spat5.pan~ (not spat5.spat~) in conjunction with poly~ in my current project, so I can confirm that it works. There are plenty ways to send audio out of poly~ to spat, most of them make use of mc.send~ / mc.receive~ objets. Below is a short and simple exemple of how you can send audio to spat5.spat~ directly from within poly~ instances.
Thank you for your response Philippe!
Unfortunately I'm using max 7. So no mc.send~/receive~ objects... I wasn't really planning on upgrading, but I can think about it. I'd prefer a method already possible in 7 though... Isn't there any documentation available somewhere on these sort of things?
Another option would use a poly~ with 16 audio outputs, and route the signal inside each poly~ voice to the outlet corresponding to the voice number, using for instance a [gate~ 16].
Hi all
i use send~ in a poly~,( inside a big poly~), for long time, to route 18 signals, everyone to 10 outs , dynamically, step by step. Idem for adc~ins. I don't understand why this is bad practice. Recording and comparing a source signal and the same via send~receive~ doesn't seem to make problem in phase or latency. Why mc.send~ mc.receive~ is good practice ? This way i have added internal busses to have internal submixes. From Max 6 to 8 without relevant problems. After Maxmsp 3-4, modifying the in or out in a adc~ or dac~ stopped the sound, if i remember well. To avoid clicks, i send a mute 1 - 0 to thispoly~ the time to change the adress of the dac~.
I'm just an intensive user, i don't know the magic underground of the things
best to You all, thanks everyone and the maxlist !
i.e:
Thank you Jean-Francois. I guess I was hoping to find a way to send audio signals directly into one of the spat inputs from within a poly instance. If not, the multiple out~ and use of a gate~ option should work fine. Thanx!