I would use the "set" message to [ctlin] wherever you have one, these number boxes can be preset with either [pattr] or [preset]. If you're using [bpatchers] then use [pattr] to store different sets for each instance.

Personally I've been converted to holding the opinion that "every max patch should start with a pattrstorage"

This example uses a simple coll to map cc numbers to the elements you wish to control via their scripting names. The controlled elements are UI elements stored in bpatchers (embedded in the parent), though the basic idea works for any combination of child patchers/bpatchers/abstractions etc.

Pattrstorage (with a sprinkling of autopattr) gives you instant (and wireless!) control of all 'scripted' elements, as well as (optionally) feedback. This has the distinct advantage that all your midi io can be in one place (rather than distributed through various midiin/notein/ctlin throughout).

You'll also cut down on patching time by not having to add send/receive pairs, or dig into patches to find the corresponding names (pattrstorage's client window will give you the 'path' to all clients)

A final benefit is that as your then using the pattr system, adding preset capabilities to the patch later is painless.

Adapt this to 'any patch' should just be a case of deciding on your mapping (fixed or dynamic) and implementing it, then adding autopattr/scripting names to any patches you plan to embed in the top level patcher.

I use jamoma (http://jamoma.org/) and the DOT tools http://idmil.org/software/mappingtools. It allows great flexibility allowing you to try out various mappings, store different configurations, swap MIDI controller with relative ease.

Thanks so much, this is *great* stuff. I was thinking along similar lines, willyc-- I just have to get my pattr chops happening. I've gotten into a little and maybe not with the most straight-forward application, and got pretty confused. But I've got some resources, so it's on the list to try again. I was not aware of these links, razzkazz, they are really interesting. I'd heard of Jamona but hadn't looked into it. Many thanks!

Although I don't have it packaged up in an easy to share way, you may want to look at how I do it in a finished product, in my Software Klee Sequencer: http://defectiverecords.com/klee (You can try it all in the demo, no need to purchase). You can also get a good idea of how it works in this YouTube demo: http://www.youtube.com/watch?v=ph5tFH1drlc

Under the hood, although the details are different, it's basically doing similar thing to what willyc advises above...

@Dan Nigrin interesting..

how the coll keeps the data saved into an app?

It doesn't - I allow the user to manually save the coll contents to a file, which they can manually load back into the coll later. That said, it would also not be too difficult to write the coll contents to a preference file, which were then automatically loaded back in when the app was restarted the next time.

Hey Dan, how did you do your "MIDI Learn" ability?

I'm a little foggy on the details now since it's been at least 3 or 4 months since I built it, but basically:

* use hover to sense when mouse over an object (exclude objects that I don't want to be able to map) * move semi-transparent blue panel over the mappable object when hover'd over * if click on that object (sensed using mousestate), then move different color (orange) semi-transparent panel on top of object to indicate "listening" mode * now listen to ctlin for controller data * when received, create a new custom ctlin object with correct CC and MIDI settings, using scripting, and connect it to object that was clicked on, also using scripting * write data to coll and display in a jit.cellblock, allowing for save/retrieval etc...

Hope that helps some!