Apple wirklich sinnvoll?

[Kuno]

Im Programme-Verzeichnis haben Programme keinen Schreibzugriff? Ist das wieder so ein überflüssiges Sicherheitsfeature?
Ich installiere nahezu alle meine Programme eh nicht im Standard-Programme-Verzeichnis.

Und es wär ja völlig ok, wenn's wirklich einen zentralen Ort gäbe, an dem alle Daten von Programmen gespeichert würden. Das ist aber leider nicht der Fall.
Viele Programme nutzen "Eigene Dokumente" (bzw. Eigene Dateien auf älteren Windows Systemen), und das ist auch ok.
Aber viele Programme benutzen eben auch die Registry, oder irgendwelche Ordner unter Appdata oder sonstwo, oder sie installieren irgendetwas im Programme-Ordner, obwohl ich das eigentliche Programm eigentlich ganz woanders hin installiert habe, etc.

Ich frage mich dann immer, was bei den Entwicklern im Kopf vorgegangen sein muss. Vielleicht sowas:
"Hmm ... wie kann ich den Benutzer eigentlich maximal auf die Palme bringen. Ah, ich habe ne Idee ... unser Programm verteilt sich beim Installieren in 3 verschiedenen Orten in der Registry und 4 verschiedenen Ordnern.
Hahaaa, der wird nie heraus finden, wo seine User-Settings gespeichert sind. xD
Außerdem muss er das Programm unnötigerweise neu installieren, wenn er das System neu aufgesetzt hat. Har har har!"

 

[derchris]

Kuno schrieb:
Im Programme-Verzeichnis haben Programme keinen Schreibzugriff? Ist das wieder so ein überflüssiges Sicherheitsfeature?

Nein, das ist eines von den sinnvollen Sicherheitsfeatures

Viele Programme nutzen "Eigene Dokumente" (bzw. Eigene Dateien auf älteren Windows Systemen), und das ist auch ok.

Eigene Dokumente/Dateien ist fuer vom Benutzer verwendete Dokumente gedacht. Appdata\Roaming ist der Ort, an dem Programme ihre Einstellungen speichern sollen. Bei mir finde ich z.B. in Eigene Dateien auf die Schnelle keine Settings von einem Programm, dafuer aber User-Daten (z.B. "Reaper Media").

[...] Außerdem muss er das Programm unnötigerweise neu installieren, wenn er das System neu aufgesetzt hat. Har har har!"

Vielleicht waere ein Mac doch was fuer dich. Einfach alles aus dem AppStore holen und nach einer System-Neuinstallation wird automatisch alles wieder installiert. Dann nur noch zuruecklehnen und eine Thread starten, wie schoen es ist, dass man dieses Frickelsystem Windows hinter sich gelassen hat.


gruss, Chris

 

[Nachtschicht]

Ich rede von VSTs und wei beschissen ungenau die von Sequencern wie Cubase getriggert werden, mal 5ms vorher, mal nachher. Ich hoer das ganz genau. Logic groovt besser.

völliger unsinn. VSTIs sind samplegenau. grad nochmal gecheckt, zwei mal hintereinander denselben 4 takter gebounct, übereinandergelegt, beim zweiten die phase gedreht = totenstille bzw "digitale null".
oder anderer test: midispur kopiert und doppelt laufen lassen - ergebnis: verdoppelung der lautstärke, nicht ein hauch von phasenhusten in den höhen. "logic groovt besser" my ass, pardon

