Nur OnTopic "True MIDI Thru" analog zum "True Bypass" bei Audio?

[noir]

Es gibt ja heutzutage viele Geräte die aus Platzgründen nur zwei MIDI Schnittstellen bieten. Dabei ist der MIDI Out manchmal auch als Thru konfigurierbar. Dabei spricht man in der Regel (so hab ichs gelernt) von einem "soft thru", da das MIDI Signal durch den Prozessor des Geräts geht. Davon wird zumindest immer ausgegangen wenn solch eine Funktionalität vorhanden ist.

Es müsste jedoch auch möglich sein eine Schaltung zu bauen welche im "Thru Modus" das Signal komplett anders leitet und somit das potentielle Latenz-Problem vermeidet oder zumindest verringert. Also ähnlich wie beim "True Bypass" welches man von Audio Effekten kennt. Ist das möglich bzw. sinnvoll? Gibt es Geräte die sowas implementiert haben?

 

[Max]

ja, der "klassische", "harte" (haha) MIDI-Thru geht nicht durch den Prozessor und ist damit ohne Latenz

siehe z.B. hier die Referenz-Schaltung der MIDI Association:

MIDI DIN Electrical Specification

 

[noir]

ja, der "klassische", "harte" (haha) MIDI-Thru geht nicht durch den Prozessor und ist damit ohne Latenz

siehe z.B. hier die Referenz-Schaltung der MIDI Association:

MIDI DIN Electrical Specification

Öhm ja das ist mir klar. Was ich meine ist eine Kombination von MIDI Out und Thru am selben Ausgang. Wenn man im Gerät den MIDI Out auf Thru schaltet dann soll eine echte Thru-Schaltung aktiviert werden anstatt eine Weiterleitung in Software.

 

[Miks]

Was ich meine ist eine Kombination von MIDI Out und Thru am selben Ausgang. Wenn man im Gerät den MIDI Out auf Thru schaltet dann soll eine echte Thru-Schaltung aktiviert werden anstatt eine Weiterleitung in Software.

Kapier ich irgendwie nicht... Midi-Out hat doch an sich mit einem Thru nix zu tun - Thru stellt normalerweise das MIDI-In-Signal quasi unverfälscht (2-fach gebuffert) wieder zur Verfügung - damit geht's dann bei einem weiteren Gerät wieder an MIDI-In. Geht trotzdem nicht beliebig oft, da die (normalerweise lt. MIDI.Specs) vorhandenen Optokoppler das Signal trotzdem immer minimal verzögern. Daher setzt man an dieser Stelle an sich schnelle Optokoppler ein.

Hier mal das Prinzip einer Thru-Schaltung:

 

[verstaerker]

Kapier ich irgendwie nicht... Midi-Out hat doch an sich mit einem Thru nix zu tun - Thru stellt normalerweise das MIDI-In-Signal quasi unverfälscht (2-fach gebuffert) wieder zur Verfügung - damit geht's dann bei einem weiteren Gerät wieder an MIDI-In. Geht trotzdem nicht beliebig oft, da die (normalerweise lt. MIDI.Specs) vorhandenen Optokoppler das Signal trotzdem immer minimal verzögern. Daher setzt man an dieser Stelle an sich schnelle Optokoppler ein.

Hier mal das Prinzip einer Thru-Schaltung:
Anhang anzeigen 80630

es gibt bei manchen Geräten kein Midi-Thru, sondern nur eine Midi-Outbuchse, die man allerdings in den Settings zwischen Midi-Out oder Thru umschalten kann.
Dadurch, das es durch eine Software geht , ansteht zusätzliche Verzögerung.

 

[MacroDX]

