Grundlegendes

Der Hardware Lemur von Jazzmutant (2005-2011) war noch ein resistiver Touchscreen, d.h. mit einer Folie über dem eigentlichen Screen, deren Rasterung man gut sah und die auch dazu neigte kleine Wellen zu bilden. Sowas macht einen natürlich nervös, wenn man gerade soviel Geld für das Gerät ausgegeben hat, aber meine Welle war relativ klein und hat nie in der Performance gestört. Der Hardware Lemur wurde mittels Ethernet mit dem Computer verbunden auf dem 2 Programme installiert wurden: Der Lemurdaemon, der die Infos des Lemuren in OSC- oder MIDI- Daten wandelte, und der Editor, mit dem sich die eigentlichen Oberflächen erstellen, abspeichern und verwalten ließen. Hierbei kann der Lemur mehrere OSC- und MIDI- Ziele verwalten, mindestens 8, wobei man normalerweise kaum mehr als 2 braucht. Eigene MIDI-Ausgänge hat der Hardware Lemur aber nicht, der Kontakt zu Hardware erfolgt ausschließlich über ein optional am Rechner angeschlossenes MIDI-Interface.

Bild „Hardware-Lemur“: Der Lemur Touchscreen Controller als Hardware wie er von der Firma Jazzmutant von 2005-2011 angeboten wurde inkl. Software-CD, Ethernet Kabel und Original-Karton. Mein Lemur hat die Seriennummer 666 (kein Joke, habe schon überlegt ob das ein Zeichen war). Insgesamt wurden nur ca. 2500 Hardware-Lemuren gebaut – keine Massenware also, was auch am Preis von 2500,- Euro gelegen haben kann.

Das Gleiche gilt ungefähr auch für die Lemur-App für iOS und Android von der Firma Liine. Nur fällt hier die Ethernetverbindung weg. Dafür koppelt man sich via WLAN (klappt bei mir einwandfrei), lokalem Netzwerk oder USB-Kabel. Auch ein direkt an das iPad gehängter MIDI-Adapter geht Bestens. In diesem Fall braucht man dann auch keinen Lemurdaemon, sollte das Ganze aber an einen Rechner zwecks MIDI-Datenverteilung gehen (und von dort aus auch gerne zu Hardware), so ist weiterhin der Daemon Pflicht. Ebenso braucht man den Editor auf einem Computer, denn der In-App Editor den Liine für die iOS Version anbietet ist zu sehr eingeschränkt, um damit ernsthaft arbeiten zu können.

