Roland TR-1000 Drummachine analog + digital + Samples + FM + ACB

Im All Tracks Mode wackeln E-RM Mulitclock oder/und Cirklon als Clock Target im Bereich von 135-139 BPM bei eingestellten 138 BPM. Das ist für mich unbrauchbar als Master Clock im Studio.
Mal so als Idee: die Tr-1000 hat doch auch Din sync Out? Das war bei Roland immer rock-solid.
Das ist ja eine 24ppq analoge Clock und es sollte möglich sein die mit entsprechendem Adapter in den Audio Sync In der E-RM Mulitclock zu senden.

Aber wie Roland es erwähnt hat, dass sie als Master Clock konzipiert wurde, haut bei der wackligen Clock nicht hin.
"Konzipiert als Master Clock" klingt auch wenig überzeugend ...

Es gibt also immer einen Weg. Ist zwar jetzt nicht ideal aber es ist alles da um auch im Layered Mode tightness zu haben.
Das macht doch keinen Spaß die Tracks manuel zu nudgen, damit die im Sync liegen. Die Funktion soll doch eigentlich das Gegenteil machen und das statische Timing aufheben ...

Ich lass das jetzt aber All Tracks Mode und hoffe, dass sie da in der nahen Zukunft die Latenz nochmal deutlich runter bekommen. Dann ist es mir gut genug.
Ich hoffe auch und denke, dass sich da gerade ein paar Leute gehörig den Kopf zerbrechen.
 
Warum gerade die DAW Fraktion sich wegen des hohen Lags aufregt wundert mich etwas... Latenzausgleich in einer DAW geht doch immer easy (außer in Cubase meine ich).
Mit einer DAW und entsprechender Hardware kommt man auf <5ms RTL runter und Latenzausgleich funktioniert tatsächlich (wenn nicht dann gibts Anleitungen, wie man es hinbekommt).

Von Hardware wird verlangt, dass es dann da mithalten kann, es stabil läuft, weil es da sogar weniger Freiheitsgrade in der Konfiguration gibt, die Hardware ist fix und kommt vom gleichen Hersteller wie die darauf laufende Software. Das sollte alles ohne Probleme und stabil laufen.

Ist ja nicht so dass die Hersteller Linux nehmen müssen. Die könnten auch 10x STM32 multicore bauen oder bare metal auf den ARM cores arbeiten, eigene Treiber Programmieren usw.
Anscheinend wollen die Firmen alle Vorteile vom Linux System mitnehmen (Dateimanagement, Display, Treiber für USB und Netzwerk usw.) und so tun als müssten sie nun nicht mehr an den Basics arbeiten. Wenn die Hersteller von vornherein falsche Hardware nehmen, um das dann mit Linux zu fixen, was die anderen Entwicklern in vielen Jahren vorher noch nicht geschafft haben (low latency auf Raspberry zum Beispiel) braucht man sich nicht wundern. Falsche Platform und/oder Architektur, normalerweise beides. Problem dabei ist u.a. auch das PCB Design. Wenn es in die Ghz Taktrate geht braucht man einen Profi im Design und gute Tools, ansonsten funktioniert es in mehreren Anläufen wahrscheinlich schlicht und einfach nicht (Anpassung der Signallaufzeiten etc.). Man muss dann Teile vom HW Design gegebenenfalls outsourcen, wenn man zum Beispiel Speicher an den Prozessor extern schnell anbinden will. Alternativ wird da mit USB rumgetrickst, also einfach USB ran und dann da alles dran. Die Denke wie bei Software. Einfach einen Layer einfügen, der wird das richten, das Problem müssen dann die Anderen (die am USB hängen) klären. Können sie jedoch nicht, wenn der Layer selbst das Problem ist, was die Performance verhindert.

Das kennt man ja schon lange vom PC, damit will man, wenn man dann ein Hardware Gerät kauft, nichts zu tun haben, sonst kann man auch gleich einen PC kaufen der das ja alles auch kann und noch viel mehr und besser, weil bessere Hardware (kein Popel-raspberry) und superniedrige Latenz bei max 1 Sample Jitter in der DAW in der DAW.

Die TR1000 läuft da doch auch 44,1 oder 48kHz Samplerate? Eigentlich auch ein Witz, in Kombination mit der Latenz.
 
Zuletzt bearbeitet:
Wenn die Hersteller von vornherein falsche Hardware nehmen, um das dann mit Linux zu fixen, was die anderen Entwicklern in vielen Jahren vorher noch nicht geschafft haben (low latency auf Raspberry zum Beispiel) braucht man sich nicht wundern. Falsche Platform und/oder Architektur, normalerweise beides.
Du meinst also, dass zumindest große Hersteller vor dem gigantischen Invest einer derartigen Hardwareentwicklung vorher keine Machbarkeitsstudien durchführen? Ich glaube das eher nicht. Aber glauben heißt nicht wissen, ich weiß ;-)
 
Du meinst also, dass zumindest große Hersteller vor dem gigantischen Invest einer derartigen Hardwareentwicklung vorher keine Machbarkeitsstudien durchführen? Ich glaube das eher nicht. Aber glauben heißt nicht wissen, ich weiß ;-)

