Ableton Midi Transport start Offset Problem

Hallo,
wie alle Menschen habe auch ich Latenz beim recorden von midi Geräten. Leider werden in den Live11 settings alle mir bekannten latency kompensations settings ignoriert. Ich habe RTFM, die live-lesson und diverse youtube tipps durchforstet, aber leider null erfolg, deshalb schreibe ich hier.
In meinem Fall, da die Noten etc von einem Elektroninternen Sequencer kommen geht es m.e. nur um den "Transport Start" befehl der Midiclock
Folgendes Szenarien:
a) Model Samples empfängt midi clock via Midi-Interface (test mit interfaces: midiflex4,miditech 2*2), die Noten kommen vom internen Sequencer vom Model-Samples
b) In Live Preferences/Midi so konfiguriert, dass M:S clock bekommt was auch funktioniert
c) In Live Audiotrack, monitor off, audio von dem Port (K-Mix) an dem der M:S anliegt, Rec-Arm ist aktiviert
d) Nach der Aufnahme des M:S gibt es einen Offset von 21 ms von der "1"
e) Stelle mir die Frage, wie kann man Live dazu bewegen Transport Start 21 sec von der eigentlichen Aufnahme zu senden, so dass man den Offset nicht manuell schieben muss..
e.1) Driver Error kompensation lesson:
Erfolgreich eingestellt, hat aber keine Auswirkungen auf die Aufnahme des M:S. die 21 sek Offset bleiben stabil selbst bei mega extremen Driver Error kompensation auch bei absurd hohen wie zB 300ms bleibt der Offset "stabil"
e.2) Midi Clock Sync Delay setting:
Der für mich aussichtsreichste Kandidat von der Benamung her gibt leider keine Verbesserung. Wenn ich den Wert höher mache erhöht sich der Offset aber ein Minus-Wert verändert die 21 ms in keinster Weise.
e.3) External Instrument mit Delay-Regler hat keine Auswirkung, vermutlich weil auch keine Midi Noten etc gesendet werden, sondern die Clock Infos.

Eigentlich habe ich die Hoffnung das "Midi Clock Sync Delay" mit einem Wert entsprechend des Offsets die Lösung sein müsste aber leider nicht.. Wenn ich direkt USB nehme vom M:S dann ist der OFFset noch größer aber mit den gleichen erfolglos Korrekturversuchen wie oben beschrieben. Aktuell ist so ein Aufnehmen von Gear für einen Gig verbunden mit viel manuellen geschiebe bei dem potentiell Groove verloren geht, wenn man einzelne Loops recorded, da dort microtiming beim übernander layern sehr wichtig ist. Es ist voll schade wenn die geilen grooves der externen Sequencer zerschrottet werden.

Habt ihr erfahrungen/tipps.

Problem ist bi Win10 und MacOs (Big Sur) vorhanden mit jeweils performanter Hardware. Nur die MidiInterfaces sind nicht so hochwertig. Danke :)
 
prinzipiell bist du mit Einstellung Midi Clock Delay -21ms völlig richtig. Allerdings ist das bei Live ein wenig skurril.
Wenn Monitor IN an ist hast du trotzdem den Versatz in der Aufnahme.
Also mache ich das so:
Monitor OFF aber um das eingehende Signal während der Aufnahme zu hören ein External Audio Effect in der Spur, den ich abschalte , wenn ich die Aufnahme hören will.

Screenshot_2021-11-21 17.10.33_C6Djr0.png
 
was auch geht:

addiere die globale Latenz deines Audiointerface zur Mdilatenz

dann gehts auch mit Monitor In und ohne external Effekt

in meinem Fall -8ms in der MidiClock Latenz
 
Ah, sehe gerade, dass Dein Problem ein anderes ist. Sorry, da war ich etwas voreilig und habe nicht genau gelesen.
 
Moment mal... Du schreibst es liegt vor der 1 ? Echt? Wie geht das?

schick bitte mal Bilder deiner Live Einstellungen
bei Audio und Midi
 
Zuletzt bearbeitet:
Danke für die Tipps :) Wenn ich bei Midi Clock Delay -21ms einstelle habe ich keine Änderungen, auch wenn ich Monitor Off mache. Auch nicht wenn ich zB -300 ms mache. Schade, sonst könnte ich gut mit Monitor Off leben.. bist du auch auf Live11? Welches Midi Interface benutzt du - vielleicht ist das auch relevant?
 
