Midi Hardware Jitter

[onepolymer]

...wird Zeit das Du von Fibre to the Toilet endlich abgeklemmt wirst...

Ich hab LTE natürlich abhörsicher, wie Frau Merkel das kleine Fer...

bussi deine
ilse

 

[Xpander-Kumpel]

...also mal einfach gesagt, um so schneller der Multiplexer ist, umso "verzerrter"/"verschmierter" wird das digitale Signal.
Im Bereich der Übertragungstechnik sollte das ja immer ein schöner Puls 50% sein :D .
Ist es aber leider nicht.
Wenn dieser Puls nun zeitlich verschmiert wird kann es zu einer Fehlinterpretation kommen, anstatt "1" wird "0" gelesen, oder umgekehrt.

Früher(nachm Krieg, BTX ) gabs schöne Protokolle wie z.B. X.25 die immer noch überprüft haben ob das Datenpaket auch richtig angekommen ist, und falls nicht das Ganze nochmal geschickt haben, die Netzwerke der Post waren nach dem Krieg ja kaum ausgelastet, da konnte man schon mal so mit Informationen um sich schmeissen !

 

[onepolymer]

@Mink - habe mir eben Reaper installiert - die Midi Verzögerungen sind ähnlich, muß ich aber nochmal genauer testen...
wo zum Geier stellt man denn den Metro Klick beim Pre Recorden (hätte gerne 1 Takt Vorzähler) ein ???

UPDATE: Jau 6-7 ms beim Shruthi - paßt ! :)

grüsslies
ilse

 

[mink99]

wo zum Geier stellt man denn den Metro Klick beim Pre Recorden (hätte gerne 1 Takt Vorzähler) ein ???

Options / Metronome pre Roll / Metronome pre Roll settings

 

[Anonymous]

Hach ist diese Jitter-Diskussion schön!

Im Berufsleben habe ich auch damit zu tun, aber da ist was völlig anderes mit gemeint("verschmiertes" Signal, was eine Signalfehlinterpretation auslöst, Nachrichtentechnik), als das was hier diskutiert wird.
Deshalb halte ich mal lieber mein kleines Schnäutzchen...

Ohne die mathematische Formel kann man natürlich unendlich weiterdiskutieren. Du kannst die Formel bestimmt jetzt hier aufschreiben, oder? Ausserdem nein, Jitter sollte oft die gleiche oder fast gleiche Bedeutung haben. Ansonsten, ich möchte unterschiedliche Formeln für Jitter und ihre Namen sehen. Danke.

 

[Xpander-Kumpel]

Reden wir dann hier wirklich von Jitter nur weil das in der Messsoftware namentlich so steht, oder gehts nicht eigentlich eher um Latenzen?

 

[Anonymous]

frag mal hans zimmer

Lieber nicht, er nutzt doch die Steinzeitdaw Cubase.

 

[Xpander-Kumpel]