Ich könnte mir vorstellen, dass das ein oder andere Gerät, bei dem man zwischen Out- und Thru-Funktion umschalten kann, tatsächlich auch True-Thru bietet. Das würde natürlich zusätzliche Bauteile erfordern. Die Software würde dann einen externen analogen Schalter betätigen.
In den Meisten Fällen gehe ich aber davon aus, dass THRU nur bedeutet, dass das Gerät keinen eigenen Output erzeugt und nur die eingehenden Daten per Software weiterreicht.
Denn sonst würde es sich de Facto um einen Merger handeln, welche eine erhöhte Anforderung an die Implementierung stellen.

 

[serge]

Wenn man im Gerät den MIDI Out auf Thru schaltet dann soll eine echte Thru-Schaltung aktiviert werden anstatt eine Weiterleitung in Software.

Einen zwischen MIDI-Out und "echtem" Hardware-MIDI-Thru umschaltbaren Anschluß zu realisieren ist schlicht teurer als die Umschaltung zwischen MIDI-Out und Software-MIDI-Thru. Und das wird man sich Hersteller zweimal überlegen, ob man die Marktchancen seines neuen Instruments für etwas reduziert,
dessen Funktion letztlich durch bereits erhältliche Thru-Boxen besser abgedeckt wird,
und das nur wenigen potentiellen Kunden wichtig sein dürfte:
Denn es werden ja selbst Geräte gekauft, die gar keinen MIDI-Thru mehr haben, obwohl dies in der Fachpresse und in Foren beklagt wird.

Anders gesagt:
Niemand würde ein Gerät kaufen, nur weil sein umschaltbarer MIDI-Anschluss einen Hardware-MIDI-Thru bietet.
Aber ein klanglich interessantes Gerät würde man selbst dann noch kaufen, wenn sein umschaltbarer MIDI-Anschluss nur einen Software-MIDI-Thru bietet.

Kurz: Ein Hersteller hat nichts davon, hier zu investieren.

 

[Miks]

es gibt bei manchen Geräten kein Midi-Thru, sondern nur eine Midi-Outbuchse, die man allerdings in den Settings zwischen Midi-Out oder Thru umschalten kann. Dadurch, das es durch eine Software geht , ansteht zusätzliche Verzögerung.

Das habe ich ja verstanden. Also kann man die MIDI-Out-Buchse (per 'Umschaltung' am/im Gerät) entweder als MIDI-Out oder als MIDI-Thru verwenden. Wobei das Thru-Signal nicht, wie normalerweise üblich, hardwaremäßig direkt am MIDI-In abgenommen wird, sondern per Gerätesoftware das In-Signal, allerdings nun von der CPU kommend, wieder zum MIDI-OUT 'zurückroutet' und so einen Thru-Anschluß quasi 'simuliert' - leider mit einer entsprechenden Verzögerung.

Eine echte Thru-Umschaltung wäre meiner unmaßgeblichen Meinung nach nur dann möglich, wenn die im Gerät verbaute MIDI-Elektronik sich an die MIDI-Standards hält UND man den Thru-Teil meiner oben geposteten Schaltung (bestehend aus DIN-Buchse, 2 Widerständen und U1/U2) per Hardware - sprich z.B. einem Relais - an das Ausgangssignal des Optokopplers anschalten würde. Das Problem sähe ich jedoch bei der Ansteuerung des Relais durch die Geräte-Software (= Firmware) - wo sollte eine per Firmware gesteuerte Spannung für das Relais herkommen? Schwierig...

 

[fcd72]

Viel interessanter als ein Hard oder Soft MIDI thru wäre, wenn intern OUT und IN gemerged würden. Also wahlweise am Ausgang OUT, THRU oder MERGE. Macht aber keiner, zumindest kenn ich das nur vom MI Shruthi (und Ambika denke ich) als MIDI Out Mode "full".
Nebenbei: Die zusätzliche Latenz sollte heutzutage eigentlich kein Problem sein, wenn man dafür sorgt, dass eingehnde Daten direkt wieder rausgeschickt werden, bevor was anderes passiert. Das kann selbst ein PicAxe so schnell, dass sich das mit meinem guten alten 20 MhZ Hameg nicht messen lässt.

 

