ok the journey goes on.
can i extend live.ui objects ?
yes, i can extend the attributes offered, they get also stored with the patch, so i can rely on their extra data given by user safely.
can i connect to pattrstorage automatically and orderly?
yes, i can find the object in the patcher and do the needed messages without extra cable salad
can i limit certain UI elements (controls) to be allowed to ‘autopattr’ and others not?
yes, it is a common problem in M4L and MAX in general when using pattrstorage linking the pattr’ed objects will be linked to pattrstorage as soon autopattr is used. This will likely mess up your preset data and become unreliable in some cases. Problem solved, i do the lookup by a name scheme used in varname (alias scriptingname) automatically. The whole patch is searched for such elements and automatically subscribe’d to the pattrstorage. Parallel i build up a lockup mechanism that allows to midi map either NRPN numbers and+or CC numbers. Which means no cables are needed to each UI element anymore. The communication to and from them is even shortened and centralised, which in turn allows for more complex tasks, like mapping automatically midi range values to NRPN range values and wise versa.
Can i find the patchername from within the patcher
… without javascript (slow)? A functionality not meant to exist until now, max just doesnt have any object that can tell you the tree of your patchers. So i wrote one explicit extension object to do just that, worked like charm. But that needed to be placed in subpatchers so it climbs up, but i try also to get rid of not needed cable salad and fasten up stuff. Well - until I figured out I can just do the same when searching the entire patch for “_varname” objects, find the according tree name and automatically subscribe to pattrstorage, read the NRPN and CC mapping given to each of those UI controls and build up the faster access lockup table…
centralsed midi NRPN & CC feeding
As now i have an lockup table that finds UI elements by CC number or NRPN number, i can just receive the data and fastforward the messaging with a direct call to the setter of the INT values.
No cables? but how do you get the integer values of the Controls out?
no big deal, same as i’d do with slower javascript, i simply let Max do what it does best, which is finding function pointers, object names and automatically notify… So i let my grand brainy extension be notified when the controls change, just like pattrstorage does as well, and from there implemented the midi CC mapping to NRPN or from NRPN to CC or even as is and punch that out as list’s feeding the midi out with data…
…and voilá
i have a fast, scalable, reliable, easy to program, visually clear maxpatch environment that can serve any NRPN/CC machinery with scaled presets recalled from pattrstorage.
Where to go from here?
I’d like to implement somethig that is similar to speedlim but for a whole buffer of midi command’s, kinda like a state-machine, so it knows if a midi byte has to be given out directly or came so fast in that i can simply replace it on the stream before is overloads the midi stream.
(photo, see no cables for controls, autopattr and pattrstorage present, and live.dial and the other 4 UI classes have the extended attribute)
wondering why this is/was not default part of Max4Live or MaxMSP… scratching my head
ps: for those who come along and might ask, but but there is fixed mapping of midi on live controls, this should mess everything up in ableton… well - nop, this extension is only at work when pattrstorage is involved, autopattr present and ‘my’ “find” (want likely to open source that) object placed in a patch. Should even work on push3
so, now it could be discussed how that brainy thingy i called “find” for now could be named… maybe ccpattr or subscriber or… any ideas ?
