Apple wirklich sinnvoll?

  • Ersteller Maid-Majoran
  • Erstellt am
Status
Für weitere Antworten geschlossen.
Lustige Wende im Thread ;)

Ich stimme rkdk zu, wo haben wir heute ein echtes Problem? Mit dem einem oder anderen OS? Das Einzige, was mich zu Zeiten von XP und OS X Tiger fasziniert hat, war der problemlose Umstieg auf Mac von, ebenso damals, Cubase 5 und Logic. Bis heute hat sich daran wenig geändert (Studio One, Cubase 6.5, Ableton Live, Reason 6.5). Mit Sicherheit ist ein gut aufgesetztes Win7 genauso gut (obwohl ich auf meinem Samsung i5, 8GB Laptop schlechte Erfahrungen gemacht habe).

Öhm, und in den modernen Hardware-Synths werkelt kein Prozessor? Echte Null-Latenz haste doch nur auf den Naturinstrumenten, Geige, Git, E-Piano, Flügel, usw.

Shit, ich stelle bei mir einen Buffer von 256 ein und die Kiste flutscht, egal ob Logic, Mainstage, Cubase, Studio One.

Hat alles nichts mit der Frage nach "Apple wirklich sinnvoll" zu tun.
 
Öhm, und in den modernen Hardware-Synths werkelt kein Prozessor? Echte Null-Latenz haste doch nur auf den Naturinstrumenten, Geige, Git, E-Piano, Flügel, usw.

Nichtmal da, denn du hast ja noch die Schallgeschwindigkeit ... ;)
 
Öhm, und in den modernen Hardware-Synths werkelt kein Prozessor? Echte Null-Latenz haste doch nur auf den Naturinstrumenten, Geige, Git, E-Piano, Flügel, usw.

Nichtmal da, denn du hast ja noch die Schallgeschwindigkeit ... ;)

Das war jetzt aber unfair! Schliesslich habe ich in der 16.Reihe genau den gleichen Anspruch auf Echtzeit, wie die in der ersten.... kann ich dafür den Veranstalter haftbar machen? Oder ist das mit dem niedrigerem Preis abgegolten?
smil451c74f42b44f.gif
 
Hat alles nichts mit der Frage nach "Apple wirklich sinnvoll" zu tun.

Nun ja, wenn der Synthpark recht hätte, dann hätte es durchaus was mit der Frage zu tun. Dann müsste man dem Ausgangsposter nämlich sagen: "Wenn du viel MIDI machen willst und auf guten Groove stehst, nimm' einen Mac."

Nun behaupten Derek und ich, dass dem nicht so ist und daraus entspinnt sich eine zugegebenermaßen detailreiche Nerd-Diskussion. Die ist aber vielleicht auch mal nötig, sonst nimmt hier noch jemand wirklich die Botschaft mit, dass man sich einen Mac kaufen muss, wenn das MIDI-Timing stimmen soll.

Die Sache hat auch noch einen zweiten Effekt:
Auch wenn ein Anfänger nicht jedes Detail versteht, es kann ihm vor Augen führen, dass Recording immer noch ein komplexer technischer Prozess ist, auch wenn moderne Sequenzer und aktuelle Rechner das gut verheimlichen können.

Wenn dann aber wirklich mal was wackelt oder einfach nicht so funktioniert, wie der Anfänger das erwartet, dann hat er zumindest mal gehört, dass es da ein paar Dinge gibt, die noch eine Rolle spielen und die er sich dann mal ansehen könnte.
 
(nebenbei, wenn der kleine OT-ausflug erlaubt sei, freu ich mich sehr von rainer hier zu lesen. good times!)


Bevor das auch noch untergeht: Freue mich auch, Dich wieder zu lesen. Habe deine Postings wirklich vermisst und habe dieses Forum u.a. deshalb gefunden, weil ich nach deinem und Dans Namen in Verbindung mit Foren gegoogelt habe ;)
 
So, ich hab jetzt fuer Rainer und Derek ne Skizze erstellt. Da sieht man, wie ich das meine. Insbesondere, dass es moeglich ist, bei konstanter Verzoegerung T0 eintreffende realzeit-Midiereignisse jitterfrei abzuspielen.

