Elektron Tonverk V1.01

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ß :D
 
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.
 
Zuletzt bearbeitet:
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).
 
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...
 
......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.......
 
Zuletzt bearbeitet:
Ich finde folgendes Statement eines Elektronauts Forum Admins/Beta Testers zu den möglichen Ursachen der vielen Bugs interessant. Eventuell gab es da gewisse Einblicke und lässt auf baldige Problembehebung hoffen. Ein paar vertrauenswürdige und fähige Beta Tester mehr hätten meines Erachtens trotzdem nicht geschadet.

 
It might help to understand that in nowadays world, a company doesn’t put a hardware product on the market without a huge amounts of logistics, with many people involved. So you have to fix a date, and as it is very hard to cancel it you have to make what you can to release at that time.
Das ist interessant ja. An sowas denkt man ja gar nicht als (allenfalls gepisster) Käufer

Last thing is that this is a brand new architecture, with most likely new devs.
So many aspects to debunk, that you might not have to retry in details if it’s the fifth version of the architecture you put out.
Und da sagt er es selbst.

Und das ist eben genau das "Problem". Man kann in dem Falle hier nicht auf Erfahrungswerte mit DT und Konsorten verweisen.
Wusste ich z.bsp. nicht !

Man muss eher auf Linux basierte Geräte anderer Häuser verweisen und gucken wie es denn dort lief.


So yeah, nowadays I think it’s best, if you don’t want to deal with teething troubles, to wait a few months for the firmware updates to come out.
Darauf läufts hinaus. Aber ->

But if you are willing to try it anyway, cause you think it is still a nice box despite the present flaws, you might want to think that you are actually helping the community when you declare a bug. Cause you do.
Zum einen: hätten sie ne gewisse "offenere" Kommunikation betreiben können, und dem Kunden damit mit ner gewissen fairness begegnen können. Da sagt dir aber jede Consulting Bude: Um himmels Willen, tu das ja nicht !

Zum anderen: hätten sie das Gerät ganz einfach auch als erste Charge gezielt mit 25% oder besser 30% Rabatt verkaufen können.
Das wäre fair gewesen.

So wie es jetzt ist, wars Kunden verarsche.
Und damit richten sie auch Schaden bei sich selbst an.
Bezweifle dass sie ein 25-30% Rabatt teurer gekommen wäre.

Alle Hersteller die so arbeiten richten insgesammt Schaden am HW-Markt an. Das Vertrauen schwindet.
ymmv
 
Nun ja. Die Response darauf ist nicht wirklich positiv.
Bei dieser Menge an teils trivialen Bugs, die *eigentlich* jede ordentlich arbeitende Qualitätssicherung, sowie jeder Beta Tester hätten finden können und müssen sind negatigve Reaktionen auch begründet und nachvollziehbar wie ich finde. Soll nicht heissen, dass man diesen Reaktionen beipflichten sollte. Aber ein im Voraus festgelegter Releasetermin wäre immerhin eine plausible Erklärung für einige der Bugs. Für mich klingt das nach mächtig Zeitdruck, was man ja sonst aus der Spielebranche leider auch bereits kennt. Vielleicht betitelt Elektron die eigenen Sample Engines des TV auch deshalb mit "Single Player" und "Multi Player"? ;-)
Wie auch immer - ob Elektron all die Bugs in dieser Fülle bereits bekannt waren wage ich mal zu bezweifeln, aber beruhigender finde ich zu wissen, dass Elektron darum bemüht ist, Bugs zu beheben. Verfrühter Release hin oder her, ich hab die Kiste gerne jetzt schon daheim stehen und bin mit dem bisherigen Ergebnis bereits mehr als zufrieden. Heulen kann ich dann immernoch, wenn es die Features, die ich mir erhoffe nicht "rechtzeitig" in eines der künftigten Firmware Updates schaffen :D
 
Linux und Timing scheint ja ein grundsätzliches Problem zu sein … wieso ein ganzes OS mitschleppen? Hab ich nicht kapiert.
 
mich beschleicht der Gedanke das die das so unfertig released haben um vor der Tr-1000 am Markt zu sein
 
Linux und Timing scheint ja ein grundsätzliches Problem zu sein … wieso ein ganzes OS mitschleppen? Hab ich nicht kapiert.
Würde ich pauschal nicht verurteilen. Der TV rennt ja auf einem Echtzeitbetriebssystem, wie sie auch beispielsweise in der Automobilindustrie Verwendung finden. Da ist Latenz auch ausschlaggebend. Keine Ahnung, ob auch im Millisekundenbereich wie bei Audio, wenn's um Autonomes Fahren geht aber bestimmt auch.

Denke mal die Leute bei Elektron werden sich schon ihre Gedanken gemacht und nicht blind darauf losgebastelt haben. Auf Dauer wird man das Latenzproblem wohl mindestens so gut wie die Konkurrenz auf ähnlichen Betriebssystemen hinbekommen und auf Dauer von der vereinfachten Entwicklungsmöglichkeit profitieren (my two cents, yet again).
 
Es wäre besser bei unfertigen risikobehafteten Produkten (neue Platform) mit einem etwas günstigerem VK Preis einzusteigen und dann, wenn die Bugs behoben sind und alles Versprochene funktioniert, den Preis anzuheben. So das man bezahlt was man bekommt zu dem Zeitpunkt. Wenn es wirklich nur ein paar Wochen bis Monate dauern wird, dann ists auch so OK. Wir werden sehen.
 


Neueste Beiträge

News


Zurück
Oben