4
45tsdfp983fou350j
Guest
Vermutlich wird deshalb bei dir zu Hause so wenig gekocht...freut sich jeder gute Koch über Kritik !
Aber jetzt ist mal gut hier. Zurück zum M.
Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: This feature may not be available in some browsers.
Vermutlich wird deshalb bei dir zu Hause so wenig gekocht...freut sich jeder gute Koch über Kritik !
Es passieren da ja aber auch noch andere Schreibvorgänge als nur das Aus- und Einschalten. Das hast Du vergessen.
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.Gibt es denn auf dem Bauteilmarkt keinen Flash der das ohne Bauchweh kann? Oder sind das alles nur Fläschchen oder Flaschen?
Wie lösen die anderen Herstelle das?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.
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 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 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?
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.Ja, man braucht die Information, aber man muss nicht bei jeder Parameteränderung was schreiben, sondern nur einmal beim Patch-Wechsel.
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.@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.
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.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.
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?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.
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.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?
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 freue mich über jedes weitere Feature das kommt, tolle Arbeit weiter so.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
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
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.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.