send~/receive~ to/from poly~ no more?
Hi,
it seems that the option to send audio to/from single instances of patchers inside poly~is no more available? That would be a pity since at least I use this quite often for the dynamical creation of dsp chains. To give an example I attach the building blocks of a feedback network which works very nice under Max 5. Some dependencies are replaced with dummy patchers.
Best
Thomas
Save as "tLb.FeedbackGridNode~":
Save as "tLb.FeedbackGrid~":
I have exactly the same problem. Can't use send~ audio signal outside a poly...
send~ and receive~ is currently not working with poly~, but we hope to have this working again down the road.
FWIW, using send~ and receive~ with poly~ should generally to be avoided.
Hi Ben,
> send~ and receive~ is currently not working with poly~
> FWIW, using send~ and receive~ with poly~ should generally to be avoided.
ok, any other (new?) way to get sound in and out of single patcher instances inside poly~ would be also fine. The framework I developed uses wrappers for abstractions made with poly~, and the number of in~s and out~s vary from time to time (e.g. sidechain conections). Doing it this way is very elegant in the context I use it. BTW, you can find it now on the "Projects" page (LSD-LVD-tLb).
Thomas
ok, any other (new?) way to get sound in and out of single patcher instances inside poly~ would be also fine.
+1<
:D
+1 to solve this problem.
It was ok with max4.5 and 5 so it could be possible to get it working with max6. no ?
I got a similar problem but with send and receive inside the poly, related in this thread :
https://cycling74.com/forums/bug-when-using-send-in-a-poly-in-max-audio-effect
FP, this should be working with Max 6.0.4. Please let us know if you are experiencing issues.
Did you receive my email regarding this other thread? I have logged it as a bug and we will be taking a closer look.
-Ben
> FWIW, using send~ and receive~ with poly~ should generally to be avoided.
My two cents: I hope that send~/receive~ in poly~ doesn't go away, because there's certain things that are not easily possible otherwise. For example, I'm building a modular synth. If I want to add another sample and hold module or step sequencer, etc. I just add another voice to its existing poly patch. Its inputs and outputs are send~ and receive~, and I can't think of an easier way to do this. I mute it when I don't need it, I can use the target messages to talk to the specific instance. Lots of good things.
I'm guessing the reasoning for not doing this has to do with parallel processing? (or is there another reason?)
Not sure where this issue is at.
Currently, I'm trying to send~ multiple instances of audio from the poly~ object in Max 6.04. I have them numbered with a #0 string.
The only problem is that the numbering system seems to change each time I reopen Max.
Is there another way to approach this?
There is. If you want to get individual sends, you shouldn't use #0, since you don't know what the numbering base will be any time you open the patch. Instead, you can change the target of the sends after the fact using the "set yourTargetHere" message. I would recommend the following:
loadbang
|
thispoly~ (reports voice instance number!)
|
sprintf set elaborateSendName-%d
|
send~ BLACKHOLE
At load, the target "BLACKHOLE" will be replaced with elaborateSendName-1 (first voice), elaborateSendName-2 (second voice), etc.
#0 is really just for situations where you need a local send/receive; if anything else has to talk to it, it's probably not what you want.
I would recommend using John MacCallum's poly.send~ and poly.bus~ which are specifically made for this - you can get them here from the CNMAT site -> http://cnmat.berkeley.edu/downloads
poly.send~ and poly.bus~ are very useful to me, but I would like to know if there are any known drawbacks using them, or any problems that should be expected, especially in large patches.
externals don't work, any real solution to this?
Any documentation beyond a trivial help patcher that doesn't really explain anything? For example, what is poly.bus~ and why does there have to be an out~ 1 "to ensure that poly.bus~ will be below poly.send~ in the dsp chain"?
Is poly.send~ a replacement for send~? There doesn't seem to be a poly.receive~ so I'm guessing "no"!
So can one use this mechanism as a replacement for the normal send~/receive~ mechanism?
i think Peter's suggestion is better ; poly.send~ and .bus~ are not for communication between poly~ voices