Midisignal von Einem auf zwei Kanäle dublizieren

[osc]

Hi

Ich suche schon seit längeren nach einem Gerät/Adapter/..., der aus einem Midichannel zwei macht.
Folgendes Beispiel: Keyboard A sendet über Midi out an Keyboard B. Leider kann Keyboard A nur auf einem Kanal gleichzeitig senden. Jetzt soll ein Gerät das Signal von Keyboard A bekommen, es auf zwei Channel dublizieren und an Keyboard B senden.

Gibt es sowas überhaupt? Ich hab bis jetzt noch nix passendes gefunden.

gruß

 

[Distance]

Gibt es denn keine Möglichkeit, mit Keyboard B nur auf einem Channel zu empfangen und das selbe Resultat zu erzielen? Das wäre eigentlich viel sinnvoller...

 

[osc]

Ja, die Möglichkeit gibt es noch. Der Ausgangspunkt ist dass ich viele Sounds gelayert hab z.b. Stringt mit Pad, 2 Synthssound, etc.. Ich müsste ca. 30-40 Sounds anpassen (Volumen, Chorus/Hall Anteil, Controller). Der Nachteil ist, dass mein Userpatch speicher ziemlich voll ist, daher möchte ich diesen Weg nur im Notfall gehen.

Außerdem könnte ich zwei Fliegen mit einer Klappe schlagen. Ich wollte das Keyboard B mit Wireless Midi ausbauen, eine Platine zum dubliezieren der Midichannels könnte ich direkt miteinbauen.

 

[Subsonic75]

hi,

aus meiner sicht sprichst du von einer art midi router oder einem patchsystem für midisignale. wenn ich deine frage richtig verstanden habe, solltest du mit jedem besseren midiinterface (z.b. von motu) derartige funktionen ausführen können. einige davon kannst du auch stand alone, also ohne angeschlossenen rechner benutzen und deinen bedürfnissen anpassen.

ich hatte mal ein motu midi express interface, dass über den parallelport des rechners lief. damit ging sowas. aktuelle geräte werden natürlich über usb betrieben, sollten aber ähnliche funktionen abbilden können.

gruß

 

[Distance]

Naja, ich sehe da in erster Linie die verdoppelte Datenmenge, wenn man die Midisignale doppelt. Das ist natürlich aus technischer Sicht vollkommen überflüssig, auch wenn es sich vermutlich nicht direkt nachteilig auswirkt.
Die Problematik mit den Patches kann ich aber irgendwie nicht richtig nachvollziehen. Du müsstest Effekte, Volumen usw. doch garnicht anfassen, sondern nur den Midi-Channel?

 

[Subsonic75]

Naja, ich sehe da in erster Linie die verdoppelte Datenmenge, wenn man die Midisignale doppelt. Das ist natürlich aus technischer Sicht vollkommen überflüssig, auch wenn es sich vermutlich nicht direkt nachteilig auswirkt.
Die Problematik mit den Patches kann ich aber irgendwie nicht richtig nachvollziehen. Du müsstest Effekte, Volumen usw. doch garnicht anfassen, sondern nur den Midi-Channel?

Datenmenge?

Geht es hier um das Livespielen oder um gespeicherte Songs? Beim Livespiel ist es egal wieviele Daten gesendet werden. Die 16 Midichannels pro Midi Port sind eh immer online. Ob sie dabei Nullen oder Einsen übertragen ist irrelevant.

.....

Was auch helfen könnte wäre, wenn am Keyboard B die Midichannels (Empfang) auf das Multiset frei routbar sind. Somit könntest du verschiedenen Sounds im Keyboard B ein und den selben Midi In Kanal zuweisen. Können aber die wenigsten.

.....

das mit den Effekteinstellungen verstehe ich auch nicht?

 

[HaraldS]

Ich suche schon seit längeren nach einem Gerät/Adapter/..., der aus einem Midichannel zwei macht.

Sollte hiermit gehen: http://www.midisolutions.com/prodrte.htm

Harald

 

[Distance]

Datenmenge?

[...]Beim Livespiel ist es egal wieviele Daten gesendet werden. Die 16 Midichannels pro Midi Port sind eh immer online. Ob sie dabei Nullen oder Einsen übertragen ist irrelevant.

Es wäre mir neu, dass Midi dauerhaft Daten sendet, das wäre auch ziemlich sinnfrei. Soweit ich informiert bin, werden Daten nur gesendet, wenn sie anfallen. Und dann habe ich in der Tat eine Verdoppelung der Datenmenge, wenn ich auf zwei Kanälen übertrage statt auf einem.

 

