Notenhänger bei mehr als 1 Midi Port Input

RonB

RonB

Registriert
21.09.15
Beiträge
496
Reaktionen
269
Punkte
1.340
bin seit heute neu hier und komme gleich mit einem recht merkwürdigen Phänomen. Das hält mich seit Tagen auf Trab.

Es gibt nirgends im Netz einen Hinweis auf das gleiche Problem. Aber erst mal die Vorgeschichte: Schon Jahre schätze ich Sonar. Derzeit nutze ich X3 (Standard) was für meine Zwecke völlig ausreicht. Besonders das gelungene Audio-Handling hat es mir schon immer angetan. Leider steht dazu im krassen Gegensatz das nach meiner Meinung nicht so tolle Midi-Editing.
Wer einmal das geniale Midi Edit-Handling in Logic (5.5.1, ja das ist uralt) innerhalb der Notendarstellung erlebt hat, weiß wovon ich rede.

Jedenfalls habe ich schon seit Jahren diese beiden Vorteile zusammengebracht. Das Midi erledigt Logic auf Computer #1. Jeglicher Ton, der hörbar werden soll wird auf Computer #2 erzeugt. Logischerweise erfolgt das Zusammenspiel mittels 2er Midi Interfaces (von M-Audio, Midisport 2x2). Irgendwann ist Midi Bearbeitung abgeschlossen, es wird auf Computer #2 übertragen, die Tracks in Audio umgewandelt und der Final Mix auf Computer #2 beginnt. Alles funktionierte bisher reibungslos.

Entweder liegt es am (neuerdings upraded) Windows 10 oder es war mir bisher nicht aufgefallen, weil ich an diese Grenze nie kam. Und damit zum Problem: Die Midisport 2x2 verfügen ja über 2 Ports, jeweils mit 16 Midi Ch. Die sind auch bitter nötig, wenn mal was umfangreiches an Library benötigt wird. In meinem Fall nutzte ich Play mit East West Libraries (Hollywood Strings etc.).
Nun muss man ja tunlichst das Play-Plugin in einer 2ten Instanz auf weitere Spuren legen, wenn bei der ersten Instanz die 16 Ch. "verbraten" sind. Und genau da geht es plötzlich mächtig schief ! Erst dachte ich, das wäre ein Peformance- oder Buffer- Problem irgendwo. Mitnichten. Hier die derzeitige Testumgebung, die so einfach ist, dass es deutlich wird.

In Sonar X3 liegt Play und hat eine Peformance, die auf Midi Ch 1 lauscht. Angesteuert wird Play durch die Midi Instrumentenspur, der ihrerseits mitgeteilt wurde, sie möge auf alle Kanäle des Interface #A lauschen und an Play weiterleiten. Das klappt auch ! Nun wirds lustig. Auf dem Quellcomputer #1 wird ein 2ter Midi Track zugeschaltet, der aber das Interface #B des Zielcomputers anspricht. Die Logik sagt uns, dass diese Midi Daten normalerweise "unter den Tisch" fallen, da sie auf dem Zielcomputer gar nicht zugeordnet werden. Das klappt auch, ABER NICHT IMMER ! Nach wenigen Sekunden gibt es bei Play einen bzw. mehrere Notenhänger ! Nicht vorhersehbar, bzw. reproduzierbar, an welcher Stelle. Hallo ?!? Wieso beeinflussen diese Daten einen Bereich, der gar nicht gerouted wurde?
Selbstverständlich geht das auch schief, wenn eine Zuordnung durch eine 2te Instanz von Play stattfindet. Und noch mehr geht es schief, wenn Instanz #1 alle 16 Ch. voll hat, und Instanz #2 ein paar weitere Sachen spielen soll. Was ist da los?

Summa Sumarum: Notenhänger, wenn Midi Daten auf einem weiteren (!) Port hereinkommen, egal ob sie verarbeitet werden oder nicht. Komischerweise klappt es wieder, sobald die Midi Daten erst mal in Tracks an Bord von X3 sind. Inclusive Controller Daten darf es dann auch gern mächtig zur Sache gehen, alles läuft.

