iConnectivity iConnect MIDI4+ MIDI2+, MIO2/4/10, MIO XM und XL

Re: iConnect MIDI 4+ wird ausgeliefert

Du kannst beide Geräte über die Software verwalten, beim Start wird eine Auswahl angezeigt, wenn mehrere Interfaces gefunden wurden.
 
Weiter gehts. Nachdem die neuen MIOs ja auf den MIDI2+/4+ basieren und nahezu baugleich sind, habe ich Mic gebeten, den Thread umzubenennen, sodaß auch die neuen Interfaces hier behandelt werden können.

Als Erstens kommt hier der bereits angekündigte Test des MIO4, in dem ich es auch mit dem MIDI4+ vergleiche, das MIO10 und die kleineren MIO2/MIDI2+ finden ebenfalls Erwähnung.
 
iconnect MIO4 im Test und Vergleich mit dem iconnect MIDI 4+

Mehr oder weniger unbemerkt hat der kanadische Hersteller iConnectivity gleich 3 neue MIDI Interfaces auf den Markt gebracht, die, anders als bisher, direkt auch schon lieferbar waren.

Es handelt sich dabei um die Modelle MIO2, MIO4 und MIO10.

Schaut man sich die Teile genauer an, so kommen einem zumindest die beiden kleinen Interfaces doch sehr bekannt vor - kein Wunder, sehen sie den Modellen MIDI2+ und MIDI4+ zum Verwechseln ähnlich.

Ich habe mir mal das MIO4 vorgenommen und werde es im Verlauf mit dem bereits hier vorhandenen MIDI4+ vergleichen, ab und zu auch das kleinere MIO2 mit dem MIDI2+.

Die Daten des MIO4 sind mit dem MIDI4+ fast identisch:

- 4x DIN MIDI Paare
- 2x USB Device Anschlüsse für Computer mit je 16 Ports (das MIDI4+ hat hier 3)
- 1x USB Host Port für 8 class compliant USB Geräte
- 1x Netzwerkanschluß

An den USB Host Port kann man einen Hub hängen, um mehrere Geräte anzuschließen, dort geht auch ein classcompliant MIDI Interface dran, somit könnte man auch mehrere Geräte kaskadieren. Am MIDI4+ hatte ich da schon das hier vorhandene MIO (USB-Kabelinterface) Zwecks Erweiterung angeschlossen.

Hier nochmal die Eckdaten von MIDI4+ und MIO4:

Multiport MIDI Interfaces mit USB-Hostport
mehrere Rechneranschlüsse (MIDI 4+: 3, MIDI2+, MIO4, MIO2 und MIO10:2)
Standalone-Betrieb
Routing (mit nur 1 Speicher)
Merging
Filter pro Port, getrennt für Eingang und Ausgang
Channel Remapping pro Port
Controller Remapping pro Port
Netzwerkanschluß (nur MIDI4+, MIO4 und MIO10) für RTP MIDI, nur Client


Auspacken

Das MIO4 kommt im gleichen Karton wie das hier bereits vorhandene MIDI4+, mit dem Unterschied, daß das Netzteil nicht zum Lieferumfang gehört. Auf dem Fach, in dem sich das Netzteil normal befinden würde, steht auch ein entsprechender Hinweis zur Spannungsversorgung über USB. Im Fach findet sich daher auch nur das USB-Kabel.

Wie schon vom MIDI2+/4+ gewohnt, ist im Karton keinerlei Handbuch oder Software drin - was durchaus konsequent erscheint, denn so bekommt man nichts veraltetes mitgeliefert. Handbuch und Software läd man sich auf der Webseite herunter.

In meinem Fall war die Software ja schon auf meinen Rechnern und dem iPad installiert, dazu aber später.

Äußerlichkeiten

Von außen sieht man dem MIO4 die Verwandtschaft zum MIDI4+ direkt an. Nicht nur das Gehäuse ist bis auf die halbe Schwarzfärbung identisch, sondern auch die komplette Rückseite mitsamt den Anschlüssen (6x MIDI DIN, ein USB A und ein USB B). Lediglich fehlt vorne eine USB-Buchse für den Anschluß eines Rechners, das MIO4 kann also "nur" an zwei statt 3 Rechnern betrieben werden.
Der USB Typ B auf der Rückseite trägt die Zusatzaufschrift "Power". Das MIO4 kann also über diesen Port über USB mit Spannung versorgt werden, denn dort ist, wie beim MIDI4+, der Anschluß des Hauptrechners vorgesehen.
Auf der Unterseite findet man, wie beim MIDI4+ auch, ein Gewinde für die Befestigung auf einem Stativ oder in einer Rackwanne. Beim MIO2 und dem MIDI2+ ist das ebenfalls so. Es handelt sich dabei um den in der Fotografie üblichen Anschluß mit 1/4" Gewinde.

Beim MIO2 gibt es auf der Rückseite einen Unterschied zum MIDI2+: Es hat keine Buchse für ein Netzteil, kann also nur über USB gespeist werden.

