MIDI Controller assignment system…

Dec 6, 2010 at 6:22am

MIDI Controller assignment system…

In trying to make things both highly functional in a number of situations and modular, I’m wondering how folks who do this a lot deal with MIDI controller number assignments between parts of a patch. For example. if I build a patch that includes 5-6 other abstractions I’ve made (maybe as [bpatchers], do you have some kind of central system for assigning controllers to various parameters? I’m thinking about doing one but trying to think through how– maybe the [pattr] system and some pre-defined parameters in the patchers that can be sent MIDI controller assignments. Hope this is making some sense…

#53752
Dec 6, 2010 at 6:52am

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.

#193322
Dec 6, 2010 at 11:17pm

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.

– Pasted Max Patch, click to expand. –
#193323
Dec 7, 2010 at 6:48pm

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.

#193324
Dec 8, 2010 at 7:53am

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!

#193325
Dec 8, 2010 at 2:18pm

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…

#193326
Dec 10, 2010 at 1:45pm

@Dan Nigrin
interesting..

how the coll keeps the data saved into an app?

#193327
Dec 10, 2010 at 1:57pm

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.

#193328
Dec 10, 2010 at 3:51pm

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

#193329
Dec 12, 2010 at 3:59pm

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!

#193330

You must be logged in to reply to this topic.