gab natürlich einige male plugins, die in irgendeiner weise buggy waren und deswegen das timing vermasselt haben. dass battery mal darunter war ist mir neu, ich wusste es bisher nur von einer der vorigen generationen von spectrasonics plugins. solche fälle gibts aber immer mal wieder in jedem pluginstandard. logics onboard-plugins - die effektplugins! - haben mal lustig zufällige latenzen generiert, und das auch noch bei jedem druck auf die playtaste neu ausgewürfelt, ist aber auch schon wieder ziemlich lange her. da konnte man keine snare von oben und unten abgenommen abmischen ohne phasensauereien zu bekommen, war ne ziemliche katastrophe (und hat mich mehrere tage meines lebens und einige haarbüschel gekostet . das heisst aber natürlich nicht, dass logic-effektplugins per se timingungenauigkeiten verursachen. das war einfach ein bug in einer alten version der mit sicherheit mit der nächsten generation wieder gefixt war.

das hat jetzt aber auch überhaupt nix speziell mit dem einen oder anderen programm zu tun: es gibt einfach keine hosts mehr, die besser grooven als andere. sämtliche pluginstandards quer über alle plattformen sind heutzutage per spezifikation samplegenau und wenn ein plugin das verkackt, dann liegts am plugin und nicht an der spezifikation. ich könnte ohne samplegenauigkeit auch überhaupt nicht arbeiten, doppele ich doch gerne mal drums und achte dabei auf die phasenverhältnisse der zu triggernden sounds untereinander. das wäre ja unmischbar, wenn das zeug dann nicht samplegenau wäre.

gilt sogar für externes midi: die einzige möglichkeit, wirklich unverletzbar sauberes (im rahmen der möglichen) oldschool-midi zu bekommen, war seit jeher die nutzung von midiinterfaces mit timestamp-technologie. perfektes timing mit logic: brauchteste nen unitor. perfektes timing mit cubase: brauchteste ein midex.

so gesehen ist das thema sogar schon vom tisch gewesen, bevor die virtuellen instrumente überhaupt aufkamen. ausser halt, dass die VSTIs dann mit ihrem samplegenauen timing dann auch mit dem timestamp-midiinterfaces noch den boden aufgewischt haben das war n ziemlich positiver schock, damals.

umso absurder, gut 15 jahre später noch sprüche a la "host X groovt besser als host Y" zu lesen.

 

[Beatback]

umso absurder, gut 15 jahre später noch sprüche a la "host X groovt besser als host Y" zu lesen.

Sehe ich genau so, ich arbeite seit 1996 mit Cubase.
Die damaligen Versionen von Cubase VST 3.5 (nicht SX das kam viel später) hatten kein gutes Timing.
Das machte sich bei mir damals in den bekannten Snarewirbeln der Dancemukke bemerkbar die völlig unkontrolliert "Gegrooved" haben .

Heutzutage liegt das mit dem ungenau eingespielten Midi eher daran, das die User überhaupt nicht mehr richtig wissen, das sie durch zusätzliche Plugins in den Inserts einfach Latenzen beim live Einspielen bekommen und diese unbewusst selbst ausgleichen.
Dann kommt die Pluginkompensation von Cubase und nach der Aufnahme ist das eingespielte Midi zu früh.
Die meisten wissen einfach nichts von der Cubase UHR mit den runden Klammern und was dieser Schalter macht.
Das habe ich des öfteren bei einigen Kandidaten im Cubasforum erlebt.
Also immer schön den "Verzögerungsausgleich einschränken" beim Midi einspielen drücken!

Back to Topic!
Bei Apple Ipad stösst mir immer wieder sauer auf, das man so gegängelt wird.
Wenn ich keinen JB hätte, wäre es wohl nach kurzer Zeit wieder in der Bucht gelandet.
Ich hasse es wenn man mir so ne Ketten anlegt.
Ganz einfache Dinge wie Daten über Bluetooth mit anderen Geräten austauschen, oder Massenspeichermodus meine ich damit.
Deswegen habe ich auch kein überteuertes IPhone.
Über einen Mac kann ich leider nichts sagen, da ich noch nie einen besessen habe..

 

[John_Lennon]

Ich rede von VSTs und wei beschissen ungenau die von Sequencern wie Cubase getriggert werden, mal 5ms vorher, mal nachher. Ich hoer das ganz genau. Logic groovt besser.

völliger unsinn. VSTIs sind samplegenau. grad nochmal gecheckt, zwei mal hintereinander denselben 4 takter gebounct, übereinandergelegt, beim zweiten die phase gedreht = totenstille bzw "digitale null".
oder anderer test: midispur kopiert und doppelt laufen lassen - ergebnis: verdoppelung der lautstärke, nicht ein hauch von phasenhusten in den höhen. "logic groovt besser" my ass, pardon

Absolut richtig, VSTis sind samplegenau, alles andere ist absurder Unsinn. Für exaktes Timing gibt es außerdem seit Jahren den "High Precision Event Timer". Nutzt allerdings kaum jemand, weil er ohnehin beim exakten Timing heutiger Systeme keinen Unterschied mehr macht.

Aber wenn die Aussage aus dem Hort der urbanen Studiomythen stammt, der Forum-gewordenen "Spinne in der Yucca-Palme", dann braucht man sich auch nicht zu wundern....

Heutzutage liegt das mit dem ungenau eingespielten Midi eher daran, das die User überhaupt nicht mehr richtig wissen, das sie durch zusätzliche Plugins in den Inserts einfach Latenzen beim live Einspielen bekommen und diese unbewusst selbst ausgleichen.
Dann kommt die Pluginkompensation von Cubase und nach der Aufnahme ist das eingespielte Midi zu früh.
Die meisten wissen einfach nichts von der Cubase UHR mit den runden Klammern und was dieser Schalter macht.
Das habe ich des öfteren bei einigen Kandidaten im Cubasforum erlebt.

Das halte ich auch für die wahrscheinlichste Erklärung. Es gibt eine ganze Menge Fallen, in die man da tappen kann (incl. Midi-Inserts mit "Human Feel", etc.). Aber das Timing der DAW ist ganz sicher NIE das Problem.

 

[synthpark]

umso absurder, gut 15 jahre später noch sprüche a la "host X groovt besser als host Y" zu lesen.

es ist alles immer samplegenau, alles ist bugfrei, bis ICH die Software mal austeste. Plötzlich "spinnt" die Hälfte der Plugins, plötzlich tauchen Bugs auf, die keiner vorher bemerkt hat, manchmal gibt die Firma dann auf meine Anfrage hin zu, dass da ein Problem ist. Kenn ich alles schon. User Error? Nein.

Auf meinem Rechner mit Cubase 4 war das alles andere als samplegenau.

Nicht mal der Sequencer in FM8 lief richtig synchron mit dem Host, wenn das Proekt komplexer wurde. Ein Plugin reingeladen ist nicht das gleiche wie 20 Spuren mit Plugins.

Wenn ich mein Cubase auf die neueste Version upgraden sollte, dann werde ich den Test nochmal machen.

Wenn die Leute Betatester wie mich, sähe die Softwarewelt etwas anders aus. Und das sage nicht aus Eigenlob.

Ich war der einzige weltweit, der rausgehört hat, das das Tiefpassfilter in Geist nicht richtig funktioinert. Die habens gefixt. Was hat der Rest gemacht, die ganze Betatester, alle taub?

Komisch, dass auf zwei meiner Systeme, PC und MAC, Battery III Zellen sporadisch vertauscht. Einfach so. Seit Jahren gibts dieses Bug, nichts passiert. Sie können es nicht nachvollziehen. Nur wegen diesem Bug hasse ich Battery und benutze es ungern. Aber sonst scheint es keinen zu stören.

Deswegen: wenn man einen Test macht, dann richtig. Projekt aufmachen, und den Fehler provozieren. Nicht mit 100 Spuren, aber in typischer Besetzung.

Und was Hardware angeht: Prophet 08: der Prozessor ist zu langam, um bei gestackten Sounds die Pattern gleichzetitg zu triggern, da ist ein Zufallselement mit drin. Das klingt untight. Seltsam, dass es keiner vor mir bemerkt, ich bin immer der erste.

 

[Nachtschicht]

Das projekt in dem ich den test gemacht gabe war das projekt an dem ich gerade gearbeitet habe. Knapp 300 audiospuren, die ueblichen 60 default busse und ca. Ein dutzend vstis.


Keine ahnung was du da machst - generell scheint mir dass du eher ein batteryproblem hast, auf jedenfall war cubase in keiner der letzten versionen die ich hatte (fast alle seit 4.irgendwas) fehlerhaft im timing. Wie gesagt, ohne samplepräzision koennte ich gar nicht mischen und das wuerde mir binnen sekunden auffallen (naemlich spaetestens dann, wenn ich erstmals die phasenverhaeltnisse mehrerer basedrums zueinander einstelle, also mehr oder wenig direkt zu anfang eines mixes). Davor war ich auf nuendo und das war auch immer samplegenau. Und da die auf der gleichen basis (seq) aufbauen halte ich es fuer eher unwahrscheinlich, dass das einen unterschied macht.

Tut mir leid, da ist user error schon die wahrscheinlichste erklaerung. mindestens aber mangelhaftes troubleshooting, wenn du direkt auf den host schliesst anstelle erstmal das plugin zu hinterfragen. Von der albernen methodik "ich hoer dass es besser groovt" ganz zu schweigen. Timing ist messbar, und kein gehoer ist so genau wie ein phasenausloeschungstest. Dein ohr ist bestechlich und wie man sieht auch empfaenglich fuer confirmation bias. Ein phasenausloeschungstest ist unbestechlich und ein "finaler" beweis, wie man so schoen sagt.
nd "grooviger" als samplegenau gibts halt nicht, zumindest nicht solange wir die samplerate vervielfachen aber mir ist das 44100stel raster genau genug. Besser als ein atari ST oder eine MPC allemal, die sind im vergleich zittrige wackelomas

 

[synthpark]

Naja, ich bin nicht verbloedet. Das Trivialste, was haette passieren koennen, ist die Humanizerfunktion in Battery. Phasenausloschtest hat es damals natuerlich nicht bestanden. Man muss bei Phasentests aufpassen in Fall von Round Robin Samples.
Das geht natuerlich nicht. Wenn Cubase sich da verbessert hat, waers'n Weltwunder, aber mir recht. ich hab noch meine C4 Lizenz.

Aber mach doch den Plugin Miditest, den ich vorgeschlagen habe. Spiel deine Performance ueber Midi unquantisiert ein und nimm das Audioresultat an der Stelle gleichzeitig als Audioquelle auf. Dann renderst du die Midispur, so dass du am Ende zwei Audiospuren hast. Dann mal den Jitter messen, nach Anpassung eines eventuellen systematischen Delays.

Ich kam damals auf Werte von plusminus 5 ms mit einer PCI RME Hammerfall, in Logic komme ich auf unter 1 ms. Einfacher Grund: Core Midi. Dss Betriebssystem kuemmert sich um Midi besser als unter Windows.

Nachtrag: bei Logic hat man nur den Nachteil, dass Plugins die Midilatenz im Fall von externen Klangerzeugern beeinflussen. Auch bloed, sowas.

 

[Kuno]

es ist alles immer samplegenau, alles ist bugfrei, bis ICH die Software mal austeste. Plötzlich "spinnt" die Hälfte der Plugins, plötzlich tauchen Bugs auf, die keiner vorher bemerkt hat, manchmal gibt die Firma dann auf meine Anfrage hin zu, dass da ein Problem ist. Kenn ich alles schon. User Error? Nein.

Tja, du hast halt die goldenen Hände.

Ich hatte irgendwann auch mal irgendwelche Timing-Probleme, wenn ich MIDI über den MIDI-Port in FLStudio recordet habe.
Das ist aber auch schon ewig her, und ich weiß auch nicht ob's an FLS, am MIDI-Port oder am Keyboard lag. Ist mir auch wurst. Heute mit dem Axiom über USB ist alles tight.

 

[never_mind]

Um mal auf die eingangs gestellte Frage zu antworten, ohne mich durch all die Antworten zu wühlen: Ist Apple wirklich sinnvoll? Nein. Apple ist ein vollkommen proprietäres System, Logic verliert technisch langsam, aber sicher den Anschluss und man ist völlig der manchmal schwer nachvollziehbaren Produktpolitik von Apple ausgeliefert. Ich sehe da keine Vorteile.

 

[synthpark]

@Kuno

Timing Probleme sind auch ne subjektive Sache. Grobe Timingprobleme hoert jeder. Wenn's dann anfaengt, subtiler zu werden, dann ist es schon ne andere Sache.Am Ende ist es mehr ein Feeling, aber messbar.

 

[Gast92251]

Hier ein sehr interessanter Beitrag zum Thema "Timing":
http://news.harvard.edu/gazette/story/2012/07/when-the-beat-goes-off/

 

[John_Lennon]

Aber mach doch den Plugin Miditest, den ich vorgeschlagen habe. Spiel deine Performance ueber Midi unquantisiert ein und nimm das Audioresultat an der Stelle gleichzeitig als Audioquelle auf. Dann renderst du die Midispur, so dass du am Ende zwei Audiospuren hast. Dann mal den Jitter messen, nach Anpassung eines eventuellen systematischen Delays.

Damit misst Du die Audiolatenz, aber nicht das MIDI-Timing. Wenn Du da die besagten 5 ms gemessen hast, dann sage ich Dir jetzt, dass die Puffergröße Deiner RME 256 Samples war Dein Mac mit Core-Audio war halt auf eine kleinere Puffergröße eingestellt. Hat aber mit MIDI alles wenig zu tun.

Aber mal etwas ganz anderes:

MIDI (jedenfalls in der klassischen Ausprägung mit der fünfpoligen DIN-Buchse) ist ein serielles Protokoll mit einer festgelegten Übertragungsrate. Es dauert etwa 1 ms nachdem Du eine Taste gedrückt hast, bis das Event am Interface und am Computer angekommen ist. Wenn Du einen dreistimmigen Akkord spielst, dauert es beim dritten Ton schon 3ms nach Tastendruck. Diese Zeiten sind aufgrund der festen Übertragungsrate auch nicht verhandelbar. Akkorde sind immer Arpeggien. Wenn Du so ein gutes Ohr für Timing hast, dann wundert mich, warum Dir das noch nicht aufgefallen, bzw. auf die Nerven gefallen ist. Denn das nervt seit 1983 jeden MIDI-User, was aber auch nichts daran ändert, dass kein Sequenzerhersteller der Welt daran etwas ändern kann. Auch Apple nicht. Daher ist auch jeder heilfroh, wenn er externe MIDI-Devices vermeiden kann, wo es nur geht.

Ändern konnte man das nur mit den von Derek schon erwähnten "Time Stamp"-Lösungen oder eben internen Sequenzern. Cubase steuert - wie letztlich jede DAW - ein VST daher auch direkt an. Es ist zwar formal ein MIDI-Event, was da eingeht, die Verarbeitung kann bei einem VSTi aber auch parallel erfolgen. Nur die Audio-Latenz bleibt dabei erhalten. Die gab es bei der Hardware früher aber auch. Ein AKAI-Sampler hatte auch so ungefähr 3 ms Latenz, wenn ich mich noch richtig erinnere.

Und zu dem Beispiel mit dem internen Sequenzer des FM8:
Es ist Sache des Plugins, das zu synchronisieren. Für den Host ist das eine Black Box . Wenn das nicht klappt, dann ist das ein Fall für den NI-Support. Aber dafür können dann weder Sequenzer noch Plattform etwas.

 

[synthpark]

Aber mach doch den Plugin Miditest, den ich vorgeschlagen habe. Spiel deine Performance ueber Midi unquantisiert ein und nimm das Audioresultat an der Stelle gleichzeitig als Audioquelle auf. Dann renderst du die Midispur, so dass du am Ende zwei Audiospuren hast. Dann mal den Jitter messen, nach Anpassung eines eventuellen systematischen Delays.

Damit misst Du die Audiolatenz, aber nicht das MIDI-Timing. Wenn Du da die besagten 5 ms gemessen hast, dann sage ich Dir jetzt, dass die Puffergröße Deiner RME 256 Samples war Dein Mac mit Core-Audio war halt auf eine kleinere Puffergröße eingestellt. Hat aber mit MIDI alles wenig zu tun.

Aber mal etwas ganz anderes:

MIDI ist ein serielles Protokoll mit einer festgelegten Übertragungsrate. Es dauert etwa 1 ms nachdem Du eine Taste gedrückt hast, bis das Event am Interface und am Computer angekommen ist. Wenn Du einen dreistimmigen Akkord spielst, dauert es beim dritten Ton schon 3ms nach Tastendruck. Diese Zeiten sind aufgrund der festen Übertragungsrate auch nicht verhandelbar. Akkorde sind immer Arpeggien. Wenn Du so ein gutes Ohr für Timing hast, dann wundert mich, warum Dir das noch nicht aufgefallen, bzw. auf die Nerven gefallen ist. Denn das nervt seit 1983 jeden MIDI-User, was aber auch nichts daran ändert, dass kein Sequenzerhersteller der Welt daran etwas ändern kann. Auch Apple nicht. Daher ist auch jeder heilfroh, wenn er externe MIDI-Devices vermeiden kann, wo es nur geht.

Sorry ich red nicht von Midilatenz. Die hab ich schon abgezogen.

Sondern ich red davon, dass ich das Plugin anspiele und den Output aufzeichne (Audio) und die Midinoten auch (Midi).

Danach rendere ich dasselbe Plugin mit den aufgezeichneten Midinoten und vergleiche das Audiofile mit dem recordeten Audiofile, Latenzkompensiert. Es geht um den Jitter, nicht die Latenz.

Ja, dass mit der Millisekunde stimmt. Aber ich vetrachte einzelne Noten, Drumschlaege, ein simpler Groove. Im allgemeinen ist das Ohr unempfindlicher bei PIanoakkorden im Vergleich zu Drumbeats. Die koennen aber naturlich aufeinanderfallen, Kick, Snare, Hihat.

Ein Zeitfenster von 10 ms (plusminus 5) entspricht dann 10 Tasten. Das ist schon ein grosser Unterschied zu drei Tasten, oder?

 

[John_Lennon]

Danach rendere ich dasselbe Plugin mit den aufgezeichneten Midinoten und vergleiche das Audiofile mit dem recordeten Audiofile.

Und die werden beide um genau die Audiolatenz auseinanderfallen. Die Audioausgabe des Plugins kommt erst nach 5ms. Wenn Du die dann aufnimmst (hoffentlich nicht auch noch einmal eine Runde über das Audiointerface), dann ist sie IMMER um die Audiopuffergröße hinter der MIDI-Aufnahme und damit auch hinter dem, was das Rendering aus selbiger macht.

Es wird dabei auch Jitter geben, aber auch das ist Audiojitter. Matthias Carstens von RME hat dazu vor zig Jahren mal einen Artikel für KEYBOARDS geschrieben. Je nachdem an welchem Punkt der Zeitscheibe das Event eintrifft, schwankt auch die effektive Ausgabe-Latenz. Glaub' mir, Du misst den Audio-Jitter und -Latenz, nicht MIDI.

Ja, dass mit der Millisekunde stimmt. Aber ich vetrachte einzelne Noten, Drumschlaege, ein simpler Groove. Im allgemeinen ist das Ohr unempfindlicher bei PIanoakkorden im Vergleich zu Drumbeats. Die koennen aber naturlich aufeinanderfallen, Kick, Snare, Hihat.

Gerade bei Kick, Snare und Hihat hat mich das früher, als ich noch Drums über MIDI auf einem Roland ausgegeben habe, wahnsinnig gemacht. Und wenn man auf dem gleichen Port auch noch Piano und sonstwas laufen ließ, war es unerträglich. Weshalb man früher ja mit Multimode-Instrumenten jeden Part einzeln als Audiospur überspielt hat. Das war früher eine nervige Routinearbeit, aber es wäre anders gar nicht gegangen.

 

[synthpark]

Und die werden beide um genau die Audiolatenz auseinanderfallen. Die Audioausgabe des Plugins kommt erst nach 5ms. Wenn Du die dann aufnimmst (hoffentlich nicht auch noch einmal eine Runde über das Audiointerface), dann ist sie IMMER um die Audiopuffergröße hinter der MIDI-Aufnahme und damit auch hinter dem, was das Rendering draus macht.

Moment!

Erstens komponsiert ein guter Audiosequencer diese Latenz sowieso.

Zweitens gleiche ich die Restlatenz aus, indem ich die Wellenformen in Wavelab auf L/R setze (sind eh mono) und dann solange schiebe, bis der Mittelwert Null ist.

Danach schaue ich, wie die einzelnen Schlaege, also die Attacks, varrieren, das ist der Jitter.

Ich kann mir auch das Geschiebe sparen, indem ich einfach den Mittelwert der zeitlichen Differenzen von allen Werten abziehe.

Auf jeden Fall mache ich eine Jittermessung, keine Latenzmessung.

 

[John_Lennon]

Moment!

Erstens komponsiert ein guter Audiosequencer diese Latenz sowieso.

Wie will er das denn bei live eingespielten Parts machen? Hellsehen kann er ja nicht. Eine Latenzkorektur kann nur nach einer Aufnahme stattfinden, nicht Real-Time.

Danach schaue ich, wie die einzelnen Schlaege, also die Attacks, varrieren, das ist der Jitter.

Ich kann mir auch das Geschiebe sparen, indem ich einfach den Mittelwert der zeitlichen Differenzen von allen Werten abziehe.

Auf jeden Fall mache ich eine Jittermessung, keine Latenzmessung.

Dazu hatte ich mein Posting von eben vorhin noch mal editiert. Es gibt auch bei ASIO Jitter und zwar in nicht unerheblichem Maße. Das ist aber prinzipbedingt und hängt davon ab, an welchem Punkt des Zeitfensters des Puffers ein Even eintrifft. Matthias Carstens von RME hat das mal genau aufgedröhselt. Das spielt sich durchaus in Bereichen von Plus/Minus der Hälfte der Audiolatenz ab, wenn ich das noch richtig in Erinnerung habe.

Mach den Test doch einfach mal mit einer wesentlich kleineren und einer wesentlich größeren ASIO-Latenz. Wenn ich recht habe, ändert sich Dein Ergebnis mit der (Audio-)Puffergröße. Wenn Du Recht hast, ist bei allen Puffergrößen der von Dir gemessene Jitter immer gleich. Und ich verwette mein altes MIDEX-8 darauf, dass sich der "MIDI"-Jitter ändern wird

 

[synthpark]

Wie will er das denn bei live eingespielten Parts machen? Hellsehen kann er ja nicht. Eine Latenzkorektur kann nur nach einer Aufnahme stattfinden, nicht Real-Time.

Wenn ein Midi-Ereignis eintrifft, kann der Sequencer pauschal die 1 ms abziehen, und eine weitere Verzoegerung, die ihm der Treiber mitteilt. Es geht auch ueberhaupt nicht um die Latenz, die kann man im Notfall manuel nachregeln. Wenn ich ueber MIdi was einspiele, dann arbeitet die Latenzkompensation sehr gut, solange keine Plugins waherend der Aufnahme im Spiel sind (Logic).

Es gibt auch bei ASIO Jitter und zwar in nicht unerheblichem Maße. Das ist aber prinzipbedingt und hängt davon ab, an welchem Punkt des Zeitfensters des Puffers ein Even eintrifft. Matthias Carstens von RME hat das mal genau aufgedröhselt. Das spielt sich durchaus in Bereichen von Plus/Minus der Hälfte der Audiolatenz ab, wenn ich das noch richtig in Erinnerung habe.

Ja, genau. ASIO, eine Windowsgeschichte. Schoen, dass du endlich selbst drauf kommst .

Mac = CoreAudio/CoreMidi = kein ASIO = kein Windows = kein Jitter.

So einfach ist das. Fast der einzige Grund, warum ich Mac verwende.

EDIT

Ich kann den Asiotest nicht mehr machen, weil ich jetzt nur mit Macs arbeite und der PC ist woanders. Bei Mac ist dieser Jitter nicht abhaengig von der Audiolatenz, frag mich nicht, warum.

Ich glaube, selbst beim PC kann man das umgehen, zumindest schafft Reason das.

 

[Kuno]

Timing Probleme sind auch ne subjektive Sache. Grobe Timingprobleme hoert jeder. Wenn's dann anfaengt, subtiler zu werden, dann ist es schon ne andere Sache.Am Ende ist es mehr ein Feeling, aber messbar.

Wenn man's fühlen kann, kann man's auch messen.

 

[Nachtschicht]

core audio hat also keinen pufferjitter? interessant. ich dachte bisher, das wäre technisch gar nicht möglich.

quelle? interessiert mich (wenn auch nur theoretisch, in der praxis halte ich pufferjitter für irrelevant bzw eine phantomdiskussion, da er bei kleinen puffern deutlich unter der ungenauigkeit von midi selbst liegt). aber quelle möchte ich trotzdem gerne haben, weil mich technisch interessieren würde wie das gemacht wurde.