Ich vermute mal, daß innen sogar bei Beiden die Hauptplatine der Modelle MIDI2+ und 4+ zum Einsatz kommt und nur entsprechend von der Bestückung her angepasst wurde - ebenso in der Firmware natürlich. Die Möglichkeit, das Interface über die hintere USB-Devicebuchse mit Spannung zu versorgen, dürfte aber eine Änderung der Platine nötig gemacht haben, außer, es wäre schon vorher geplant gewesen.

Erste Inbetriebnahme

Nachdem ich keine Lust hatte, das Netzteil meines MIDI4+ aus dem Rack rauszufrickeln, habe ich daher USB genutzt, aber erstmal ohne Rechner. Natürlich war ich neugierig und wollte wissen, ob sich das MIO4 ohne Netzteil am iPad betreiben läßt - Fehlanzeige, braucht also mehr als 300mA Strom. War zu erwarten, aber ich wollte es halt auch mal wissen. Ob das mit dem MIO2 geht, konnte ich mangels dessen bisher nicht testen.

Also über den hinteren Port ran ans USB-Netzteil und das iPad via CCK und einem USB-Kabel an den vorderen Anschluß gesteckt, das schon vorhandene iConfig gestartet, welches das Interface auch sofort erkennt. Das MIO4 ist also eindeutig aus dem MIDI4+ abgeleitet und nutzt offenbar auch das gleiche Sysex-Datenformat (was ja sinnvoll ist). Scheint auch so, daß diese neuen Interfaces schon länger in Planung sind, und im für alle aktuellen Interfaces gültigen MIDI Sysex Datenformat werden interessanterweise die Product IDs nicht im Detail gelistet.

Da ich die App von der Bedienung her ziemlich bescheiden finde, nehme ich mir einen meiner Rechner, auf dem ebenfalls iConfig installiert ist, aber nicht in der aktuellen Version 4.20, sondern in der vorigen 4.13. Auch diese erkennt das MIO4 sofort und kann auch alle Parameter einstellen.

Ich habe dann aber auch mal die aktuelle Version aufgespielt, und die zeigt dann auch ein Bild der Front des Interfaces im Infodialog an. Der Rest der Software hat sich (leider) nicht geändert und auch die Namen der MIDI-Ports, besonders die der über USB, ist wieder so seltsam wie beim MIDI4+ im Auslieferungszustand. Im Handbuch wird gesagt, das ist Absicht, damit man bei den USB Ports gleich sehen kann, wo sie hingeroutet sind. Die Idee hat durchaus was für sich, ich hab aber die Ports lieber eindeutig bezeichnet. Für alle, denen es genauso geht, habe ich mal eine Datei mit sinnvolleren Default Names erstellt und diese hier angehängt. Fürs MIDI4+ habe ich sowas auch, stelle ich hier ebenfalls bereit.

Bei dieser Gelegenheit mußte ich feststellen, daß die Datenformate der beiden Interface nicht miteinander kompatibel sind - eigentlich bei so nahezu identischen Geräten unverständlich. Zumindest hätte man das MIO4 die Daten des MIDI2+ einlesen und den Rest ignorieren lassen können - das MIDI Sysex Format ist ja auch identisch. Noch seltsamer ist, daß beim MIO4 immer zwei Dateien pro Preset gespeichert werden, wo das MIDI4+ nur eine Datei speichert (und mehr kann als das MIO4). Eigentlich verstehen die Jungs bei iconnectivity ihr Handwerk, aber offenbar können die besser embedded Hardware entwickeln als Desktopsoftware.

Was übrigens noch seltsamer ist: das extra von iconnectivity für die MIDI2+, 4+ und Audio 4+ entwickelte Lightning Kabel für iOS-Geräte funktioniert nicht am MIO4, während die Kombi aus CCK und USB-Kabel geht. Ich halte das für einen Bug und werde ich mal nachfragen, denn eigentlich kann man solche Kombikabel ja schon im Detail einstellen, was sie dann dürfen und was nicht. Da wird's wohl um die Ladefunktion gehen. Bin mal gespannt, was ich von denen als Antwort bekomme. Liegt vielleicht einfach nur an der Firmwareanpassung, daß man das schlicht rausgenommen hat, statt es anzupassen.

Ich bin ja normal auf dem Mac unterwegs, habe aber auch zwei Windowsmaschinen hier, und da eine davon mit Win7Pro läuft, habe ich dort mal iConfig 4.20 installiert - um damit eine Bauchlandung hinzulegen. Vom Programm wird nämlich Visual C 2013 Runtime installiert, aber da hakt es noch etwas, denn bei Programmstart bekam ich die Meldung, daß eine msvp100.dll fehlen würde. Nach etlichen Probieren mit erneutem Installieren und DLLs manuell runterladen, ohne daß es half, habe ich schließlich All in One Runtimes von sereby.org installiert und siehe da, jetzt lief die Software. Irgendwas stimmt aber noch nicht, den die Menüpunkte für Laden und Speichern von Presets sind ausgegraut. Ok, noch ein Ticket bei iconnectivity öffnen.


