4
45tsdfp983fou350j
Guest
Vermutlich wird deshalb bei dir zu Hause so wenig gekocht...
Aber jetzt ist mal gut hier. Zurück zum M.
Nur OnTopic Waldorf M - Microwave Nachfolger
- Ersteller intercorni
- Erstellt am
Aber jetzt ist mal gut hier. Zurück zum M.
4
45tsdfp983fou350j
Guest
@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:
SerErris
|||||||
Ich war jetzt ein paar Tage mal nicht hier, will aber noch mal was zum Flash schreiben:
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.
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.
Synthet
|||
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?
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?
Synthet
|||
micromoog
Rhabarber Barbara
Verstehe ich jetzt auch nicht warum das heute so schwer sein soll. Das konnte 1983 schon ein DX7/DX9.
micromoog
Rhabarber Barbara
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?
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:
swissdoc
back on duty
Nein. Flash nutzt sich beim Schreiben ab, je nach Typ (NAND ist besser als NOR) unterschiedlich. Dazu kommt, dass man in Blöcken schreiben muss.
kybernaut_01
No Fate!
Wie lösen die anderen Herstelle das?
micromoog
Rhabarber Barbara
Naive Frage zum Flash: Wer nutzt die Lebensdauer bis zum Anschlag?
rolfdegen
|||||||||||
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.
Dadurch reduziert sich die Schreibrate zum Flash und verlängert die Lebenszeit.
Zuletzt bearbeitet:
Tom Noise
*****
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:
Synthet
|||
Ja, man braucht die Information, aber man muss nicht bei jeder Parameteränderung was schreiben, sondern nur einmal beim Patch-Wechsel.
Tom Noise
*****
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:
swissdoc
back on duty
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.
Technischer Fortschritt geht eben auch mal nach hinten los. Siehe auch TDM vs. VoIP.
V
VladiS
|||||
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.
V
VladiS
|||||
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.
Synthet
|||
Das klingt doch sehr gut!
Ich persönlich finde es sowieso besser, die Patches per Recall-Taste zu laden – das würde perfekt passen!
lowcust
|||||
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?
V
VladiS
|||||
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
V
VladiS
|||||
Nein, und nicht einzige Person bei M. Obwohl ich war ein "Firestarter" dabei, und hatte viele Sachen darin gemacht.Der Vladi von Waldorf wird das schon machen... Es scheint so als ob Er der einzige ist, der bei Waldorf am M arbeitet
Ich brauche euere Feedback um :
a) M zu verbessern
b) Benutzer Wuenche und Kritik wie eine Orientirung fuer naechste Projekt sammeln.
VG
Vladimir
lowcust
|||||
Ich freue mich über jedes weitere Feature das kommt, tolle Arbeit weiter so.
Synthet
|||
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.
V
VladiS
|||||
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.
Synthet
|||
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.
Similar threads
News
-
-
-
SequencerTalk 210 - letzte vor der Superbooth mit TGM Heiner Kruse "the green man"
- Gestartet von Moogulator
- Antworten: 1
-
-
-
-
Happy Knobbing 2024 Modular Synthesizer Meeting - Video / Pics
- Gestartet von Moogulator
- Antworten: 3