Es betrifft auch Sonar Artist(Demo wurde installiert)mit gleichem Phänomen. Auch an Play liegt es wahrscheinlich nicht, denn Kontakt kommt mit dem gleichen Phänomen. Sogar Microsoft GS Wave-Trallala macht das gleiche. Es hängt. Leider hat man beim Sonar Support bisher keine Lösung bzw. Antwort. Eventuell hat ja hier jemand die rettende Idee.

Besten Dank für die Aufmerksamkeit

Gruß Ron
 
Ich würde nicht auf die DAWs tippen. Nach dem Ausschlussverfahren könnte es sein, dass der Treiber für die Midisports noch ein Problemchen mit Windows 10 hat. Ich nutze zwar auch ein Midisport 2x2 unter Windows 10 ohne derartige Probleme. Das könnte aber daran liegen, dass nur ab und an für externe Hardware einsetze, das Setup also weitaus einfacher ist und dadurch nicht so fehleranfällig. Eventuell könnte auch eine MIDI-Schleife zu so einem Verhalten führen.
 
... könnte es sein, dass der Treiber für die Midisports noch ein Problemchen mit Windows 10 hat...

Ja, da kommen wir zu ähnlicher Einschätzung. Dummerweise kann ich das unter Win 7 (übrigens alles 64 Bit) nicht testen, da ich das ja auf 10 upgegraded habe. Eine Midi Schleife schließe ich mal aus (Du meinst ein Feedback?). Das würde dann doch einen sofortigen Midi-Kollaps an gleicher Stelle bedeuten?

Ich habe auch schon erwägt, dass vielleicht Logic irgendeinen "Müll" schickt. Kann ich aber auch ausschließen. Als Sender wurde alternativ (Demo-) Artist verwendet, mit gleichem Resultat.

Hm, wo ich das gerade schreibe... Ich machte vorhin mal einen Test, wo ich Play als Standalone einsetzte. Also ohne Sonar. Wenn ich dort den 2ten Port des Midisport öffnete, passierte das gleiche. Allerdings ist mir dieses Scenario sehr suspekt. Ich kann zwar den 2ten Port des Midisport öffnen, aber WOHER "weiß" denn Play eigentlich, welcher Midi Ch auf welchem Port gemeint ist?! Das kann man nämlich nicht explizit zuordnen. Am Ende liegt da der "Hund begraben" :( Denn was Standalone nicht richtig durchdacht ist, wird doch als Plugin auch nicht funzen?

Ich weiß es nicht.
 
Einen kompletten Kollaps würde eine MIDI-Schleife nicht erzeugen. Nur eben hängende Noten.
Wenn man dem Plugin in SONAR als Eingang nur Port 1 Kanal 1 gibt, sollten da eigentlich nur Daten ankommen, die auf diesem Kanal gesendet werden.
Könnte natürlich auch sein, dass die Play-Engine selbst noch nicht zu 100% kompatibel mit Windows 10 ist. Dennoch dürfte sie in SONAR kein Signal von einem anderen Input als dem auf der Spur angegebenen erhalten. Von daher tippe ich auf den Treiber.
 
@RonB

Also wenn Du sagst, dass es auch bei Kontakt auftritt, dann können wir sämtliche Play-Verdachtsmomente beiseite schieben. Dann bringt es auch nichts wenn ich sage, dass von all meinen virtuellen Samplern das Play die meisten Probleme mit hängenden Noten und Aussetzern macht.
smil470009513826a.gif




Nun, mein Verdacht liegt auch eher beim MIDI-Interface oder dessen Treiber. Voraussgesetzt Du hast wirklich sicher gestellt, dass in der Instrumentenspur von Sonar unter MIDI Eingang auch wirklich der Port #A vom Interface ausgewählt wurde.

Denn was Standalone nicht richtig durchdacht ist, wird doch als Plugin auch nicht funzen?

Das Handling von MIDI und Audio ist allerdings bei Standalone eine ganz andere Geschichte wie als Plugin im Host. Da kann man leider keinen relevanten Zusammenhang bilden.


Ich würde mal folgendes versuchen. In Kontakt gibt es ein globales Script unter Utils, den MIDI Monitor. Mit dem kannst Du dann sehen, was für Daten in Kontakt ankommen. Ich habe 2 Screenshots dazu mal angehängt.

Und wenn Daten vom Port #B kommen obwohl eigentlich #A eingestellt ist, dann ist das Problem irgendwo schon vorne dran.
Wähle doch dann im Instrumenten Kanal von Sonar mal ein ganz anderes Interface als Eingang aus und schaue ob dann die Daten immer noch in Kontakt ankommen. Wenn dann nicht, dann weißt Du das es ein Problem spezifisch mit dem Midi-Interface zu tun hat.

Also ich kann Dir sagen, dass ich bislang (auch unter Windows 10, allerdings neues Sonar) keine Probleme mit MIDI Routing habe und bei mir wird auch einiges durch externe oder virtuelle Interfaces geroutet.

Bezüglich Windows 10 muss man aber auch erwähnen, dass es für Sonar X3 keine offizielle Win10 Kompatibilität gibt. Somit der Support von Cakewalk hier also eingeschränkt werden könnte.

-Markus
 

Anhänge

  • Kontakt-Midi-Monitor1.jpg
    Kontakt-Midi-Monitor1.jpg
    40,9 KB · Aufrufe: 296
  • Kontakt-Midi-Monitor2.jpg
    Kontakt-Midi-Monitor2.jpg
    29,1 KB · Aufrufe: 313
Ich würde mal folgendes versuchen. In Kontakt gibt es ein globales Script unter Utils, den MIDI Monitor...

Danke für den Tip! Kannte ich noch gar nicht. Liegt wohl daran, dass Kontakt bei mir etwas eingeschlafen ist.

Das half ungemein. Wie man unten sehen wird, macht Kontakt und Play eigentlich alles richtig: Denn wenn sie einen NoteOn bekommen und nie einen passenden NoteOff dann wird der bis in alle Ewigkeit dudeln ;) Ich musste jeweils immer etwas warten, bis der Fehler wieder auftrat. Aber dann war's soweit

