Elektron Tonverk V1.01

[polysix]

Hab mich nie mit DSP Programmierung beschäftigt aber eine höhere Latenz klingt für mich bei einem Linux OS allein schon aufgrund der Treiber und vermutlich einigen Abstraktionsschichten, durch die die ganzen Audio- und Steuerdaten durchgereicht werden auch erstmal logisch.

Ich hoffe, dass es Möglichkeiten gibt, die Latenz auf nen möglichst statischen Wert zu bekommen (also unabhängig von Routing, Anzahl verwendeter FX usw), eventuell per DMA und Durchreichen? Kennt sich hier jemand damit aus?

Ich hoffe Fragen dieser Art stellt man sich bei Elektron nicht erst jetzt

ich habe keine Ahnung von Programmierung, aber Push 3 setzt meiner Meinung nach (bzw. was ich gelsen habe) auch auf ein Linux auf und da habe ich nichts wegen Sync Problemen gelesen. Warum sollte das nicht bald von Elektron behbar sein?
Bei meinem DT 2 war das Display nicht i.o = laut E. Produktionsfehler, beim DN 2 war das Volume Poti falsch verbaut = laut E. Produktionsfehler.
Wer weiß was beim Tonverk schief gelaufen ist. Vielleicht Abweichungen von Bauteilen in der Produktion? Mit / auf was anderem designed und muss jetzt angepasst werden? ich denke das Ganze ist bald gefixed... und die Kiste macht uns allen dann noch mehr spaß

 

[C0r€]

ich habe keine Ahnung von Programmierung, aber Push 3 setzt meiner Meinung nach (bzw. was ich gelsen habe) auch auf ein Linux auf und da habe ich nichts wegen Sync Problemen gelesen.

Ich habe mal gesucht und einige Beiträge zu hoher Latenz usw. beim Push 3 gefunden. Vielleicht wurden die mittlerweile gefixt?
Das ist eben nicht trivial zu programmieren, weil man gegebenenfalls MIDI und Audio Treiber gemeinsam anpassen muss und zusätzlich recht geringe Puffergrößen wählen muss (und ggf. höhere Sampleraten) - für die Wiedergabelatenz, was die Audio Algorithmen gegebenenfalls einschränkt, je nachdem wie man das implementiert, sodass man das vorher einplant.

Bei der Hardware haben sie ja ansich alles selbst in der Hand, also könnten sie auch die Treiber usw. alles anpassen und theoretisch könnten sie audio und MIDI auf Treiberebene synchronisieren, an einen Core binden, den Kernel ala Gentoo selbst kompilieren ohne den nicht benötigten Schnickschnack an Unterstützung nicht eingebauter Hardware usw.

Elektron wäre nicht die erste Firma, die das Thema Treiber unterschätzt.
Ich traue ihnen zu, dass sie es hinbekommen, bei dem was sie bislang schon alles umgesetzt haben.

Normal steige ich bei Elektron erst ein, wenn ein paar Jahre verstrichen sind. Bis dahin wird das dann wohl alles vergessen sein.

 

[rz70]

ich habe keine Ahnung von Programmierung, aber Push 3 setzt meiner Meinung nach (bzw. was ich gelsen habe) auch auf ein Linux auf und da habe ich nichts wegen Sync Problemen gelesen.

Also ich fand Push 3 in Bezug auf Sync beim Erscheinen unbrauchbar. Selbst 6 Monate später, war der in meinen Augen so schlecht, dass ich auch das zweite Gerät wieder zurück gegeben habe. Das wars dann auch bei mir mit Push und Ableton. Von Elektron bin ich glücklicherweise schon länger geheilt, aber die sollten aufpassen das man durch sowas nicht seine Kunden verprellt. Lustig würde ich das nicht finden, vor allen bei dem Preis (das gleiche galt für die Standalone der Push 3).

 

[aliced25]

Elektron hat bei den anderen Geräten einen ziemlich guten Job gemacht (Rytm, Monomachine, Machinedrum...). Elektron verwendet Glättungs- bzw. Kompensationsalgorithmen, um Jitter zu eliminieren. Der Sequencer lässt sich kaum stören!
Ich habe in der Vergangenheit einige Messungen und Testszenerien analysiert (Referenz Source: Innerclock Synclock). Jitter und Schwankungen werden erstaunlich gut von den Elektrons weggefiltert. Trotzdem können gewollte Tempoanpassungen präzise interpretiert werden, da haben andere Hersteller größere Probleme...
Latenz bzw. Jitter addieren sich und manchmal ist die Clock Source schon der erste Übeltäter, die MidiClock Bytes nicht priorisiert sendet. Gerade Controllerdaten (CC, MPE etc.) können den gemächlichen Midistream verstopfen...

zum Thema Hardware / Sequencer & Midi Latenz / Jitter:
https://www.innerclocksystems.com/litmus
Testreihen von vintage bis neu...

 

[siebenachtel]

......für die neue Platform........

Das ist das Stichwort.




edit: jetzt ist es ein Linux basiertes System.

Für die ganze "wir reden alles schön" Fraktion habe ich kein Verständnis.
Es ist eines wenn man sowas basierend auf einem gewissem vorab gegebenen Wissen macht.
Das ist aber hier nicht der Fall. Kann es auch gar nicht. Neue Plattform, neuer deal (zumindest elekron intern). Jetzt ist die kiste quasi ein PC.
Bei Elektronauts scheints ein paar Experten zu haben. Die reden davon das die meisten ein Linux System bis auf 8ms runter bringen.
Nach Jahren wie mir scheint. Erfahrungswerte dazu gibts ja. Gibt genug Linux basierte Gerätschaften. Sihe die posts vor meinem vs. Push z.bsp. . D.h. das Wissen was zu dem Fall hier vs. Latenz vorliegt zeigt -wenn schon denn schon- eher nicht in Richtung optimismus. Sihe ->

Wenn ich mir vorstelle dass wenn man ne andere Elektron durch den TV schleift, Audio rein-raus, und sich dabei 8ms Latenz einhandelt, dann ist das nicht das was Elektron user erwarten unter "verbesserter Latenz".


Denke die werden da längere Zeit an dem Gerät rumbasteln müssen.
sihe @Core ´s posts. Kann alles gut laufen. Könnte aber auch recht böhse enden.
Das weiss man zum jetztigen Zeitpunkt alles so nicht.


D.h. ergo: die Kiste kann was sie kann. Ist das was sie ist. Jetzt !
Nicht weniger, aber auch nicht mehr.

Finds ein bedauerliches Trauerspiel.Auch: weils auch sonst intern in der Kiste zeichen für Pfuscherei gibt.
Mal die ganzen one shot samples im PC durchhören.......
"Das" hat dann nichts mit coden und "neue platform" Problemen zu tun. Eigentlich noch nicht mal mit timeline.
Da liegen die Probleme ganz woanders.......