Entweder bin ich völlig blöd oder Deine Skizze hat einen Fehler. Du reichst das Event im zweiten Fall an "played" (also die Soundkarte) weiter, bevor es überhaupt "synthesized" wurde. Da stimmt die Logik in sich nicht. Wenn Du die Logik einhälst, dann ergibt auch Deine Grafik, dass nach T0 das Event im Paket n+2 berechnet wird und damit hast Du nichts gewonnen, außer die Latenz erhöht.

Wie man es machen müsste, wollte man das überhaupt lösen, beschreibt Mathias Carstens in dem hier schon verlinkten Artikel. Allerdings stammt der noch aus Zeiten, wo man tatsächlich mit Latenzen um die 6 ms im Alltag leben musste und eine Strategie zur Vermeidung noch einen Sinn gehabt hätte.

Heute macht man das aber ganz einfach so, wie Derek das schon beschrieben hat: Man setzt die Puffergröße runter und gut iss.

Das ist auf Mac und PC aber absolut identisch quer über alle möglichen Sequenzer, so dass man die Frage des Ausgangsposter durchaus mit "iss wurscht" beantworten könnte. Ich würd's jedenfalls so tun.
 
Ich hab hier tolle Kollegen um mich herum. Die sind alle ziemlich intelligent, wir verstehen uns quasi fast ohne Worte hier. Und die wuerden mir nie untstellen, ich sei minderbemittelt und wuerde so ein triviales Zeugs hier ewig ausdiskutieren. Dinge, die eigentlich klar sein sollten.

Entschuldige, aber du erzaehlst hier was von vstis die (in deiner urspruenglichen darstellung generell ) 5ms ungenau sind, und das ist halt einfach die geschichte vom pferd. Ist halt schlicht faktisch falsch, egal wie nett man das sagen moechte.

Wir sind jetzt etappenweise von diesem punkt weg, erst wars dann nur noch wenn das system belastet ist, und als dh gemerkt hast dass auch das nicht der fall war und ich meinen test in einem 300 spur projekt gemacht habe haben wkr uns jetzt auf das doch eher spezielle thema echtzeitmidireaktionsjitter zurueckgezogen. Ich persoenlich glaube ja eher, dass du einfach ein problem hast, zu sagen "ok dann hab ich mich wohl geirrt, vstis sind also auch samplegenau, aha" und wir deswegen jetzt hier schritt fuer schritt von einem thema zum naechsten huepfen.

Und was pufferjitter angeht, jemand hat auf der letzte seite den artikel mit den erlaeuterungen von mathias carstens verlinkt. Der kann das besser erklaeren als ich, und dem schenke ich eher glauben bei dem thema, denn der baut hauptberuflich low latency audio interfaces und du meines wissens bisher noch nicht.

Und die wuerden darueber lachen, wenn es technisch nicht moeglich waere, ueber einen USB Bus mit gigantischer Datenrate gleichzeitig Midi und Daten zu uebertragen, so dass die Midiereigniesse verjittert werden, nur weil der Audiobuffer hoeher gewaehlt wird. Das ist der letzte Mumpitz.

*facepalm* ja, das ist in der tat der letzte mumpitz, denn das hat auch keiner behauptet. Einmal noch: es geht nicht um den empfang der mididaten sondern um die wiedergabe als audio. Die mididaten empfaengt der rechner natuerlich unabhaengig von der puffergroesse, aber die wiedergabe als audio (und die hast du als timingvergleich bei deinem test benutzt, so wie du den test beschreibst) ist eben sehr wohl abhaengig von der puffergroesse.

Aber Musiker wissen immer alles besser. Na dann ...

Ich weiss gar nix besser, deswegen zitiere ich hier auch nur den chef von RME. Der besserwissende musiker, der "einfach hoert" dass sequencer unterschiedlich grooven, das war nicht ich ;-)