Die Unterschiede

An dieser Stelle mal etwas zu den Unterschieden. Weiter oben hatte ich bereits geschrieben, daß die neuen MIO2 und MIO4 aus den MIDI2+ und MIDI4+ abgeleitet sind, aber hier mal konkret zu den Unterschieden:

-Kein Audiopassthru
-2 statt 3 Deviceports beim MIO4
-kein Netzteilanschluß beim MIO2
-Netzteil beim MIO4 optional
-keine Ladefunktion für iOS Geräte an den Deviceports (das Lightning-Kabel aus dem eigenen Hause funktioniert komplett nicht mit den MIOs, was ich für einen Bug halte)
-MIO4 kann per USB mit Spannung versorgt werden (nur hinterer Port)

Im Betrieb

Eigentlich muß ich das Ding nicht wirklich auf Herz und Nieren testen, habe ich doch das MIDI4+ bei mir im Betrieb, seit es auf dem Markt ist, aber ich will das trotzdem mal tun, einfach aus Neugierde, zumal ich das MIDI4+ nicht komplett ausnutze.

Daher habe ich mir mal mit den lose rumstehenden Geräten ein Setup gebaut:

Yamaha RX120 an DIN1 (nur Ausgang)
Ensoniq SQ2 an DIN2
Yamaha TQ5 an DIN3
Microwave XT an DIN4
BeatStep Pro am USB Host Port

Ein Rechner oder iPad hängt am vorderen Deviceport, um das Gerät zu konfigurieren.

Im MIDI Infofenster werden bei den Hostports alle angeschlossenen Geräte namentlich angezeigt, zudem kann man pro Hostport auch die Geräte fest reservieren, damit sie immer auf dem gleichen Port landen (wichtig fürs Routing).

Im Auslieferungszustand werden ja alle Ports auf alles geroutet, sodaß man beim Anschließen erstmal direkt loslegen kann. Außerdem ist das ein guter Test, ob bei dieser Art Verteilung das Timing in die Knie geht. Eine Schaltfläche, mit der man alle Routings für den jeweiligen Port einfach löschen oder auf Default setzen kann, fehlt hier leider.

Der Beatstep Pro sendet ja MIDI Clock, die RX120 kann diese ebenso empfangen wie auch der Ensoniq SQ2 und auch der Microwave XT. Die Clock geht aber an alle 4 MIDI Ports und ebenso an alle USB Devices (16 Ports) und die 8 Host Ports.

Bei einem ersten Testaufbau hatte ich den BSP an meinen Novation KS-5 dran, und beim Stoppen haut der BSP jedesmal einen Controller raus, der mir den Sound beim KS verstellt. Also per MIDI Monitor den Übeltäter gefunden und gleich mal einen Filter im MIO4 gesetzt. Den kann man entweder am Ausgang des BSP oder am Eingang des KS setzen. Ich habe mich für den Ausgang des BSP entschieden, dann kann dieser Controller auch beim nächsten Testaufbau keinen Schaden anrichten.

Wie bei einer MIDI Patchbay auch, muß man bei solchen Sachen wie Filtern und Routings immer vom Interface ausgehen, also sind die Ein/Ausgänge umgekehrt, denn zB der BSP hängt ja mit seinem Ausgang an einem Eingang des MIO4. Demzufolge muß ich auch den Filter am Eingang des ersten Host-Ports setzen, der hier normal HST1 heißt, ich aber auf BSP umbenannt habe.
Ich wähle also den Reiter "MIDI Controller Filters", den Filter Type "Input", gehe auf den Hostport "BSP" und stelle im Klappmenü den General Purpose Controller 4 ein, den der BSP beim Stoppen auswirft. Dies geht im laufenden Betrieb, passiert aber etwas verzögert, da die Software die Befehle nicht sofort sendet - was durchaus sinnvoll ist, gerade wenn man mehrere Sachen ändert.

Das oben beschriebene Testsetup habe ich nun mit einer Sequenz aus dem BSP befeuert, welches alle Instrumente gleichzeitig abspielten - was natürlich ein heilloser Krach war, aber ohne irgendwelche Effekte, die auf Verzögerungen hindeuten würden.

Jetzt wollte ich, daß die RX120 nicht mit startet, also setze ich bei den Port Filtern am Ausgang zur RX120 den Klick bei System Realtime und schon bleibt sie stehen.

Als nächstes bringe ich einen weiteren Hardwaresequenzer ins Spiel, einen meiner beiden Kawai Q-80. Da ich aber keinen Anschuß am MIO4 mehr frei habe, schnappe ich mir das MIO und schließe es ans MIO4 an - in diesem Fall über einen USB Hub, da der Hostport ja bisher mit dem BeatStep Pro belegt war. Vorher noch in der MIDI Info das Häkchen bei "Enable routing between ports on multi-port USB devices" setzen, damit das auch so funktioniert, wie ich das vorgesehen hatte. Damit das frisch angesteckte MIO auch bei den Hostports angezeigt wird, mache ich 1x "reread settings" und schon ist es da. Nebenbei: Das am MIO4 angeschlossene MIO wurde durch die Software erkannt und sogar ein Firmwareupdate durchgeführt!

