MIDI-Timing-Probleme im Sequencer

  • Ersteller tubeless
  • Erstellt am
um gleichzeitige Ereignisse bei Controllerbeschuss auch gleichzetig wiederzugeben.
.........was zudem bei der exzessiven heutigen Verwendung liebevoll gemalter Automationskurven so furchtbar selten ganz sicher nicht ist.
 
.........was zudem bei der exzessiven heutigen Verwendung liebevoll gemalter Automationskurven so furchtbar selten ganz sicher nicht ist.
aber nur wenn externe Klangerzeuger angesteuert werden.
Die Automation innerhalb den Midi Pfades im Sequencer hat damit keine Probleme.
Ausserdem lässt sich bei dem Problem z.B. die Reduktion der Daten schön über das Automationsfeld in Cubase reduzieren.
 
synthpark schrieb:
das serielle Protokoll ist insofern nicht unempfindlich, als dass die Datenrate nicht hoch genug ist, um gleichzeitige Ereignisse bei Controllerbeschuss auch gleichzetig wiederzugeben.

Mit Verlaub: diese Aussage ist bei einem per def. seriellen Protokoll ohne jede Fehlerkorrektur u/o zeitliche Angaben ( wo gehört das hin ? ) in den Datenpaketen Quark. Das hat *nichts* mit der Übertragungsrate zu tun. Im übrigen gibt es seit einiger Zeit sehr brauchbare [g=32]Midi[/g] über Lan Produkte, die diesen Missstand dann ja beseitigen würden.

Eigentlich kann ich aber leider nichts zur Diskussion beitragen , also shutte ich - the.fuck- up. Chris' post kann ich aber gut nachvollziehen, da ich gestern auch erstmal dachte "[g=32]Midi[/g]" "Jitter " häh ? Aber ok, im Sinne von TimingSchwankungen scheint man sich auf diese Namensverwendung ja geeinigt zu haben.

Das Einzigste, was in meinem Hinterkopf schwebt, sind diverse ( immer wieder auftauchende ) Interviews von gestandenen E-Musik-Menschen, die der Meinung sind, mit [g=32]Midi[/g] "macht man nichts", weil es zu ungenau ist.

Interessanter Thread also: bitte weitermachen :)

lg
Andi

PS: Schade, dass ein Werner_O, seines Zeichens MidiGott nicht mehr hier aktiv ist.

PPS: Weil ich s grade gelesen habe: wenn es etwas, wie MTC gibt ( wusste ich nicht ): wieso ist das dann alles so ( mühsam ) , wie es zu sein scheint ?
 
@Beatback
aber nur wenn externe Klangerzeuger angesteuert werden.
Gilt das nicht auch für externe Steuergeräte wie Controller?

@anthe

PS: Schade, dass ein Werner_O, seines Zeichens MidiGott nicht mehr hier aktiv ist.
Allerdings.
Werners Erfahrungen fehlen hier ganz klar.

PPS: Weil ich s grade gelesen habe: wenn es etwas, wie MTC gibt ( wusste ich nicht ): wieso ist das dann alles so ( mühsam ) , wie es zu sein scheint ?
MTC versteht nicht jeder. Und wenn man sich früh genug auf eine korrekte Timingquelle als Muss eingeschossen hätte, dann wäre wohl das Ganze auch nicht so schwierig.

Es sind ja verschiedene Einflussgrössen, die teilweise nicht mal miteinander zusammenhängen, die dazu führen, dass die Dinge nicht so laufen, wie sie sollen.
Irgendwo hab ich gelesen, dass irgendein Hersteller die Kopplung zwischen MIDI- und AUDIO-Engine irgendwann geändert hat, und dass es ab da mit dem Timing vorbei war. Also eine Sache, die DAW- und Versionsabhängig ist.

Dann kann man lesen, dass Firewire deshalb besser als Übertragungsweg für MIDI geeignet ist als USB, weil FW Timinginfis beeinhaltet, USB aber nicht und das Protokoll sich sowieso in keiner Weise um Timing kümmert, weil es eine andere Prioritätensetzung beinhaltet. Am Ende hat man bei USB nur deswegen wenig Timingprobleme, weil die Datenverarbeitung an Geschwindigkeit in den letzten Jahren unablässig zugenommen hat und deshalb innerhalb der nötigen Zeiten abläuft.

