Nur OnTopic Waldorf M - Microwave Nachfolger

Bitte stark genau im Thema bleiben wie es im ersten Beitrag steht. Alles andere gilt als OT und kann gelöscht werden.
@VladiS Mir ist heute beim Schrauben am M aufgefallen, das das Audiosignal weiterhin (sehr leise, aber immerhin) durchkommt, obwohl der Master Volume auf 0 gedreht ist (bei einer laufenden Arp Sequenz bzw. Drone durch Note On). Ist das schon bekannt? Ich bin auf dem aktuellen Patchstand.
 
Zuletzt bearbeitet von einem Moderator:
Ich war jetzt ein paar Tage mal nicht hier, will aber noch mal was zum Flash schreiben:


Es passieren da ja aber auch noch andere Schreibvorgänge als nur das Aus- und Einschalten. Das hast Du vergessen.

Natürlich passieren auch noch andere Schreibvorgänge. Es ist ja aber nicht so, daß das Flash nur eine Zelle hat, die 100k mal beschrieben werden kann, sondern jede einzelne Zelle kann so oft beschrieben werden. Wenn man jetzt ein vernünftiges Interleaving einbaut (und nicht einfach nur den nakten Flash baustein), dann reicht das echt ewig, weil so viel nun auch nicht geschrieben wird in das Flash. Der eine Block (256k (oder wie gross der auch ist) ) wird ja erst dann wieder überschrieben, wenn er der älteste derzeit nicht verwendete block ist.

Aber das nur am Rande. Man müsste also das Flash nicht so schnell kaputt schreiben.

Allerdings muss man noch was ganz anderes bedenken. Mann schreibt dem Patch ja nicht beim Ausschalten. Da kann man in der Regel mal gar nichts mehr machen, weil Ausschalten einfach den Strom komplett wegnimmt und nichts mehr geht.

Vielmehr müsste man den Patch bei jedem Patch select wieder speichern oder zumindest beim Patch Edit.

Noch eine alternative wäre im Übrigen ein Gepuffertes RAM mit einer CR2032 einzubauen und einfach keine Knopfzelle mitzuliefern. Und schon gibt es kein Problem, weil der Benutzer die Baterrie einsetzt. Ansonsten soll es wohl auch mit Akkus gehen ;-) Da gibt es welche, die z.B. für Handys hergestellt werden. Da könnte man einfach einen von nehmen. Ein Platzproblem wird es wohl nicht sein.
 
Ich verstehe das Problem immer noch nicht. Es muss dem System beim Ausschalten doch nur *einmal* gesagt werden: "Lade beim nächsten Mal nicht Bank 0, Patch 0", sondern "Lade beim nächsten Mal Bank X, Patch Y".

Und falls das beim Ausschalten nicht gehen sollte, schreibt man halt bei jedem Speichern zwei Zahlen für die Bank und die Patchnummer. Der Sequential Take 5 startet übrigens automatisch mit dem letzten aufgerufenen Patch – ist denen einfach egal, ob der Flash irgendwann hinüber ist? ;-)
 
Hallöchen..

Ich mache das in meinem DIY Synthi "Jeannie" ähnlich. Wenn ich einen Patch selektiere bzw auswähle wird die Patch No in das EEPROM geschrieben und beim Starten des Synthis wieder geladen.
 
Verstehe ich jetzt auch nicht warum das heute so schwer sein soll. Das konnte 1983 schon ein DX7/DX9.
 
Mein Kronos merkt sich auch immer den Zustand beim Ausschalten...muss ich jetzt Angst drum haben und die Funktion deaktivieren ? 😂
 
Frei nach Queen:

Flash! ah ahhhhh!


Gibt es denn auf dem Bauteilmarkt keinen Flash der das ohne Bauchweh kann? Oder sind das alles nur Fläschchen oder Flaschen?
 
Zuletzt bearbeitet:
Mann könnte einen Timer Funktion beauftragen, der alle 30 Sekunden oder kürzer schaut ob sich Patch Parameter geändert haben und wenn ja, diese dann vom Ram in das Flash schreibt.

