Squarp Hapax - polychronic Midi MPE Sequencer V2.0X

[Blingistan]

Schon klar, aber diese naive Implementierung würde eine lange (und berechtigte) Liste weiterer Feature-Wünsche nach sich ziehen. Denn, was wenn ich ein neues Projekt angelegt hab vor dem Ausschalten. Was, wenn ich das Projekt lange nicht gesichert habe. Wenn schon beide Projekte automatisch geladen werden, dann erwarte ich auch, dass sie in dem Zustand geladen werden in dem sie zuletzt waren. Inklusive welches Projekt aktiv war, etc. Und da fängt es dann halt wieder an, wann was mit welchen Konsequenzen für die Haltbarkeit das Speichers gesichert wird. Mich nervt es ja auch, dass Hapax das immer noch nicht kann.
Roland hats ja beim TR-8S so gemacht, dass ein Ausschalten erstmal ein Sichern und Runterfahren zur Folge hat. Wenn der Strom plötzlich weg ist – aus Versehen oder via Steckerleiste – dann gibt es ganz schnell mal ein kaputtes Dateisystem. Zumindest ist mir das 2x passiert. Seitdem verzichte ich da auf Auto-save.

Vielleicht ist es auch wirklich viel simpler als ich mir das vorstelle und Squarp haben einfach nur keine Hamburger essenden Praktikanten.

 

[laux]

Im Pyramid gehts ja auch und ist so von der Funktionalität ausreichend mMn:

AUTOLOAD OFF / LAST SAVED PROJECT / LAST LOADED PROJECT
After startup, Pyramid can load an empty project, load the last saved project or load the last loaded project.

 

[Gisel1990]

Wenn schon beide Projekte automatisch geladen werden, dann erwarte ich auch, dass sie in dem Zustand geladen werden in dem sie zuletzt waren.

Was hat das eine mit dem anderen zu tun? Du redest von Autosave, ich von Autoload. Autosave brauche ich persönlich übrigens nicht und finde es im Gegenteil lästig. Ich stamme EDV-technisch noch aus der Zeit, wo man selber verantwortlich für seine Daten war. Ich brauche keine 100 Autosave-Dateien oder 'ne Software, die mich ständig daran erinnert, dass man häufig speichern soll.

Vielleicht ist es auch wirklich viel simpler als ich mir das vorstelle und Squarp haben einfach nur keine Hamburger essenden Praktikanten.

Es ist simpler, als du dir vorstellst.

Es geht mir auch gar nicht darum. Dass hier Anwender (nicht nur ich) ein simples Standardfeature requesten, und es nicht umgesetzt wird, damit bin ich 100% fein!

Seltsam finde ich, wie Squarp stolz erwähnt, dass Booten jetzt noch "faster" ist. Ich meine, ich muss dann doch sowieso händisch das Projekt laden, also welche große Zeitersparnis bringt mir die Zehntelsekunde beim Booten?

 

[verstaerker]

Im Pyramid gehts ja auch und ist so von der Funktionalität ausreichend mMn:

richtig.. völlig unverständlich das es das hier nicht mehr gibt

 

[Moogulator]

Im Pyramid gehts ja auch und ist so von der Funktionalität ausreichend mMn:

Wenn ihr schon zu dritt diese Idee habt, ggf. mal weiter leiten an Squarp? Ist bestimmt dann irgendwo in der Liste und wenn es sinnvoll und machbar ist, machen sie es bestimmt auch mal.

 

[Blingistan]

Wieso sollen sie das Improvement nicht erwähnen? Ist echt nochmal schneller geworden. Kein Vergleich mehr zu der Zeit, die das Starten und erst recht das Laden von Projekten anfangs benötigt hat.

Was hat das eine mit dem anderen zu tun? Du redest von Autosave, ich von Autoload.

Ich fand es beim Pyramid aber auch irritierend, dass beim Start zwar das letzte Projekt aber nicht der letzte Zustand dieses Projekts geladen wurde. Hat mich immer genervt. Dann lieber gar nichts laden. Oder ein Default.

Wie gesagt, meine Vermutung ist, dass es an der Doppel-Projekt-Struktur und dem Fehlen einer Speichermöglichkeit des Zustands beider Projekte liegt, weswegen es noch nicht mal das default als Start-Option gibt. Kann mich täuschen.

Das nächste Update soll ja dann ein Feature-Update sein. Sollte das Verhalten beim Start dann immer noch nicht besser sein, wird mir auch das Verständnis ausgehen…

 

[Gisel1990]

Ich fand es beim Pyramid aber auch irritierend, dass beim Start zwar das letzte Projekt aber nicht der letzte Zustand dieses Projekts geladen wurde. Hat mich immer genervt. Dann lieber gar nichts laden. Oder ein Default.