Q-80 starten, Sequenz laden und abfahren - läuft.
Q-80 auf externe Clock stellen, BSP starten - läuft auch.
Ich könnte ja noch die eingebauten Sequenzer von SQ-2 und TQ5 an die Clock hängen, aber das wäre gerade zuviel des Guten. Geht ja vor allem auch darum, daß bei Clockausgabe auf allen Ports gleichzeitig keine Verzögerungen auftreten.

Im Rahmen meines Drumcomputer Kreuz-und Quer-Tests (der noch nicht veröffentlicht ist) habe ich auch das MIO4 mal drangehängt, und zwar folgendermaßen:

TD-8: DIN1
RY20: DIN2
DR-770: DIN3
SR-16: DIN4
SR-18: MIO an HST

Hier habe ich ebenfalls, wie beim Setup mit dem Q-80 beschrieben, das einfache MIO als Erweiterung am USB Host Port eingesetzt. Hier könnte ich auch mein MIDI4+ oder jedes andere, x-beliebige classcompliant MIDI Interface einsetzen und es auch im Routing integrieren.

Es gab bei diesem Aufbau keinerlei Verzögerungen durch MIDI selbst.


Zu MIO2 und MIO10:

Das hier Gesagte gilt auch für das größere MIO10, welches einem erweiterten MIO4 entspricht, nur daß es statt der 4 DIN-MIDI Ports 10 davon hat. 7 davon befinden sich auf der Rückseite, 3 davon vorne. Die USB-und Netzwerkanschlüsse sind die Gleichen wie beim MIO4. Das MIO10 ist 19" 1HE, während MIO4/MIDI4+ Halfrack sind und die beiden 2er nochmal die Hälfte. Das MIO10 wird aber trotzdem mit einem externen Netzteil betrieben. Das MIO2 ist mit dem MIDI2+ bis auf den Netzteilanschluß identisch, muß also immer über USB versorgt werden, während man beim MIDI2+ die Wahl hat.

Genereller Hinweis zu Arturtia-Geräten:

Arturia hat leider bei seinen Geräten zwar USB classcompliant ausgelegt, aber so seltsam, daß es, wenns am Hostport des Interfaces hängt, nicht erkannt wird. Der BeatStep Pro zB meldet sich mit 2 Ports an, einer davon nennt sich BeatStep Pro Editor. Der macht eigentlich nichts, außer daß er der Software anzeigt, daß das Gerät am Rechner angeschlossen ist. Erst wenn dieser Port erkannt wird, spricht die Software MCC das Gerät an, mit ganz normalen MIDI Sysex Befehlen.
Was ich noch nicht probiert habe ist, ob man zB bei OSX im MIDI-Setup einen virtuellen Port des gleichen Namens anlegen kann und den normalen Port entsprechend routet, sodaß man nicht umstecken muß.

Fazit:

Sowohl das MIO4 als auch das MIDI4+ (und auch die anderen Modelle wie MIO10, MIO2 und MIDI2+) sind sehr gute MIDI-Interfaces mit Qualitäten einer MIDITemp Patchbay, was Timing, Filterung und Routing angeht, gehen also über normale MIDI Interfaces hinaus, da auch standalone verwendbar. Leider kann man im Gegensatz zu einer richtigen MIDI Patchbay wie einer MIDITemp nur ein Setup im Gerät speichern.

Welches soll man nun nehmen?

Ganz einfach: Wer die ganzen iPad-Zusatzfeatures wie Audiopassthru nicht braucht, ist mit MIO2, 4 und 10 bestens bedient.

Wer ein iPad im Setup hat und das auch entsprechend nutzen möchte, für den sind MIDI2+ und MIDI4+ die passende Wahl.

Ich hatte mir, wie ja hier zu Anfang zu lesen war, das MIDI4+ gekauft und das immer noch im Einsatz, ebenso das MIO4 neu dazubekommen, würde mir aber heute, wo ich das iPad nicht mehr so nutze, wie mal angedacht, würde ich das MIO4 nehmen, mir reichen 2 Computeranschlüsse völlig aus.
 
Hier die versprochene Datei mit den korrekten Default-Namen für das MIO4.

Auspacken und in den Ordner mit den Setups legen, der läßt sich in der Software einfach anzeigen bzw aufrufenm dann von dort aus in die Software und dann ins Interface laden.

Hinweis: In dieser Datei sind die USB-Deviceports auf 4 Ports begrenzt, die restlichen abgeschaltet. Pro Port werden ja 16 Kanäle bereitgestellt.

Leider werden die abgeschalteten Ports beim Routing trotzdem angezeigt.
 

Anhänge

  • MIO4defaultNames.zip
    2,7 KB · Aufrufe: 8
Man kann die Konfiguration auch als Midifile abspeichern.