Dadurch reduziert sich die Schreibrate zum Flash und verlängert die Lebenszeit.
 
Zuletzt bearbeitet:
Es muss doch einfach immer nur der letzte aufgerufene, gespeicherte Patch geladen werden, unabhängig von Parameteränderungen.
Dafür braucht man beim Einschalten die Information, welches Patch zuletzt geladen war. Damit diese ausgelesen werden kann, muss das System die Info erst schreiben.
Es ist quasi nur ein Eintrag/link zum Patch - nicht das Patch selbst. Da beißt sich die Katze in den Schwanz.

Wie das im M gehandhabt wird, scheint heutztage eher normal zu sein. Sowohl beim Jupiter X (dort muss man aber erst eine Startup Scene von Hand einstellen) als auch beim Summit muss man das Systemsetting einmal abspeichern, um das beim Speichervorgang geladene Patch beim Einschalten zu laden.
Das ist dann so etwas wie ein globaler Snapshot, der beim Booten abgerufen wird. Von da an wird beim Einschalten immer das Patch geladen, das von Hand mit dem Systemsetting gespeichert wurde.
Vielleicht wäre das auch eine Option für den M?
 
Zuletzt bearbeitet:
Dafür braucht man beim Einschalten die Information, welches Patch zuletzt geladen war. Damit diese ausgelesen werden kann, muss das System die Info erst schreiben.
Es ist quasi nur ein Eintrag/link zum Patch - nicht das Patch selbst. Da beißt sich die Katze in den Schwanz.

Wie das im M gehandhabt wird, scheint heutztage eher normal zu sein. Sowohl beim Jupiter X als auch beim Summit muss man das Systemsetting einmal abspeichern, um das beim Speichervorgang geladene Patch beim Einschalten zu laden.
Das ist dann so etwas wie ein globaler Snapshot, der beim Booten abgerufen wird. Von da an wird beim Einschalten immer das Patch geladen, das von Hand mit dem Systemsetting gespeichert wurde.
Vielleicht wäre das auch eine Option für den M?

Ja, man braucht die Information, aber man muss nicht bei jeder Parameteränderung was schreiben, sondern nur einmal beim Patch-Wechsel.
 
Ja, man braucht die Information, aber man muss nicht bei jeder Parameteränderung was schreiben, sondern nur einmal beim Patch-Wechsel.
Ach so meinst Du das - ja logisch, das stimmt. Ob das beim M aus irgendwelchen Gründen anders ist oder sein muss, das weiß ich auch nicht.
Da war der alte Microwave schon sehr vorbildlich, auch mit all seinen Edit Buffern.
 
Zuletzt bearbeitet:
Flash hält nicht ewig. SSDs in Servern z.B. sterben deshalb und müssen getauscht werden. Man schreibt mit einer Logik, so dass alle Zellen gleichmässig ausleiern. Waldorf hatte das "Problem" erstmalig beim Microwave II. Der Microwave nutzt noch batteriegepuffertes SRAM und EPROMs für das OS. Vladmir hat beim M nun so entschieden, weil ihm Langlebigkeit wichtig war. Daher gibt es im M auch keine Edit Buffer, hatte er mal erwähnt. Er überlegt ja schon, ob und wie er es (Patch beim Start) ändern mag und kann.

Technischer Fortschritt geht eben auch mal nach hinten los. Siehe auch TDM vs. VoIP.
 
@VladiS Mir ist heute beim Schrauben am M aufgefallen, das das Audiosignal weiterhin (sehr leise, aber immerhin) durchkommt, obwohl der Master Volume auf 0 gedreht ist (bei einer laufenden Arp Sequenz bzw. Drone durch Note On). Ist das schon bekannt? Ich bin auf dem aktuellen Patchstand.
Interessant. Es gibt nicht bei meinem M, obwohl es kann im Prinzip sein, wegen passive Komponenten Toleranz. Ich koennte das aber fixen bei schalten Mixer Ausgabe aus 0 beim Mastervolume 0.
 