3 Screenshots dazu:

Nr. 1 zeigt den roten Pfeil mit NoteOn auf Gb4. Das witzige: an dieser Stelle ist gar kein Gb4 dran! sehr wohl aber 2 Events vorher (grün gestrichelt) was aber per NoteOff abgearbeitet wurde. Was tatsächlich dran wäre, ist G4. Das wiederum findet sich auch auf Port #B, der "nirgends" hingerouted wird. Den Wahnsinn komplettiert ein NoteOff von G4 (grüner Pfeil) was wiederum korrekt ist. Allerdings könnte man jetzt eine hitzige Debatte darüber führen, ob dieses NoteOff das "richtige" aus Port #A oder ein "falsches" aus Port #B ist
smil69.gif
Da NoteOff des fälschlichen Gb4 fehlt, hängts.

Nr. 2 deckt auf, dass es tatsächlich ein Event aus Port #B geschafft hat, sich da einzuschmuggeln (roter Pfeil), identifizierbar am MIDI Ch. 15. Auch dieses Event erfährt kein NoteOff und hängt folglich.

Nr.3 (Setting) beweist, dass nur Port #A gerouted wird.

Zur Erinnerung: Diese Erscheinungen treten nicht nachvollziehbar aber sporadisch auf und machen ein "falsches" Setting daher eigentlich unwahrscheinlich.

Es bleibt auch die bange Frage, ob diese falschen Events den Quell-Computer evtl. so verlassen haben ?! Wie ich das protokollieren soll..
smil451e7746efcd9.gif
 

Anhänge

  • fehler1.jpg
    fehler1.jpg
    20,5 KB · Aufrufe: 311
  • fehler2.jpg
    fehler2.jpg
    27,7 KB · Aufrufe: 306
  • Setting.jpg
    Setting.jpg
    44,5 KB · Aufrufe: 322
So, nun weitere Tests gemacht. Mit Hilfe von MIDI-OX konnte ich neue Erkenntnisse gewinnen, nachdem ich die In-Ports des Midi-Sport "angezapft" hatte.

Ich habe eine kurze Sequenz als Loop definiert. Die gibts als Bild 1. Sonar tat mir den Gefallen und hat beim ersten Start dieser Sequenz funktioniert. Ein Vergleich mit MIDI-OX zeigte dann auch Übereinstimmung in den Events (Speed 255bpm)