Dann kann man sie mit jedem Sequencer oder Midifileplayer ins Interface laden.
Insbesondere kann man das Midifile im Sequencer gleich mit in das Projekt aufnehmen, hat dann mit dem Projekt also auch gleich die zugehörige Konfiguration parat.
 
Um den Alyseumthread nicht zu kapern, also hier weiter.

Die MIOs können leider nach wie vor nicht direkt per Ethernet miteinander verbunden werden.

Ich habe deshalb heute mal simuliert, wie die Latenz aussieht, wenn man per RTP-Midi Midinoten über zwei MIOs überträgt, mit einem Rechner als RTP-Midi Router dazwischen.

Da ich keine zwei MIOs habe, habe ich einfach zwei der 4 RTP-Midi Ports meines MIO10 benutzt.

Der Testaufbau sieht wie folgt aus

PC -> ETH1 -> MIO -> DIN 1 Out -> DIN 1 In -> MIO -> ETH1 -> PC -> ETH2 -> MIO -> DIN 2 Out -> DIN 2 In -> MIO -> ETH2 -> PC

Das entspricht dann einer Kette Keyboard -> DIN -> MIO1 -> PC -> MIO2 -> DIN -> Synth

PC mit Ubuntu 14.04, kernel 4.8.1, Realtime Priorität für Netzwerk.

Die Gesamtlatenz lag stehts bei ca. 2.35 ms

Allerdings verschlechtert sich die Latenz dramatisch (auf bis zu 9 ms) sobald man die Realtime Priorität für das Netzwerk wegnimmt.
 
Danke, sehr aufschlußreich, müßte ich mal mit meinen beiden 4ern probieren. Womit hast Du denn gemessen, eigene Software dafür gebaut oder einfach Signale drübergeschickt?
 
Einfach Midinoten mit dem Virtual Keyboard erzeugt und dann die Zeitstempel der RTP-Midi Pakete im Wireshark verglichen.

Interessant wäre mal der Vergleich mit einem Mac oder einem Arduino mit Ethernetshield.
 
Zuletzt bearbeitet:
Uh, ich kenne zwar einen der Wireshark-Entwickler, habe damit aber noch nie gearbeitet, würde das dann eher übers Gehör machen. Mal schauen, wann ich das angehe.
 
Das erste, was ich hier machte, war, die Portnamen umzubenennen. Die Vorlagen wollte ich ja mal hochladen fällt mir ein ...

Es hat sich was getan bei denen, hab auf der Messe mit einem Neuen von denen gesprochen, der die Entwicklung insbesondere der App weiter vorantreibt, die ganze Software müßte eh mal überarbeitet werden, hab schon eine Menge Ideen gesammelt.
 
Habe eben mit großem Aufatmen feststellen dürfen, dass die PortManager-App auch noch unter macOS 10.12.6 anstandslos mein uraltes iConnect MIDI (das allererste, die kleine schwarze Kiste von 2011) steuert.

"Not that anybody cares…"
 
Ich quote das mal aus dem anderen Thread hier rüber.

Zu MIO/MIDI+. Zum Ersten kann man die Devices komplett per Sysex konfigurieren.
Zum Zweiten ist gerade ein Open Source Configtool in Arbeit https://github.com/dehnhardt/mioconfig

Das Configtool ist von Dir, oder?

Die als MIDIfile gespeicherten Konfigs sind übrigens auch modellgebunden, da in den ersten 2-3 Dumps Name, Firmwareversion und MAC-Adresse des Interfaces drinstehen. Einen Dump vom MIDI4+ nimmt das MIO 4 natürlich so nicht, das müßte ich nochmal genauer analysieren.

Für Dein Linuxtool kann ich Dir gerne mal die Ideen, die ich für die Verbesserung des Originaltools notiert habe, geben. Auf jeden Fall sollten die abgespeicherten Konfigs zwischen den Geräten austauschbar sein, die nicht vorhandenen Ports sollten dann einfach beim Laden ignoriert werden, vielleicht sollte die Software ne Warnung ausgeben, die daruf hinweist, wenn man Daten eines größerem Modells in ein Kleineres importiert.
 
Nein, von mir ist der RTP-Midi Treiber. Das Tool ist von Holger Dehnhardt. Übers iConnectivityforum kann man den auch erreichen.
 
Nein, von mir ist der RTP-Midi Treiber. Das Tool ist von Holger Dehnhardt. Übers iConnectivityforum kann man den auch erreichen.

Wir sollten uns mal zusammentun, zB in einer Mailingliste, kann ich gerne aufsetzen und den Kollegen Mink99 noch dazuholen, der ebenfalls Entwickler ist.

Was Anderes: Ich muß das mit dem RTP MIDI nochmal probieren, vielleicht hab ich was falsch gemacht, aber ich hab die fixe Idee, das ICM4+/MIO4 als Host für den USB Only X-Touch Mini einzusetzen, um damit den noch anzuschaffenden MR12 anzusteuern, was ja direkt nicht geht, weil der MR12/XR12 am USB Host nur Storage erlaubt und der X-Touch Mini nur USB hat, der XR/MR12 aber sowohl Netzwerk als auch MIDI.
 