Jede Maschine hat ja ihren Workflow, und der Workflow beim Hapax ist halt, dass man selber speichert, wenn man a) Arbeit getan hat, die nicht verloren gehen soll (z.B. durch einen Absturz) oder b) bevor man die Kiste ausmacht. Find ich nicht irritierend sondern klassisch. Und da ich normaler Weise an einem Projekt mehrere Wochen arbeite, würde ich persönlich ein Autoload vom letzten Projekt begrüßen. Aber andere starten vielleicht lieber mit einem Default-Projekt, wo die ganzen Tracks schon auf die Synths konfiguriert sind. Denkbar wäre ja auch - und hier wird's richtig crazy - dass man das Boot-Verhalten als Anwender selber in den Settings bestimmen kann. Nicht, dass ich es wagen würde, so einen abgefahrenen Request an Squarp heranzutragen. Die Zehntelsekunde Bootersparnis durch das neue Update - also wenn man das mal zusammenrechnet, das sind bei 10 Starts schon eine Sekunde gewonnene Lebenszeit

 

[Blingistan]

Ich will doch auch ein Autoload vom letztem Projekt bzw beiden. Aber halt "wie bei Elektron". Dass es schnell zu coden ginge, den letzten Projektnamen beim Laden irgendwo hin zu schreiben und dann beim nächsten Boot das abzurufen ist mir doch auch klar. War lange genug Entwickler. Aber zwischen dem was ich als Entwickler "schon ok so" finden möchte und dem was ich als Benutzer erwarte, liegen halt manchmal ein paar Schluchten. So auch hier. Zumindest hoffe ich, dass Squarp da eine bessere Lösung als beim Pyramid findet.