[intercorni]

leider mit einer entsprechenden Verzögerung.

Von welchen Verzögerungen in welcher Höhe sprechen wir hier genau?

 

[kirdneh]

Also beim neuen Fantom kann man Thru oder Out 2 einstellen, hab da noch keine Verzögerung gemerkt.
Beim Virus Ti kann man Soft Thru aktivieren, auch da hatte ich nie Probleme.

Welche Geräte haben denn da Verzögerungen und wie hoch?

 

[Miks]

Von welchen Verzögerungen in welcher Höhe sprechen wir hier genau?

Ich hätte besser schreiben sollen "leider offenbar mit einer entsprechenden Verzögerung." Denn ich weiß es nicht, da ich keine Geräte besitze, die diese Soft-Thru-Funktionalität aufweisen! Alle meine Synths/Module haben, soweit ich mich recht erinnere, 3 DIN-MIDI-Buchsen, also eine 'echte' Thru-Funktion... bis auf mein Ferrofish B4000+ Modul, das hat 2x DIN MIDI-In (und Midi über USB).

 

[Max]

Von welchen Verzögerungen in welcher Höhe sprechen wir hier genau?

eine MIDI Message komplett übertragen dauert ca. 1 ms, aber wenn der Eingang als "Soft-Thru" exakt 1:1 an den Ausgang übertragen werden soll, kann man auch die einzelnen Bits sofort wieder losschicken sobald sie angekommen sind (ohne erst den Rest der Message abwarten zu müssen) - die Verzögerung sollte dann wie der Kollege @fcd72 schon geschrieben hat absolut vernachlässigbar sein (im Mikrosekundenbereich)

also im "Worst-Case" (bei schlechter Implementierung) ~ 1 ms, wenn es richtig gemacht ist so klein dass man schon gutes Test-Equipment braucht um es überhaupt messen zu können

 

[MacroDX]

wo sollte eine per Firmware gesteuerte Spannung für das Relais herkommen? Schwierig...

Das würde man glaube ich eher mit einem elektronischen Schalter wie einem 4051 oder (ich glaube) Darlington-Transistor machen.

 

[Green Dino]

Genaues habe ich zu Soft Thru nie gefunden, es wird aber davon gesprochen, dass es problemlos so implementiert werden kann das die Verzögerung unter 1 Millisekunde liegt.

 

[Miks]

Das würde man glaube ich eher mit einem elektronischen Schalter wie einem 4051 oder (ich glaube) Darlington-Transistor machen.

Oder so - meine Bemerkung bezieht sich eher auf ein: wo ein(en) solche(n/s) Signal/Impuls bei einem gegebenen Gerät abgreifen?

Dazu müsste man ein konkretes Gerät benennen, das evtl. so auf/umgerüstet werden soll, dann kann man versuchen, anhand eines hoffentlich verfügbaren Schaltplanes zu ergründen, ob sich ein geeigneter Impuls/ein geeignetes Signal irgendwo abgreifen ließe...

 

[Miks]

Genaues habe ich zu Soft Thru nie gefunden, es wird aber davon gesprochen, dass es problemlos so implementiert werden kann das die Verzögerunh unter 1 Millisekunde liegt.

Das wäre klasse und sicherlich wünschenswert - in der Hoffnung, daß die Hersteller das a.) auch so sehen und b.) die Firmware auch entsprechend programmieren (lassen)...

 

[MacroDX]

Oder so - meine Bemerkung bezieht sich eher auf ein: wo ein(en) solche(n/s) Signal/Impuls bei einem gegebenen Gerät abgreifen?

Dazu müsste man ein konkretes Gerät benennen, das evtl. so auf/umgerüstet werden soll, dann kann man versuchen, anhand eines hoffentlich verfügbaren Schaltplanes zu ergründen, ob sich ein geeigneter Impuls/ein geeignetes Signal irgendwo abgreifen ließe...