Update für Windows User:
iConnectivity hat jetzt einen eigenen multiclientfähigen USB Midi Treiber veröffentlicht.
Und auch einen eigenen RTP-Midi Treiber.
 
Neuer Windowstreiber und Firmware.

Wesentlichste Änderung: The MIDI+/MIOs sollen jetzt auch als RTP-Session Initiator arbeiten können, d.h. die Geräte sollen sich jetzt per Ethernet kaskadieren lassen.

Edit: Leider ist die Änderung anscheinend doch nicht drin, obwohl sie in den Releasenotes steht. Schade.
 
Zuletzt bearbeitet:
Gestern Abend war nichtmal die neue Firmware online, gehe gleich nochmal gucken. Standalone RTP MIDI wäre genial.

Inzwischen habe ich noch ein MIDI2+ zu meiner Sammlung hinzugefügt.

Falls jemand noch 30polige Dock-Kabel für die Interfaces brauchen sollte: davon hab ich jetzt zwei hier rumliegen und kann beide abgeben.
 
Jetzt ist die neue Firmware online.

Beim Start von iConfig zuerst die Firmwareupdatemeldung ignorieren, die Einstellungen speichern und dann Firmwareupdate abrufen. Sollte es nicht durchlaufen, das Programm nochmal starten und gleich zu Anfang die Updatemeldung quittieren.
 
die neue congif software sollte auch demnächst zu haben sein,zumindest als beta.....

Hoffentlich sind da die ganzen Bugs raus. Bin gespannt. Und hoffentlich werden jetzt auch die Einstellungen einheitlich gespeichert und der Speicherdialog zeigt nur dann Audiofelder, wenn es auch Audio gibt.

Das MIO4 meldet sich bei Windows immer noch als USB Verbundgerät an, was Blödsinn ist, denn im Gegensatz zu seinem Schwestermodell MIDI4+ wird ja kein Audio übertragen.
 
Wesentlichste Änderung: The MIDI+/MIOs sollen jetzt auch als RTP-Session Initiator arbeiten können, d.h. die Geräte sollen sich jetzt per Ethernet kaskadieren lassen.

Ich hab das heute mal probiert.

Da ich eh gerade ein zweites Setup, welches räumlich vom Ersten getrennt ist, aufgebaut habe, wurde dort gleich mal mein MIO4 mit der aktuellsten Firmware (2.03) ausgestattet, ans Netzwerk gehängt und per USB-Netzteil mit Spannung versorgt. Dann habe ich mit dem Macbook Air, WLAN only, geschaut, ob das MIO4 bei den Netzwerk-MIDI Geräten sichtbar ist: Jawoll, es erscheint, natürlich dann auch auf meinem MacMini, der am Netzwerkkabel hängt. Also gleich mal eine Session erstellt und einen Port verbunden, der wird auch sofort vom MIDI Monitor als Quelle akzeptiert und wenn ich auf den Tasten drücke, sehe ich die Daten. Sehr schön.
Das Ganze am MacMini, an dem das iconnect MIDI4+ per USB hängt, ebenfalls mal verbunden, die iConfig Software gestartet und whoo hoo, was ist das? In der Auswahl bei Start erscheint das per Netzwerk eingebundene MIO4! Jetzt bin ich aber platt, daß sich die Kisten auch per Ethernet fernkonfigurieren lassen.
Hab mir dann den Song vom Rechner des Zweitsetups geschnappt, ihn auf den Hauptrechner geladen, Ports angepaßt und siehe da, das Zweitsetup macht Töne. Jetzt wollte ich es genauer wissen und habe meinen Beatstep Pro des Hauptsetups mit dem Model D des Zweiten verbunden und mit schnellen 1/32 Noten wie "Franke-Triller" befeuert - einwandfrei, auf den Punkt, keine Ausfälle.

Was ich aber nicht geschafft habe ist, die beiden Interfaces direkt per Ethernet zu verbinden, das ging nur über den Rechner - oder ich bin zu blöd. Auf dem MIDI4+ ist noch die Firmware 2.0 drauf, nicht 2.03. Eine IP-Adresse erscheint in der MIDI Info von iConfig erst, wenn ich einen Port in der Netzwerksession verbunden habe, dann aber auch mit dem Defaultnamen ETH1, während das MIO4 sich mit MIO4-048-01 identifiziert.

Negativ: Seit der Firmware 2.0 werden über den USB Hostport angeschlossene iConnect-Interfaces nicht von der Config-Software erkannt, sodaß man sie zum Editieren umstecken muß. Beim Hostport selbst ist alles Ok. Habe den Fehler schon bei 2.0 gemeldet, ist aber in der 2.03 immer noch vorhanden, weshalb ich meist auf die 1.8 zurückgehe (habe ich hier gesichert).
 