Das wird alles kommen. Ganz sicher. Schon bald Vielleicht noch dieses Jahr ;(

 

[Gisel1990]

Hatte noch nie was von Elektron. Wird bei denen jede Änderung direkt gespeichert, und man muss das Projekt gar nicht selber speichern, oder wie oder watt?

Ich denke, das ist technisch eine gewisse Herausforderung für den Hersteller, wird beim Hapax sicher nicht kommen, und überhaupt frage ich mich, ob ich das als Anwender unbedingt brauche. Wenn ich der Kiste den Saft nehme, indem ich sie ausschalte, ist doch logisch, dass der nicht gespeicherte Fortschritt weg ist. Find das jetzt nicht so problematisch, dass man vorher mal eben speichert.

 

[Blingistan]

Es wird bei Elektron alles in einen quasi permanenten temporären Speicher gesichert. Sofort. Dabei wird allerdings das gespeicherte Projekt nicht berührt. Das Sichern in dieses Projekt passiert manuell. Das Arbeiten/Frickeln/Komponieren findet in diesem temporären Speicher statt, der aber eben jederzeit erhalten bleibt, auch wenn der Strom plötzlich weg ist. Aber prinzipiell "muss" man nie speichern. Außer man wechselt das Projekt und/oder will die Änderungen erhalten. Natürlich ist es trotzdem sinnvoll ab und an zu sichern um sich vor unabsichtlichem Überschreiben/Löschen/Verändern zu schützen.
Wenn man von diesem Workflow kommt fühlt sich alles andere ein bisschen wie Steinzeit an. (Also, klar, nur meine Meinung. Nicht alles an Elektron ist perfekt, aber das ist wirklich richtig gut gemacht.)

EDIT 1:
Ich erwarte das jetzt nicht direkt so beim Hapax. Aber ich hoffe, dass das lange Warten auf eine Lösung dieses Themas durch eine schönere Umsetzung als beim Pyramid belohnt wird.

EDIT 2:
Habe auch vor vielen Monaten an Squarp einen entsprechenden Feature Request geschickt. War nicht mein einziger.

 

[verstaerker]

Wenn ihr schon zu dritt diese Idee habt, ggf. mal weiter leiten an Squarp? Ist bestimmt dann irgendwo in der Liste und wenn es sinnvoll und machbar ist, machen sie es bestimmt auch mal.

hab ich schon vor nem Jahr gemacht zusammen mit anderen Wünschen

 

[Gisel1990]

Ok, dann hat Elektron also RAM, der bei Wegfall des Stroms seine Daten behält. Oder normalen RAM, und nur die Objekte werden in einen weiteren, nicht flüchtigen RAM ausgelagert. Bei spezialisierten Maschinen wie Grooveboxen und Sequenzern mag diese Technik sinnvoll sein. Aber deswegen die klassische Kombo RAM + Massenspeicher als Steinzeit zu bezeichnen, halte ich für übertrieben.

Ich denke, Elektron hat da einen Technologievorsprung. Bei kleinen Firmen wie Squarp, die auf ARM-Architektur von der Stange setzen (mutmaßlich), würde ich das in absehbarer Zukunft nicht erwarten.

 

[microbug]

dann hat Elektron also RAM, der bei Wegfall des Stroms seine Daten behält.

Das haben Andere schon sehr lange, nennt sich entweder batteriegepuffert oder Flashspeicher, der aber kein RAM ist.

Oder normalen RAM, und nur die Objekte werden in einen weiteren, nicht flüchtigen RAM ausgelagert.

RAM gibts in 2 Versionen: statisch (teuer) und dynamisch (je nach Ausführung in Massen hergestellt, weil in Desktop-und Mobilrechnern eingesetzt in Form von DIMMs oder SODIMMs - dieser Speicher braucht einen sogenannten Refresh und ist immer flüchtig). Nur SRAM kann man batteriepuffern, wobei man da idealerweise CMOS-Varianten nimmt, die noch weniger Strom im Standby brauchen als die Normalversionen (es gab auch schon Konstruktionen, bei denen man DRAM mitsamt der sie versorgenden Refreshlogik batteriegepuffert hat, aber das gehört in die Abteilung Kuriositäten und war auch nicht mit einer 3V-Batterie erfolgt, sondern mit Bleiakkus).

Aber deswegen die klassische Kombo RAM + Massenspeicher als Steinzeit zu bezeichnen, halte ich für übertrieben.

Da gehe ich mit, wobei ich glaube, daß es vom Autor nicht so gemeint war.

Bei kleinen Firmen wie Squarp, die auf ARM-Architektur von der Stange setzen (mutmaßlich), würde ich das in absehbarer Zukunft nicht erwarten.

Was bitte hat ARM-Architekur "von der Stange" (was auch immer das heißen mag) mit der Art des (massen)Speichers zu tun?

 

[molemuc]

Ich habe meinen Hapax lieb ...

 

[Lauflicht]

Schön, dass es endlich ein Lebenszeichen der Entwickler gibt.

 

[Gisel1990]

Was bitte hat ARM-Architekur "von der Stange" (was auch immer das heißen mag) mit der Art des (massen)Speichers zu tun?

Z.B. wenn da ein Raspberry PI (oder ein ähnliches Standard-Board) drinsteckt, dann hätte der Hersteller nicht die Möglichkeit, das so zu machen wie Elektron, weil die Architektur vorgegeben ist.

Speichern "on the fly", sprich ich ändere im Sequenzer eine Note und die Änderung ist auch bei einem plötzlichen Stromausfall noch vorhanden, würde auf jeden Fall einen schnellen und nicht flüchtigen Speicher erfordern, und das ist sicherlich nicht die billigste Variante.

 

[molemuc]

wiw ma Henry die das dann mit undo und redo

 

[fairplay]

wiw ma Henry die das dann mit undo und redo

…bitte: wie? - was?…

 

[molemuc]

Wie machen die das mit undo und redo

 

[fairplay]

Wie machen die das mit undo und redo

…bei objektorientierter Programmierung ist das quasi schon mit drin: alle User-Eingaben setzen Eigenschaften von Objekten - wenn man diese Eingaben im Arbeitsspeicher hält solange das Gerät läuft kann man die Kette der Eingaben vor- und zurück laufen und die entsprechenden Eigenschaften eines Objektes setzen; mit dem Ausschalten des Gerätes verliert man allerdings diese ‘Ketten’…

 

[Gisel1990]

@molemuc Undo/Redo findet genau wie das ganze Projekt im schnellen flüchtigen RAM statt. Bei Stromausfall, Betätigen des Aus-Schalters oder einem Absturz/Freeze ist Undo/Redo mit weg. So ist der klassische Weg.

Wenn ich allerdings Projekt-Objekte (Noten, Automationen usw.) und Undo/Redo-Informationen so speichern will, dass diese Daten auch nach "Strom weg" bzw. Absturz immer da sind, dann brauche ich einen extra Speicher, der a) nicht flüchtig ist und b) auch nicht zu langsam ist, weil der User ansonsten beim Arbeiten einen LAG bemerken würde, wenn er z.B. Noten live recordet. Auch der BUS zum "normalen RAM", wo die Berechnungen stattfinden, sollte natürlich schnell sein. Das alles kostet.

Meine Roland MC 707 kann das übrigens auch nicht. Wie ist das bei Akai?

Ich sollte mir vielleicht mal ne Elektron Groove-Box aus Spaß zulegen, wenn die so gut sind. Welche wäre für den Einsteg zu empfehlen? Digitakt?

 

[microbug]

Z.B. wenn da ein Raspberry PI (oder ein ähnliches Standard-Board) drinsteckt, dann hätte der Hersteller nicht die Möglichkeit, das so zu machen wie Elektron, weil die Architektur vorgegeben ist.