ich hab mal Wiki bemüht(obwohl da ja auch nicht alles rechtens ist:

"Als Jitter [ˈdʒɪtɚ] (engl. für „Fluktuation“ oder „Schwankung“) bezeichnet man das zeitliche Taktzittern bei der Übertragung von Digitalsignalen, eine leichte Genauigkeitsschwankung im Übertragungstakt (engl. Clock). Jitter ist als Störsignal im Normalfall unerwünscht. Allgemeiner ist Jitter in der Übertragungstechnik ein abrupter und unerwünschter Wechsel der Signalcharakteristik. Dies kann sowohl Amplitude als auch Frequenz und Phasenlage betreffen. Der Jitter ist die erste Ableitung einer Verzögerung (engl. Delay). Die spektrale Darstellung der zeitlichen Abweichungen wird als Phasenrauschen bezeichnet. Jitter ist nicht zu verwechseln mit Quantisierungsfehlern.

In der Netzwerktechnik wird mit Jitter außerdem die Varianz der Laufzeit von Datenpaketen bezeichnet. Dieser Effekt ist insbesondere bei Multimedia-Anwendungen im Internet (wie Internet-Radio und Internet-Telefonie) störend, da dadurch Pakete zu spät oder zu früh eintreffen können, um noch rechtzeitig mit ausgegeben werden zu können. Der Effekt wird durch einen sogenannten Jitterbuffer, einen speziellen „Datenpuffer“ reduziert, allerdings zum Preis von zusätzlicher Laufzeit, was vor allem bei Dialoganwendungen stört. Dieser Effekt spielt außerdem in der Prozessleittechnik eine Rolle. Kritische Prozessinformationen müssen innerhalb einer bestimmten Zeit verschickt und empfangen werden. Wird der Jitter zu groß, ist ein rechtzeitiges Eintreffen der kritischen Prozessinformationen nicht gewährleistet."

Satz Nummer 3 ist das Problem was man in der ÜT manchmal hat, ich vermute mal das das nicht das gleiche Problem ist was bei Midiverbindungen auftritt.

 

[mink99]

Jitter sollte oft die gleiche oder fast gleiche Bedeutung haben. Ansonsten, ich möchte unterschiedliche Formeln für Jitter und ihre Namen sehen. Danke.

http://de.wikipedia.org/wiki/Jitter

Hier im Zusammenhang mit midi sind wir zugegebenermassen etwas vereinfachend .

Zum einen interessiert uns die maximale Abweichung , in msec ,
Zum anderen interessieren uns nur ausschliesslich frequenzverschiebungen, amplitudenverschiebungen und phasenverschiebungen nicht ,
die deterministischen Anteile können hier als Latenz herausgerechnet werden ....

Latenz ist hier die immer gleiche Verschiebung der Ticks , jitter die variable Verschiebung ...



In der signaltechnik werden alle Werte benötigt .....

 

[swissdoc]

Wir planen und betreiben ein separates Taktnetz für die SDH und DWDM, das heißt es gibt Planungsprämissen wieviele Netzelemente hintereinandergeschaltet werden dürfen damit alles läuft(Ringproblematik, Taktschleifen etc.).
Dann gibts noch verschiedene Taktqualitäten, wobei das fast alles an den Geräten so megastrong im Takt ist, das man sich da kaum noch Gedanken machen muß.
Als Clock haben wir meistens Cäsium-Normale oder leiten den Takt von der Hauptvermittlungseinheit, GPS-Takt oder den Netzübergängen ab.
Seit ca.16Jahren bei verschiedenen Betreibern, fast noch nie ein Problem damit gehabt.

Bei welchem Verein arbeitest Du denn? Klingt ja doch sehr nach Telco-Biz Vendor von Systemtechnik, Operator oder Diensteanbieter? Bei mir ist es ein Operator, Netztechnik, OSS...
Lustig ist ja noch Synchronisation über IP bei z.B. Pico BTS, Femto Zellen oder auch all IP und LTE.

Bei LTE sollte übrigens ein vernünftiger Operator den Traffic von den eNodeBs zum MME über IPSEC abwickeln.

 

[Xpander-Kumpel]

Mannesmann Mobilfunk, Vodafone, Deutsche Bahn.
Netzplanung GSM, UMTS, LTE, ATM, Richtfunk, SDH, IP, DWDM, Core, Kabel, MSC/BSC, RNC, Takt, Media Gateway, blahblahblubb :D also alles was hinter der Funkantenne der Basisstation/Node B kommt.

 

[Anonymous]

http://de.wikipedia.org/wiki/Phase-locked_loop
http://de.wikipedia.org/wiki/Negative_Rückkopplung
http://de.wikipedia.org/wiki/Regelkreis
http://de.wikipedia.org/wiki/Regler <-- Was für einen Regler hat wohl Ableton Live? Vermutlich einen Scheissregler neben Pfush. Was für ein Regler wäre ideal für den Midi-Jitter-Fall?

Seit Kalman (1960) nichts mehr passiert auf diesem Gebiet, hmm?

 

[Xpander-Kumpel]

Wir planen und betreiben ein separates Taktnetz für die SDH und DWDM, das heißt es gibt Planungsprämissen wieviele Netzelemente hintereinandergeschaltet werden dürfen damit alles läuft(Ringproblematik, Taktschleifen etc.).
Dann gibts noch verschiedene Taktqualitäten, wobei das fast alles an den Geräten so megastrong im Takt ist, das man sich da kaum noch Gedanken machen muß.
Als Clock haben wir meistens Cäsium-Normale oder leiten den Takt von der Hauptvermittlungseinheit, GPS-Takt oder den Netzübergängen ab.
Seit ca.16Jahren bei verschiedenen Betreibern, fast noch nie ein Problem damit gehabt.

Bei welchem Verein arbeitest Du denn? Klingt ja doch sehr nach Telco-Biz Vendor von Systemtechnik, Operator oder Diensteanbieter? Bei mir ist es ein Operator, Netztechnik, OSS...
Lustig ist ja noch Synchronisation über IP bei z.B. Pico BTS, Femto Zellen oder auch all IP und LTE.

Bei LTE sollte übrigens ein vernünftiger Operator den Traffic von den eNodeBs zum MME über IPSEC abwickeln.

Die all Ip-Lösung wurde ja schön von z.B.Huawei unter der Prämisse verkauft das, wie der Name sagt, alles über IP läuft.
Die Realität sieht leider ganz anders aus, alle Voice-Anwendungen und die Synchronisation laufen wie eh und je über PCM30/G.703.
Schön die Katze im Sack gekauft und toll jetzt auch dahinter zwei verschiedene Netze(Paket und Leitung) die eine völlig unterschiedliche Architektur haben betreiben zu müssen. Es gibt wohl auch synchrone IP-Netzmöglichkeiten, aber das hat leider grad niemand zur Hand :D .

 

[mink99]

Was ist mit class compliant, warum sind die so schlecht ?

Zunächst einmal, class compliant heisst nicht gut oder schlecht. Es heisst einfach nur, das es einer bestimmten Spezifikation
(Usbmidi1 oder usbmidi2, die links hab ich verschusselt) entspricht.
Probleme mit class compliant Geräten , ausser die Hardware ist Schrott, gibt es eigentlich nur unter Windows, iOS und osx haben dort keine Schwierigkeiten. Häufig werden bei hochpreisigen Geräten für Windows Treiber angeboten, während sie unter coremidi classcompliant betrieben werden.

Es ist der generische midi Treiber für windows, der hier die Probleme bereitet.
Drei Probleme sind dokumentiert, ein viertes wurde mit Windows 7 nach nur 15 Jahren behoben.

Erstes Problem : der gegnerische Treiber ist nicht multiclientfähig, mehrere Applikationen können nicht gleichzeitig auf dasselbe Gerät zugreifen. Spezielle Treiber des Herstellers machen dies möglich, wenn es die Hardware und das Entwicklungsbudget hergibt. Spezielle Tricks auch...

Zweites Problem: der windowstreiber kann keine zwei gleichen Geräte kaskadieren, d.h. man muss , wenn man mehrere usb midi interfaces verwenden will, unterschiedliche Geräte nehmen. Das war lange das Problem mit den esi Geräten , bis es hier Treiber gab .

Drittes Problem : die buffergrösse für sysex Messages ist beim Windows Treiber angeblich nur 1024 Bytes gross, was nahezu jeden sysex Transfer scheitern lässt.

Gelöst wurde inzwischen das Problem Nummer 4 , dass alle midi Interfaces "USB Audio device" mit laufender Nummer heissen, und sich von zeit zur zeit die Nummer des konkreten Interfaces änderte. Dies führte dazu, dass bei einem gespeicherten Projekt nach dem Laden die Zuordnung der angeschlossenen Geräte auch nicht mehr stimmte.

Berichtet wird auch, dass das timestamping einzelner midi Messages potenziell fehlerbehaftet ist, wenn man die die midi Daten erzeugende Applikation genau nach den Microsoft Vorgaben schreibt. Ob das allerdings heute noch gilt, kann ich nicht sagen.....

 

[max123]

Ich grabe diesen alten Thread mal aus.

Ich habe unseren Jitterreport mal ueberarbeitet und zu einem Bericht zusammengefasst, in dem Ableton's Sync ausgiebig untersucht wird.

Das PDF gibt es unter http://midiclock.de/data/ERM_Jitter_Report_02_14_EN.pdf , leider bisher nur in Englischer Sprache.

Mal wieder etwas Input für die Diskussion :)

 