Wenn du das Konzept verstanden hast, dass der Sequencer eine kostante Latenz aufrechterhaelt, damit eben keine Ereignisse verjittert werden, dann hast du es verstanden. Das hat nix mit der Uebertragungsgeschwindigkeit zu tun! Denn die naechsten 256 Samples werden quasi "gebacken", waehrend die vorherigen abgespielt werden. Und wenn dann Ereignisse eintreffen, werden diese an die richtige Stelle im Buffer gesetzt. Das ist der Punkt. Aber dafuer braucht es eine konstante Verzoegerung. Dabei wird gar nix verjittert, aber das Plugin spielt das Ereignis mit einer konstanten Verzoegerung ab.Und wenn das Ereignis noch spaeter kommt, dann wird es in den naechsten Bufferabschnitt gesetzt, so wie es sein soll. Dabei bleibt die Verzoegerung weiterhin gleich und variiert nicht. Das muss man verstehen.

Lies bitte einfach den artikel von herrn carstens. Wenn ichs dir nicht erklaert kriege, muss kein wunder sein, denn bei mir handelt es sich um eine amateur-nacherzaehlung seiner erklaerungen und da gibt es natuerlich sowohl einen gewissen stille post effekt als auch fachsprachliche ungenauigkeiten - bei ihmeher nicht. Aber vielleicht hat ers ja einfach auch nicht verstanden und es ist reines glueck sass dierme interfaces so performen wie sies tun.
 
Entweder bin ich völlig blöd oder Deine Skizze hat einen Fehler. Du reichst das Event im zweiten Fall an "played" (also die Soundkarte) weiter, bevor es überhaupt "synthesized" wurde. Da stimmt die Logik in sich nicht. Wenn Du die Logik einhälst, dann ergibt auch Deine Grafik, dass nach T0 das Event im Paket n+2 berechnet wird und damit hast Du nichts gewonnen, außer die Latenz erhöht.

Muss ich mich jetzt mit Carstens beschaeftigen?
Hat Carstens irgendwas mit Mac zu tun zum Beispiel?

Zu deiner Anmerkung:

Das Midi Event trifft ein.

Nach der Zeit T1 werden die getriggerten Audiodaten, dei durch dieses Event ausgeloest werden, in den gerade aktuellen Synthese-Buffer geschrieben (mit anderen Audiospuren zusammen, deren Berechnung hier nicht weiter interessiert). Das ist quasi die Zeit, die man der gerade scharfgeschalteten Spur goennt. Diese Spur hat in Logic enorm CPU Verbrauch, nicht ohne Grund. Denn man will T1 klein halten. Wenn das Paket fertig ist, vergeht eine kleine Zeit Tb bis es ueber den Bus uebrtragen ist, auch dargestellt, das kleine graue Kaestchen. Die Linie nach oben markiert nur den Zeitpunkt, damit die effektive Latenz ersieht.

Wenn die Pakete eine Dauer von Tp haben, und die reservierte Zeitdauer fuer
die Busuebrtragung Tb waere, dann ist halt T0 = Tp+T1+Tb.

Hier wird nix uebertragen, bevor es synthetisiert ist. ;)
 
Hi Derek!
Deine Beiträge aus dem alten S&R-Forum haben mir gefehlt! Endlich wieder Stimmung und Sachverstand!

Gruß
Doc No
 
Entschuldige, aber du erzaehlst hier was von vstis die (in deiner urspruenglichen darstellung generell ) 5ms ungenau sind, und das ist halt einfach die geschichte vom pferd. Ist halt schlicht faktisch falsch, egal wie nett man das sagen moechte.

Das was wir jetzt besprechen, ist Problem Nr.2, der Midijitter.

Das mit der ungenauen Triggerung von 5 ms war Problem Nr.1.

Zwei Gruende, warum ich zu MAC gewechselt bin. Und an der Meinung hat sich nichts geandert, ausser du machst einen Midi Test "mit Sachverstand" wie es hier jetzt so schoen heisst, und postest hier deine Messergebnisse, die bescheinigen, dass man mit einem PC unter Cubase Win 7 geringe Midi-jitterwerte erhaelt.

edit

und wie gesagt, es gibt noch andere, welche solche Probleme haben unter Windows 7.
Wenn ich der einzige weltweit waere, der da sich was zusammenspinnt, dann waers natuerlich seltsam zu lesen.