Es gibt auch das Szenario, dass sie es einfach in Kauf nehmen, dass Latenz und Jitter mindestens erstmal schlecht sind, dann kaufen eben ein paar Kunden weniger. Also es kaufen ja die, die die Kiste zum Beispiel nur hinstellen und nichts groß damit machen, oder die, die nur mit der Kiste arbeiten und nichts anderes anschließen und die, die dafür Soundsets erstellen usw. Dann kann man aus Produktmanager noch hoffen, dass ein Entwickler es vielleicht doch schafft es zu fixen. Wenn nicht geht ja die Welt auch nicht unter, wie man an den Wettbewerbern sehen kann.
Der Markt bestätigt das ja, die TR1000 ist überall ausverkauft. Also scheint es nicht groß wichtig zu sein wie Latenz, Jitter und Kit-Umschaltung ist. Steht ja auch nicht in der Produktbeschreibung auf den Verkaufsplattformen in der Liste von Eigenschaften und Features. Die Leute kaufen das sogar ohne das vorher zu wissen und selbst wenn sie es wissen kaufen und behalten es trotzdem genügende “blind”. Also aus Produktmanager Sicht wird da einfach gebaut, was gerade wichtig ist damit die Käufer kaufen.
Das könnte dann jedoch langfristig einen Effekt haben. Wie bei Automobilherstellern, die schnell rostende Karosserien verkaufen. Das hat langfristige Auswirkungen auf die Kernmarke.

Bei mir hat das zum Beispiel schon dazu geführt, dass ich mir diese Jitter und Latenzen vor dem Kauf genau ansehe und dann fallen die lahmen Linux Kröten beim Kauf komplett raus, zumal es die auch oft parallel als Plugin gibt und das für mich besser performt (keine Latenzprobleme, mehr Instanzen, kein Platzbedarf, gegebenenfalls höhere Samplerate, einfachere Integration, weniger Peripheriekosten/Mischpult, auf mehreren Rechnern etc.)
Die TR1000 hat hier den Bonus der analogen Drums, die man so 1:1 nicht in ein Plugin bekommt. Diese Drumsounds brauche ich jedoch nicht mehr, das ist 2 Jahrzehnte zu spät. Dann hätte sie noch den Vorteil all-in-one Lösung für Drums, da fehlt eigentlich nur Physical Modelling oder ein Plugin-Konzept wie bei Korg für Fremdhersteller Soundengines. Da ist Roland eher konservativ. Da nehme ich für sowas lieber Modular, weil “kann es auch” und ist “da” und “wünsch dir was, das geht damit auch”, besserer Sound (je nach Modul, wenn man will) und Timing hat 0ms jitter, 0ms Latenz, kann ich ja auf dem Scope sehen. Wenn man damit nicht live performt ist die Größe nicht so wichtig.
Workflow spricht noch für TR1000. Das ist was mich am meisten reizt. Stimmige Drumsets auf Abruf mit direkter Kontrolle über viele Knobs und Elektron-Like Sequenzer. Special Sounds, zum Beispiel vom Modular, könnte man da per Samples reinladen und hat dann “alles drin” und abrufbar. Das kann die Rytm auch ähnlich und über viele Jahre gereift, halt etwas anders und paar Sachen besser, paar Sachen schlechter.
 
Zuletzt bearbeitet:
Ist ja nicht so dass die Hersteller Linux nehmen müssen.
Vor allem kann man Linux ja gerne nutzen fuer die ganze Datei-, USB- usw. -Sache usw, aber das eigentliche Abspielen koennte ja trotzdem ein minimaler Mikrocontroller machen, der dann vom Linux-Prozessor einfach nur den Befehl erhaelt, jetzt bitte abspielen oder jetzt bitte stoppen.
 
Die Leute kaufen das sogar ohne das vorher zu wissen und selbst wenn sie es wissen kaufen und behalten es trotzdem genügende.
Letztendlich liegt es in unserer Hand, das mitzumachen. Beim Tonverk, den ich kürzlich gekauft habe, war ich nicht so konsequent. Aber zu diesem Zeitpunkt hatte Elektron bereits öffentlich bekundet, dass sie an dem Jitter-Problem dran sind und es fixen werden. Mal schauen. Davon scheint Roland ja noch etwas entfernt zu sein.

Kleine Anekdote (ziemlich OT) dazu:

Letzten Samstag wollte ich neue Sportschuhe kaufen. Eigentlich war der Kauf schon fast abgeschlossen, als ich festgestellt habe, dass der Schuh in Größe 46 ganze 10 EUR teurer ist als in 45. Kann man mitmachen, muss man aber nicht. Ich hab die Schuhe dann nicht gekauft und dem Verkäufer auch freundlich mitgeteilt, warum. Vote with your wallet. Es sei denn, es geht um Krachmaschinen aus Schweden :mrgreen:.
 
Vor allem kann man Linux ja gerne nutzen fuer die ganze Datei-, USB- usw. -Sache usw, aber das eigentliche Abspielen koennte ja trotzdem ein minimaler Mikrocontroller machen, der dann vom Linux-Prozessor einfach nur den Befehl erhaelt, jetzt bitte abspielen oder jetzt bitte stoppen.
Bei multicore kann man das auch so machen, das man einen oder mehrere Core nur für echtzeit Tasks nimmt (Soundengine) und UI usw. dann in einem anderen core, der asynchron mit dem Echtzeit-core kommuniziert.
Das hat einige Vorteile und ist ein altes bekanntes Vorgehen.
Dann kann man die Echtzeit Tasks auf diesen Echtzeit Cores sogar ganz gut mit einem downgestrippten Realtime Linux oder anderen Realtime getrimmten OS laufen lassen, das nur diese Cores verwaltet. So schafft man locker <1ms oder <0,25ms Jitter an den Inputs und Outputs bei 1ms Latenz, selbst mit alten Cores bis zu einer gewissen Rechenlast. Damit das geht sollte der Chip dann gewisse Sachen mitbringen, die man auch für die Virtualisierung braucht.
 
Zuletzt bearbeitet:


Neueste Beiträge


Zurück
Oben