[Widy75]

Moin Mink,
da ist kein großer Unterschied, zumindest für mich nicht 100% meßbar, weil der Shruthi immer im Timing schwankt: ca. 1 bis max. 2 ms. Oder anders ausgedrückt: gehe ich davon aus, dass die Latenz vom SL MK2 zur Patchbay sehr gering ist - sicher unter 1 ms.
grüsslies
ilse

Wenn ich den Shruthi eine Midi Note schickt und mir das am Oszi anschau sieht das für mich so aus, dass
der kleine immer auf einen/den nächsten 0-Durchgang der Wavtable wartet bis der den VCA wieder neu triggert
somit kommt bei solchen digitalen Synths diese Zeitschwankung auch dazu und das hat nix mit Midi Jitter zu tun ...
ölg widy

 

[Discordia]

mal ne frage, ich hab hier 2 bis 3 geräte (hardware) die midi clock ausgeben können. wie kann ich am sinnvollsten messen welche die "beste" clock ist?
es handelt sich um einen OP-1, ein OPLAB und die R&M Midiclock. natürlich denke ich das die midiclock von R&M am saubersten läuft aber ich würd einfach gern mal die clocks der 3 geräte gegeneinander "antreten" lassen. jemand ne idee wie sich das bewerkstelligen liese?

 