Ja, man braucht die Information, aber man muss nicht bei jeder Parameteränderung was schreiben, sondern nur einmal beim Patch-Wechsel.
Ich werde das Speichern/Wiederherstellen des zuletzt geladenen Patches in der naechsten FW-Version zusammen mit der Option des schnellen Ladens hinzufuegen (d.h. keine Recall zu druecken, einfach den Encoder drehen). Allerdings muss in diesem zukuenftigen "Schnelllademodus" - um zu vermeiden, dass der Flash (nicht das EEPROM, das ist noch schlimmer) abgenutzt wird - immer noch explizit Recall gedrueckt werden, um den Zustand des zuletzt geladenen Patches zu speichern. Ich kann nicht zulassen, dass jede Umdrehung des Patch-Encoders protokolliert wird, was zum Laden des Patches fuehrt. Sorry.
 
Ich werde das Speichern/Wiederherstellen des zuletzt geladenen Patches in der naechsten FW-Version zusammen mit der Option des schnellen Ladens hinzufuegen (d.h. keine Recall zu druecken, einfach den Encoder drehen). Allerdings muss in diesem zukuenftigen "Schnelllademodus" - um zu vermeiden, dass der Flash (nicht das EEPROM, das ist noch schlimmer) abgenutzt wird - immer noch explizit Recall gedrueckt werden, um den Zustand des zuletzt geladenen Patches zu speichern. Ich kann nicht zulassen, dass jede Umdrehung des Patch-Encoders protokolliert wird, was zum Laden des Patches fuehrt. Sorry.

Das klingt doch sehr gut! 👍

Ich persönlich finde es sowieso besser, die Patches per Recall-Taste zu laden – das würde perfekt passen!
 
Ich werde das Speichern/Wiederherstellen des zuletzt geladenen Patches in der naechsten FW-Version zusammen mit der Option des schnellen Ladens hinzufuegen (d.h. keine Recall zu druecken, einfach den Encoder drehen). Allerdings muss in diesem zukuenftigen "Schnelllademodus" - um zu vermeiden, dass der Flash (nicht das EEPROM, das ist noch schlimmer) abgenutzt wird - immer noch explizit Recall gedrueckt werden, um den Zustand des zuletzt geladenen Patches zu speichern. Ich kann nicht zulassen, dass jede Umdrehung des Patch-Encoders protokolliert wird, was zum Laden des Patches fuehrt. Sorry.
Wenn sich es machen ließe, wäre ein Digitaler Hochpass von der Güte also 24db super. Perfekt wäre noch ein Kopplung an denn Tiefpass um ein Bandpass zu erzeugen?
 
Wenn sich es machen ließe, wäre ein Digitaler Hochpass von der Güte also 24db super. Perfekt wäre noch ein Kopplung an denn Tiefpass um ein Bandpass zu erzeugen?
Die zusaetzlichen VCF-Typen koennten im Prinzip in DSP Firmware fuer mindesten den Modern Mode implementiert werden. Ich versuche gerade nach den MW2-Code, um einen Weg zu finden, wie man bestimmte VCF-Typen aus MW2 in den M uebertragen kann. Aber erwarten Sie das bitte nicht zu frueh, vielleicht ist es auch kann nicht moeglich sein.

Vladimir
 
Der Vladi von Waldorf wird das schon machen... Es scheint so als ob Er der einzige ist, der bei Waldorf am M arbeitet 🤔
Nein, und nicht einzige Person bei M. Obwohl ich war ein "Firestarter" dabei, und hatte viele Sachen darin gemacht.
Ich brauche euere Feedback um :
a) M zu verbessern
b) Benutzer Wuenche und Kritik wie eine Orientirung fuer naechste Projekt sammeln.

VG
Vladimir
 
Die zusaetzlichen VCF-Typen koennten im Prinzip in DSP Firmware fuer mindesten den Modern Mode implementiert werden. Ich versuche gerade nach den MW2-Code, um einen Weg zu finden, wie man bestimmte VCF-Typen aus MW2 in den M uebertragen kann. Aber erwarten Sie das bitte nicht zu frueh, vielleicht ist es auch kann nicht moeglich sein.