Der Initiatormode soll in der Firmware bereits vorhanden sein, aber iConnectivity will den Sysexbefehl zur Aktivierung noch nicht herausrücken. Gibts wohl erst wenn Auracle fertig ist.
 
Gibts wohl erst wenn Auracle fertig ist.

Da haben die aber noch bissl was zu tun. Auracle ist unter Windows derzeit schlicht unbrauchbar, weil komisches Rendering der Schriften, das kann man nicht lesen.

Initiieren geht ja, siehe oben, das MIO4 hing ja nicht am Rechner, heute habe ich das gleiche Spiel umgedreht getestet und das MIDI4+ des Hauptsets, bei dem der Rechner ausgeschaltet war, vom Zweitset-Rechner (einem alten Powerbook G4 mit OSX Tiger) ferngesteuert.

Was fehlt, ist ein Hostmodus. Da kann man doch sicher was mit einem Raspberry Pi machen, oder? Ich PN Dich da mal an.
 
Initiatormode = Das Gerät stellt sebständig eine Verbindung zu einem oder mehreren anderen Gerät(en) her.
Ich denke das ist das, was du unter Hostmode verstehst. Quasi wie AVB für Midi.
 
Hm. Wie nennt sich denn der seit der 2.0 implementierte Modus, mit dem eine Netzwerkverbindung ohne Zutun eines Rechners geht?
 
Hallo miteinander

Zu den iConnectivity MIDI devices will ich auch mal meine Erfahrungen hier beisteuern.

Mein altes Setup:
MotU MIDI TIMEPIECE (I)
daran sind folgende MIDI devices:
- Roland R8M
- Roland OCTAPAD
- Alesis D4
- Alesis Quadraverb
- Lexicon LXP-1 &
- LXP-5
- PCM80
- PCM90
- MRC

MotU MIDI TIME PIECE II
- Kurzweil 1000PX+
- Roland JV2080
- Yamaha TG77
- Korg Wavestation SR
- EMU PROTEUS VINTAGE KEYS+
- EMU Ultra Proteus
- KAWAI MP9000
- ROLAND A-50 Master Keyboard
die beiden MotU´s sind via MotU´s RS422 IF miteinander verbunden.
vom MTPII ging es via PC ISA Karte in einen Win2k PC.

Dieses "old school" Setup ließ sich vom PC oder Standalone vom A-50 wunderbar steuern (bis ca. 2003), da das MTPII 8 Setup Speicher hatte, welche sich via MIDI Cmd umschalten ließen.

Der MotU Treiber hat unter WinXP nie richtig funktioniert, da die ISA Karte nicht mehr unterstüzt wurde. So wurde dieses System nur noch "stand alone" (ohne PC) betrieben.

Jetzt haben wir 2018 und ich habe mir vor einiger Zeit die iConnectivity IFs 1 x MIDI4+ & 2 x mio10 zugelegt.
Der Grund: RTP MIDI Unterstützung.

Bis FW Version <V2.0 war jedoch nur der Typ "Session Listener" implementiert.
Es brauchte also immer einen PC/MAC, der als "Session Initiator" fungierte.
Das einzige MIDI IF, das auch diese Funktion unterstützte, war das CINARA MidiGateway. Dies erscheint mir jedoch mit seinen Möglichkeiten überteuert.

Seit FW V2.0? sollen ja die iConnectivity MIDI IFs mit Netzwerkanschluss auch die RTP Funktion " Session Initiator" unterstützen.
Um diese Funktion zu aktiveren, braucht es aber die Appl. Auracle V1.3 beta.
Ich persönlich hasse diese Apps., da es m.A. ausser zum Definieren von "Session Initiator" zu nichts zu gebrauchen ist.

Ich habe also auf dem MIDI4+ die max. zulässigen 4 RTP Sessions definiert und verschiedene Performance-Tests zwischen iCon. MIDI4+ & dem iCon. mio10 durchgeführt.

Als Mess-PC verwendete ich ein altes IBM Thinkpad mit Windwos XPembedded und einem Roland USB MIDI IF: UM-1SX
Mess-SW ist MIDITest V4.12. Diese gibt es nicht mehr f. aktuelle OS!
Das LAN dieses PCs ist nicht in Betrieb.


Test Bedingungen:

Alle iConnectivity MIDI Interfaces wurden nach ihrer Konfiguration vom PC getrennt.

Message count: 31250 Sysex count: 158
Sysex size: 9999 Sysex passed: 9999

Note off: yes
Note on: yes
Key aftertouch: yes
Controller: yes
Program change: yes
Channel aftertouch: yes
Pitchbend: yes
System exclusive: yes
MIDI time code quarter frame: yes
Song position pointer: yes
Song select: yes
Tune request: yes
MIDI clock: yes
MIDI tick: no
Start: yes
Continue: yes
Stop: yes
Active sensing: no
System reset: yes
System exclusive mixed with realtime messages: no

Ports:

MIDI Output: 1:EDIROL UM-1 MIDI
Description: EDIROL UM-1
Provider: Roland
DriverDate: 9-29-2006
DriverVersion: 2.0.2.0


