Brian H.

Just want to just clarify my understanding, as well as see if there are suggestions for better approaches than the ones I present here:

1. In order to use an abstraction with [poly~], all in/outlets will now *also* need [in]/[out] objects. So in making an abstraction, if there is a chance at all it might end up being used with [poly~] (and who can tell?), they'll need to be added (now or later).

2. [Poly~]'s can be nested reliably-- So my [poly~] subpatch can contain another [poly~] object + patch.

3. [send~/receive~] is a reasonable way around the problem of needing to send different signals to different instances. For example, to load 4 instances of a delay patch in [poly~] and send them all different signals to control delay time.

4. Along those lines, I'm having problems when signals and floats need to get along together. For example, in using a delay patch, one might drive the [tapout~] time from either a float or signal. But as long as the signal is connected (even if you want to use the float at the time), it will output a stream of 0.00. Is this where I'm supposed to use the polyphony management parts of [poly~] I haven't looked at yet, as efficiency has not been the most pressing problem?

Hi all,
Just want to just clarify my understanding, as well as see if there are suggestions for better approaches than the ones I present here:

1.  In order to use an abstraction with [poly~], all in/outlets will now *also* need [in]/[out] objects.  So in making an abstraction, if there is a chance at all it might end up being used with [poly~] (and who can tell?), they'll need to be added (now or later).

2.  [Poly~]'s can be nested reliably-- So my [poly~] subpatch can contain another [poly~] object + patch.

3.  [send~/receive~] is a reasonable way around the problem of needing to send different signals to different instances.  For example, to load 4 instances of a delay patch in [poly~] and send them all different signals to control delay time.

4.  Along those lines, I'm having problems when signals and floats need to get along together.  For example, in using a delay patch, one might drive the [tapout~] time from either a float or signal.  But as long as the signal is connected (even if you want to use the float at the time), it will output a stream of 0.00.  Is this where I'm supposed to use the polyphony management parts of [poly~] I haven't looked at yet, as efficiency has not been the most pressing problem?

confirming-points-about-in-signalsfloats

I have noticed some oddness when nesting poly~ subpatches where signals gets through to the nested [in~]'s even when they're disconnected.

As far as signals and floats getting in each others' way, is the answer just to make separate abstractions that use each where necessary? For example, do folks have separate versions of patches that control [tapout~] with a signal and a float?

Any pointers here?
I have noticed some oddness when nesting poly~ subpatches where signals gets through to the nested [in~]'s even when they're disconnected.
As far as signals and floats getting in each others' way, is the answer just to make separate abstractions that use each where necessary?  For example, do folks have separate versions of patches that control [tapout~] with a signal and a float?

Confirming points about [in~] signals+floats...