Danke für die Tipps :) Wenn ich bei Midi Clock Delay -21ms einstelle habe ich keine Änderungen, auch wenn ich Monitor Off mache. Auch nicht wenn ich zB -300 ms mache. Schade, sonst könnte ich gut mit Monitor Off leben.. bist du auch auf Live11? Welches Midi Interface benutzt du - vielleicht ist das auch relevant?
Das ist strange.. das dürfte nicht sein.
Egal was für ein Midiinterface.
Benutze Live 11, letzte Beta.

Hast du irgendwelche plugins in deinem Set?
Latenzkompesation an?
Reduzierte Latenz beim Monitoring an?

Was für ein Audio Interface? Was ist die Globale Latenz?
Steht Midi Clock auf Pattern?
Nimmst du im Arrangement view oder Session view auf?
 
Zuletzt bearbeitet:
Ah ok danke!
Plugins im Set: nein
Latenzkompensation: nein (habe aber auch mit probiert vorher)
Reduzierte Latenz: nein (habe aber auch mit probiert vorher)
AudioInterface: K-Mix
Midiclock: Song (aber auch Pattern probiert)
Aufnahmeproblem in beiden Views

In den folgenden Screenshots ist das Midilink Interface out 1 welches die CLock liefert an den Model:Samples. Hier steht noch -100ms drinnen aber alle negtiven Werte haben scheinbar keinen Einfluss auf den Offset nur die positiven addieren sich drauf. Wenn ich dort zB +20 eingeben, dann liegt der Offset in der Arrangement View bei 41 und nicht den jetzigen 21.
Der M:S geht in den K-Mix.
Danke!

offsetProblem_midiPrefs.png
 

Anhänge

  • offsetProblem1.png
    offsetProblem1.png
    302,8 KB · Aufrufe: 14
  • offsetProblem_audioPrefs.png
    offsetProblem_audioPrefs.png
    163,4 KB · Aufrufe: 13
Zuletzt bearbeitet:
Stell mal auf pattern um ?

und am besten ne ERM Multiclock kaufen ;-)
Das Teil sieht super aus :) Dennoch würde ich gerne das Problem in der DAW lösen zum Vorbereiten des Gigs etc. Das ERM Teil ist aber suoer interessant, auch weil man andere clocks shuffeln kann und selber unabhäbgig Offsets drauf rechnen kann und vieles mehr!
steck doch mal den M:S direkt per Usb dran und guck mal Obst damit besser geht.
Wenn alle Kabel reißen, könnte ich mir vorstellen dich per video-chat/teamviewer session zu unterstützen
Geil danke sehr nett von dir :) Mit dem USB abe ich mal probiert aber leider gibt es nur einen größeren Offset aber die Korrektur greift genau so wenig wie mit den beiden midi interfaces. Ich habe mal ein Video aufgezeichnet - vielleicht habe ich etwas ultimativ übersehen und sonst würde ich mich natürlich freuen wenn ich hilfe bekomme dem PRoblem auf die schliche zu kommen ;-)
Hier das Video:

https://youtu.be/d4JxCP3YlEA


Danke schon mal :)
 
Das Teil sieht super aus :) Dennoch würde ich gerne das Problem in der DAW lösen zum Vorbereiten des Gigs etc. Das ERM Teil ist aber suoer interessant, auch weil man andere clocks shuffeln kann und selber unabhäbgig Offsets drauf rechnen kann und vieles mehr!

Geil danke sehr nett von dir :) Mit dem USB abe ich mal probiert aber leider gibt es nur einen größeren Offset aber die Korrektur greift genau so wenig wie mit den beiden midi interfaces. Ich habe mal ein Video aufgezeichnet - vielleicht habe ich etwas ultimativ übersehen und sonst würde ich mich natürlich freuen wenn ich hilfe bekomme dem PRoblem auf die schliche zu kommen ;-)
Hier das Video:

https://youtu.be/d4JxCP3YlEA


Danke schon mal :)

also ehrlich gesagt da bin ich gerade überfragt

hast du evtl noch Zugriff auf eine andere Live-Version? Vielleicht ist da irgendein blöder Bug drin?
der M:S bekommt auch wirklich clock? Also folgt er auch Tempoänderungen?

du hast nicht zufällig noch ein andere Audiointerface? Zur Not über Mikro des Macbook . Die Änderung des Offsets muss doch eine Auswirkung haben.

Probier bitte mal noch die Session View (also bei mir gehts in beiden)
 
Zuletzt bearbeitet:
also ehrlich gesagt da bin ich gerade überfragt

hast du evtl noch Zugriff auf eine andere Live-Version? Vielleicht ist da irgendein blöder Bug drin?
der M:S bekommt auch wirklich clock? Also folgt er auch Tempoänderungen?

du hast nicht zufällig noch ein andere Audiointerface? Zur Not über Mikro des Macbook . Die Änderung des Offsets muss doch eine Auswirkung haben.