MIDI Input: 1:EDIROL UM-1 MIDI
Description: EDIROL UM-1
Provider: Roland
DriverDate: 9-29-2006
DriverVersion: 2.0.2.0


1. UM-1 SX mit Loopback UM1 MIDI Out -> MIDI In:
Message latency: 0.68 ms
Message jitter: 0.42 ms
Message max deviation: 1.52 ms

2. MIDI4+ Local; UM-1 Out -> Local In1 -> Local Out2 -> UM-1 In:
MMessage latency: 1.56 ms
Message jitter: 0.64 ms
Message max deviation: 1.78 ms

3: mio10 Local: UM-1 Out -> Local In1 -> Local Out2 -> UM-1 In:
Message latency: 1.56 ms
Message jitter: 0.64 ms
Message max deviation: 1.78 ms

4.MIDI4+ mit RTP MIDI & unmanaged Netzwerk Switch:
UM-1 Out -> MIDI4+ In1 -> MIDI4+ RTP -> Switch -> mio10 RTP -> Mio10 Out1 -> UM-1 In
Message latency: 1.40 ms
Message jitter: 0.67 ms
Message max deviation: 1.93 ms

5. MIDI4+ mit RTP MIDI direkt zu mio10:
UM-1 Out -> MIDI4+ In1 -> MIDI4+ RTP -> mio10 RTP -> Mio10 Out1 -> UM-1 In
Message latency: 1.47 ms
Message jitter: 0.66 ms
Message max deviation: 1.87 ms

Bemerkungen:
1. Von den Messungen (2..5.) sind noch die Latenz von Messung 1. (0.68 ms) abzuziehen.
2. Als LAN Verbindung zwischen MIDI4+ und mio10 kann ein ungekreuztes CAT5 Kabel verwendet werden.
3. Die Verzögerung der MIDI Meldungen liegt bei einer 3 byte MIDI message bei allen Messungen 2. bis 5. bei ca. 1 ms. Dies ist unabhängig, ob Lokal oder oder via RTP.
4. Der Jitter liegt bei allen Messungen bei max, 1.9 ms und kann nicht eindeutig dem RTP IF zugeordnet werden, sondern ist immer die Summe aus UM-1 und Messobjekt.

Liebe Grüße
Jo
 
Zuletzt bearbeitet:
Auracle 1.3 Beta ist raus mit besagtem Initiatormode.

Heute getestet, läuft prima, auch wenn Auracle zuerst reproduzierbar beim Trennen der des zweiten Interfaces abstürzte. Konnte jetzt beide Interfaces, also mein MIDI4+ am Hauptset mit dem MIO4 am Zweitset verbinden, auch wenn Auracle fürs MIDI4+ meckert, es wäre ja nicht im Netzwerk. Der Beatstep Pro spielte dann den MicroX am Zweitset und auf den Punkt. Sauber.

Hab auch mal die Sysex Kommunikation mitgeschnitten, vielleicht kannst damit ja etwas anfangen:

RTP Initiator Sequence

Gesendet an Interface:
F0 00 01 73 7E 00 06 00 00 00 03 4F 01 39 40 7F 00 1A 01 00 3D 01 0F 07 00 00 00 00 00 00 27 0C 0B 6D 69 6F 34 2D 30 34 38 2D 30 31 32 F7
(nach 0B steht hier „mio4-048-012“, das ist der Name des ersten ETH Ports meines MIO4, unterstrichen)

Antwort:
F0 00 01 73 7E 00 06 00 00 00 03 4F 01 39 00 0F 00 03 40 7F 00 1D F7

Gesendet:
F0 00 01 73 7E 00 06 00 00 00 03 4F 01 3A 40 2C 00 03 00 3D 01 40 F7


Antwort:
F0 00 01 73 7E 00 06 00 00 00 03 4F 01 3A 00 2D 00 0D 01 00 3D 01 00 00 00 00 00 00 00 00 00 74 F7


Gesendet:
F0 00 01 73 7E 00 06 00 00 00 03 4F 01 3B 40 2C 00 03 00 3D 01 3F F7

Antwort:
F0 00 01 73 7E 00 06 00 00 00 03 4F 01 3B 00 2D 00 18 01 00 3D 01 0C 05 20 00 12 00 27 0C 0B 6D 69 6F 34 2D 30 34 38 2D 30 31 17 F7

(hier wieder ab 0B der Name „mio4-048-01“ des ETH Ports, aber ohne die "2")


RTP Disconnect

Gesendet:
F0 00 01 73 7E 00 06 00 00 00 03 4F 01 3C 40 7F
00 06 01 00 3D 01 0F 05 53 F7

Antwort:
F0 00 01 73 7E 00 06 00 00 00 03 4F 01 3C 00 0F
00 03 40 7F 00 1A F7

An irgendeiner Stelle wird dann wohl vorher der Name des Netzwerkports des Gegeninterfaces abgefragt.
 


Zurück
Oben