[osc]

Was auch helfen könnte wäre, wenn am Keyboard B die Midichannels (Empfang) auf das Multiset frei routbar sind. Somit könntest du verschiedenen Sounds im Keyboard B ein und den selben Midi In Kanal zuweisen. Können aber die wenigsten.

Versteh zwar nicht so ganz was du damit meinst, aber hab das schon probiert...geht nicht.

das mit den Effekteinstellungen verstehe ich auch nicht?

Normalerweise hat jeder Part seinen eigenen Midichannel. Wenn ich jetzt 2 Parts den gleichen Channel gebe dann gelten für beide Parts der Sendanteil für Hall/Chorus. Außerdem haben die Parts eine Volumeneinstellung. Wenn jetzt der eine Part lauter sein muss, muss ich den Sound intern verändern und als Userpatch abspeichern. Ebenso ist die gleichen Tasterturzone zugeordnet, sprich keine Spillts.

Sollte hiermit gehen: http://www.midisolutions.com/prodrte.htm

Harald

Kenn ich, löst aber nicht mein Problem. Ich möchte ja keine 2 Outs, sondern nur das der Channel verdoppelt wird.

Es würde ich mich wundern wenn es sowas nicht gäb. Ein komplexer Midirouter wäre hier oversized und außerdem würde er den Kostenrahmen sprengen ;-)

Trotzdem danke für eure Lösungsvorschläge

 

[HaraldS]

Kenn ich, löst aber nicht mein Problem. Ich möchte ja keine 2 Outs, sondern nur das der Channel verdoppelt wird.

Kennst du ihn wirklich? Lies doch erst mal genau die Bedienungsanleitung und schick ihm mal F0 00 00 50 01 02 00 7f 00 7f 00 03 F7 und F0 00 00 50 01 02 00 7f 00 7f 01 03 F7.

Harald

 

[osc]

Ich hab versucht die kostelose Software zu installieren. Leider kommt die Meldung dass sie nicht mit windows7 64 kompatibel ist.

Aber ich glaub dir einfach mal jetzt und bestell mir das Teil, wenns nicht geht kannich es ja wieder zurückschicken. Na toll beim großen T gibs das ja gar nicht

 

[Subsonic75]

Es wäre mir neu, dass Midi dauerhaft Daten sendet, das wäre auch ziemlich sinnfrei. Soweit ich informiert bin, werden Daten nur gesendet, wenn sie anfallen. Und dann habe ich in der Tat eine Verdoppelung der Datenmenge, wenn ich auf zwei Kanälen übertrage statt auf einem.

es ist also neu, dass digitale, serielle und gemultiplexte datenbusse einen dauerhaften stream erzeugen?

wir sprechen hier nicht von nutzdaten. also z.b. das senden von einem zugewiesenen binärcode bei tastendruck am keyboard o.Ä. logischerweise zeichnet ein midirecorder nur die aktiven mididaten auf, die vom quellgerät gesendet werden. also z.b. note on´s, note off´s, velocitywerte oder programm changes ect.

es ist aber quasi unmöglich, dass bei inaktivität des quellgerätes ein stream ohne inhalt übertragen wird. das würde ja bedeuten, dass die digitalverbindung auf dem bus abreißt und weder clock noch zeitinformationen übertragen werden. der midibus arbeitet mit 56kbit/s und teilt seinen stream per zeitmultiplex in 16 kanäle auf. ob innerhalb der kanäle nutzbare mididaten gesendet werden oder nicht, ist vollkommen irrelevant. 56kbit/s nullen sind genau so viele daten wie 56kbit/s einsen oder kombationen aus beiden zuständen.

es ist also nicht von bedeutung ob nun 1 note on auf kanal 1 oder 16 note on´s auf allen kanälen gesendet werden.

es sind und bleiben 56kbit/s

 

[Distance]

es ist aber quasi unmöglich, dass bei inaktivität des quellgerätes ein stream ohne inhalt übertragen wird. das würde ja bedeuten, dass die digitalverbindung auf dem bus abreißt und weder clock noch zeitinformationen übertragen werden.

Nun, ich muss zugeben, dass ich nicht die offizielle Midi-Spezifikation vorliegen habe. Das, was ich dazu aber bisher online gelesen habe, beschrieb alles eine simple, asynchrone Übertragung (mit je einem Start- und Stopbit).

der midibus arbeitet mit 56kbit/s

