frage zu ppq settings bzw. den auflösungen

tom f

tom f

|||||||||||
hallo:

je nach gerät wird ja die midiclock anders aufgelöst (tr-707 zb 24ppq) nun haben aber zb die modernen sequencer apps ja schon bis zu 960 (intern) und 96 ppq in der midclock...
soll man dann zb wenn ich die 707 ans logoc hänge die ausgegevbene midiclock den 24 ppq anpassen um da nen potentiellen datenstau zu verhindern?
dir frage ist rein theoretisch weil das logic mit meinem unitor8 wirklich eine tolle und "rocksolid" midiclock ausgibt ...aber man kann ja nie genug im mididatenfluss sparen :)

danke
 
Ich verstehe nur Bahnhof. :mrgreen:

Wie willst Du denn das begrenzen, gibt es dafür eine Einstellung?
 
Midi hat immer 24ppq. Und das braucht bei 120BPM rund 1.5% der Bandbreite.
(Die 96 Clock-Bytes sind pro *ganze* Note. )
 
Da habe ich mir auch noch nie Gedanken gemacht. Dranhängen, Midiclock ein und läuft.
 
Ich bin ja gerade in der Hinsicht am basteln, sonst wüsste ich das auch nicht...
 
danke für die antworten ...aber so unlogosch finde ich die frage nicht - denn man kann ja in den diversen sequencer apps die ppq settings abändern - das macht natürlich sinn wenn man midi unquantosoert spielen will und halt bensonderen wert legt auf extrem exaktes (grooviges) timing
dass die midiclock automatisch IMMER 24ppq hat hätte ich da nicht geadcht

naja - die frage kam mir auch nur in den sinn weil logic als im zum ertsenmal die midiclock aktiviert habe irgendwas wegen ppq fragte - ich aber gleich auf ok gedrückt hatte
 
nordcore schrieb:
Midi hat immer 24ppq. Und das braucht bei 120BPM rund 1.5% der Bandbreite.
(Die 96 Clock-Bytes sind pro *ganze* Note. )


also ich denke du meinst midi-clock, oder ? denn der rest kann ja mehr haben

mfg
 
doch nicht ganz übrigens

"...MIDI Timing Clock (MIDI Sync) is a status byte (F8) that is sent 24 times per quarter note for note resolution. Advanced sequencers will also subdivided each MIDI clock twenty times for a resolution of 480 times per quarter note. Standard - 24 PPQ. Professional - 480 PPQ. If the tempo changes, the speed of the MIDI Timing Clock will pass at a faster rate, but the number of status bytes (F8) per quarter note will stay the same..."
 
In *dem* Sinne hat Midi gar keine (bzw. real um 4µs Jitter) Auflösung. Die allerdings daran krankt, dass das Kabel immer nur ein Zeichen zur Zeit übertragen kann, das braucht 320µs.
Die Midi-Clock synchronisiert die Zeitgeber von Sender und Empfänger ja nur, die Clock-Bytes direkt als kleinstes Raster zu nehmen ist nur eine billige (und vor allem eine funktional-robuste!) Abkürzung.

Will man feiner auflösen, dann braucht man eine (D)PLL - und die kann aus dem Tritt kommen. In einer technisch soliden Implementation geht dann die Lock-LED aus. An der Menge von verbauten Lock-LEDs kannst du unmittelbar die Menge der seriösen Umsetzungen ablesen.
 
nordcore schrieb:
In *dem* Sinne hat Midi gar keine (bzw. real um 4µs Jitter) Auflösung. Die allerdings daran krankt, dass das Kabel immer nur ein Zeichen zur Zeit übertragen kann, das braucht 320µs.
Die Midi-Clock synchronisiert die Zeitgeber von Sender und Empfänger ja nur, die Clock-Bytes direkt als kleinstes Raster zu nehmen ist nur eine billige (und vor allem eine funktional-robuste!) Abkürzung.

Will man feiner auflösen, dann braucht man eine (D)PLL - und die kann aus dem Tritt kommen. In einer technisch soliden Implementation geht dann die Lock-LED aus. An der Menge von verbauten Lock-LEDs kannst du unmittelbar die Menge der seriösen Umsetzungen ablesen.


ich konnte bei diversen messungen einen konstamten jitter zwischen 1 und 3 ms feststellen - allerdings immer nur bei sehr dünnen daten und auch abhängig vom empfangeneden gerät (juno 106v ist zb arsch-langsam im umsetzten auf audio) ....den technischen teil deines postst kann ich leider aus mangel an kenntnis nicht nachvollziehen :)

cheers
 


Neueste Beiträge

News

Zurück
Oben