Um eine bidirektionale MIDI-Kommunikation herzustellen braucht man nun noch virtuelle Midikabel. Die sind beim Mac als IAC Ports gleich vorhanden, beim PC ist man (wie so oft) wieder mal auf 3rd-Party-Software angewiesen. Damals verwendete ich MidiYoke. Mittlerweile verwende ich Loopbe (http://nerds.de/en/loopbe30.html) – die Version mit 30 Midiports kostet zwar etwas Geld (17 Euro – oder kostenlose Demoversion), ist aber ne super stabile Software eines kleinen deutschen Entwicklers. Macht man die (virtuelle) Verkabelung richtig, so werden nicht nur Befehlsdaten vom Lemur an die DAW (oder Hardware) übertragen, sondern auch umgekehrt: Änderungen, die an der DAW/Hardware vorgenommen werden, werden auch auf der Lemuroberfläche angezeigt. Das ist praktisch, da man im Workflow ja vielleicht auch mal was mit der Maus ändert, oder z.B. den Filter zusätzlich auf einem Hardware-Drehregler hat und somit die Lemuroberfläche immer auf dem aktuellen Stand ist.

Bild “Lemur Editor MultiSlider”: Der Editor versprüht irgendwie noch den Charme der 90er Jahre. Aus der Palette (oben rechts) werden Objekte in den Anzeigebereich in der Mitte gezogen. Im Projektbereich (unten rechts) sieht man alle Interfaces, Objekte, Variablen und Scripte. Im Mapping Bereich wird der Output festgelegt. Im Object Bereich darunter die Eigenschaften der Objekte wie Farbe und Größe.

Die Kontroll-Oberfläche gestaltet man mit dem Editor. Hierbei kann der Lemur mehrere Seiten (“Interfaces”) darstellen, zwischen denen man hin und her schalten kann. Innerhalb eines Interfaces bietet es sich an, mit Containern zu arbeiten, in denen dann verschiedene Kontrollelemente drin sind. Über die Arbeit mit Containern lassen sich die einzelnen Gruppen besser verwalten und kombinieren, notwendig sind sie nicht. Die Erstellung eines Interfaces erinnert mich ein wenig an Powerpoint – man hat halt verschiedene Elemente und zieht sie da hin, wo man sie haben will, passt Größe, Form und Farbe an.

Als Kontrollelemente gibt es so ziemlich alles was das Herz begehrt:

• Container – zum Gruppieren, senden kein Midi, durchsichtig oder mit Farbumrandung
• Custom Button – Button (toggle/latch) mit Symbolen oder Text
• Fader
• Knob – Drehregler, optional endlos
• LEDs – als programmierbare Anzeige, keine Eingabeform
• Menu – drop down menu mit wählbarer Anzahl an Optionen und deren Benennung
• Monitor – zeigt Werte als Zahl an, Auflösung wählbar
• Multiball – xy Controller mit bestimmbarer Anzahl an Bällen/Touchpoints
• MultiSlider – bis zu 32 kleine Fader
• Pads – bis zu 16×16, haben optionale ADSR Hüllkurve
• Range – 2 seitiger Fader ohne feste Mitte
• Breakpoint – grafische ADSR Umgebung
• Ringarena – xy Controller mit frei wählbaren Mittelpunkt
• Switches – bis zu 16×16, on/off
• Signaloscope – zeigt z.B. Kontrolldaten über die Zeit oder LFOs
• SurfaceLCD –
• Lagedaten des iPads (x,y,z)
• Canvas (neu seit v5)
  • Mit Canvas lässt sich eigentlich jedes Objekt in jeglicher Form bauen. Ich selbst habe mich da nicht mehr rein vertieft, es gibt aber in der User Area Tutorials und verschiedene Beispiele, jemand hat sogar “Flappy Bird” damit nachgebaut.
• Sequencerobjekte (neu seit v5)
  • Zwar war es schon immer möglich, sich Sequencer auch auf dem Lemur alleine zu bauen, nur waren diese nicht immer tight, da sie von der Framerate des Lemurs abhingen, die wiederum von der Arbeitslast des Systems abhängt. Mit den neuen Sequencerobjekten wird nun sehr genau im Takt getriggert. Es gibt Switches oder MultiSlider (für CC oder Notenwerte)

Bild “Palette_shaded” zeigt die meisten Kontrollelemente des Lemur in der Skin “shaded”. Es gibt auch noch flat, classic und pixel. Skins ändern die Erscheinungsform der Elemente.

Die einzelnen Elemente haben dann Eigenschaften (“Properties”), die Namen, Position, Größe, Farbe, Ausrichtung (hier geht nur horizontal und vertikal – schräge Fader kann der Lemur also nicht) und weitere Eigenschaften (wie bipolar) enthalten, sowie in einem zweiten Rider das Verhalten (“Behavior”, paint, capture) und die weiter unten beschriebenen Physics mit den dazugehörigen Parametern je nach Kontrollelement.

Es sei hier erwähnt, dass es für die Kontrollelemente allgemein 4 verschiedene Skins gibt, die sich auf Projektebene einstellen lässt und die Erscheinungsform aller Elemente deutlich verändert (classic, flat, pixel, shaded… ist Geschmackssache).

Unter “Mapping” (im Bild oben links) kann man die OSC und MIDI Zuordnung einstellen:

• MIDI-Target (meist stelle ich als “Parent” hier Traget 0 ein, da dies mein Hauptausgang ist und der dann automatisch bei neuen Objekten übernommen wird),
• welche Variable sendet (meist by default x, bei manchen Controllern aber auch y, bei Bedarf auch z – was Berührung ja/nein ist – oder andere Variablen),
• was für eine Message (meist Control Change),
• welche Controller Nummer,
• welche Values (nur falls man doch mal was anderes senden will, z.B. Variablen…),
• wann getriggert wird (das kleine Kästchen hinten steht hier auf “any”, kann aber auch eingeschränkt werden, z.B. nur wenn die Werte von 0 auf 1 gehen),
• Man kann über Scale den Wertebereich einschränken
• zum Schluss noch den MIDI-Kanal

OK, das klingt jetzt doch recht umfangreich. Im Normalfall stellt man meist aber nur CC, die Controller Nummer und den Kanal ein, der Rest bleibt bei den Grundeinstellungen.

Und natürlich gibt es neben CC auch alle anderen möglichen MIDI-Befehle zur Auswahl, die ich zwar eher selten genutzt habe, aber die Möglichkeiten des Lemurs zeigen:

• Note Off
• Note On
• Key Pressure
• Control Change
• Program Change
• Channel Pressure
• Pitch Bend
• System Exclusive
• Song Position
• Song Select
• Bus Select
• Tune Request
• Timing Tick
• Start Song
• Continue Song
• Stop Song
• Active Sensing
• System Reset

Neben den Kontrollobjekten kann man auch Variablen definieren, deren Output dann z.B. MIDI sendet. Oder man nutzt Custom-MIDI, dessen Input dann Variablen oder Kontrollobjekte sein können. Das hat Vorteile, wenn man z.B. den MIDI-Kanal dynamisch einstellen will. Das könnte man aber auch über Multiline-Scripte erledigen (Setattribute), mit denen man aber auch noch viel mehr in die Tiefe gehen kann.

Eine Besonderheit des Lemurs ist, dass er auch eine “Physics-Engine” besitzt. Dieses simuliert physisches Verhalten bei den Kontrollelementen, so z.B. dass der Fader noch eine Zeit lang weiterläuft, wenn man den Finger loslässt. Oder man kann bei einen XY Controller den Punkt anstoßen und er läuft dann dauerhaft weiter, prallt an den Wänden des XY-Feldes ab wie ein Ping-Pong Ball und erzeugt so auch nach dem Loslassen noch Controller-Daten. Ich persönlich habe die “Physics” eher selten benutzt, sie vermitteln aber schon (bei vorsichtigem Einsatz) ein irgendwie realistischeres Spielgefühl.

Eine Sache, weswegen Touchscreens als Controller häufig abgelehnt werden, ist das nicht vorhandene haptische Feedback und damit einhergehend die Befürchtung vom Kontrollelement abzurutschen und plötzlich was ganz anderes zu kontrollieren als geplant, sofern man nicht ständig auf den Screen schaut. Das ist beim Lemur mit einer weiteren Checkbox bei den Eigenschaften der Kontrollelemente durch “Capture” bedacht: Ist dies z.B. bei einem Fader angeklickt, bleibt die Kontrolleingabe bei diesem Fader, egal ob man über das ganze Interface rutscht oder gar zwischen den Interfaces wechselt [sic!] – so lange, bis der Finger, der ursprünglich den Fader berührte, wieder vom Touchscreen abhebt. Dabei haben die anderen Finger (Multitouch…) die Möglichkeit, neue zusätzliche Elemente aufzugreifen. Dieses Feature kommt bei meinen Interfaces oft zum Einsatz, gerade wenn es kleine Elemente sind. Extrem gut auch bei “Knobs”, den runden Encodern: Einmal beim aktuellen Wert angesetzt, kann ich den Finger nach außen ziehen und so in einem viel größeren Kreis die Werte viel genauer setzen. Das Capture-feature ist meines Erachtens total unterschätzt und macht im Workflow der Interaktion viel mehr als die Physics aus.