http://www.gearslutz.com/board/elec...3456-windows-7s-midi-out-jitter-disaster.html
 
aha. Es geht also weiter mit euch?
Na denn... ;-)
Lustig, dass dies alle in geballter Info gleich in der Forums-Sparte -> "Newbie Kaufberatung" steht!!:D

Also... als totaler Anfänger würd mich die gesamte Audiobranche und die ganzen Computers völlig abschrecken, wenn man sich dann als aller erstes um Jitter, Latenzen & Co. kümmern müsste... :hammer:

Zum Glück kann Musik machen aber auch Spass machen, (zumindest für einige Leute....) und man braucht sich heutzutage keinerlei Sorgen zu machen, was für eine Rechner-Plattform (oder DAW!) man nimmt, da eine komplette Produktion nur im Rechner mit allem drum und dran wunderbar möglich und leicht umsetzbar geworden ist.
Aber ich komme ab vom Thema, es ging ja um Jitter.
Garry Jitter und die Jedi Jitter? oder so? (keine Ahnung, ich mach lieber Mukke, interessiert mich nicht, was mein Mac oder mein PC da im Hintegrund wandelt/berechnet.)
 
@rkdk

was schlägst Du vor? Soll ich Thread dieser Art, die ja nicht selten vorkommen, direkt schliessen?!
Deine Art von Hilfmoderarion ist hier nicht erwünscht. Du hast jetzt schon mehrfach erwähnt das Du alles "lächerlich" findest - ist doch in Ordung. Halte Dich fern und gut is.
Wenn Du was zu beanstanden hast drücke den "Melden-Butten"
 
Den hat Mathias Carstens, wie gesag,t schon vor knapp 10 Jahren gemacht.

Jetzt hab ich den Artikel von Carstens gelesen. Er will sagen:
VST Instrumentendaten werden immer nur vollstaendig gefuellt und immer der naechste Puffer.

Ich halte den Artikel fuer fragwuerdig.

Erstens ist unklar, inwiefern ASIO mit dem VST Standard ueberhaupt zu tun hat, das sind verschiedene Stellen des Ablaufs. Es laueft ja auch mit anderen Treibertypen, auch wenn diese schlechter sind.

Es werden Puffergroessen, Reaktionszeiten etc. fuer den VST Standard festgelegt.

ASIO beschreibt nur das Interface zwischen Sequencer und Audiotreiber, mehr nicht, also ganz andere Baustelle. Es gibt keinen Grund, warum die Instrumenten-Sampledaten vom Sequencer immer aligned werden sollen zum ASIO Buffer.

Das hab ich anhand der Skizze nachgewiesen. Und diese Skizze passt auch ins Schema ASIO, nur dass eben die Audiodaten vom VST Instrument nicht an den Anfang des Buffers geschrieben werden, sondern da, wo sie hingehoeren. Und das geht, weil ein kuenstliches Delay T1 vom Sequencer eingeplant ist, welches dem Plugin ermoeglicht, seine Berechnungen auszufuehren (diesen Punkt ignoriert Herr Carstens komplett !!). Das gesamte Delay ist dann T1+das Pufferdelay und Uebertragungsdelay, aber konstant, und das ist das wichtigste.

Mit Core Audio hat das eh alles nichts zu tun. Sollte Cubase unter Windows tatsaechlich so erbaermlich mit den Audiodaten und Echtzeitereignissen umgehen, waere das erst recht ein Grund, zu wechseln.

Mit irgendwelchen technisch bedingten prinzipiellen Einschraenkungen hat das nichts zu tun.
 
Ich frage mich, warum hier keiner das einfach mal testet.

Ich habe das gerade gemacht: Sample eingespielt & in Sampler geladen, dann die MIDI-Daten, Audio aus dem Klangerzeuger und den Sampler wieder aufgenommen und auf den ersten Anschlag uebereinander gerueckt.

Ich habe das zuerst mit einer Saffire Pro 24 gemacht, bei der ich aber unter OS X MIDI nicht zum laufen gekriegt habe. Mit einem USB-MIDI Adapter habe ich dann das sowohl unter Windows als auch unter OS X wiederholt. Ich habe fuer eine richtig stichhaltige Aussage nicht genuegend Toene eingespielt, aber grundsaetzlich haben beiden einen Jitter.