Schon beim nächsten Test gab es wieder das übliche Desaster. Nun aber die Überraschung: MIDI-OX zeigte nach wie vor die korrekten Events, die an den In-Ports von diesem ausgelesen wurden!

Bild 2 zeigt diese richtige Liste. Bild 3 dagegen die Events, die von Sonar aus Port #A (sollten eigentlich alle Midi Kanal1 sein) aufgezeichnet wurden. Völlig daneben ! Die Vermutung eines faulen Treibers des Midi-Sport ist doch damit dahin? Denn wenn dieses Tool die korrekten Events ausliest, sollte das Sonar auch können. Ich vermute einfach mal, dass Sonar da mit den verschiedenen Ports heftig durcheinander kommt.

Oder kann sich jemand vielleicht doch eine Fehl-Bedienung/Einstellung vorstellen?
 

Anhänge

  • sequenz.jpg
    sequenz.jpg
    12,5 KB · Aufrufe: 294
  • Liste.jpg
    Liste.jpg
    125,6 KB · Aufrufe: 287
  • Events.jpg
    Events.jpg
    126,1 KB · Aufrufe: 319
Diese beiden Screenshots miteinander zu vergleichen ist jetzt etwas mühsig, da die Informationen recht unterschiedlich dargestellt werden und auch in unterschiedlicher Oktave notiert sind.

Die Frage ist wirklich, wieso kommen einzelne Events auf Kanal 15 durch, welche eigentlich nur auf Port 2 anliegen. Es kommen ja nicht alle von Port 2 durch, sondern im Beispiel-Screenshot nur 2 Events.

Somit denke ich nicht an ein Konfigurationsproblem, denn hättest Du was bei der Ein- Ausgangszuordnung in Sonar doch falsch eingestellt, würden alle Events von Port 2 eintreffen und nicht vereinzelt.

Wäre es ein Fehler (Bug) von Sonar, dann wäre dir dies aber auch schon vor deinem Upgrade auf Windows 10 aufgefallen, denn Dein Testprojekt ist ja jetzt nicht irgendwie grenzwertig und besonders belastend.
Somit liegt die Offensichtlichkeit eher bei Windows 10.

Ich arbeite schon seit Jahren mit mehreren Ein- und Ausgehenden MIDI Ports unter Sonar und ein solches Fehlverhalten wäre mir schon längst aufgefallen. Ich habe allerdings kein Midisport Interface.

Bei mir war nach dem Windows 10 Update auch ein zwingendes Update meines Focusrite Firewire Interface-Treiber notwendig, weil es Audiohänger gab.

Mal noch eine weitere Frage. Wie ist denn das Midisport physikalisch am Windows 10 Computer angeschlossen, per USB? Hättest Du noch ein anderes Midi Interface zur Hand?
Meine Idee hinter der Frage ist, mal nur den Port #A mit dem Computer zu verbinden.

-Markus
 
Hallo Markus,
ja, das Midisport ist ein USB Teil. Ich bin ja bei MIDI kein Freund von USB. Hab vor Tagen mal geschaut, unfassbar. Da gibt's ja nur USB auf dem Markt.

Wenn ich nur Port #A verbinde, bzw auf #B keine Daten ankommen lasse(egal, ob gerouted oder nicht) dann ist alles beste Sahne. Ich spule jetzt einfach mal noch offene Ideen ab, inclusive am Ende ein Rollback nach Win 7. Mal sehen, wie das ausgeht. Zurück auf Win 7 insbesondere deswegen, weil ich heute Mittag mal eine funktionierende Version (auf nur 1 Port) hatte, wo aber das Midi-Timing bei genauem Hinhören regelrecht gruselig war. Sogar einzelne Noten eines Mehrklangs wurden einfach mal verschluckt. Zwar selten, aber es passierte.

Gruß Ron
 
Zunächst die gute Nachricht. Wie ich oben schrieb, läuft der Laden erstaunlich präzise, wenn die MIDIs alle "Im Kasten" sind, sprich, wenn Sonar sie erst mal als Tracks vorliegen hat, und kein externer Midi-Traffic zu bewältigen ist.
 