[mink99]

Wenn du einen wirklich stabilen Rechner hast ....
Nimmst du dir nen wirklich stabilen Slave , dein freundlicher Nachbar hat bestimmt noch einen rumliegen ...
Eine sr 16 oder
Eine Boss dr670 oder was in der Geräteklasse
Dort machst du dir nen simpel Beat (16tel HH , 1/4 Bd und Snare auf 2&4)

Dann nimmst du in deiner daw mit diesem beat jeweils einen Audio track auf, mit der gleichen bpm
In der daw stellst du die gleichen bpm ein, schneidest in jedem Track die ersten 2 Takte ab und zupfst dann die 3 Tracks in das Raster , da sie wahrscheinlich nicht exakt gleich schnell sind.

Bei extremem Zoom wirst du dann sehen, wie die einzelnen Beats in einem Track ein paar Samples früher oder später sind. Immer so 1-2 . Der am wenigsten abweicht ist der beste Master .

 

[Discordia]

Wenn du einen wirklich stabilen Rechner hast ....
Nimmst du dir nen wirklich stabilen Slave , dein freundlicher Nachbar hat bestimmt noch einen rumliegen ...
Eine sr 16 oder
Eine Boss dr670 oder was in der Geräteklasse
Dort machst du dir nen simpel Beat (16tel HH , 1/4 Bd und Snare auf 2&4)

Dann nimmst du in deiner daw mit diesem beat jeweils einen Audio track auf, mit der gleichen bpm
In der daw stellst du die gleichen bpm ein, schneidest in jedem Track die ersten 2 Takte ab und zupfst dann die 3 Tracks in das Raster , da sie wahrscheinlich nicht exakt gleich schnell sind.

Bei extremem Zoom wirst du dann sehen, wie die einzelnen Beats in einem Track ein paar Samples früher oder später sind. Immer so 1-2 . Der am wenigsten abweicht ist der beste Master .

haha das einzige gerät das ich auftreiben könnte wäre der stabile rechner (mein macbook) alles andere wüsst ich grad nich woher ich nehmen sollte. elektronik musiker die sowas haben sind hier selten :D

aber egal. ich nehm einfach die midi clock als master gerät und fertig. dafür hab ich sie immerhin gekauft und so kann ich jedes gerät aus der reihe nach belieben zuschalten und mit resync wieder richtig eintakten. ich hab auch vorhin mal einen (nicht representativen) test gemacht und muss sagen dass das ipad am wenigsten zuckt wenn es von der midiclock gesynced wird (und das sogar via wlan!)

 

[C0r€]

Die Webseite funktioniert leider nicht mehr!