Nach meinen Informationen handelt es sich um 31,25kBit/s.

und teilt seinen stream per zeitmultiplex in 16 kanäle auf.

Auch davon habe ich noch nie gehört, was zumindest mal konsistent mit meinen Informationen über asynchrone Übertragung ist.

Es würde mich daher wirklich interessieren, woher du deine Informationen hast. Falls du irgendwelche Links hast, immer her damit - ich wollte mich da ohnehin schon lange mal im Detail mit beschäftigen.

 

[MidiSchorsch]

Nimm den hier damit funktioniert es http://www.midisolutions.com/prodevp.htm
du doppelst die Daten eines beliebigen Kanals komplett oder teilweise (Filter) und sendest die Originaldatei unverändert allerdings wäre ein MidiThru Anschluss hierbei von Vorteil

gruss Jürgen

 

[HaraldS]

es ist also neu, dass digitale, serielle und gemultiplexte datenbusse einen dauerhaften stream erzeugen?

Um beliebige Datenbusse ging's ja gar nicht, sondern nur um MIDI. Und MIDI erzeugt keinen dauerhaften Stream.

wir sprechen hier nicht von nutzdaten.

Schade, denn wenn wir von Nutzdaten sprechen würden, wäre deine Argumentation sogar haltbar - zumindest bei den vielen Geräten, die Active Sensing 0xfe senden. Viele Instrumente senden einen Active-Sensing-Stream. Wenn es dir aber um die einzelnen Bits auf Hardware-Ebene geht: nein, die werden nicht dauernd gesendet.

es ist aber quasi unmöglich, dass bei inaktivität des quellgerätes ein stream ohne inhalt übertragen wird. das würde ja bedeuten, dass die digitalverbindung auf dem bus abreißt und weder clock noch zeitinformationen übertragen werden.

Genau das passiert aber bei MIDI. Im "Idle"-Zustand fließt kein Strom (entspricht dem Zustand "1"). Dann kommt das Startbit 0, woraufhin der Empfänger die Daten erwartet und mit 31250 Bit/Sekunde (bei 1% Toleranz) die Datenbits entgegennimmt. Das Stopbit ist wieder Zustand "1" und dabei bleibt's, bis ein neues Byte übertragen wird. Das steht hier ("Hardware transport") und hier (Folie "MIDI hardware (3)") sowie bei Justus Noll, Musikprogrammierung, S.21:"Im Ruhezustand fließt bei MIDI kein Strom, also kann man auch nicht unterscheiden, ob das korrekt ist oder z.B. durch einen Kabelbruch verursacht wurde."

56kbit/s nullen sind genau so viele daten wie 56kbit/s einsen oder kombationen aus beiden zuständen.

Ja, aber wenn keine Nutzdaten anfallen, werden auch keine gesendet. Dann bleibt die Leitung im "Idle"-Status, und das bedeutet per Definition: kein Datenfluss.

Aber du scheinst dir deiner Argumentation sicher zu sein - woher hast du deine Informationen?

Harald

 

[osc]

Nimm den hier damit funktioniert es http://www.midisolutions.com/prodevp.htm
du doppelst die Daten eines beliebigen Kanals komplett oder teilweise (Filter) und sendest die Originaldatei unverändert allerdings wäre ein MidiThru Anschluss hierbei von Vorteil

gruss Jürgen

Hi,

ich hab mir jetzt den Midi Solutions Router bestellt den HaraldS empfohlen hat. Außerdem möchte ich ja nicht nur den Kanal doppeln, sondern auch einen Channel verändern.

Gruß

 

[BinaryFinary]

Falls jemand ein ähnliches Problem hat, der kann ja mal auf dem Gebrauchtmarkt nach einer Kawai MAV-8 MIDI-Patchbay ausschau halten. Das Ding hab ich leider leider mal vertickt, als ich mir ein Steinberg MIDEX 8 gekauft habe.


http://www.kawai.de/mav8_de.htm

 

[Subsonic75]

Um beliebige Datenbusse ging's ja gar nicht, sondern nur um MIDI. Und MIDI erzeugt keinen dauerhaften Stream.



Schade, denn wenn wir von Nutzdaten sprechen würden, wäre deine Argumentation sogar haltbar - zumindest bei den vielen Geräten, die Active Sensing 0xfe senden. Viele Instrumente senden einen Active-Sensing-Stream. Wenn es dir aber um die einzelnen Bits auf Hardware-Ebene geht: nein, die werden nicht dauernd gesendet.