Probier bitte mal noch die Session View (also bei mir gehts in beiden)
Ich habe noch Live 10, damit werde ich es nochmal checken gute Idee! Der M:S bekommt clock, man sieht s im Display "Ext" und auch start/stop und tempi gehen mit. Sonst habe ich noch ein Digiface USB und ein olles Fast Track Ultra, ich werde beide checken und berichten! Bin momentan aber im Proberaum und habe da nur das K-Mix dabei. Aber echt vielen Danu und schon mal gut zu wissen, dass es "eigentlich" funktionieren sollte ;-)
 
Ich habe noch Live 10, damit werde ich es nochmal checken gute Idee! Der M:S bekommt clock, man sieht s im Display "Ext" und auch start/stop und tempi gehen mit. Sonst habe ich noch ein Digiface USB und ein olles Fast Track Ultra, ich werde beide checken und berichten! Bin momentan aber im Proberaum und habe da nur das K-Mix dabei. Aber echt vielen Danu und schon mal gut zu wissen, dass es "eigentlich" funktionieren sollte ;-)
ich hab grad 10.1 probiert .. das geht "leider" genauso gut
 
Hast du die Latenz bei allen Noten oder nur bei der ersten auf 1.1, die zeitgleich mit dem Midi Clock Start kommt?
 
Zuletzt bearbeitet:
Hast du die Latenz bei allen Noten oder nur bei der ersten auf 1.1, die zeitgleich mit dem Midi Clock Start kommt?
Ja, also der Offset wird auf die timestamp aller events draufgerechnet wenn man so will, d.h. es ist alles verschoben um zB 14 ms aber ab diesem punkt zwischen den Events konsistent. Deshalb würde mir schon reichen dass das Transport-Start Event 14 ms vor dem Ableton DAW internen Transport start losgesendet würde damit dann zB die Bassdrum auf der "1" des Model:Samples auch so auf der "1" in Ableton aufgezeichnet wird. LOL ich könnte mir Notfall etas mit M4L basten haha aber ich würde lieber nicht in dieses Rabbit-hole gehen :P
 
@fairplay @verstaerker
Hier eine weitere "spannende" :sarg:Episode in der wundersamen Welt der Midi-Latency:

https://youtu.be/A2izA4C8biE



Diesmal habe ich das interne Mic verwendet. Die Ergebnisse des Videos sind mit Latenz-Kompensation an und aus identisch.
Es wurde nur mit dem midi-clock Delay experimentiert. Wem das video zu obzön ist (clickbait :P) - hier die zusammenfassung:

MBP internec Mic / Core driver -> midiclock sync delay: negtiver Offset wirkt sich überhubt nicht aus, positive Werte funktionieren wie ich es erwarte

So auch mit dem Core driver des KMI K-Mix und auch vom FTU Ultra
 
Zuletzt bearbeitet:
Ich denke das Problem ist, dass sich nach 1981 im MIDI Bereich außer Roland niemand mehr Gedanken darüber gemacht hat, wie Master/Slave Systeme funktionieren. Und dieses "Funktionieren" bedeutet in erster Linie, dass der Master nach dem Senden des Start-Kommandos dem Slave Zeit lassen muss "in die Puschen zu kommen". Eigentlich müsste Live seinen interne Aktivität verspätet starten. Tut es aber nicht.

Roland hat bereits bei der DIN-Sync Definition im Service-Manual der TR-808 eindeutig beschrieben:
1637931396195.png

Wenn man sich den MIDI-Out von Roland-Geräten auf dem Oscilloskop ansieht, dann sieht man auch, dass das erste Clock-Byte nach dem Start-Byte verzögert wird. Die folgenden Clock-Bytes kommen aber wieder im dem Tempo entsprechenden Abstand
ASCII-grafisch dargestellt:
C=Clockbyte
S=Startbyte
.= nix...


Die erste Zeile zeigt wie die Clock ohne Starbyte durchlaufen würde,
die zweite Zeile zeigt, wie es sein sollte,
die dritte Zeile wie es alle außer Roland machen,
und die vierte Zeile ist, was bei den Slaves defacto verarbeitet wird:
C...C...C...C...C...C...
C...C...C..S.C..C...C...
C...C...C..SC...C...C...
C...C...C..S....C...C...


Das "C" nach dem "S" sollte verzögert kommen. Macht aber keiner. Die Slaves verpennen das Clock-Tick nach dem Start und starten entsprechend verspätet.
Ob das einzelne Clock-Byte dabei real als Step ausgewertet wird, oder ob die vermeintliche Clock-Tick-Pause zu einem kurzfristigen Runterrechnen des interpolierten Tempos führt ist dabei egal.
 