Unter Windows gibt es einen Ausreisser bei ~40 Samples, alles andere ist sowohl mit Windows als auch unter OS X um die 15-20 Samples. Mit der Saffire war der Jitter unter Windows meist bei 40 Samples, teilweise auch bei 80 Samples.
DAW war in beiden Faellen Reaper.

Wie gesagt, das sind eher Indizien als harte Fakten, aber weder gibt es keine Latenz, noch scheint OS X um Welten besser zu sein.


gruss, Chris
 
Muss ich mich jetzt mit Carstens beschaeftigen?
Hat Carstens irgendwas mit Mac zu tun zum Beispiel?

äh...RME?

(meine güte...)

Das was wir jetzt besprechen, ist Problem Nr.2, der Midijitter.
Das mit der ungenauen Triggerung von 5 ms war Problem Nr.1.

genau. und wir fassen mal zusammen:

problem nr. 1 ist widerlegt bzw faktisch falsch. VSTIs sind samplegenau. es gibt ein paar verbugte plugins, von denen du irrtümlich auf VSTI als standard allgemein geschlossen hast und dich jetzt schwer tust, einzugestehen dass das vielleicht voreilig war. übrigens hab ich inzwischen auch battery 3 getestet. battery 3 ist prinzipiell auch samplegenau, hat allerdings (und das ist auch ein systemübergreifendes problem) einen leichten drift, wenn man mit externer wordclock arbeitet - das heisst: der bounce ist nicht samplegenau identisch mit der echtzeit-wiedergabe (weil unterschiedliche clock), aber alle bounces untereinander sind samplegenau identisch. das heisst, das gebouncte file ist samplegenau, hat aber im vergleich zur echtzeitwiedergabe einen leichten drift im samplebereich. wohlgemerkt: da reden wir nicht von zahlen wie du sie erwähnt hast (plus minus 5 millisekunden) sondern von einem drift, der über längere dauer von einem sample zum nächsten springt, wenn man den nulltest macht, weil ein anderer quarz der wordclockgeber ist. von timing oder groove problemen kann man da natürlich nicht reden, ist eine rein technische frage, die bedingt durch die externe clock ist, die natürlich nicht exakt gleich taktet wie ein interner offline bounce.

problem nr. 2:

ausser du machst einen Midi Test "mit Sachverstand" wie es hier jetzt so schoen heisst, und postest hier deine Messergebnisse, die bescheinigen, dass man mit einem PC unter Cubase Win 7 geringe Midi-jitterwerte erhaelt.


diesen test mache ich regelmässig in der praxis, wenn ich mein laptop als klangerzeuger nutze. dieses fahre ich wie gesagt inzwischen bei 48 samples (eine latenz, die die meisten OSX systeme wegen der schlechteren low-latency-tauglichkeit von OSX nicht oder nur ziemlich wackelig hinbekommen). der jitter liegt dabei naturgemäss zwischen 0 und 48 samples (laut herr carstens lesart im schlimmsten fall bei 96 samples) und ist damit noch unter der präzision von midi selbst.


nach wie vor denke ich, dass du einfach damals einen test mit der damals quasi zwingenden pragmatikerlatenz von 5ms gemacht hast, dir nicht über die problematik von pufferjitter bewusst warst und (wie auch nach wie vor hier im thread) dir nicht klar war, dass das in diesem setup produzierte audiosignal mitnichten eine referenz zur beurteilung des miditimings ist - sondern ganz im gegenteil eine demonstration von pufferjitter. heisst: nicht die aufnahme der mididaten ist ungenau, sondern die *echtzeitwiedergabe* des entsprechenden audioevents, welches eben immer erst im "nächsten pufferpaket" getriggert werden kann, weil der rechner ja nicht kurz nachdem das vorige paket rausgegangen ist, das paket nochmal zurückholen kann um die neue information hinzuzufügen.

