Forums > Beta

send~/receive~ to/from poly~ no more?


Oct 20 2011 | 11:27 am

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~":


-- Pasted Max Patch, click to expand. --

Save as "tLb.FeedbackGrid~":


-- Pasted Max Patch, click to expand. --


pm
Oct 20 2011 | 1:53 pm

I have exactly the same problem. Can’t use send~ audio signal outside a poly…

Oct 20 2011 | 11:21 pm

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.

Oct 21 2011 | 1:44 pm

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

Oct 21 2011 | 2:29 pm

ok, any other (new?) way to get sound in and out of single patcher instances inside poly~ would be also fine.

+1< <1024

:D


FP
Mar 16 2012 | 1:19 pm

+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 :
http://cycling74.com/forums/topic.php?id=38508&replies=4#post-188547

Mar 16 2012 | 4:09 pm

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

Mar 16 2012 | 6:33 pm

> 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?)

Aug 13 2012 | 8:22 pm

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?

Aug 13 2012 | 8:46 pm

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.

Aug 13 2012 | 9:40 pm

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

Dec 08 2012 | 2:54 pm

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.

Mar 29 2016 | 1:35 pm

externals don’t work, any real solution to this?

Mar 30 2016 | 7:27 pm

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?

Mar 31 2016 | 6:39 am

i think Peter’s suggestion is better ; poly.send~ and .bus~ are not for communication between poly~ voices

Viewing 15 posts - 1 through 15 (of 15 total)

Forums > Beta