Vladimir
Ich freue mich über jedes weitere Feature das kommt, tolle Arbeit weiter so.
 
Nein, und nicht einzige Person bei M. Obwohl ich war ein "Firestarter" dabei, und hatte viele Sachen darin gemacht.
Ich brauche euere Feedback um :
a) M zu verbessern
b) Benutzer Wuenche und Kritik wie eine Orientirung fuer naechste Projekt sammeln.

VG
Vladimir

Ich habe das nur so halb mitgelesen, aber ist es wirklich so, dass der M die Stimmen im Multimode nicht dynamisch verteilt? Das wäre ja ziemlich schlecht, da man zum Beispiel nicht sagen wir mal zwei Pads, die jeweils die volle Stimmenzahl benötigen, abwechselnd mit entsprechendem Release und jeweils acht Stimmen spielen könnte, obwohl die Stimmen ja "da" sind.

Im Digitone funktioniert das zum Beispiel problemlos: Vier Sounds, acht Stimmen und eine recht flexibel einstellbare dynamische Stimmenzuteilung, die perfekt funktioniert.

Gut wäre es, wenn man die Stimmenanzahl pro Part festlegen kann (da man manchmal wirklich nur eine oder zwei Stimmen braucht), aber ansonsten die Sounds jeweils die maximal möglichen Stimmen erhalten, wenn man es *nicht* festlegt.
 
Ich habe das nur so halb mitgelesen, aber ist es wirklich so, dass der M die Stimmen im Multimode nicht dynamisch verteilt? Das wäre ja ziemlich schlecht, da man zum Beispiel nicht sagen wir mal zwei Pads, die jeweils die volle Stimmenzahl benötigen, abwechselnd mit entsprechendem Release und jeweils acht Stimmen spielen könnte, obwohl die Stimmen ja "da" sind.

Im Digitone funktioniert das zum Beispiel problemlos: Vier Sounds, acht Stimmen und eine recht flexibel einstellbare dynamische Stimmenzuteilung, die perfekt funktioniert.

Gut wäre es, wenn man die Stimmenanzahl pro Part festlegen kann (da man manchmal wirklich nur eine oder zwei Stimmen braucht), aber ansonsten die Sounds jeweils die maximal möglichen Stimmen erhalten, wenn man es *nicht* festlegt.
Der M verteilt die Stimmen zwischen den Parts entsprechend der voreingestellten Polyphony pro Part (Parameter V.TOTAL). Aufgrund der analogen Schaltung des AUX Ausgangs gibt es kein partuebergreifendes Voice Stealing. Der "Stimmenklau" findet sich nur innerhalb der Stimmen statt, die zu diesem Part gehoeren.

Das Beispiel mit Dual Layer Pad, jeweils 8 Stimmen Polyphonie - leider nur in der 16-stimmigen Konfiguration richtig implementiert werden kann.
 
Der M verteilt die Stimmen zwischen den Parts entsprechend der voreingestellten Polyphony pro Part (Parameter V.TOTAL). Aufgrund der analogen Schaltung des AUX Ausgangs gibt es kein partuebergreifendes Voice Stealing. Der "Stimmenklau" findet sich nur innerhalb der Stimmen statt, die zu diesem Part gehoeren.

Das Beispiel mit Dual Layer Pad, jeweils 8 Stimmen Polyphonie - leider nur in der 16-stimmigen Konfiguration richtig implementiert werden kann.

Hmmm, ich verstehe jetzt nicht ganz, was das mit der analogen Schaltung zu tun hat. Das "Problem" (das grundsätzlich keines ist, da es woanders ja auch gelöst wurde) liegt ja auf der digitalen Ebene der Verteilung.

Das hieße dann aber, wenn man die Aux-Ausgänge nicht verwenden würde, könnte man *doch* Stimmen dynamisch verteilen? Alles andere macht den Multimode zu großen Teilen relativ unbrauchbar.
 
(Bei dem Beispiel mit zwei Pads würde es mir nicht darum gehen, die gleichzeitig, sondern beispielsweise abwechselnd mit jeweils acht Stimmen spielen zu können.)
 


Zurück
Oben