Why am I being defeated by poly~ ????

[chaircrusher]

So I have read the tutorials for poly~ and thispoly~ and I can't create a working patcher to use in an instance of poly~.

I've included them below.

My procedure:

1. Start Live, load an empty Max Instrument on a MIDI track.
2. Save the empty instrument in a Live set's directory.
3. Creat new patcher (below), save in same Live set's directory as testPolyPatcher.maxpat.
4. attach the output of midiin to the poly~
5. Create an instance of poly~ i.e. "poly~ testPolyPatcher 4"
6. Nothing happens -- no outlets appear on the poly~ instance.
7. Open inspector for poly~ and choose testPolyPatcher.maxpat.
8. Live + Max go busy for a few seconds, and then Max crashes.

I know I'm a noob but this is getting frustrating. If I read the documents right, this should work. So there is some undocumented mojo I'm missing. Anyone have any ideas?

Thanks in advance!


http://www.cornwarning.com/xfer/Max/tes ... her.maxpat

[flowdesigner]

divide the velocity output of unpack by 127, skip the stripnote and patch the third outlet of adsr into poly~ to save cpu when the voice is not playing.
You should pack all messages to adsr into a list and prepend it with target 0, or you need to prepend each message with target 0, wich gets messy in the main patch

[pid]

Poly will look in Max' filepath, and this doesn't include the Live library. Hence it won't be able to find your "external" (that's basically what you're setting up here; a patch which will be used in another patch).

this is not correct. while max does look in the max search path, however you have set it up, it ALSO looks in the directory local the the max patch and/or .amxd device. this can be simpler in some circumstances when you do not want / need to reuse patches.

the op's patch is almost correct but with some problems. whilst flow designer is right to point out the divide by 127 for velocity, it is crucial you divide by 127. and not 127 (ie, a float and not an int). also, while the list idea for the adsr values as a list is a good one, the POINT of using adsr~ inside a poly~ abstraction coupled with thispoly~ is to save cpu usage. how? - because coupling with thispoly~ auto-mutes voices with sample accuracy when envelopes engaged / disengaged in their different stages ('release' point etc). [furthermore, if the ONLY messages being sent to the parent poly~ object will be global anyway (e.g. adsr values), you could just use the instantiation attribute '@target 0' to the parent poly object itself].

ultimately though, what the op should do is the following:
- open the adsr~ helpfile (alt-click on the object)
- once open, double-click the 'p polysynth' subpatch near the bottom
- study this patch and look inside the poly~ abstraction therein - this abstraction does exactly what you are after in a simple and effective way.

NOTE, your (and the example) poly~ abstraction REQUIRE your midi data to be sent into the abstraction using 'midinote $1 $2' or 'prepend midinote' or whatever means before your pitch/velocity list.

crucially, swapping the ordering of the pitch and velocity is important, and using the adsr~ sample rate information to do all the voice muting etc for you is a little more effective. AND, using sah~ might be useful to you - see what samples the input and see how thispoly~ is patched up from the adsr~. while the patch of the OP demostrates a correct use of the master envelope going directly into thispoly~, when you have an adsr~ in your poly~ abstraction you might as well be using the added benefits of that to do you dsp management.

hth.

p.s. - if you continue to have problems with the poly~ parent finding your subpatch, be sure to double check exactly where it is in relation to you master patch / .amxd.

[flowdesigner]

if the ONLY messages being sent to the parent poly~ object will be global anyway (e.g. adsr values), you could just use the instantiation attribute '@target 0' to the parent poly object itself

when opening the inspector to poly~, it seems to have target 0 as a starting point, so I do not have to think about it unless I want to reach a specific voice?

Good to know

[pid]

yes. i mean i was talking about actually typing in the instantiation attribute '@target 0' to the object box - for some reason i have never done this particular target thing via the inspector only. if you do ever do such important global 'things' via inspector only, i would recommend freezing the attribute in the inspector - i do this all the time with certain pattr-type attributes in m4l as i have had so many issues with 'things' randomly changing in big device developments. ymmv.

tbh, i would normally only ever use '@target 0' if the poly~ is a one-voice poly~ used for non-polyphony purposes, i.e. switching patchers dynamically, or using to dynamically change arguments, or using as a solid cpu muting system, etc etc. in the example of the OP i would not use it. i would use an 'a d s r' values list with 'target 0' externally and unpack 0. 0. 0. 0. internally.