Genau das passiert aber bei MIDI. Im "Idle"-Zustand fließt kein Strom (entspricht dem Zustand "1"). Dann kommt das Startbit 0, woraufhin der Empfänger die Daten erwartet und mit 31250 Bit/Sekunde (bei 1% Toleranz) die Datenbits entgegennimmt. Das Stopbit ist wieder Zustand "1" und dabei bleibt's, bis ein neues Byte übertragen wird. Das steht hier ("Hardware transport") und hier (Folie "MIDI hardware (3)") sowie bei Justus Noll, Musikprogrammierung, S.21:"Im Ruhezustand fließt bei MIDI kein Strom, also kann man auch nicht unterscheiden, ob das korrekt ist oder z.B. durch einen Kabelbruch verursacht wurde."



Ja, aber wenn keine Nutzdaten anfallen, werden auch keine gesendet. Dann bleibt die Leitung im "Idle"-Status, und das bedeutet per Definition: kein Datenfluss.

Aber du scheinst dir deiner Argumentation sicher zu sein - woher hast du deine Informationen?

Harald

all das,mal abgesehen von der tatsächlichen bandbreite der midiverbindung, halte ich für ausgemachten unsinn. ungeachtet davon, ob in einem midikanal nutzdaten gesendet werden oder nicht, wird bei verbundenen geräten ständig und ohne unterbrechung eine midi clock information übertragen. deutlich zu erkennen an der blinkenden midi in led´s des hardwaresequencers oder eines midi interfaces, die sofort ihren dienst aufnehmen, sobald ein midigerät angesteckt wird oder das interface online geht.

es ist schon technisch vollkommen unmöglich, dass ein digitaler datenbus mit anderen bussen, ohne eine dauerhafte clockinformation synchronisiert werden kann. genau das passiert, wenn man mehrere midiports (z.b. an einem midi interface) gleichzeitig betreiben will. dabei kann man nicht einfach mal die leitung kappen und hoffen, dass der clock beim nächsten note on befehl wieder passt.

als praktischer nachweis wäre z.b. anzuführen, dass man das miditempo so nicht übertragen könnte. verändert man z.b. das tempo im sequencer (stop betrieb) von 120 auf 140 bpm, passen sich auch automatisch alle zeitrelevanten parameter (z.b. delaywerte) im angeschlossenen klangerzeuger an. würde danach die datenverbindung abbrechen, würde der klangerzeuger irgendwann einen völlig anderen delaywert wiedergeben als noch vor 5 minuten.

ähnliche anpassungen finden auch bei tempoabhängigen hüllkurvenwerten statt. was passiert dann nach 10 minuten ohne mididaten? die hüllkurve ist dann plötzlich 2 16 noten länger als zuvor weil der interne clock aus dem sync gelaufen ist?

unsinn.

 

[HaraldS]

Falls die Diskussion länger wird, würde ich sie in einen eigenen Thread auslagern, weil sie vom Threadtitel wegführt.

all das,mal abgesehen von der tatsächlichen bandbreite der midiverbindung, halte ich für ausgemachten unsinn.

Das ist dein gutes Recht, aber ein schwaches Argument. Ich würde dir durchaus gerne glauben, wenn du deine Meinung belegen könntest. Hast du einen Link, der deine Meinung über MIDI unterstützt und belegt?

ungeachtet davon, ob in einem midikanal nutzdaten gesendet werden oder nicht, wird bei verbundenen geräten ständig und ohne unterbrechung eine midi clock information übertragen. deutlich zu erkennen an der blinkenden midi in led´s des hardwaresequencers oder eines midi interfaces, die sofort ihren dienst aufnehmen, sobald ein midigerät angesteckt wird oder das interface online geht.

Ja, aber das sind doch Active-Sensing-Daten! Das wirst du doch wissen, wenn du dich mal damit auseinandergesetzt hast. Da wird 0xfe alle 300ms gesendet. Und: MIDI-Clock-Daten sind etwas ganz anderes, nämlich 0xf8 - und das Senden von MIDI Clock-Daten muss oft ausdrücklich aktiviert werden. Active Sensing nicht, wenn also direkt nach dem Einstecken die LEDs blinken, wird es höchstwahrscheinlich Active Sensing sein. Probier's mit MIDIOX aus, kann ich nur sagen.

es ist schon technisch vollkommen unmöglich, dass ein digitaler datenbus mit anderen bussen, ohne eine dauerhafte clockinformation synchronisiert werden kann.