Was die Schwierigkeiten angeht, so sind die ja auch nicht gerade Neuzeitprodukte.
Das Theater mit MIDI, Ungenauigkeiten, Steueurungsprobleme etc gabs schon früher. Und es gab auch Wege, da drumherum zu kommen.
Sicherlich lagen manche Probs nicht so offen zu Tage, weil die Interfaces hochwertiger waren. Wenn man sich mal so Dinger wie AMT8 anschaut, dann wird schnell offensichtlich, dass da mehr drin steckt als in solchen Billiglösungen wie den berüchtigten "USB-MIDI-Kabeln" heutiger MAchart.
 
Gilt das nicht auch für externe Steuergeräte wie Controller?
Ich habe noch keine Probleme mit richtung Controller --> Sequencer oder anders herum gehabt.
Wenn es Probleme geben sollte, wäre die MCU wohl der beste Kandidat dafür.
Dort werden die Meterwerte schliesslich alle 10 Millisekunden an bis zu 3x MCU (jeweils 8 Kanäle) vom Sequencer an den Controller als Feedback übertragen.


Das Midex 8 hatte damals (LTB)Linear Time Base und war das beste Midi Interface für Cubase.
Das Gerät wurde ebenfalls über USB verbunden.
Steinberg und Access haben das damals zusammen entwickelt.
LTB hatte jedem Midi Event einen Zeitstempel mitgegeben und im Sequencer wurde anhand des Zeitstempels die richtige Reihenfolge/Timing der Events sichergestellt.
Leider gibt es dafür kein Win7 treiber, deshalb musste ich das vor einigen Jahren verkaufen.
 
synthpark schrieb:
das serielle Protokoll ist insofern nicht unempfindlich, als dass die Datenrate nicht hoch genug ist, um gleichzeitige Ereignisse bei Controllerbeschuss auch gleichzetig wiederzugeben.

Mit Verlaub: diese Aussage ist bei einem per def. seriellen Protokoll ohne jede Fehlerkorrektur u/o zeitliche Angaben ( wo gehört das hin ? ) in den Datenpaketen Quark. Das hat *nichts* mit der Übertragungsrate zu tun. Im übrigen gibt es seit einiger Zeit sehr brauchbare Midi über Lan Produkte, die diesen Missstand dann ja beseitigen würden.

Wieso ist das Quark? Eigentlich ne ziemlich klare Problematik, ohne die man keine mehrfach-Midiinterfaces benötigen würde. Das Problem kennt fast jeder, der mit Midi zu tun hatte. Es gibt einen Datendurchsatz, der kann nicht überschritten werden, und er ist bei MIDI (ohne USB) relativ gering, wenn man an viele Instrumente denkt. Und da kann die Anzahl der Sysex Controllerdaten die "Busbandbreite" schnell übersteigen bzw. zu Notenschwankungen führen.
 
Und da kann die Anzahl der Sysex Controllerdaten die "Busbandbreite" schnell übersteigen bzw. zu Notenschwankungen führen.
Dem stimme ich zu.
Nur solche Sysexdaten sendet man, bevor man einspielt, oder in den Pausen.
 
Ich weiss nicht genau, wie das gehandhabt wird. Aber wenn man beim Nordlead an den Reglern dreht, dann wird das aufgezeichnet und wiedergegeben.
 
Die Systemzeitgeschiche ist den Meisten schon klar, aber Andere hauen sich noch Lautmacher etc. in den Masterinsert und wundern sich nach dem Einspielen, das das Eingespielte neben dem Klick liegt.

Wer aktiviert denn einen Lautmacher im Masterinsert, wenn es noch darum geht, den Song einzuspielen?
Auf die 5 dB mehr Lautstärke kann man doch beim Einspielen verzichten, oder etwa nicht?

Bei unregelmäßigen Ungenauigkeiten hört bei mir der Spaß auf.
Das ist auch bei der klassischen MIDI-Produktion der Fall: Jede Note und jeder Controller beeinflusst das "Verhalten" der anderen Noten und Controller.
Das manchmal lahme interne Timing von Hardware-Klangerzeugern setzt dem Unheil die Krone auf.
Da kann man durchaus wahnsinnig werden.

Fazit:
Timingschwankungen sind scheiße.
 
synthpark schrieb:
synthpark schrieb:
das serielle Protokoll ist insofern nicht unempfindlich, als dass die Datenrate nicht hoch genug ist, um gleichzeitige Ereignisse bei Controllerbeschuss auch gleichzetig wiederzugeben.

Mit Verlaub: diese Aussage ist bei einem per def. seriellen Protokoll ohne jede Fehlerkorrektur u/o zeitliche Angaben ( wo gehört das hin ? ) in den Datenpaketen Quark. Das hat *nichts* mit der Übertragungsrate zu tun. Im übrigen gibt es seit einiger Zeit sehr brauchbare [g=32]Midi[/g] über Lan Produkte, die diesen Missstand dann ja beseitigen würden.

