dynamic poly~ and M4L issues

Aug 15, 2011 at 5:19pm

dynamic poly~ and M4L issues

I’m having a lot of problems when using poly~ in M4L as an object wrapper. I’m using it to switch between different oscillators, and it’s really not working once I get it into Live. It makes sound, but the pitch of the oscillators seems to be stuck on something really low since I’m just getting impulses.

I’m using a change object to prevent the constant updating of the chosen patcher, but it’s not helping. The code within the poly~ is very simple, and it works fine in Max, just not Live. I had something similar happening with another patch and I replaced it with mute~ and subpatchers, but it’d be great if poly~ worked in this situation. Does anyone have a similar issue?

– Pasted Max Patch, click to expand. –

Here’s the selection code:

– Pasted Max Patch, click to expand. –

P.S. No upsampling, vs or anything special for the poly~, and only one voice.

Aug 15, 2011 at 6:51pm

all i can say is:
i feel a bit guilty because i keep meaning to report this exact bug and never get round to it.
yes, i have exact same problem – M4L is not allowing the dynamic switching of poly~ patches, period.
however, for spanner in works, i DID have this working fine as far back as max 5.1.3-ish. i think this bug might have been added in 5.1.7 or 5.1.8.
similarly, works fine in max standalone, but not in M4L. could not get it working in editor either as far as i could recall.
you can actually check his by simply turning the dynmaic-poly~ section of the standard help patch into an M4L device – does not work.
sorry i do not help.
would be good to get this fixed for this version of M4L and not have to wait for compatibility to Max6.

Aug 15, 2011 at 8:34pm

Hey, it’s good to know I’m not the only one.

Aug 25, 2011 at 7:17pm

I confirm this behavior.

Sep 1, 2011 at 9:42am

ok. strange. i managed to get the poly~ dynamically reloading. it needed the FULL file path AND “.maxpat” at the end. weird. it seems to work though on initial tests. (before, i just used the file name as it was in the same folder as the .amxd). have not tested ‘frozen’ yet though. can it really be this simple? or am i being an idiot (likely)? [pointless code demo at end of post].

however, for me, big problem still. my poly~ patches contain an embedded pfft~ patch. inside the pfft~ patch is an [index~] with a m4l device-wide “—” unique identifier in the name. the actual buffer~ is in the parent .amxd. whatever i do, on reloading the poly~ dynamically, the device can never find the unique identifier OR the buffer~. it loads the index~ in the pfft~ as if it is not even in m4l – i.e., with the actual three slashes “—” characters rather than the replaced unique identifier number. so, with dynamic poly~, it appears embedded “—” identifiers for buffers/etc do not pick up the load order correctly. makes sense? no, thought not.

anyway, have either of you two officially bug reported any of these issues to cycling? i am sort of scared to ‘cos they are busy on max6… i assume they have not seen this thread.

– Pasted Max Patch, click to expand. –
Sep 3, 2011 at 3:35pm

hey pid, I confirm your findings (poly patch with full path and maxpat ending) also. this one works for me too. But I havent tried your workaround patch yet.

No, i havent reported this. Since I stumbled upon this thread by accident. Its not a actual problem for my patches, but its always good to know about.

Sep 7, 2011 at 2:48pm

Dumb question, but do you just send mail to the support folks for bugs and the like?

Sep 7, 2011 at 4:08pm

i guess so. i am dumb too of course.

i’ve just realised how desperately i need this feature back!

who will take plunge?


You must be logged in to reply to this topic.