Ja. Genau deswegen ist ja MIDI auch eine asynchrone Verbindung. Hier wird das auf S.2 erklärt. Synchronisation wird bei MIDI nur auf der Ebene kompletter MIDI-Messages erreicht, aber nicht auf der Bit-Ebene. Immerhin ist der Kernbaustein ein UART, kein USART. Vielleicht hast du das verwechselt?

als praktischer nachweis wäre z.b. anzuführen, dass man das miditempo so nicht übertragen könnte. verändert man z.b. das tempo im sequencer (stop betrieb) von 120 auf 140 bpm, passen sich auch automatisch alle zeitrelevanten parameter (z.b. delaywerte) im angeschlossenen klangerzeuger an. würde danach die datenverbindung abbrechen, würde der klangerzeuger irgendwann einen völlig anderen delaywert wiedergeben als noch vor 5 minuten.

Tempo wird bei MIDI erst mal überhaupt nicht übertragen. Wenn deine angeschlossenen Geräte die Tempiwechsel mitmachen, wird offensichtlich MIDI Clock 0xf8 gesendet, und zwar unterschiedlich viele 0xf8 pro Sekunde. Daraus kann ein empfangendes Gerät das Tempo errechnen - aber das Tempo selbst (die BPM-Zahl) wird nirgendwo übertragen. Dass das empfangende Gerät den Tempowechsel mitmacht, ist also kein praktischer Nachweis für eine Synchronisation auf Bit-Ebene. Stattdessen liegt hier eine Synchronisation über die Nutzdaten vor, aber deren Relevanz verneintest du ja: "wir sprechen hier nicht von nutzdaten".

unsinn.

Glaube ich nicht. Aber wenn du Beweise für deine Meinungen hast: her damit.

Harald

 

[BinaryFinary]

Ich finde es als ziemlich unhöflich, etwas als "Unsinn" zu bezeichnen und dann ohne Quellen und weitere Informationen wilde Theorien aufzustellen.

MIDI ist - wie hier schon tausendfach erwähnt - eine unidirektionale, asynchrone, serielle Datenschnittstelle. Es ist also kein kontinuierlicher Datenstrom, im Sinne es digitalen Streams, wie z.B. bei Audio-Daten.

Der Witz bei asynchronen Übertragungen ist doch, dass Sender und Empfänger beim Datenaustausch keinen gemeinsamen Taktbezug haben. Dadurch entstehen doch erst die legendären MIDI-Timing-Probleme, weil MIDI-Daten einfach brutal seriell auf die Leitung gejagt werden.

Alle "normalen" Daten - Note ON/OFF, Controller, Bank-Select, Programm-Change, etc, haben als Information für welchen "Kanal" sie bestimmt sind. Getreu dem Motto: "Wer zu erst kommt", werden die Daten auf die Leitung geschickt. Die Informationen für einen Akkord werden also NIEMALS gleichzeitig übertragen. Wenn ich also viele Informationen gleichzeitig verarbeiten möchte, kann es so zu ungewollten Timing-Schwankungen kommen.

Gerade wenn der Empfänger (also z.B. ein Synthesizer) die eintreffenden Daten nicht schnell genug weiter verarbeiten kann. Die User eines Roland D-50 werden hier bestimmt wissen, was gemeint ist. Es gibt in Sequenzer-Programmen (Senderseite) die Möglichkeit, die Daten eines Kanals manuell vor zu ziehen, um Timing-Problemen etwas entgegen zu wirken. Sehr nützlich, wenn man den "Groove" von Schlagzeugspuren verbessern möchte.

Andere Verfahren, die das Timing von MIDI verbessern sollen, sind z.B. LTB (Linear Time Base) von Access/Steinberg, welches in den MIDEX-Interfaces benutzt wird. LTB soll sicherstellen, dass bei mehreren MIDI-Ports (ein MIDEX 8 stellt acht unabhängige Ports zur Verfügung) dort die Daten gleichzeitig (mit sehr geringer Verzögerung) ankommen, und so die Latenz wenigstens auf Interface-Ebene reduziert wird. Dies ist dann in der Tat ein Multiplex-Verfahren. Dies geschieht aber auf der USB-Busebene mit ganz anderen Übertragungsraten. An der MIDI-Latenz an sich kann es aber nichts ändern.

Auch wenn es nicht gerade DER Fachartikel ist, wird das in der Wikipedia aber ganz ordentlich erklärt:
http://de.wikipedia.org/wiki/MIDI#Systemexklusive_Meldungen

Dort wird auch MIDI-Clock und MIDI-Timecode erklärt.

Gruß Dennis