Achso, ich hatte das auf Neuentwicklung bezogen, bei der dann explizit ein Signal von der CPU kommt.

 

[fcd72]

Nur mal so am Rande: die ganze Diskussion ist ziemlich witzlos, weil man ja für ein paar Euro einfach eine THRU-Box basteln (oder für ein paar Euro mehr kaufen) kann, die das Problem beseitigt. Nur falls jemand sich wirklich an 1mS oder so Verzögerung stört. Wir alle haben ja nur einen MIDI-Port und müssen so ja alle unsere Synths hintereinander hängen.....

 

[Green Dino]

Ich hatte vorhin mal kurz im Mutable Instruments Forum geschaut, aber nichts gefunden.
Das wäre u.a. eine Anlaufstelle wo man mal fragen könnte. Anushri, Shruthi und Ambika haben Soft Thru.

 

[fcd72]

Ich hatte vorhin mal kurz im Mutable Instruments Forum geschaut, aber nichts gefunden.
Das wäre u.a. eine Anlaufstelle wo man mal fragen könnte. Anushri, Shruthi und Ambika haben Soft Thru.

Musst nicht extra nachfragen: beim Shruthi (also anzunehmenderweise auch bei Anushri und Ambika) ist es ein SoftThru bei dem die Daten Byte-Weise direkt weitergereicht werden (sofern nicht noch interne Daten dazugemerged werden müssen). Also etwa 1mS Verzögerung, da erst das komplette Byte empfangen werden muss.

 

[Max]

Das dauert 320µs (Byte) plus ein paar µs (Interrupt, Transportbefehle in der CPU).

ein Note On hat aber z.B. 3 byte, also im "regulären Fall" das Ganze mal drei = ca. 1ms pro Note

man kann aber für den speziellen Anwendungsfall "Soft Thru" die Bits auch gleich einzeln wieder raushauen sobald sie reinkommen, wenn man das so implementiert ist die Verzögerung nur gute 30µs

 

[Miks]

In der Elektor-Ausgabe vom Februar 1987 (!) wurde ab Seite 56 der MIDI-Star veröffentlicht - ein MIDI-Verteiler mit 4 Eingängen und 16 Ausgängen. Schaltbare Kombinationen waren (soweit ich mich erinnere):

1 Eingang auf 16 Ausgänge

2 Eingänge auf je 8 Ausgänge

4 Eingänge auf je 4 Ausgänge

Ist vom Prinzip her X Eingang auf X Thru

Irgendwo müßt' ich das Heft noch rumoxidieren haben...

 

[fcd72]

ein Note On hat aber z.B. 3 byte, also im "regulären Fall" das Ganze mal drei = ca. 1ms pro Note

man kann aber für den speziellen Anwendungsfall "Soft Thru" die Bits auch gleich einzeln wieder raushauen sobald sie reinkommen, wenn man das so implementiert ist die Verzögerung nur gute 30µs

Nur mal so zum Klugscheissen: mit Running Status sinds nur 2. Gibt dann so ne Art ultrafeinen Shuffle. Ansonsten kann ich mir keinen Treiber vorstellen, der nach jedem Bit guckt, macht ja auch irgendwie keinen Sinn im Sinne von "Die ersten 5 Bits sind schonmal 01101". Aber kann man sicher ja selber implementieren?

 

[Max]

Nur mal so zum Klugscheissen: mit Running Status sinds nur 2. Gibt dann so ne Art ultrafeinen Shuffle. Ansonsten kann ich mir keinen Treiber vorstellen, der nach jedem Bit guckt, macht ja auch irgendwie keinen Sinn im Sinne von "Die ersten 5 Bits sind schonmal 01101". Aber kann man sicher ja selber implementieren?

