Concepts
Of course all conceivable concepts within ranges between music and video can be realized with Max. Because it would blow up the framework, I concentrate on the description of the main parts of my Max applications here. This is above all the parameter control, value storage and variable interconnecting of I/O's.
The parameters in the used modules, provided with Script names, are captured and stored as presets (pattr object group). The presets may be switched or interpolated (see: pattrstorage Max Help). The parameters which can be controlled are routed to selected corresponding controllers, which can take over software changed values (like e.g. a motorfader).
The Controllers
Good controllers are the key and central component of my computer friendship. I´ve always worked for years, or several computer generations, with the same controllers. Some prevail, either because of the quality or because of the price. Since these machines have begun to correspond (continuous potentiometers or motorfaders), the programming has become more complex - what i see as a a reason to develop a good, comprehensive patch for it. It also brings the effect of having always the optimal software for the controllers available.
Euphonix MC Mix
My central controller - here I also collect all the key data, such as the parameter and addressing to the modules. I have connected two MC Mix.
Unfortunately the faster Eucon Protocol is not available in Max, so the MC MIX is "only" a MIDI controller in this environment. Nevertheless I am not limited to 128 steps (MIDI standard) - for the endless rotary encoders I can determine individual limitations - the rotating speed certainly controls the rate of the movement within the given limts. The faders of the MC Mix have a resolution of 1024 steps - therefore I use the 14 bits conversion (16384 steps) of the xbend object for MIDI applications within Max. In MIDI operation (Mackie Protocol) the touch-sensitive faders can be monitored - the touch-sensitive rotary encoders are not detected. Also the OLED display is only constrained useable.
The push dials of the MC MIX may also be switched noiseless over software or soft buttons - therfore also the “more distant” controllers remain always accessible. 
In the presets I also store the presetnumbers of attached “sub”-controllers, whose values and allocations can be changed from here collectively.
Because I am asked in regular intervals, how the patches for my controllers (motorfader and push dials) are programmed, i made a little example patch. It indicates, how several parameters are connected in a simple manner with one controller and how the values can be stored.
Mac and Windows: Download Maxpatch (6kb)
The MIDI Implementation of the MC Mix is here.
Kenton Killamix Mini
(Translation soon!) Ein solcher Sub-Controller ist für mich der Killamix Mini. Die Raster-Lautstärke der Drehgeber ist recht hoch und nicht Kammermusik tauglich. Seine Oberfläche ist für mich eher wie die von Boden-Effektgeräten, die nur nachgeregelt und an/aus- geschaltet werden. In einer solchen Funktion ist dieser Controller sehr gut aufgehoben. Leider lässt sich der aktive MIDI Kanal nicht über Software, sondern nur am Gerät umschalten.
TouchOsc for iPhone/iPad
Das iPhone hat sich als idealer Controller am ARP Odyssey erwiesen - es hat den Killamix Mini verdrängt, der nun auf dem Minimoog seine neue Heimat gefunden hat. Es passt auch besser, weil der Moog Potis hat und der Arp Sliders (zu denen ein multifunktionales XY-Pad besser passt).
Die veränderten Anzeigen auf dem iPhone werden durch ein Max-Patch "live" editiert. So kann ich durch Umschalten auf dem iPhone verschiedene Wertigkeiten auf einem Pad realisieren.
Im Gebrauch dieser Alltagsgegenstände als Controller liegt sicherlich eine grosse Zukunft - insbesondere für das grössere iPad. Leider muss ich aus wirtschaftlichen Gründen weiter auf die Anschaffung eines iPads warten.
Audio-Matrix
Für eine möglichst hohe Flexibilität ist bei Audioverbindungen eine Matrix ideal. Eingänge werden auf Ausgänge gelegt - in diesem Beispiel sind es je 24. Die Belegung kann in Presets gespeichert werden. Je 8 der Ein- und Ausgänge repräsentieren die I/O's des Audio-Interfaces, alle restlichen Ein- und Ausgänge der Matrix führen zu den verwendeten Audio-Modulen. Weil Funktons-Werte zu jeder Adresse geschickt werden können, ist die Matrix ausschliesslich für Audio (im Gegensatz zur analogen Elektronik).
Auf dem Bild ist zu sehen, wie die Matrix über den anderen Modulen schwebt. Der Grund ist die von mir favorisierte "Ein-Fenster" Programmstruktur. Ausserdem gibt es einige Module, die beim Spielen nicht sichtbar sein müssen. Im Gegenteil: sie nicht zu sehen erleichtert jeden Blick in den Monitor und auch die grafische Belastung des Rechners wird deutlich reduziert. Unter diesen Modulen sind z.B. MIDI-Controller, Matrix, Adressbelegungen, Step-Presets etc.. Diese Module kann ich durch einfache Befehle aufrufen -> H=Help, C=Controller, Shift C= Adressierungen, M=Matrix, S=Save Presets etc. pp.. Die Sicht-/Unsichtbarkeit wird durch ein Script und dem thispatcher Object erzeugt (siehe Max-Help).
Audio-Modules
Viele komplexe Anwendungen lassen sich bei genauer Betrachtung in "Basis-Funktionen" unterteilen. Die häufigsten Bestandteile im Audiobereich sind immer gleich: Delay, Filter, RM, AM, LFO. Bei einem Echo (Delay) können beispielsweise Equalizer/Filter und Compressor mit in die Feedbackschleife gesetzt werden, um einen "guten" Sound zu behalten. Wenn ich ein komplettes Patch (nicht-modular) programmiere, werde ich minimale Einsatzmöglichkeiten bei maximalem Ressourcenverbrauch haben (auch die Arbeitszeit betreffend). Habe ich die einzelnen Bestandteile (Delay, EQ, Compressor), kann ich das gleiche Patch über eine Matrix schalten, kann aber auch ganz andere Verknüpfungen mit den verwendeten Prozessoren realisieren. Ausserdem verinnerliche ich das Aussehen der Module und muss mich nicht jedesmal an ein anderes Erscheinungsbild gewöhnen. Ein ganz entscheidender Schritt, um beim Musizieren nicht immer auf den Monitor zu schauen.
Um die Anzahl der Details auf dem Monitor zu reduzieren, haben manche Module verdeckte Preferences: beim Ringmodulator z.B. wird der Minimal- und Maximal-Ausgabewert (Hz) voreingestellt. Die Preferences und Controller-Adressierungen werden im Preset festgehalten.
Presets können über das Preset-Menu extern gespeichert werden. Die aktuellen Parameter-Werte werden am entsprechenden Controller eingetellt und gespeichert.
Für Software, die mit Kompositionen verknüpft ist, fallen die Presets in den Modulen weg und alle Daten werden dann zentral und scriptgesteuert gespeichert.
Function-Modules
Ein sehr wichtiges Modul ist - besonders bei mehrfacher Anwendung - ein komplexer LFO. LFO 1 und -2 können z.B. die Parameter von LFO3 steuern, etc. - Modulisten werden mir beipflichten: viele LFOs sind viel besser als wenige!
Auch bei diesem Modul lassen sich Presets, LFO Umfang und Minimal- Maximal-Ausdehnung durch Controller steuern / natürlich nach Bedarf auch alles andere.
Durch den Aufbau meines analogen Modular-Synthesizers werden Oszillatoren, Filter, RM, Overdrive etc. sich in Zukunft mit den analogen Modulen messen müssen.
Bestimmte Dinge, wie Sampling und alles was dazugehört (z.B. Granular-Synthese), Pitch-Shifting, FFT Funktionen etc. bleiben natürlich Aufgabe von Max/MSP, weil es digitale Anwendungen ohne analoges Pendant sind.