Wieso ist das Quark? Eigentlich ne ziemlich klare Problematik, ohne die man keine mehrfach-Midiinterfaces benötigen würde. Das Problem kennt fast jeder, der mit [g=32]Midi[/g] zu tun hatte. Es gibt einen Datendurchsatz, der kann nicht überschritten werden, und er ist bei [g=32]MIDI[/g] (ohne USB) relativ gering, wenn man an viele Instrumente denkt. Und da kann die Anzahl der Sysex Controllerdaten die "Busbandbreite" schnell übersteigen bzw. zu Notenschwankungen führen.

Du meintest scheinbar ein praktisches Problem ( (zu) viele Geräte mit ( zu) vielen Sysex.Daten), ich bezog mich auf Deine Aussage "Empfindlichkeit des Protokolls" vs "Datenübetragungsrate". Das ist für mich (hier) als Informatiker Quark. Ich verstehe aber, wie bereits zugegeben, von [g=32]Midi[/g] nicht wirklich genug um hier sinnvoll mitdiskutieren zu können.

lg
Andi
 
Ich kann Synthpark nur zustimmen. Habe selbst mit dem ganzen Hardwarepark immer wieder so meine Probleme gehabt. Sehr lustig wird es wenn man zB. 8 oder mehr Synths hintereinander in einer Kette hat und immer schön durchverkabelt. Noch lustiger ist es wenn man eine TR909 verwendet in die nachträglich ein Midi Interface, bzw. ein Midi2CV eingebaut wurde. :roll:

Da das Thema ja am Anfang aber nicht zuletzt um Midi-Timingprobleme bei Sonar X1 und Cubase drehte möchte ich kurz noch ein Sonar X1 Phänomen schildern, vielleicht kann einer was damit anfangen, ich komm nicht drauf was das sein könnte. Ich habe keine Midi Timingprobleme wenn ich einen neuen Song aufmache und aufnehme, alles kein Problem. Auch mit Audio, funzt soweit ... Aber manchmal passieren da Dinge die mir schlicht nicht in den Kopf gehen. Bei manchen Songs (!!!) versuche ich eine zusätzliche Midispur einzuspielen auf ein internes virt. Instrument oder ein VST Plug-In und plötzlich habe ich Latenzen von geschätzten 15-20 ms. Huu?? Dabei spielt es keine Rolle ob die Mididaten über Keyboard oder über virtuelle Tastatur / Pianoroll kommen. Schlimmer wird der Effekt wenn der Sequenzer läuft und man aufnehmen will, besser wird es wenn der Sequenzer nicht mitläuft und man nur rumklimpert. Tritt der Effekt aber einmal auf dann kann man die Sache scheinbar wirklich knicken.

Ich weiss nicht was ich schon alles versucht habe das in den Griff zu bekommen. Einmal habe ich aus Verzweiflung einen neuen Song aufgemacht und die Spuren 1:1 in den neuen Seq kopiert - lief wieder einwandfrei. Was kann denn das sein? Und nein... ich habe keine Effekte in den einzelnen Spuren oder im Master.
 
@boeserAbdul
Sehr lustig wird es wenn man zB. 8 oder mehr Synths hintereinander in einer Kette hat
Wenn das einer macht, dann gesciehts ihm recht, wenns klemmt. So doof kann man ja nwohl nicht sein, oder?

Und nein... ich habe keine Effekte in den einzelnen Spuren oder im Master.
Aber VSTis. Was die Latenzen angeht, kommt sich das aufs Gleiche raus. Wenn nicht noch schlimmer. Aber ich bezweifle mal, dass das ein Midi-Problem ist.
 
@boeserAbdul
Sehr lustig wird es wenn man zB. 8 oder mehr Synths hintereinander in einer Kette hat
Wenn das einer macht, dann gesciehts ihm recht, wenns klemmt. So doof kann man ja nwohl nicht sein, oder?

......... Kann man schon, sogar ohne Probleme, solange man darauf achtet das man nicht alle Synths zur gleichen Zeit anspielt. Man muss deshalb also nicht doof sein sondern nur ein bisschen taktisch und zielorientiert denken können.

Und nein... ich habe keine Effekte in den einzelnen Spuren oder im Master.
Aber VSTis. Was die Latenzen angeht, kommt sich das aufs Gleiche raus. Wenn nicht noch schlimmer. Aber ich bezweifle mal, dass das ein Midi-Problem ist.