^ Genau das. Das sofort Starten ohne Abwarten ist so beabsichtigt. Derzeit gibt es nur die Möglichkeit erstmal mit einem Takt (oder weniger) Stille zu starten.
Interessant danke :) aber wie soll ich out of the Box Live mitteilen, dass nach 1-N Takten spielzeit die Midiclock dann z.B. um den Midiclock-Delay Wert verzögert einsezen soll? Wie hat das ZB @verstaerker in seinem Beispiel (video oben) gemacht. Es scheint ja doch bei andern zu funktionieren. So wie ich das verstehe kommt bei aktivierten Sync erst das Start Event gefolgt von den Ticks. Ich hätte mir das so vorgestellt, dass Live alle anderen Midiclocks/Empfänder Device die kein Midi Delay Wert in den Prefs haben um den Wert der Devices mit DElay Verzögert um so das früher Einsetzen zu ermöglichen. So ähnlich wie der Lookahead bei Limitern funktioniert, die ms rechnen sich ja auch auf die Audio-Lantency.

Sorry lange Rede @ppp wie würdest du es machen mit dem einen Takt vorlauf? Aktuell startet die clock ja direkt mit..
 
Zuletzt bearbeitet:
Ich könnte mir ein Max for Live device vorstellen in dem man ein ms Wert einträgt. Dann wird direkt das Midi Transport Start Event an zB den Model:Samples abgefeuert und dann werden die eingetragenen ms abgewartet bis dann die LiveApi mit Transport Start bemüht wird. Dann bekommt das M:S dann nach ein paar Ticks noch ein Start Event aber hofentlich wird dies ignoriert, sonst müsste man noch einen komischen Midifilter einbauen. Aber das bringt einen total aus dem Sampling Workflow und immer wenn amn so hacking Ideen hat sollte man aufmerksam werden ob das Problem nicht woanders ist :P
 
Ich denke das Problem ist, dass sich nach 1981 im MIDI Bereich außer Roland niemand mehr Gedanken darüber gemacht hat, wie Master/Slave Systeme funktionieren. Und dieses "Funktionieren" bedeutet in erster Linie, dass der Master nach dem Senden des Start-Kommandos dem Slave Zeit lassen muss "in die Puschen zu kommen". Eigentlich müsste Live seinen interne Aktivität verspätet starten. Tut es aber nicht.

Roland hat bereits bei der DIN-Sync Definition im Service-Manual der TR-808 eindeutig beschrieben:
Anhang anzeigen 121817

Wenn man sich den MIDI-Out von Roland-Geräten auf dem Oscilloskop ansieht, dann sieht man auch, dass das erste Clock-Byte nach dem Start-Byte verzögert wird. Die folgenden Clock-Bytes kommen aber wieder im dem Tempo entsprechenden Abstand
ASCII-grafisch dargestellt:
C=Clockbyte
S=Startbyte
.= nix...


Die erste Zeile zeigt wie die Clock ohne Starbyte durchlaufen würde,
die zweite Zeile zeigt, wie es sein sollte,
die dritte Zeile wie es alle außer Roland machen,
und die vierte Zeile ist, was bei den Slaves defacto verarbeitet wird:
C...C...C...C...C...C...
C...C...C..S.C..C...C...
C...C...C..SC...C...C...
C...C...C..S....C...C...


Das "C" nach dem "S" sollte verzögert kommen. Macht aber keiner. Die Slaves verpennen das Clock-Tick nach dem Start und starten entsprechend verspätet.
Ob das einzelne Clock-Byte dabei real als Step ausgewertet wird, oder ob die vermeintliche Clock-Tick-Pause zu einem kurzfristigen Runterrechnen des interpolierten Tempos führt ist dabei egal.
Cool danke für die Analyse :) Ich hätte mir gewünscht dass man im Sync Standard noch einen Modus hätte der ohne das zeitkrittische aufeinander folgen von den CLock-Bytes auskommt und dafür jeweils autarke genormte interne Clocks verwendet. Dann hätte man nur die Latenz des Start-Bytes als Problem.

Praktisch gesehen finde ich die Lösung die Live suggeriert (wenn sie denn funktionieren würde) die Beste. Also es sieht jedenfalls so aus als ob das die Intention von Ableton wäre im Hinblick auf Midi Sync:
1) Man schaut in die Timeline wie der Versatz in ms ist
2) trägt den Wert ein in den presfs
3) Live oder die jeweilige DAW startet um diesen Offset die Midiclock früher und alles andere (DAW timeline, Recording-Punch In dies-das) folgt dann nach dem Offset "pünktlich"
 
Zuletzt bearbeitet:


News

Zurück
Oben