Hi Ron,

der USB Anschluss des Midisport geht ja nur in eine Richtung, ich vermute der hängt am Sonar-Rechner. Eingehend kommen die Daten, wenn ich richtig verfolgt habe, mit normalem Midi Kabel vom Logic-Rechner. Und was verwendest Du dort für ein Midi Interface?

Hättest Du die Möglichkeit das ganze Szenario mal umzudrehen, also den USB Anschluss in den Logic Rechner?



Zur Musik.
Bei schnellen Midi Daten ist hauptsächlich der Sampler gefragt. Für eine DAW wie Sonar ist es kein Problem sehr schnell MIDI Daten zu versenden. Die Systemlast entsteht da nicht durch die Midi Verarbeitung, sondern das der Sampler (Play) enorm viele kleine Audiosamples laden und streamen muss. Aussetzer gibt es da meist nicht auf dem Midi Weg, sondern bei der Audioverarbeitung des Samplers.

Ja die EW Hollywood macht das sehr gut, ist halt eben auch eine wirklich tolle Lib.



Ich weiß nicht ob Du nicht irgendwann das Ziel verfolgen solltest, alles in einer DAW oder zumindest in einem Rechner zu haben.
Klar, der Noteneditor von Sonar ist nicht das Gelbe vom Ei. Dieser dient aber nicht dazu, darin wirklich großartig Musik zu schreiben.
Ich sehe eine mögliche Lösung vielleicht darin, mit einem Notationsprogramm wie Sibelius oder Notion zu arbeiten. Am besten auf dem gleichen Rechner wie Sonar.

Bei der Übertragung der Midi Daten frage ich mich zudem noch, warum Du das via Midi Aufnahme machst und nicht einfach MIDI Files transportierst?

-Markus
 
Und was verwendest Du dort für ein Midi Interface?

Na ja, dreimal darfst Du raten: Auch ein Midi-Sport, allerdings noch ein recht betagtes, die grasgrüne Schachtel.

Meine Audiophile 192 hat ja auch einen Midiport. Die war vorher Im Sonar-Rechner auch drin. In der Tat hab ich das ganze vor 2 Tagen mal umgedreht. Ergebnis ist aber das gleiche.

...und nicht einfach MIDI Files transportierst?

Stimmt genau, so mach ich das auch immer. Ich wollte aber einfach das Verhalten beobachten.

In grauer Vorzeit hatte ich mal den Logic-Vorgänger Notator, da kaufte ich mir deswegen sogar nen Atari.

Ich werd mal kurzzeitig mein Win 7 wieder zurückspielen und sehen ob sich da was tut. Wenn da keine Besserung eintritt kann ich ruhigen Gewissens Win 10 behalten.
 
In der Tat hab ich das ganze vor 2 Tagen mal umgedreht. Ergebnis ist aber das gleiche

Wenn Du es umgedreht hast, dann müsste es Dir doch eigentlich möglich sein, zwar beide Ports in das Interface schicken und aber nur einen Port zum Sonar Rechner führen.
Wenn dann immer noch beide Ports am Rechner ankommen, dann geschieht schon im Interface was falsches.

-Markus
 
ach so ! da hab ich Dich missverstanden. Aber das hatte ich ja (vielleicht missverständlich) geschrieben. Sobald nur ein Port Daten schickt, ist alles wunderbar. Dabei spielt es keine Rolle, ob er verbunden ist oder nicht. Das kann also beispielsweise dadurch geschehen, dass im sendenden Logic alle Spuren gemuted werden, die den Port #B nutzen
 
Und wieder neue Erkenntnisse:
Nachdem Win 7 versuchshalber zurückgespielt wurde, ergab sich keine Besserung.

Dann hab ich mal den Midi-Fluß umgedreht. Also vom Sonar-Rechner zum Logic-Rechner geschickt. Überraschung: Da läuft es wie geschmiert. Ich sehe nun 2 mögliche Ursachen.

1.) der Treiber des Midisport(die habe ich mittlerweile auch getauscht) kommt mit dem 64 Bit System nicht zurecht

2.) der Rechner selbst (Bios?Hardware?) stellt das Problem dar.