ja, das geht schon, die MIDI Solutions Merge-Boxen machen das z.B. so - wenn nur auf einem Kanal was ankommt wird das sofort Bit für Bit weitergeschickt (wenn auf mehreren Eingängen Sachen ankommen muss natürlich gewartet werden)

und stimmt, mit Runnign Status kann man sich hier und da manchmal ein byte sparen (weiß aber nicht ob das wirklich oft genutzt wird? es gibt glaub ich oft Probleme mit manchen Geräten, die das nicht unterstützen)

(wieso sind wir hier wenn nicht zum Klugscheißen?? )

 

[Max]

@bjv für einen normalen MIDI-Thru braucht man GAR KEINEN Microcontroller, das funktioniert rein elektronisch

hier geht es um SOFT-Thru und je nachdem wie gut das implementiert ist kann da die Länge schon einen Unterschied machen.. wenn man z.B. eine MIDI Library benutzt oder bestimmte Befehle rausfiltern will muss erst der gesamte Befehl abgewartet werden

wenn es wirklich 100% 1:1 Rein-wie-Raus sein soll kann man auch (mit wenig Aufwand) einzelne Bytes oder sogar (mit etwas mehr Aufwand) einzelne Bits sofort weiterleiten

 

[microbug]

Also beim neuen Fantom kann man Thru oder Out 2 einstellen, hab da noch keine Verzögerung gemerkt.

das ist ziemlich sicher eine Hardware-Umschaltung. Die aktuellen ESI MIDI Interfaces haben sowas an jedem Port, dort allerdings dient es zur Umschaltung zwischen Eingang und Ausgang.

 

[microbug]

MIDI Solutions Merge-Boxen

Er hat Jehova gesagt

und stimmt, mit Runnign Status kann man sich hier und da manchmal ein byte sparen (weiß aber nicht ob das wirklich oft genutzt wird? es gibt glaub ich oft Probleme mit manchen Geräten, die das nicht unterstützen)

Geräte mit Running Status kenne ich eigentlich nur aus den 80ern, von den Geräten, die ich seit meinem Wiedereinstieg in 2010 in den Fingern hatte (und das waren Einige) hatte keines sowas.

 

[Max]

Er hat Jehova gesagt

haha, an der Stelle sag ich normal immer, dass ich noch niemals in 20 Jahren ein Problem mit den MIDI Solutions Teilen hatte, aber letzte Woche ist mir tatsächlich mal eine abgestürzt... hat auch sehr lange gedauert, bis ich die Box als Schuldigen ausgemacht hab. Aber ja, 100% "sauber" sind die nicht aufgebaut weil sie u.a. auch den Strom aus der MIDI Schnittstelle abzapfen... (was natürlich auf der anderen Seite wieder recht praktisch ist)

bei running status stimme ich zu dass es ein Empfänger gemäß MIDI-Spezifikation können muss, aber als Sender sollte man definitiv drauf verzichten (einmal für etwaige nicht kompatible Empfänger, aber ich finds auch besser wenn die Latenz immer konstant ist)

 

[microbug]

Aber ja, 100% "sauber" sind die nicht aufgebaut weil sie u.a. auch den Strom aus der MIDI Schnittstelle abzapfen...

Power over MIDI ist halt laut Spec nicht erlaubt, daher das Jehova, und daher brauchen die ja auch so eine überflüssige Kompatibilitätsliste. Sowas ging früher problemlos, da am MIDI OUT immer die dicken Treiberchips wie 7406/07 saßen, was heute eben nimmer der Fall ist.

Du erinnerst Dich sicher noch an die Anatek Pocket Serie aus den 80ern, die sich ebenfalls aus MIDI mit Spannung versorgt. Da diese auf 5V Geräte ausgelegt sind, funktioniert der Kram mit modernen, meist auf 3V ausgelegten Geräten nicht mehr, konnte ich sehr schön an meinem Yamaha MX61 sehen. MIDI Solutions scheint das schlauer gelöst zu haben.