[poly~] subpatch Strategies?

    Nov 08 2013 | 5:04 am
    Hi, [poly~] certainly is useful. But I'm looking for a some advice/good practice to being able to make it more productive and fight with it a little less.
    For instance, do people have to maintain a separate library of abstractions for use in [poly~], just because they have different inlets/outlets? For example, if I made a generic delay, it might essentially be the same for use in and outside of [poly~]. I've had some odd results in the past when including both regular inlets/outlets AND [poly~] in/out, just to make it useable in either. Is that a bad idea, or something others have done?
    When developing several abstractions, is there something to do differently if they are to used inside [poly~] or specific considerations?
    Just throwing it out there (in kind of a vague way, I know) to try and minimize my frustration and develop things in a smart way.
    Thanks, Brian

    • Nov 08 2013 | 10:14 am
      Somewhere it suggests, I think in the tutorials, to include an inlet and outlet for each in and out of a poly, then the same object can be embedded inside a patch. Mostly it works the same way. There's only a few exceptions. The thispoly~ object, and anything it controls, won't work unless it's in a poly~. The adsr~ features for polyphony don't work when it's not in a poly~.
      If you put the object which was inside poly~ into exaxctly the same place where the poly~ object was, then any attributes you were setting for poly~ (like 'voices') will appear inside the patch on the first inlet instead.
      Anything which would be set across all instances of a poly~ normally isn't inside the poly~. That includes panel controls, presets, and pattr things. But that's more an issue of design partitioning, and not really something for which one would make a separate library of things, if one has anticipated polyphonizing the things, they would be separate anyway.
    • Nov 10 2013 | 5:49 am
      Hmm…I *think* I'm following. I did find a suggestion in the [in~] helpfile to add inlets + [in~] in the same patch, to be used in both places. I was just checking, because I've had what appeared to be some odd behavior at times (signals getting places even after patchcords had been disconnected!). The situations were quite complex (well, to me) and I had several layers of things inside a poly~ subpatch. But I wanted to see if anyone was cautioning against doing that or behavior could be unpredictable.
      Thanks, Brian
    • Nov 15 2013 | 12:45 am
      Send and receive objects could relay singals after disconnecting a wire, but I tend not to use them, so I don't know the gotchas on them. The reason I don't use them is, every time a value is sent somewhere, Max scans every single object to see if any of them are set up to receive it, which is not very efficient.
    • Nov 15 2013 | 11:43 pm
      IMO, send and receive are really useful, and I strongly advocate their usage for people who are new to poly~. If you want to send messages to all instances, send/receive is by far the simplest way to do so. I use inlets when a message needs to be unique to a particular instance. (I usually only do this in a non-voice-allocated system, e.g. a vocoder)
      There may be some small differences in efficiency, but I think that really depends on your application. I've used send and receive for a long time and the flexibility in design that they facilitate more than makes up for any difference in performance. I'm a strong believer in Knuth's advice re: efficiency, and I prefer to design the architecture to meet my musical needs, then look at efficiencies as necessary. YMMV.
    • Nov 17 2013 | 4:34 pm
      My own preference is to use send and receive objects only as I might use global variables in a standard programming language, not just as a way to avoid using patch cords. To communicate with all voices in a poly~, I use "target 0".
    • Nov 17 2013 | 6:24 pm
      The value object might be an alternative to send/receive to transmit data to all the voices, when there is a triggering mechanism to start a voice.
      I prefer to avoid target 0 because if some messages need to be send to specific voices also then one must always alternate between "target 0" and "target n" messages where n is a number between 1 and the total number of voices.