Derzeit wird Win 10 wieder zurückgespielt. Wer weitere "wilde" Ideen hat...
 
@Ron

Eine weitere Idee wäre es auf Hardware-Interfaces zu verzichten und die MIDI Daten via virtuelle MIDI-Ports über Netzwerk zu schicken.
Das geht mittels Software wie ipMidi von nerds.de. Spart Kabel und USB Ports. :)

Und wie stehst Du eigentlich zu dem Vorschlag, komplett auf den zusätzlichen Logic-Rechner zu verzichten und alles im Sonar Rechner zu machen?
Wenn ich Dich richtig verstanden habe, benutzt Du das Logic hauptsächlich wegen der besseren Noteneingabe. Der Noteneditor von Sonar taugt da ja nicht so.
Ein vernünftiges Notationsprogramm wie Notion oder Sibelius könnte hier eine Lösung darstellen.

-Markus
 
@Markus


...und die MIDI Daten via virtuelle MIDI-Ports über Netzwerk zu schicken.
Das geht mittels Software wie ipMidi...

wow! das ist ja ein feines Stück Software. Habe mir die Trial runtergeladen und bin völlig weg und alle :) Wem sagst Du das. Kabel/Treiber, ade !
Hätte ich Dein Posting mal abgewartet. In der Zwischenzeit kaufte ich mir ein 4x4 Interface was auch gar nicht schlecht ist. Du ahnst es aber vielleicht schon. Gleiches Phänomen. Aber nicht nur das. Sondern auch das ipMidi bringt keine Besserung. Das ist doch zum Mäuse melken :vangry:

Wer oder was spuckt mir da in die Midi-Suppe ?

Ein vernünftiges Notationsprogramm...
...habe ich bereits ;)

Außerdem, bedenke, irgendwas stimmt hier nicht, und es könnte mir passieren, dass nach Anschaffung eines "vernünftigen" Programms der Trouble auf anderer Baustelle weitergeht. Morgen erst mal das neu angeschaffte Interface zurück. Denn ipMidi überzeugt sofort. 20 Ports mit traumhaften Latenzzeiten. Das ist der Kracher...

Wie es allerdings dann mit meinen Notenhängern weitergeht, keine Ahnung. Jetzt sind mir die Ideen ausgegangen. Aber herzlichen Dank für den Tip mit ipMidi.

-Ron
 
Durch den Versuch mit ipMidi weißt Du zumindest, dass es kein Interface Problem ist und auch keines mit dem Treiber des Midisport.

Meine Ideen gehen dann aber leider langsam auch zur Neige.
smil451c70cce146f.gif




Ich habe bei mir die Tage mal versucht das nachzustellen und konnte keine solchen Midi Querschläger feststellen. Allerdings habe ich kein Sonar X3 mehr drauf, sondern arbeite mit der aktuellen Version unter Windows 10.

Da wäre natürlich noch die Idee, mal die aktuelle Sonar Demoversion zu laden. Die neue Version lässt sich parallell zu X3 betreiben, ist also kein direktes Upgrade.

Und irgendwie kann man auch mal alle Einstellungen auf Default zurücksetzen, wie genau weiß ich jetzt aber nicht.

-Markus
 
...mal die aktuelle Sonar Demoversion zu laden...
Hatte ich ja erwähnt. Das hab ich auch schon probiert. Keine Änderung. Was mich stutzig macht: Offenbar bin ich weltweit der einzige (bis auf eine Ausnahme, wo ich neulich was ähnliches las, finde das aber jetzt nicht mehr), der dieses "Problem" hat.
Auch ein langes Gespräch heute bei Session in Frankfurt auf "Augenhöhe" (danke Euch Experten für die Zeit) brachte nur Achselzucken.
Was noch interessant ist: Bei Steinberg fand ich eine Beschreibung exakt meiner Symptome, wo es heißt:

...um über das Windows MIDI System Ports bereitzustellen. DirectMusic selbst hat eine Funktion, diese Windows MIDI Ports als "emulierte DirectMusic" Ports zu spiegeln. Leider kann das zu einer Reihe von Problemen führen, wenn man diese Ports nutzen möchte:


-Die Benutzung von emulierten DirectMusic Ports kann häufig zu verschobenen MIDI Events bei der Aufnahme führen (Events werden zu spät oder zu früh aufgenommen).
-Manchmal werden gar keine MIDI Events aufgenommen.
-Es kann passieren, dass Events hängen bleiben oder aber Events aufeinander gestapelt anstatt hintereinander aufgenommen werden.
-Generell schlechtes bzw. wackeliges MIDI Timing bei Wiedergabe.

Leider stand in dem Artikel kein Datum, aber es passt, was da steht.

@Markus, war Dein Zielcomputer auch 64 Bit? Wir könnten (damit Dein Nachstellversuch realistisch ist) ja mal -wenn Du Lust hast- die gleichen Daten nehmen. Einfach diese Midi-File runterladen. Da sind beide Instrumente (Oboe, Clarinet). Dann einen Loop basteln, der das erste Set bestehend aus 6 Event-Gruppen immer wiederholt. Wichtig ist, das die Ausgabe auf 2 Ports (für jedes Instrument einen) erfolgt, denn auf einem Port mit 2 unterschiedlichen Kanälen klappt bei mir alles.
 
So, Lösung habe ich zwar keine gefunden, aber dafür einen Workaround. Wie der zustande kommt ist ziemlich merkwürdig. Erklären kann ich es -technisch- nicht, aber...es klappt :)

Drauf gekommen bin ich bei einem Test, den ich noch nicht gemacht hatte:
G-Player als Standalone und dann mit 2 In-Ports "füttern". Anders als Play kann man beim G-Player explizit die Performance auf dem Port definieren, wo das entsprechende Event auch reinkommen soll.

Jedenfalls laufen lassen und...er macht das klaglos. Stundenlang! da wackelt nichts und es gibt keine Hänger. Ab ins Sonar und G-Player als VST mit gleichem Setting eingebunden. Rumms. Es hängt nach wenigen Sekunden.

Und dann erinnerte ich mich an die Ausgabe von Midi-OX. Da stimmten die Events ja auch, wie sie sein sollten. Hm, wie bekomme ich Sonar dazu, so zu "arbeiten" wie Midi-OX? Regelrecht laienhaft dachte ich mir:

1.) Indem ich 2 virtuelle Ports mittels LoopB30 eröffne
2.) das Routing in Midi-OX so abändere, dass die Eingänge des MidiSport direkt auf LoopB geschaltet werden.
3.) In Sonar als Midi-Eingangs-Ports NUR die von LoopB öffnen.

Und was soll ich sagen: Juhuuuuu :)

Das seltsame ist: Sobald ich in Sonar auch nur die Midisport In-Treiber einbinde, OHNE sie überhaupt zu routen, geht es WIEDER schief. Nach wenigen Sekunden!
Aber, nun klappts. Kleiner Wermutstropfen, es muss natürlich MIDI-OX als Prog. mitlaufen.

Ich habe keine Ahnung, wieso das in dieser abenteuerlichen Konstellation klappt. Es ist doch im Grunde nur eine "Umleitung" ?! Etwa so wie bei einer gesperrten Autobahn, die in schlechtem Zustand ist. Vielleicht hat ja jemand die plausible Erklärung, oder sogar einen Weg, wie Sonar das von sich aus richtig macht.

Wenn man darüber nachdenkt, kommt man zu dem Schluss, dass Play UND Sonar vermutlich irgendwas "anders" machen, was verhindert, dass das klappt.

Edit: Pustekuchen! dieser Mist klappt immer noch nicht.
 

Ähnliche Themen

moonbooter
    • Danke
  • Artikel
Antworten
4
Aufrufe
4K
Audix
A
moonbooter
    • Danke
  • Artikel
Antworten
4
Aufrufe
5K
music-anderson
M
tim_heinrich
    • Danke
  • Artikel
Antworten
4
Aufrufe
13K
guitarheroe
guitarheroe
moonbooter
    • Danke
  • Artikel
Testberichte Test: Dreadbox Typhon
Antworten
2
Aufrufe
16K
KoolKolle
KoolKolle
moonbooter
    • Danke
  • Artikel
Antworten
3
Aufrufe
23K
DocM.M
D

Oft gelesene Themen

Zurück
Oben