War es auch nicht. Es war ein Problem mit einem Plug-in das sich nicht so wirklich mit Sonar verträgt. Nachdem ich das Ding rausgeworfen habe funzt es einwandfrei. Das mit den Latenzen bei VSTis kann ich nicht nachvollziehen, macht mein System ohne Murren mit. Ok, was bei 64 Spuren und pro Spur 3 eingesetzten Effekten kann ich noch nicht sagen, aber an den Punkt werde ich schon noch kommen, früher oder später...
smil451c7211b9e19.gif
 
aber an den Punkt werde ich schon noch kommen, früher oder später...
Nun ja.
Da brauchts nur ein Plugin, welches nicht sauber programmiert ist. Davon gibts zwar zugegebenermassen immer weniger, aber es existieren noch welche. Und wenn Du das Richtige erwischst, dann ist Dein Rechner mal ganz schnell dabei, Latenzen zu produzieren... :D
 
jupp, hab ich gemerkt. Und die Rechenleistung kann dann plötzlich auch erstaunlich ansteigen. Aber ich bin zuversichtlich, meine Mördermaschine macht mir ein Plug-In so schnell (hoffentlich) nicht platt hehe .. aber man sagt ja das in jedem Programm so ungefähr 30% Crap drin stecken, also unsauber programmierter Murks, entsteht wohl meistens dadurch das mehrere sich die programmieraufgabe teilen und einer von den Buddys nicht korrekt dokumentiert was er da treibt :)


so, und jetzt werd ich mal mein erstes Ergebnis / Song veröffentlichen. Bin ich ja mal gespannt auf die Kritik
smil451c7211b9e19.gif
 
Timing Probleme ... jetzt haltet Euch mal fest, das glaubt kein Schwein! Die Timing Probleme waren eine Sache, nach dem deaktivieren eines Plug-ins war die Sache gegessen soweit. Allerdings hatte ich immer noch ab und an das Problem das die Audio Engine abgeschaltet hat, weiss der Kuckuck warum. In den letzten paar Tagen kam dann eine Meldung von Win dazu das Daten auf F:$archiv\installer nicht gespeichert werden konnten. So weit, so schlecht. F:\ ist keine Platte die bei mir temp. Daten aufnimmt oder eine Auslagerungsdatei beherbergt auf die zugegriffen werden müsste. Es ist aber eine von 3 SATA Platten die zusammen mit anderen SCSI Platten läuft die allerdings unabhängig voneinander laufen, also nicht in einem SCSI Verbund. Nachdem die Fehlermeldung ein paar mal auftauchte und fast jedesmal den kompletten pc schachmatt setzte dachte ich an ein Verbindungsproblem. Also hab ich ihn reingesteckt und wieder rausgezogen, quasi, also alle Stecker die ich so gefunden hab die mit SATA zu tun haben, bis auf einen, den Netzstecker der ersten Platte. Und vorhin stelle ich fest das das Ding da doch irgendwie schepp (für Nichthessen: schief) draufsitzt. Mangels Vorstellungskraft wieso dieses Ding da schepp draufsitzen kann aber dank erdrückendem visuellen Beweismaterials habe ich das Ding abgezogen und noch mal neu draufgesteckt - und voilá ... alles wieder gut! Keine Timing Probleme mehr mit dem Plug-In, alles funktiniert wie frisch poliert! Hat man da noch Worte?

Warum ich das hier schreibe - und es ist gerade für mich peinlich genug denn ich hab beruflich mit PC Technik zu tun - ist weil ich vielleicht dem ein oder anderen damit helfen kann der Ursachen für Probleme mit der Audio Software im Software-Bereich sucht, die aber vielleicht im Hardware Bereich angesiedelt sind. Soll heißen das man immer erst versuchen sollte die Hardware so perfekt wie möglich miteinander arbeiten zu lassen und dann erst einen Fehler in der Software suchen sollte, auch wenn es wahrscheinlicher scheint das der Fehler die Software betrifft. Aber manchmal, und das hab ich mal wieder gemerkt, steckt der Teufel im Detail. Und das Detail ist nicht immer das worin man den Fehler vermuten würde, wie in diesem Fall. Sonar war hier absolut unschuldig. Schuld war ein leicht verkantet eingestecktes Stromkabel einer SATA Platte. Shit happens...
 

Ähnliche Themen

greenman
  • Artikel
Antworten
4
Aufrufe
50K
sigale
sigale
baumskie
Antworten
7
Aufrufe
33K
DerGipfel
DerGipfel
M
Antworten
0
Aufrufe
31K
M

Oft gelesene Themen

Zurück
Oben