Nein. Man kann sowohl beim Standard RPi als auch beim Compute Module entsprechenden Speicher einbinden.

Elektron setzt aber auf Coldfire MCUs, das sind von der 68k-Familie abgeleitete RISC Prozessoren. Komplett andere Baustelle also.

 

[Gisel1990]

Elektron setzt aber auf Coldfire MCUs, das sind von der 68k-Familie abgeleitete RISC Prozessoren. Komplett andere Baustelle also.

Ich dachte, Motorola 68000 wäre CISC, so wie auch Intel 80386, aber ich gestehe offen, mein Informatik-Studium ist ewig her, von daher no RISC no fun.

 

[Moogulator]

Nö, die 68K Familie war ja bekannt dafür - Apple, Amiga, Atari - alle gegen Intel auf RISC. Ist aber bisschen OT.
In div. Synths der Zeit waren die auch - Waldorf zB.

 

[Gisel1990]

Also dass der 68000 RISC war, würde mich jetzt extrem wundern, könnte man zur Not auch googeln, hab den damals an der UNI in Assembler programmieren müssen.

Aber weiß man denn, was der Hapax für 'ne CPU benutzt? Beim Googeln find ich auf den 1. Blick immer nur die Info "dual-processor architecture" und nichts weiter. Gibt aber sicher irgendwelche Freaks, die den Kasten schonmal geöffnet haben.

 

[microbug]

Ich dachte, Motorola 68000 wäre CISC

Natürlich. Da gehts aber um die Register und den gernerellen Aufbau, wußte ich mal im Detail, müßte ich selbst nachschauen.

Also dass der 68000 RISC war, würde mich jetzt extrem wundern,

Zu Recht. Wenn man überhaupt einen aus der Motorola/Rockwell-Familie als RISC bezeichnen könnte, wäre es der 6502, aber sicher nicht 6809 und 68000. 68k Assembler ist aber noch angenehm im Vergleich zu dem ganzen Intel-Murks und der davon abgeleitet wurde (Z80, 64180, 78xxx). Bei denen streike ich heute noch, leider sind die gerade in Musikelektronik sehr häufig eingesetzt worden.

Hapax wird wohl die gleiche MCU bzw aus der gleichen Familie benutzen wie der Pyramid, die werden wohl kaum mit verschiedenen Entwicklungssystemen arbeiten wollen. CPUs werden in Embedded Systemen übrigens schon lange nimmer eingesetzt, und auch in Synths findet man deutlich mehr MCUs als CPUs, selbst in den 80ern. Z80 und 6502 waren da eher die Ausnahme, MCS48/51/96 und die uPD78xx(x) Reihe eher die Regel, ebenso 6303/6803/6805.

Meine Roland MC 707 kann das übrigens auch nicht. Wie ist das bei Akai?

Akai weiß ich nicht, aber die Maschine plus kann das, speichert wohl zwischendurch temporäre Dateien auf die SD Karte, man wird dann beim Einschalten gefragt, ob man das gesicherte Projekt wiederherstellen möchte.

Bei den Elektrons muß man die Bedienung mögen. Meins war die nicht, jedenfalls nicht die der "Model"-Teile.

 

[Kai-vD]

Ich hatte ja wirklich gehofft, dass mit dem Update auch die Step-Recording Funktion kommt. Bin ich hier der einzige, der diese Funktion vermisst?

 

[verstaerker]

Ich hatte ja wirklich gehofft, dass mit dem Update auch die Step-Recording Funktion kommt. Bin ich hier der einzige, der diese Funktion vermisst?

hattest du ein Featurerequest eingereicht?

Squarp haben schon beim Pyramid sehr lange gebraucht neue Features einzubauen... beim Hapax ist da nicht anders. Ich würde an deiner Stelle nicht drauf warten. Es sei denn der Support hat dir schon versichert das es bald kommt. (ich bekomme immer so eine Antwort wie "wir werden das prüfen und mit dem Team besprechen")

P.S. weil du gefragt hast: ich brauch so ein Feature nicht wirklich und P.P.S. der Cirklon kann dann das

 

[Kai-vD]

hattest du ein Featurereduest eingereicht?

Nein, ich ging davon aus, dass dieses Featurerequest massenhaft dort aufgelaufen wäre.

 

[verstaerker]

Nein, ich ging davon aus, dass dieses Featurerequest massenhaft dort aufgelaufen wäre.

ich würde nie darauf bauen das ein Feature das einem wichtig ist, Andere auch wollen .. du unterstreichst die Wichtigkeit wenn du auch schreibst

Email an Squarp
[Hapax - Feature Request] Step Recording