dass du dann diesen test noch für dich selbst auf ein "VSTIS haben allgemein ein schlechtes timing" verallgemeinert hast sagt mehr über deine unpräzise vorgehensweise aus als über den VSTI standard selbst. ich bin auch ein timingfetischist (nicht zuletzt weil ich u.a. für meine art des mischens samplepräzision zwingend benötige). aber ich springe nicht beim ersten schluckauf in einem testsetup zu irgendwelchen verallgemeinernden schlussfolgerungen. sonst würde ich hier heute stehen und sagen "logicplugins verursachen einen zufälligen drift und offset im bereich von fast 2 millisekunden". das war mal wahr für eine logicversion vor einigen jahren, ist deswegen aber nicht verallgemeinerbar, selbstverständlich ist der pluginstandard der internen logic-plugins per se auch samplegenau. und ich würde mich hüten, wenn mir hier mehrere leute sagen dass das faktisch falsch ist und die entsprechenden screenshots posten, darauf zu bestehen, einfach weil ich das mal in einem test so erlebt habe.

"differenzierung". probieren sies mal aus. ist gar nicht so scheisse :)
 
Hi Derek!
Deine Beiträge aus dem alten S&R-Forum haben mir gefehlt! Endlich wieder Stimmung und Sachverstand!

Gruß
Doc No


herr docno! voll das ehemaligentreffen hier! i like :)
 
Ok, ich hab jetzt den gleichen Test wie damals nochmal gemacht.
Einmal mit 128 Samples Buffer und einmal mit 1024 Samples.

Mit 128 Samples bekomme ich irgendwelche Maximalabweichungen von 2 ms.

Bei 1024 Samples scheint sich die Peformance tatsaechlich wesentlich zu verschlechtern, extreme Abweichungen, obwohl es theoretisch gar nicht auftreten braeuchte. Tja, immerhin habs ichs mal nachgemessen. Wenn jetzt PCs mit 128 Samples extrem midigenau laufen, waere die Sache vom Tisch. Damals hatte ich groessere Latenzen, weil XP/Cubase sonst nicht stabil liefen, und das trotz Quadcore.
 
q.e.d....
 
@ Wennto: naja, "lächerlich" nicht, aber ich persönlich fand, dass es etwas arg abschweift...
Und diese Wandlung dem Thread-Ersteller sicher nicht so in den Sinn kam. ;-)
Aber es ist natürlich klasse, dass auch mal tiefere Einblicke in die digitale Technik von Leuten mit passendem Fachwissen jedem hier ermöglicht wird. Ich selber lese ja gespannt mit, muss ich zugeben. Fast würde ich mir einen eigenen fachspezifischen Thread hierzu wünschen. Egal.
Alles Gute weiterhin!
 

Ja, wenn das so geloest ist, ich hab das nochmal mit einer anderen Soundkarte getestet, dann ist das echt schwach, denn es geht auch anders. Aber gut, hier gehts nur um die aktuelle Wiedergabe. Dennoch, wenn man den Rechner als eine Art Hardwaresynth betreiben will, und stellt die Latenz hoch, dann ist Feierabend.

Ich hab damals nie so geringe Latenzwerte unter XP erreichen koennen wie unter MAC, egal wie ich mein System optimieren wuerde. Und das mit RME Hammerfall. Deshalb hab ich anscheinend auch bessere Midiwerte unter MAC erhalten.

Wenn jemand ne konkrete PC Rechnerkonfiguration kennt, die 64-128 Samples selbst bei hoher Beanspruchung (UHE, Massive, Arturia etc.) ohne jegliche Muckser erlaubt, dann waere das ne Hilfe.

Es gibt viele Traps, man sehe die ganzen Threads ueber Rechner/Latenzprobleme etc.
 
Status
Für weitere Antworten geschlossen.

Ähnliche Themen

moonbooter
    • Danke
  • Artikel
Testberichte Test: Behringer Pro-1
Antworten
5
Aufrufe
25K
moonbooter
moonbooter
F
Antworten
7
Aufrufe
2K
FoggyDu
F
moonbooter
    • Danke
  • Artikel
Antworten
16
Aufrufe
84K
alex-reed
alex-reed
moonbooter
    • Danke
  • Artikel
Antworten
1
Aufrufe
28K
L0rdVetinari
L0rdVetinari

Oft gelesene Themen

Zurück
Oben