DYI: MIDI Fußleiste selber bauen?!

Andy

Well-known member
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Okt 21, 2012
Beiträge
8.738
Hi,

ich schreib mal was das AxeFx so ausspuckt:

SYSX: F0 00 01 74 03 64 64 05 03 F7

Bitte nicht danach suchen, ich will die Arbeit nicht abwälzen. Nur wenn einer sofort weiß, was das sein soll.

Ich hätte gedacht, ich hab Zeit. Leider aktuell doch nicht.

Gruß

Andy
 

axefx

Administrator
Teammitglied
Axe-Fest 2019 Teilnehmer
Mitglied seit
Sep 28, 2012
Beiträge
5.867
Ich habe da aktuell auch keine Ahnung und kann nur auf Wiki`s Axe-Fx Sysex verweisen ;( sorry.
 

Andy

Well-known member
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Okt 21, 2012
Beiträge
8.738
Kein Problem, ich schau am Wochenende nach.

Nur, wenn man beim ATMEGA den RX beim UART aktiviert, wird das ggf. für ne gewisse Systemlast
sorgen. :)

Hab mein Board übrigends bekommen. :) Komm aber vorm Wochenende zu nix :(
 
P

Pacosipulami

Guest
Kein Problem, ich schau am Wochenende nach.

Nur, wenn man beim ATMEGA den RX beim UART aktiviert, wird das ggf. für ne gewisse Systemlast
sorgen. :)

Hab mein Board übrigends bekommen. :) Komm aber vorm Wochenende zu nix :(
Das kenne ich - hab auch alles, bloss keine Zeit für mich... :cry:
 

Andy

Well-known member
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Okt 21, 2012
Beiträge
8.738

Andy

Well-known member
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Okt 21, 2012
Beiträge
8.738
So, das Senden von dem merkwürdigen Frame war, nachdem ich alles nochmal neu gestartet hatte, vorbei.

Hab jetzt mal die IDE zum Board installiert und mal ein Beispiel kompiliert.
Mist, die Jungs haben mir kein Netzteil zum Board mitgeliefert. Download war dann leider nix.


Hab ihr eigentlich nen ISP (also den Programmer?) Müsst ich mal in der Arbeit schaun, könnt sein, dass wir da was haben.
Wobei wir eher PIC einsetzen, wenn es was Kleines sein soll.

Ich hab jetzt mit dem Midi-OX mal ein wenig mit Kommandos experimentiert. PC, Scenes umschalten ging schon mal.

Könnt ihr mir "über die Strasse helfen?" :) Wo find ich ne Info, wie ich einen einzelnen Effekt in nem Preset Ein/Aus Schalten kann?

Muss mich dann erst mal hinsetzen und überlegen, WAS ich eigentlich will :) Sprich, was das Board letztendlich alles können soll.
 

axefx

Administrator
Teammitglied
Axe-Fest 2019 Teilnehmer
Mitglied seit
Sep 28, 2012
Beiträge
5.867
Vorab: Ich konzentriere mich in meinen Ausführungen auf den aktuellen Stand des Arduino Sketches von Basti!:
https://github.com/oson/midi_board_ONE
Video: http://www.youtube.com/watch?v=5v_LOX48E0Q&list=PLT2sYJRe7JGzRZjYknhBgOrFEbOZDuBH5

Teil1:
AXE-FX II

Nochmal zur Synchronisation von LED-Statusanzeige und aktuellem Schaltzustand des zu steuernden Gerätes (hier: Axe-Fx II):

Derzeit haben wir 4 „Klassen“ respektive „Gruppen“ von Schaltern, die in sich konsistent Synchron zum steuernden Gerät agieren:

Presets / Scenes / Amps / Stompoxes:
Schalte ich ein Preset um, leuchet ausschließlich die LED des geschalteten Presets (der Gruppe Presets)
Schalte ich eine Scene um, leuchet ausschließlich die LED der geschalteten Scene (der Gruppe Scenes).
Schalte ich einen Amp um, leuchet ausschließlich die LED des geschalteten Amps (der Gruppe Amps).
Schalte ich ein "Bodentreter" ein/aus, leuchtet dessen korrespendierende LED entsprechend (oder eben nicht).

Nun ist es natürlich so, dass ein Umschalten von Presets bzw. Scenes Auswirkungen hat, auf den Schaltzustand einzelner FX Blöcke. Genau an diesem Punkt verliert sich jegliche Synchronität. Es bestehen anders gesagt keine korrelierenden Abhängigkeiten zwischen unterschiedlichen „Gruppen“ von LEDs. Die Frage ist also, wie kann dies sichergestellt werden? Dazu gibt es generell zwei Ansätze:

Entweder das Steuergerät (MIDI Footcontroller) steuert exklusiv, sprich gibt alle relevanten Schaltanweisungen an das zu steuernde Gerät aus und kann diese deshalb auch synchron (LED-Status) wieder auswerfen. In diesem Fall wäre das Steuergerät der MASTER, das angesteuerte Gerät der SLAVE.

Oder das gesteuerte Gerät übergibt seine aktuellen Schaltzustände an das Steuergerät, welches diese dann wiederum mit den LEDs synchron anzeigen kann. In diesem Fall wäre das Steuergerät der SLAVE, das angesteuerte Gerät der MASTER.

Das MFC-101 beispielsweise kennt beide Paradigmen: Im “Axe-Fx Mode = II“ agiert es als SLAVE, im „Axe-Fx Mode = NONE“ agiert es als MASTER.

In Anbetracht der Tatsache, dass die MFC-101 im „Axe-Fx Mode = II“ auch bei Preset- und/oder Scene-Änderungen, ausgeführt am Axe-Fx II selber trotzdem immer wieder synchron korrekte Stati anzeigt bedeutet im Umkehrschluss, dass das Axe-Fx II entweder bei Schaltvorgängen alle relevanten Änderungen von sich aus am MIDI Out auswirft oder zumindest den Befehl an die MFC auswirft, das Änderungen vorliegen und die MFC daraufhin diese Änderungen per Befehlssatz zur Übermittlung anfordert.
Des Weiteren sind wir uns bewusst, dass im „Scene Revert = OFF“ Mode, Schaltänderungen innerhalb einer Scene bei Wiederaufruf gemerkt sind.

Bei näherer Betrachtung dieses Umstands wird deutlich, dass eine Synchronität auch bei Scene- und PC-Befehlen zwischen den LED-Anzeigen des MIDI Footcontrollers und des Axe-Fx II nur genau dann vollständig garantiert sein kann, wenn das Axe-FX II als MASTER agiert. Anders ausgedrückt: Wenn der MIDI Footcontroller eingehende Sysex-Daten, die das Axe-Fx II an den Controller sendet auswertet und für die LED-Anzeigen korrekt interpretiert.

Wir müssten also mehr darüber erfahren, wie wann welche Daten über Schaltzustände des Axe-Fx II am MIDI Out des Axe-Fx II zur Verfügung gestellt werden.

Bedenkt man ferner, dass ein Program Change im Axe-Fx II ebenfalls zuerst einem MIDI-Mapping Prozess durchlaufen KANN, stellt sich die Frage, ob es überhaupt noch einen Sinn macht, dass der MIDI Footcontroller selber noch einen Zusammenhang zwischen Schaltvorgang und LED-Anzeige herstellt.

Beispiel 1:
Ich schalte von Scene1 (Scene 1 LED leuchtet) auf Scene2. Der Footcontroller interpretiert diesen Vorgang auch für die LEDs: LED Scene1 geht aus, LED Scene2 geht an. Diese Interpretation könnte durch eine Interpretation eingehender Sysex Signale des Axe-Fx II ersetzt werden.

Beispiel 2:
Schalter 24 des Footcontrollers wird betätigt. Für Schalter 24 werden folgende MIDI messages ausgesendet: PC 004 und CC34 Vaue2 (Scene3).
Das Axe-Fx II schaltet dementsprechend auf Programm 003 (MIDI OFFSET 0!) und SCENE3. Dies bewirkt eine Übermittlung aller relevanten Daten vom Axe-Fx II an den Controller, der diese entsprechend interpretiert und als LED on/off auswirft:

  • Welche LED der Preset-Gruppe muss leuchten?!
  • Welche LED der Scenes-Gruppe muss leuchten?!
  • Welche LED der Amp-Gruppe muss leuchten?!
  • Welche LEDs der Stompboxen müssen leuchten?!
Kurzum: Eine Schalterbetätigung am MIDI Footcontroller wirkt sich überhaupt nicht mehr auf irgendwelche LED-Anzeigen aus. Es wird nur der entsprechende MIDI Befehl gesendet. Nur eingehende Sysex-Signale an einem MIDI IN des Controllers würden für die LED-Anzeigen interpretiert. Dabei gilt weiterhin, dass die Interpretationsgrundlage im Footcontroller hinterlegt sein muss: Welche LED Lampen schliessen das leuchten anderer aus (Gruppenscenario), welche LED korrespondiert auf welchem CC (effekt), etc.

Für Scenes und PCs kann ich mir dabei vorstellen, dass das genau so abläuft. Beim schalten einzelner Stompboxes (bzw. Amps) bin ich mir weniger sicher, ob auch hier eine Rückantwort des Axe-Fx II geliefert wird, denn: Schalte ich am Axe-Fx II selber einen Effekt an oder aus, wird dies (wenn ich nicht irre) eben NICHT von der MFC interpretiert, oder?! (Habe sie gerade nicht zur Hand). Scenenwechsel und Program Change Wechsel allerdings eben schon!
 
Zuletzt bearbeitet:

Andy

Well-known member
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Okt 21, 2012
Beiträge
8.738
Musste deine Email jetzt in der Tat zwei mal durchlesen ;) Mir ist die Funktionsweise und der -umfang des MFC noch nicht so ganz bewusst.

Jetzt versteh ich auch ein wenig die Funktionsweise des MFC im AxeFx - Modus.
War mir bis dato nicht so ganz klar, zumal ich kein MFC habe.

So gesehen ist das - meiner Einschätzung nach - die einzige vernünftige Umsetzung, wenn man nicht nur Presets schalten will.
Also den Status usw. vom AxeFx auszulesen und demnach die LEDs zu schalten.
Ansonsten bräuchte man eine doppelte Datenhaltung, einmal im AxeFx und einmal im MFC.

Wobei, man müsste dann aber auch die "Aktion" eines Schalters damit synchronisieren. Wenn ich bspw. in Scene 1 den Drive 1 deaktiviert habe, dann
bedeutet ein Tritt auf den entsprechenden Schalter ja, mach den Drive 1 EIN. Hab ich den Drive hingegen aktiviert (Default) dann soll er durch den Tastendruck
ja deaktiviert werden.

Wie "zwingt" man das AxeFx eigentlich dazu, diese Daten zu schicken? Kontinuierlich wäre meiner Meinung nach nicht der richtige Weg. Eher nach einer Aktion.
Bspw. bei nem Presetwechsel, einem Scenewechsel usw....

Gruß

Andy
 
Zuletzt bearbeitet:

axefx

Administrator
Teammitglied
Axe-Fest 2019 Teilnehmer
Mitglied seit
Sep 28, 2012
Beiträge
5.867
Teil2: Generische MIDI-Gerätschaften allgemein.
Nochmal zur Synchronisation von LED-Statusanzeige und aktuellem Schaltzustand des zu steuernden Gerätes (hier: Allgemeine Midi Geräte wie Multieffekte, Switcher, Looper, Midifizierte Amps, etc.):

In diesem zweiten Teil konzentriere ich mich auf die Synchronität, wenn vom zu steuernden Gerät (oder geräten) eben KEINE Rückantwort gegeben wird, sprich: keine zu interpretierende MIDI Daten an den MIDI Controller zurückgesendet werden.

Wenn dies der Fall ist, so MUSS der MIDI Controller in die Funktion des MASTERS rücken. Die unangenehme Folge davon ist, dass alle ausgeworfenen MIDI Befehle erstens im Steuergerät hinterlegt sein müssen und zweitens auch die korrelierenden LED-Anzeigen vollständig durch das Steuergerät gedeckt werden müssen.

Das auch in diesem Scenario die „Gruppen“ weiterhin Sinn machen, will ich vielleicht als erstes verdeutlichen:
Stellen wir uns vor, wir wollen einen MIDIfizierten Amp, ein Multieffekt und einen analogen Looper/Switcher steuern. Auch hier behält die Idee von „Gruppen“ seinen Sinn, die folgende Ansichten durch ihre LED-Korrespondenz sichern:


  • Welcher Amp (-kanal) ist aktiv, welche nicht? Nur dieser leuchtet
  • Welche Einzel-Effekte sind an bzw. aus? Nur diese leuchten
  • Welche Effekt-/Ampgruppe ist aktiv? Diese Scene leuchtet (Clean/Solo/Lead/Crunch/Rythm,etc.)
Stellt man sich dabei vor, dass vormals die Gruppe „Presets“ im Axe-Fx jeweils ein eigenes Preset geschaltet hat, was man auch als „RIG“ bezeichnen könnte, so würde nun diese Gruppe wahrscheinlich in der Tat nicht mehr gebraucht werden. In der Regel hat man ja nur noch ein (analoges) gleichzeitig in Betrieb. Die Gruppe „Scenes“ dagegen kann auch weiterhin Sinn machen, beispielsweise, wenn eine „Scene“ mehrere Schaltvorgänge (dieser Amp, dieses Preset eines Multieffektes, jene Looper /Switcher an/aus Befehle diverser Bodentreter) abbilden soll.

Um nun weiterhin Synchronität von LEDs und aktuellem Schaltstatus der gesteuerten Gerätschaften zu garantieren, müssten „Gruppenabhängigkeiten“ geschaffen werden:

Beispiel1: Bisher gibt es diese nicht:
Ich schalte Amp2 ein und Stompbox 2,4,und 6 ein (LEDs leuchten entsprechend). Nun schalte ich auf SCENE „Lead“: Diese leuchtet nun auch auf. In dieser Scene sind die direkten MIDI Befehle äquivalenten zu Amp3 ein, Stompbox 2,4 und 6 AUS, 1,2,5 AN hinterlegt. Die Geräte würden nun genau diesen Schaltbefehl wiedergeben, soweit so gut, allerdings leuchten die LEDs nicht mehr Synchron: Ich höre Amp3, Amp2 leuchtet aber. Ich höre Stomp 1,3 und 5, diese leuchten aber nicht, sondern immer noch Stomp 2,4 und 6.

Anstatt also einem Schaltbutton LEAD die gewünschte MIDI Befehle direkt zu hinterlegen, die am MIDI Out des Controllers ausgesendet werden, müsste man eigentlich genau die Befehle hinterlegen, die einem „manuellen“ Einstellen der gewünschten Scene „Lead“ entspräche. Das manuelle Einstellen würde bedeuten:
Ich klicke mit dem Fuss auf Button AMP3 (dieser schickt dann seinen MIDI Befehl raus, gleichermassen leuchtet die LED und die LED am AMP2 erlischt, da beide innerhalb einer Gruppe definiert sind). Desweiteren klicke ich auf Stomp 2,4 und 6 (die nun ihren OFF Befehl senden, die LEDs erlischen) und klicke desweiteren auf Stomp 1,3 und 5 (die nun ihren ON Befehl senden und deren LEDs nun leuchten.)

Beispiel2:
Um also die Synchronität der LEDs der „Einzeleffekte“ zu gewährleisten beim Aufrufen einer SCENE, die eben MIDI Befehle dieser Effekte betrifft, müsste ich also der Scene nicht die direkten MIDI Befehle hinterlegen, sondern den Status des betreffenden Schalters:
Schalter AMP3 -> sei AN
Schalter Stomp 2,4 und 6 -> sei AUS
Schalter 1,3 un 5 -> sei AN.

Anders gesagt: Eine Scene sendet keine direkten MIDI Befehle, sondern definiert den Schaltzustand der korrespondierenden Schalter. Und DIESE selber schicken dann erst die entsprechenden MIDI Befehle „physisch“ raus.
Bedeutet: Jeder Scene-Schalter müsste jede Stompbox in ihrem AN/AUS Status definieren und zusätzlich den einen AN-Schalter pro Gruppe (Gruppe AMPs beispielsweise).

Somit würden „Gruppen“ in Abhängigkeit der nächst höheren Gruppe stehen, aber nicht umgekehrt. Damit ergäben sich folgende Prioritäten:
Ein Preset der Gruppe „Presets“ definiert presetbezogene Scenes (z.B. 8 Scenes pro Preset), wobei ein Scene-Schalter (AN) der Gruppe „Scenes“ direkt angewählt wird, diese Scene wiederum definiert einen Amp-Schalter (AN) der Gruppe „Amps“ und alle Stompboxes in ihrem AN/AUS Status.

Und jetzt wird (zumindest für mich) nachvollziehbar, wieso beliebige „Standard-MIDI Footcontroller“ meist auch genau so funktionieren: Hinter jedem PC-Schalter müssen alle CC-Schalter auf AN oder AUS konfiguriert werden. Wobei der Befehl OFF (sende gar nix) auch sinnvoll sein kann.

Im Anhang noch ein Excel, welches die hier nun ausgeführten Erklärungen Teil1 und Teil2 etwas grafischer unterstützt ( oder noch mehr verwirrt…*hust… )
 

Anhänge

Zuletzt bearbeitet:

axefx

Administrator
Teammitglied
Axe-Fest 2019 Teilnehmer
Mitglied seit
Sep 28, 2012
Beiträge
5.867
Wie "zwingt" man das AxeFx eigentlich dazu, diese Daten zu schicken? Kontinuierlich wäre meiner Meinung nach nicht der richtige Weg. Eher nach einer Aktion.
Bspw. bei nem Presetwechsel, einem Scenewechsel usw....
Das weiss ich eben auch nicht. Kontinuierlich macht für mich auch keinen Sinn. Ob das MFC einen Befehl aussendet, was abzuholen bzw. ob das Axe-Fx von sich aus wie wann was raussendet wäre halt echt die Frage. Leider kann ich da auch überhaupt nicht helfen - weil null Plan.

Diese ganzen "Ablässe" die ich hier schreibe sind eigentlich auch nur der Versuch MIR darüber klar zu werden, wie man ein Design formulieren könnte, dass dann das macht, was man will. Nur WIE das dann Programmiertechnisch umzusetzen wäre, was man wie wo auslesen muss, wie Sysex im Detail funktioniert - das weiss ich leider alles nicht. Das ist ja das dumme.

Allerdings führt mein Versuch, für mich selber herzuleiten, wie man so eine Fussleiste von seiner Struktur her basteln müsste ein bisschen dazu, dass ich nun auch die MFC besser verstehe. Vielleicht liege ich ja auch komplett daneben, aber die ganzen Überlegungen haben jetzt zu Formulierungen geführt, die komischerweise sehr der Funktionalität der MFC entsprechen. Vielleicht denke ich auch komplett falsch, aber irgendwie begreife ich jetzt besser, wieso die MFC eben einen Axe-Fx Mode und einen generischen MIDI Mode hat, warum sie im generischen Mode bei jedem PC alle IA Schaltzustände zudefinieren sind (leider kein OFF (sende gar nix) Zustand auf Preset-Ebene, wie bei der FCB) und wieso IAs global definiert sind und nicht auf Preset-Ebene. Nicht zuletzt die link-Groups, die an die "Gruppenidee" erinnern - oder andersrum ... ;)
 
Zuletzt bearbeitet:

Andy

Well-known member
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Okt 21, 2012
Beiträge
8.738
Den Teil 2 lese ich mir morgen durch. Mir helfen deine "Ablässe" :) das MFC und die Funktionsweise des MFC in Verbindung mit dem axefx besser zu verstehen.
Weil die Punkte, die du ansprichst einfach aus der Praxis kommen. Das Handbuch ist da nur die halbe Miete.

Folgendes "Kommando" müsste die Infos für ein Preset liefert:

MIDI_GET_PRESET_EFFECT_BLOCKS_AND_CC_AND_BYPASS_STATE

Steht auf der von dir verlinkten AxeFx Wiki Seite. Nur die Response dazu hab ich noch nicht so ganz durchblickt.

http://wiki.fractalaudio.com/axefx2/index.php?title=MIDI_SysEx#MIDI_GET_PRESET_EFFECT_BLOCKS_AND_CC_AND_BYPASS_STATE

Gruß

Andy
 

OSon

Administrator
Teammitglied
Axe-Fest 2023 Teilnehmer
Axe-Fest 2022 Teilnehmer
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2019 Teilnehmer
Axe-Fest 2018 Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Sep 29, 2012
Beiträge
2.583
Genau! Ich meine, ich habe da schonmal was ausgelesen. Allerdings nicht das was, das MFC sendet und empfängt, sondern was von Axe-Edit kommt. Ist nur schon länger her.

Aber das MFC weiß, welche IAs welche Funktion haben. Wenn ein Preset (oder eine Szene) gewechselt wird, fragt das MFC genau den Status dieser Effektblöcke per SYSEX ab und wertet das aus. Wenn ein Effekt-Block am Axe-FX direkt geschaltet wird, kriegt auch das MFC was davon mit, weil das Axe-FX dann auch ein SYSEX-Befehl (undokumentiert im Axe-FX Wiki meine ich) raus. Meine aktuelle Vermutung ist daher, dass daran das MFC merkt, oh da hat wer umgeschaltet, frag ich mal wieder alles ab. Anschließend fragt das MFC dann das Axe-FX wieder ab.

Alles aktuell meine Vermutung, aber so könnte das funktionieren! :)
 

axefx

Administrator
Teammitglied
Axe-Fest 2019 Teilnehmer
Mitglied seit
Sep 28, 2012
Beiträge
5.867
Genau! Ich meine, ich habe da schonmal was ausgelesen. Allerdings nicht das was, das MFC sendet und empfängt, sondern was von Axe-Edit kommt. Ist nur schon länger her.

Aber das MFC weiß, welche IAs welche Funktion haben. Wenn ein Preset (oder eine Szene) gewechselt wird, fragt das MFC genau den Status dieser Effektblöcke per SYSEX ab und wertet das aus. Wenn ein Effekt-Block am Axe-FX direkt geschaltet wird, kriegt auch das MFC was davon mit, weil das Axe-FX dann auch ein SYSEX-Befehl (undokumentiert im Axe-FX Wiki meine ich) raus. Meine aktuelle Vermutung ist daher, dass daran das MFC merkt, oh da hat wer umgeschaltet, frag ich mal wieder alles ab. Anschließend fragt das MFC dann das Axe-FX wieder ab.

Alles aktuell meine Vermutung, aber so könnte das funktionieren! :)
Das macht eigentlich ja auch Sinn so. Und wäre ein Erklärungsansatz, wieso die MFC zwar synchron läuft, wenn am Axe-Fx Presets oder Scenen gewechselt werden, nicht jedoch, wenn einzelne Blöcke im Layout Menu am Axe-Fx direkt aktiviert bzw. deaktiviert werden (hat wer das Gerät zur hand und kann das validieren? Ich meine nur, es wäre so!):

Die MFC unterscheidet im Axe-Fx Mode zwischen spezifischem Block (z.B Delay1) und dessen im Axe-Fx CTRL Menu vergebene CC-Nummer (z.B. 47). Da die MFC ihre eigene IA-Konfiguration natürlich kennt (welcher Block liegt auf welchem IA Switch), nicht aber die CC#-Nummer, mit der dieser Block im Axe-Fx II angesprochen wird scheint die MFC bei Einschalten beider Geräte als "Startroutine" das Axe-Fx alle relevanten (nämlich als IA-Switch zugeordneten) FX Blöcke nach Ihrer aktuellen CC# Nummer abzufragen.

Das interessante ist nun:
Die Kommunikation von Axe-Fx nach MFC scheint über Block-Definition (als Sysex) statt zu finden.
Die Kommunikation von MFC nach Axe-Fx II hingegen in "einfachen" CC# und PC# Befehlen.

Konfigurationsbeispiel als Nachweis dieser These:
Axe-Fx II: MIDI->CTRL:
Delay1 Byp: CC# 47
PEQ1 Byp: CC#47

MFC: Axe-Fx Mode = II
Axe-Fx IA1 = Delay1

Ruft man nun ein Axe-Fx Preset, welches Delay1 und PEQ1 beinhaltet auf erkennt die MFC: Delay1 ist vorhanden. Schaltet man nun den IA Delay1 wird am Axe-Fx II das Delay1 UND der PEQ1 gleichermassen geschaltet.

Ruft man nun ein Axe-Fx Preset, welches NUR PEQ1 und KEIN Delay1 beinhaltet, erkennt die MFC: KEIN Delay1 ist vorhanden - Schalter bleibt funktionslos! Er zeigt den Status NICHT BELEGT (LED AUS) an und sendet ebenso KEINEN CC#47 aus, mit dem ja immernoch der vorhandene PEQ1 ansprechbar wäre.

Diese Beobachtung lässt auf folgendes schliessen:
Die Unique Zuordnung auf Block-Ebene (delay1 gibts es nur einmal!) in der MFC und dessen Status (AN/AUS/Nicht vorhanden) wird durch senden eines uniquen Sysex-Befehls (der delay1 definiert) vom Axe-Fx II an die MFC getätigt.

Das Axe-Fx gibt also nicht den CC#-Wert zurück an die MFC, wie ich zu Beginn meiner MFC Zeiten dachte. Senden tut die MFC allerdings NICHT im uniqen Sysex, um einen dedizierten Block anzusprechen, sondern offensichtlich mit "einfachem" CC# command, ansonsten könnte ja der PEQ1 Block nicht MIT angesprochen werden, wenn der Delay1 Schalter ja eben auf Delay1 gestellt wurde. Deshalb MUSS bei einschalten der Geräte die MFC die aktuellen CC# Zurodnungen im Axe-Fx II auslesen.

Des Weiteren könnte ich mir vorstellen, dass das Axe-Fx II immer nur DANN einen Befehl "Hallo MFC, ruf mal den aktuellen Status ab", wenn am Axe-Fx II selber ODER via Remote (Footcontroller) wenn sich mehr als ein Block gleichzeitig ändert.
Sprich: Andere ich am Gerät einen Block auf aktiv oder inaktiv gibt es keine Aufforderung des Axe-Fx an die MFC, sich über Änderungen zu informieren (Synchronität geht verloren). Lösche ich einen Block aus dem Layout merkt das die MFC auch nicht! Erst bei Wiederaufruf des neu abgespeicherten Presets. (Auch bei Scenen-Wechsel? Das müsste getestet werden...)

Wird allerdings EIN Befehl von extern (Footcontroller) oder intern (am Axe-Fx II selber) ausgelöst, der theoretisch den Status VON MEHR ALS EINEM Block berührt, sendet das Axe-Fx II den Befahl an die MFC aus, sich über den aktuellen Schaltzustand zu infomrieren. Von diesen Befehlen gibt es genau zwei: Program Change oder Scene Change.

Dieser Schluss würde dann folgende Annahme unterstützen:

Für PC- und SCENE-CC#-Befehle der MFC-101 gilt: MFC fordert Axe-Fx zur Datenübergabe auf: LED Status aller Schalter wird durch Entgegennahme von Statusmeldungen, die das Axe-Fx II an die MFC übergibt ausgewertet und interpretiert.

Für NICHT-SCENE-CC#-Befehle der MFC-101 gilt: MFC fordert NICHT zur Datenübergabe auf: LED Status des betreffenden Schalters interpretiert die MFC aus ihrem eigenen Schaltvorgang heraus.

Jetzt gibt es eine interessante Ausnahme: Auch die Scene-Wahl bestehet aus EINEM CC#-Befehl! Allerdings WEISS die MFC, wenn sie einen Scene-Befehl (als CC# Command) auswirft, denn im Axe-Fx Mode wurde der entsprechende Switch ja als SCENE-Switch definiert (und im Umkehrschluss Nicht-Scene IA´s eben NICHT). Von hat die MFC wieder die Möglichkeit das zu unterscheiden. Deshalb unterscheide ich in NICHT-SCENE-CC# und SCENE-CC#.

Dass das Axe-Fx vermutlich auch immer erst eine Aufforderung zur Datenübermittlung raussendet und nicht pro forma immer ständig alles rausschickt macht eigentlich auch Sinn:

1) Es bietet der MFC die Möglichkeit auf "Angebot zur Datenübermittlung" eben auch nur die für sie RELEVANTEN Daten abzufragen (Sysex-Datenverkehr über den Status von Blöcken, die nicht auf der MFC konfiguriert sind, sind überflüssig!)
2) Und das auch nur, WENN es relevant ist: Die Statusänderung eines NICHT-SCENE-CC#s braucht keine Bestätigung durch Statusrückmeldung der MFC.
 
Zuletzt bearbeitet:

Andy

Well-known member
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Okt 21, 2012
Beiträge
8.738
Ich hab leider aktuell keine Zeit mir die Inputs durchzulesen aber die Response des AxeFX auf die Anfrage nach den Blöcken im Preset ist mir mittlerweile klar.
Für jeden Block in einem Preset gibt es fünf Bytes, mit folgender Codierung:


0xdd Status Bits

Bit 0: 0=Bypassed, 1=Enabled
Bit 1: 0=Y, 1=X
Bit 2:
Bit 3:
Bit 4:
Bit 5:
Bit 6:

0xdd IA CC Number LSB

Bit 0:
Bit 1: IA_CC_Number Bit 0
Bit 2: IA_CC_Number Bit 1
Bit 3: IA_CC_Number Bit 2
Bit 4: IA_CC_Number Bit 3
Bit 5: IA_CC_Number Bit 4
Bit 6: IA_CC_Number Bit 5

0xdd IA CC Number MSB

Bit 0: IA_CC_Number Bit 6
Bit 1: IA_CC_Number Bit 7
Bit 2:
Bit 3:
Bit 4:
Bit 5:
Bit 6:

0xdd Effect ID LSB

Bit 0:
Bit 1:
Bit 2:
Bit 3: Effect_ID Bit 0
Bit 4: Effect_ID Bit 1
Bit 5: Effect_ID Bit 2
Bit 6: Effect_ID Bit 3

0xdd Effect ID MSB

Bit 0: Effect_ID Bit 4
Bit 1: Effect_ID Bit 5
Bit 2: Effect_ID Bit 6
Bit 3: Effect_ID Bit 7
Bit 4:
Bit 5:
Bit 6:

[Quelle: http://wiki.fractalaudio.com]
 

guitardoc

Active member
Mitglied seit
Sep 29, 2012
Beiträge
126
Puh - da habt ihr euch ja schon ordentlich Gedanken gemacht... Daher gleich mal eine Frage hier an der Stelle zu einem angrenzenden Thema:

Gibt es eigentlich eine Möglichkeit mit einem internen Switch des MFC einen externen Switch umzuschalten? Ich werde da aus dem Handbuch nicht schlau...
 

guitardoc

Active member
Mitglied seit
Sep 29, 2012
Beiträge
126
Naja, eigentlich will ich Folgendes: Habe mir 4 Schalter gebaut welche an den externen Schalterbuchsen des MFC stecken. Diese 4 steuern 4 Scenes. So, wenn ich jetzt in Scene 3 bin und ein anderes Preset auswähle welches auf Scene 1 springt dann steht der externe Schalter immer noch auf Scene 3 (wenn er denn Lämpchen hätte was er aus genau diesem Grund nicht hat). Da es mich aber nervt nicht zu wissen welche Scene gerade an ist dachte ich mir es gibt vielleicht mittlerweile eine Möglichkeit den Schaltern zu LEDs zu verhelfen die sich mit den Scenes synchronisieren, aber dem scheint nicht so zu sein nachdem ich diesen Thread mal quergelesen habe. Wobei es mir ja ausreichen würde dass beim Ansteuern eines neuen Presets immer auf Scene 1 der externen Schalter gesprungen wird.
Das nächste Problem ist die Stromversorgung der LEDs - gibts da eine Chance die über das MFC zu realisieren (ohne dieses auseinander zu nehmen)?
 
Zuletzt bearbeitet:

axefx

Administrator
Teammitglied
Axe-Fest 2019 Teilnehmer
Mitglied seit
Sep 28, 2012
Beiträge
5.867
Naja, eigentlich will ich Folgendes: Habe mir 4 Schalter gebaut welche an den externen Schalterbuchsen des MFC stecken. Diese 4 steuern 4 Scenes. So, wenn ich jetzt in Scene 3 bin und ein anderes Preset auswähle welches auf Scene 1 springt dann steht der externe Schalter immer noch auf Scene 3 (wenn er denn Lämpchen hätte was er aus genau diesem Grund nicht hat).
Exakt so nutze ich die vier external Switche auch. Auch ohne LED aus demselben Grund. Bei "normalen" Schaltern schliesst und öffnet der Schalter physikalisch den Stromkreis zur LED. Allein aus diesem Grund wird es eine Synchronisierung der LED Status externer Schalter niemals geben können.

Das nächste Problem ist die Stromversorgung der LEDs - gibts da eine Chance die über das MFC zu realisieren (ohne dieses auseinander zu nehmen)?
Cliff hatte zur Einführung des Axe-Fx II mir mal geantwortet, dass die Ethernet Leitung genug Power vom Axe-Fx II bekommt um eine theoretische MFC-Extension mit Strom zu versorgen (die ja bis MFC FW1.04 noch angedacht schien - ab FW2.0 hat man die Verwaltung von theoretischen 41 Switche der MFC auf die physischen 17 reduziert, um die Geschwindigkeit zu erhöhen - zu dem Zeitpunkt wurde wahrscheinlich auch die Idee mit der Extension fallen gelassen).

Von daher gehe ich davon aus, das man theoretisch vom RJ45 Kabel die zwei Stromadern anzapfen könnte. Nur welche das genau sind, und ob man da mit einfachen Y-Adaptern weiterkäme, um an den Strom zu kommen, kann ich nicht sagen.

Das wäre eben auch für die DIY-Lösung die sauberste: Anstatt den MIDI-Port am Axe-Fx für die DIY Extension zu nehmen (phantomisiert), eben die MIDI Daten + Strom aus dem ethernet Port nehmen und vom DIY Board and die MFC weiterrouten ... *hust ...
 
Zuletzt bearbeitet:

guitardoc

Active member
Mitglied seit
Sep 29, 2012
Beiträge
126
Ich hab gerade mal gemessen - am Midi Out liegen bei Verbindung des MFC mit dem AXE per Ethernet 5V an. Die könnte man für die LEDs anzapfen...
Wäre nur noch die Frage des Scene-Status. Wenn ich mal Zeit finde schaue ich mal mit Midi-Ox was am Midi-Out des MFC passiert wenn am AXE Scenes gewechselt werden. Wenn da was passiert müsste man 'nur noch' die Midi-Daten überreden den LEDs zu sagen welche davon an sein soll... Womit die Mikrocontroller-Freaks dann wieder gefragt wären... ;-)
 

OSon

Administrator
Teammitglied
Axe-Fest 2023 Teilnehmer
Axe-Fest 2022 Teilnehmer
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2019 Teilnehmer
Axe-Fest 2018 Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Sep 29, 2012
Beiträge
2.583
Wenn Du schonmal am Messen bist... Mich würde interessieren, ob das Ethernet-Kabel nicht einfach nur eine eine MIDI-In/-Out Verbindung inkl. Strom ist. Welche Ader entspricht da die MIDI-In und MIDI-Out Adern... usw...
 
Oben
mainframe-fourhanded
mainframe-fourhanded