Steuerung von Kemper und Cortex via Midi automatisieren

[Midian666]

Hallo Leute,

Ich habe eine Frage an die Community wie ich am besten das Cortex und den Kemper über Midi automatisiere. Wir spielen mit Laptop und dort wäre es möglich über USB in ein Midi Interface zu gehen, was dann die midi Signale an die Endgeräte verteilt.

Meine Frage ist nun, geht das so einfach da quad und kemper ja nicht dieselben midi CC hat. Und kann ich vom Laptop also über usb mehrere Spuren an das Interface senden und dann richtig verteilen, also midi1 cortex midi2 kemper.

Welche Geräte sind dafür nutzbar bzw. am besten geeignet?

 

[Andelaz]

Moin!
Wir benutzen ein MIDIface 4x4 und steuern damit 2 Kemper und 1 Axe FX. In unserer DAW werden die MIDI Spuren auf die entsprechenden Ausgänge geroutet und fertig.
Grüße ✌

 

[boisdelac]

Beide Geräte erhalten separate Midi-Kanäle zugewiesen werden. Für jedes der Geräte muss eine separate Midi-Befehls-Sequenz programmiert werden, die auf dem entsprechenden Kanal gesendet wird. Dann sollte das funktionieren. Probleme kann es mit Verzögerungen geben, wenn die Geräte unterschiedlich lange zum Umstellen der Soundparameter brauchen.

Beispiel ... beim GT1000 geht der Soundwechsel so schnell, den bemerkt man als Spieler garnicht. Auf CC# reagiert das GT1000 auch ohne Verzögerung. Beim Helix soll es da teilweise zu Verzögerungen und/oder Tonaussetzer gekommen sein. Wie das beim QC oder Kemper ist, kann ich aus Mangel an Gerät nicht sagen.

Was bei einer Midi-Steuerung problematisch ist, sind sich kontinuierlich ändernde CC#, weit das auf Grund der Datenmenge die Midi-Leitungen ( bei 5-Pol-Din-Midi) quasi verstopft. Beispiel hier wäre eine Delayzeit, die zyklisch mit einem Sinussignal modelliert werden soll, oder ein automatisiertes Wahwah.

Ich würde auch einmal probieren, ob der QC und der Kemper nicht in der Nähe des Laptops stehen können, und jeweils mit einen USB-Kabel mit dem Rechner verbunden werden können. Dann könnte man noch darüber nachdenken, auf Grund der Ausfallsicherheit beiden Geräten noch einen separaten Fußschalter zu spendieren, denn was machst Du, wenn sich die Midi-Steuerung aufhängt. Gibt es einen Panik-Button für den Midi-Reset?

 

[Midian666]

Über usb kann ich beide Geräte steuern, dass ist kein Problem mit den CC Kommandos. Den Fußschalter wollte ich aus der Gleichung rausnehmen, weil mir grundsätzlich irgendwelche Sound Engineers ständig die Midi Kabel zum Fußschalter zerstören durch Unachtsamkeit beim laufen.

 

[Navar]

Was bei einer Midi-Steuerung problematisch ist, sind sich kontinuierlich ändernde CC#, weit das auf Grund der Datenmenge die Midi-Leitungen ( bei 5-Pol-Din-Midi) quasi verstopft. Beispiel hier wäre eine Delayzeit, die zyklisch mit einem Sinussignal modelliert werden soll, oder ein automatisiertes Wahwah.

Weißt du, wie hochfrequent das sein darf? Ich hab das mal mit dem Whammy DT gemacht und das funktionierte gut soweit.

Über usb kann ich beide Geräte steuern, dass ist kein Problem mit den CC Kommandos. Den Fußschalter wollte ich aus der Gleichung rausnehmen, weil mir grundsätzlich irgendwelche Sound Engineers ständig die Midi Kabel zum Fußschalter zerstören durch Unachtsamkeit beim laufen.

Hm, also das ist mir ehrlich gesagt echt noch nicht passiert und wir legen Cat Kabel für den Kemper Remote und das Helix Remote. Wir haben uns irgendwann mal eine einfache Kabelmatte eingepackt, die wir dann über den Hauptlaufweg drüber werfen. Cat Kabel neigen ja auch gerne mal zu Stolperschlaufen.

Aktuell sind meine besten Erfahrungen was das angeht, mit einer direkten USB Verbindung zum Kemper (ein QC hab ich leider, leider nicht), mehrere MIDI Interfaces in einer DAW getrennt anzusteuern ist ja an sich kein Problem und dann kann man auch auf eine mögliche Schaltverzögerung getrennt eingehen. Beim Kemper kann ich noch den Tipp geben, nicht nebenbei den Rig Manager laufen zu lassen, der kann eine Latenz mit reinbringen beim Umschalten.

 