miditest (http://miditest.earthvegaconnection.com/) 64 bit

Ich habe die Datei aber bei mir noch gefunden.

 

[DanReed]

@max123: Wenn auch völlig üblich in der Wissenschaft, ist es trotzdem immer fragwürdig, wenn die Untersucher ihr eigenes Produkt einbeziehen (wg. bewußtem und unbewußtem Bias). Außerdem ist bei mir der Unterschied zwischen 38ms und 400ns zwei Größenordnungen und nicht "drei" wie in den Conclusions geschrieben.

Grundsätzlich wäre ein Timing-Jitter von 38ms katastrophal, den hört jeder, und man muß sein Setup schon unglaublich schlecht konfigurieren, um auf solche großen Werte zu kommen.

Man muß immerhin bedenken, daß bei 120 BPM alle 20.8ms ein 0xF8 eintrifft. Das ist eine Frequenz von 48Hz. Um 38ms Jitter zu erreichen, müßte man schon mindestens eine MIDI-Clock aus der Rechnung nehmen (z.B. durch einen Wackelkontakt) und die Glättung/Prädiktion des Empfängers ausschalten.

Die MIDI-Clock darf sich sogar zwischen die Bytes der MIDI-Kommandos drängen und wird daher bei einem mittelmäßigen Master nur um maximal 10/31250 = 0.32ms von der eigentlichen Position verzögert. Ein perfekter Master verzögert bis 0.16ms eher das kollidierende MIDI-Kommando (da er ja "weiß", wann genau er die nächste MIDI-Clock schicken muß), so daß bei einem guten Sender selbst unter Belastung ein maximaler Jitter von nur +-160ns auftritt.

Was will ich mit dem ganzen Zeug sagen: 38ms Jitter ist nie das Problem eines mittelmäßigen oder besseren Senders, sondern des Setups und/oder Empfängers/Slaves.

 

[swissdoc]

Die Webseite funktioniert leider nicht mehr!

miditest (http://miditest.earthvegaconnection.com/) 64 bit

Ich habe die Datei aber bei mir noch gefunden.

Hast Du beide Versionen 32/64 bit und könntest Du diese evtl. verfügbar machen? Wäre super. Danke.

Edit: Version 4.6 und die Page an sich sind unter web.archive.org noch zu finden.

 

[ChromaMan]

Die Webseite funktioniert leider nicht mehr!

miditest (http://miditest.earthvegaconnection.com/) 64 bit

Ich habe die Datei aber bei mir noch gefunden.

Hast Du beide Versionen 32/64 bit und könntest Du diese evtl. verfügbar machen? Wäre super. Danke.

Edit: Version 4.6 und die Page an sich sind unter web.archive.org noch zu finden.

Jep THX
am 27Jul2010 ist es noch zu finden.
Die 64Bit scheint obsolet schade

 

[verstaerker]

Litmus Timing Tests | Hardware & DAW Clock Accuracy Benchmarks

Independent timing tests measuring jitter, latency and clock accuracy across hardware sequencers, drum machines and DAWs. Real-world results.

innerclocksystems.com

interessant wieviel Jitter die Synths selbst mit herausragender Midiclockquelle generieren

 

[fanwander]

Litmus Timing Tests | Hardware & DAW Clock Accuracy Benchmarks

Independent timing tests measuring jitter, latency and clock accuracy across hardware sequencers, drum machines and DAWs. Real-world results.

innerclocksystems.com

interessant wieviel Jitter die Synths selbst mit herausragender Midiclockquelle generieren

Spannend ist da der 1975er Minimoog, dass der überhaupt eine Trigger Latenz produziert. Das wirft insgesamt die Frage auf, wie er bei den Audiosachen gemessen hat. Wenn da der Threshold hoch ist (oder hoch sein muss, damit das im Eigenrauschen des Geräts überhaupt wahrnehmbar ist), dann misst er halt die minimale Attackzeit der VCA-Hüllkurve.

Beim MKS10 verstehe ich nicht ganz, was er da gemessen haben soll. Da gibts keinen Sequencer, und laut Beschreibung hat er keinen NoteOn verwendet.

Das meiste andere verwundert nicht, bzw ist bekannt.

 

[microbug]

Beim MKS10 verstehe ich nicht ganz, was er da gemessen haben soll. Da gibts keinen Sequencer, und laut Beschreibung hat er keinen NoteOn verwendet.

Nicht nur da. In der Liste stehen sowohl 1 mechanische als auch einige elektronische MIDI Patchbays, allesamt welche mit gemultiplexten Ports, die also den Datenstrom über Hardware durchleiten, arbeiten - was soll das?
Außerdem verstehe ich die Klassifizierung nicht bzw ist sie falsch. Kawai R100 und LinnDrum stehen als Sequenzer drin, dabei sind sie Klangerzeuger, beim Roland MC-4 steht gar "Sound Generator" dabei, was völliger Quark ist.
Bei Samplern wie den MPCs kommts zudem beim Testen auf exakt geschnittene Samples an, sonst ist das Ganze ja für die Füße.

 

[fanwander]

Nicht nur da. In der Liste stehen sowohl 1 mechanische als auch einige elektronische MIDI Patchbays, allesamt welche mit gemultiplexten Ports, die also den Datenstrom über Hardware durchleiten, arbeiten - was soll das?

Naja, Dir und mir ist der Grund für das "Zero" bei den mechanischen Patchbays klar. Dann müssten aber auch die ganzen diskret digitalen Teile wie der Garfield Dr. Click rausfallen.
Aber genau darum geht es ja: zu zeigen, dass bestimmte Geräte einfach null Latenz zwischen Auslöser und Ergebnis haben.

Dass Grund dafür ist, dass diese Geräte halt keine serielle Verarbeitung intern haben, muss den Rezipienten erst mal nicht interessieren.

Außerdem verstehe ich die Klassifizierung nicht bzw ist sie falsch. Kawai R100 und LinnDrum stehen als Sequenzer drin, dabei sind sie Klangerzeuger,

Naja, da geht es um die Latenz "Clock-In -> Sequencer -> Klangereignis". Da ist der Sequencer schon relevant (und tatsächlich ist ja zumindest bei der LinnDrum die Klangerzeugung ab Triggerout der CPU komplett ohne Latenz).

beim Roland MC-4 steht gar "Sound Generator" dabei, was völliger Quark ist.

D'accord

Bei Samplern wie den MPCs kommts zudem beim Testen auf exakt geschnittene Samples an, sonst ist das Ganze ja für die Füße.

Das hat er aber mal auf einer anderen Page beschrieben. Er nutzt da ein extra für diesen Messzweck erstelltes Sample.

 

[verstaerker]

mir geht es vor allem um so moderne Vertreter wie

Elektron Digitakt​

Sequencer​

External Sync Source: GRIDLOCK II
Format: 5pin MIDI Clock
Source Jitter: 7µs [ sub sample @ 96kHz ]

Max Audio Out Jitter: 64 samples / 0.667 ms

in Bezug auf eine andere Diskussion , wo man schon über den Unterschied zwischen 20µs (Multiclock) und 0,3 µs jitter (NomeII)
spricht... ich versuche mir ein Bild zu machen ob das eine Rolle spielt.

 

[fanwander]

mir geht es vor allem um so moderne Vertreter wie

Elektron Digitakt​

Sequencer​

External Sync Source: GRIDLOCK II
Format: 5pin MIDI Clock
Source Jitter: 7µs [ sub sample @ 96kHz ]
Max Audio Out Jitter: 64 samples / 0.667 ms

in Bezug auf eine andere Diskussion , wo man schon über den Unterschied zwischen 20µs (Multiclock) und 0,3 µs jitter (NomeII)
spricht... ich versuche mir ein Bild zu machen ob das eine Rolle spielt.

Wir sind mal wieder bei Apfel versus Birne.

In der "anderen Diskussion" geht es nur um das Clock-Signal per se. Es werden also im Scope oder Datensampler eingehendes MIDI-Clock-Byte und ausgehendes MIDI-Clock-Byte miteinander verglichen. Und da geht es um die Latenz - und nicht um den Jitter.

Bei der Messung von Innerclock werden eingehendes MIDI-Clock-Byte und ausgehendes Audiosignal für die Latenz miteinander verglichen und die Varianz mehrerer Messungen für den Jitter.

Die Elektron-Daten zeigen nur den Jitter aber nicht die Latenz. Wir wissen also nicht, wie spät der Audio Out nach dem Clock-Byte ankommt. Wir wissen nur, den Unterschied. Wenn die Latenz 120ms Sekunden wäre (=mieser Wert), dann hätten wir einen Jitter von 0,5% (=toller Wert). Wenn die Latenz 6ms wäre (=großartiger Wert) dann wäre der Jitter bei 10% (=nicht so toller Wert).

Außerdem sagen die Daten nichts über die Rahmenbedingungen aus. Wir wissen aber überhaupt nicht wie sich der Digitakt verhält, wenn er gleichzeitig 8 Sounds mit Step-orientieren Parametern gleichzeitig rausgibt, im Vergleich zu einem einzigen Sound gleichzeitig ohne Parameteränderung.


Und auf Deine Frage, ob der Jitter-Wert (im Kontext einer Produktion mit einer breiteren Gerätelandschaft) eine Rolle spiele: Nein, spielt er nicht. Selbst wenn zwei parallel laufende Digitakts das gleiche Pattern mit den gleichen Sounds wiedergeben würden, so wäre der Unterschied im Flanging der beide Digitakt-Signal kaum wahrnehmbar.

 

[verstaerker]

Wir sind mal wieder bei Apfel versus Birne.

nein, es wurde ja behauptet das das Nome setup einen Vorteil hat , weil die Nome-Clock ja weniger Jitter hat

Daran habe ich halt gewisse Zweifel, die du ja bestätigst.

ob der Jitter-Wert (im Kontext einer Produktion mit einer breiteren Gerätelandschaft) eine Rolle spiele: Nein, spielt er nicht.