[boisdelac]

Die Übertragungsdauer eines Midi-PC# ist rund 64us, der eines CC# liegt so bei 100us über eine 5-Pol-Midi-Schnittstelle. Das ist der eine Punkt. Der andere Punkt ist, wie lange das angesprochene Gerät braucht, um den jeweiligen Parameter zu ändern. Und wieviel Änderungen gesendet werden können, ohne dass sich das Gerät aufhängt, das die Daten empfängt.

Ich hab da mal mit einem Arduino ein Midi-Expression-Pedal gebastelt, da hat dann das Gerät, das die CC# empfangen hat, nicht mehr kontinuierlich, sondern nur noch mit Sprüngen auf die Änderung reagiert.

 

[boisdelac]

Muss mich korrigieren... die Übertragung eines Midi-PC# dauert rund 512us und der CC# dauert rund 768us. I am so sorry

 

[HaraldS]

Muss mich korrigieren... die Übertragung eines Midi-PC# dauert rund 512us und der CC# dauert rund 768us. I am so sorry

Start- und Stoppbit nicht vergessen...eine komplette CC-Message aus 3 Byte besteht damit aus 30 bit und die dauern beim MIDI 1.0-Standard von 31250 Bit/s dann 960 µs. Aber wenn da dauernd der gleiche CC gesendet wird, kann und sollte natürlich der Running Status verwendet werden, was die Datenmenge auf 20 Bit und deren Übetragungsdauer auf 640 µs reduziert.

 

[boisdelac]

Ja hast recht, das Start- und Stop-Bit hab ich nicht mitgerechnet. Und den Running Status hab ich unterschlagen. Den zu implementieren, überlasse ich den Geräten und/oder Sequenzern, weil das schwierig ist, eine entsprechende Befehlssequnz von Hand einzutippen.

 

[Mr. Pickles]

übers MIDI Kabel kannst du 16 Kanäle gleichzeitig übertragen.

D.H.
1. z.B. MIDI Kanal 1 für die #CCs fürs Quad Cortex und MIDI Kanal 2 für die #CCs für den Kemper
2. Cortex auf MIDI through schalten
3. Verkabelung dann: Interface MIDI Out => Quad Cortex MIDI in => Quad Cortex MIDI Out => Kemper

sollte das Funktionieren ist alles bestens, falls nicht kannst du die jeweiligen MIDI spuren von der Latenz in deiner DAW korrigieren, also händisch leicht nach vorne schieben.

falls alle Stricke Reißen kannst natürlich nen Splitter oder das Midiface ins Setup einbinden

 

[boisdelac]

Ob jetzt ein Gerät 100ms früher oder später auf ein CC# oder PC# reagiert, ist bei unserem derzeitigen Wissensstand ganz egal. Wir wissen ja nicht genau, was der TE alles steuern will.

PC# senden, Midi-Time-Clock senden wird das meiste sein. CC# werden wohl nicht viele kommen, weil die Parameter eigentlich in den Patches der Einzelgeräten hinterlegt sind. Wahwah automatisieren würde ich garnicht, ein Touch-Wah verwenden oder über Midi-Timeclock steuern aber nicht über CC#. Dann bleiben für CC# eigentlich nur die Lautstärke übrig, aber das würde ich dann nicht an den Einzelgeräten, sondern am Mixer kontrollieren/steuern lassen..

 

[Mr. Pickles]

also 100ms wären nach meinem Bauchgefühl schon störend, wenn man bedenkt, dass man bei Latenzen zum Aufnehmen schaut deutlich unter 10ms zu bleiben, kann aber auch täuschen, Latenzen vom MIDI gemessen habe ich da nicht, solange was funktioniert ist mir der rest immer relativ wurst Ich habe mein Setup auch komplett automatisiert (Sampler MIDI Out auf Quad Cortex MIDI in) und keine Probleme wegen Latenz beim Umschalten.

tendenziell hatte ich das eher darauf bezogen um Latenzen die beim MIDI through vom Cortex entstehen könnten bezogen, da ich mir vorstellen könnte dass durch das Daisy-Chaining beider Geräte störende Latenzen entstehen könnten, müsste man halt ausprobieren. wie es mit Daisychaining des Midi Signals über das Cortex aussieht weiß ich leider nicht, ich weiß nur dass es geht.
Das Cortex wird bei uns für beide Gitarren genutzt, bassisten haben wir nicht, kommt vom Sampler, daher keine weiteren Endgeräte in der MIDI-Kette.

aber im Grunde würde ich das zuerst mit Daisychaining probieren, da hier lediglich ein MIDI Kabel vom Cortex zum Kemper oder falls technisch möglich wahlweise auch umgekehrt einfach günstiger ist als zusätzliche Geräte. und so oder so zwei MIDI Kabel notwendig wären.

 

[boisdelac]

USB-Midi ist ja auch noch vorhanden und funktioniert ja wohl auch. Da ist das Daisy Chaining sowieso nicht möglich, und USB-Midi ist sowieso schneller

 

[Mr. Pickles]

Also bevor wir aneinander vorbeireden, oder ich voll am schlauch stehe:

ich habs so verstanden, das Samples ohnehin vom Laptop laufen und jetzt halt eine Automation via MIDI realisiert werden soll.

Eingebunden werden soll der Kemper und das Cortex.

Wie soll das dann als MIDI via usb laufen? Da müssten ja Kemper und Cortex gleichzeitig als MIDI Interface zusätzlich zum vorhandenen audioInterface installiert und in der DAW konfiguriert sein, oder gibts da Möglichkeiten die ich einfach nicht kenne?

 

[HaraldS]

also 100ms wären nach meinem Bauchgefühl schon störend, wenn man bedenkt, dass man bei Latenzen zum Aufnehmen schaut deutlich unter 10ms zu bleiben, kann aber auch täuschen, Latenzen vom MIDI gemessen habe ich da nicht, solange was funktioniert ist mir der rest immer relativ wurst

Ja, 100ms wären ja 0.1 Sekunden, das wäre schon störend. Die 100ms hat boisdelac (so habe ich ihn verstanden) aber nur als Beispiel gebracht. In deinem konkreten Fall ist alles viel schneller: von einem CC im Running Status bis zum nächsten vergehen 640 µs, und das sind 0.00064 Sekunden (hiermit gerechnet).

Die MIDI-Geschwindigkeit von 31250 Bit/s ist halt das, was 1983 sinnvoll und möglich war. Aber bei ehrlicher Betrachtung sind die Ansprüche an rhythmische Genauigkeit seitdem auch nicht gewachsen. Damals wie heute muss eine musikalische "1" eben zusammen sein bzw. bei serieller Datenübertragung wie bei MIDI nur so weit auseinander, dass das menschliche Ohr mehrere Töne als zeitgleich empfindet. Das gilt in gleichem Maße für Controllerdaten.

In der Summe würde ich mir also keine Gedanken darüber machen, dass einzelne Controller über MIDI zu langsam übertragen werden. Wenn es Massen von Daten sind, kann es in der Tat problematisch werden, aber dann liegt das Problem vermutlich schon früher in der Signalkette.

 

[Mr. Pickles]

Ok, hatte ich nicht als Beispiel aufgefasst, mein Fehler

 

[boisdelac]

Die 100ms sind nur ein Beispiel.

Mann muss um alles genau zeitlich planen zu können, auch die eigentlichen Reaktionszeiten der angesteuerten Geräte mit einbeziehen. z.B. Ich brauche beim Song Nr. 1 genau auf Songposition 2:30,375 den Sound xxx vom Kemper. Dazu schicke an den Kemper einen PC# xxx. Wie lange braucht der Kemper um vom aktuellen Patch auf das Patch xxx zu schalten, um dann mit Patch xxx spielbar zu sein. Da muss man dann den PC# schon diese gemessene Zeit vorher schicken, damit auf 2:30,375 der neue Sound erklingt.

Dazu kommt noch ... Was macht der Kemper, nachdem er den PC# empfangen hat, bis er wieder komplett spielbar ist. Ist der Kemper in dieser Zeit stumm geschaltet, spielt er mit altem Sound weiter oder blendet er stufenlos um.

Den Kemper habe ich hier nur beispielhaft genannt. Es können dafür auch andere Effektmultis eingesetzt werden, wie z.B. der QC, Helix, GT1000.....

 

[Mr. Pickles]

@boisdelac
Das ist aber aus meiner sicht Praxisfern.

Ich habe für meine Automation in der DAW immer exakt auf dem Punkt wo geschaltet werden soll meine #CC zum schalten gelegt, keinen Offset gesetzt und das Ganze funktioniert einwandfrei.

Ich könnte jetzt natürlich nochmal irgendwie nen offset mit 1ms oder was auch immer die MIDIspur nach vorne ziehen, aber außer dass ich damit ein „Problem“ behebe das man in der Praxis nicht realisiert und damit wiederum kein Problem ist sehe ich da nichts.

D.h. Am sinnvollsten aus meiner sicht iat Midispur Programmieren und erst wenn bei den testläufen auf Probe der Versatz zu groß ist die jeweilige Spur um benötigten offset nach vorne ziehen.

 

[boisdelac]

Das wäre mir ja auch gerade egal, weil mein GT1000 nahezu auf den Punkt schaltet und dann auch noch Spillover hat. Aber irgendjemand hier hat das Korinthenk...n angefangen. Und wenn schon das, dann richtig.