der MODULAR

[helmsklamm]

gib einfach mike dalliot in die suchleiste, dann isses dabei. ich würd dir empfehlen ALLE treffer (sind nur 5 oder 6) zu downen. interessantes zeux.

[herw]

gib einfach mike dalliot in die suchleiste, dann isses dabei. ich würd dir empfehlen ALLE treffer (sind nur 5 oder 6) zu downen. interessantes zeux.

habe ich gemacht (er heißt übrigens mike daliot, hat aber nichts gebracht, da es irgendwo dort drinnen versteckt ist.

[helmsklamm]

selstsam ich finds jetz auch niet mehr - vorige woche wars noch da

ich hängs mal hier hin - lösch das mal lieber nach dem dwn.

ok download gelöscht; danke

[herw]

selstsam ich finds jetz auch niet mehr - vorige woche wars noch da

ich hängs mal hier hin - lösch das mal lieber nach dem dwn.

ok download gelöscht; danke

ja ich habe hineingeschaut, speziell in das Modul LR (links-rechts-Maus); das Erkennen von decrement und increment geschieht ebenfalls mit Hilfe des PY-Ausganges, nur ist das ganze im primary-level ausgeführt. Die dahinter stehende Logik ist identisch mit meiner Core-Version. D.h. wir haben unabhängig voneinander dieselbe Idee gehabt.
Die Verarbeitung in primary level gestaltet sich aber wegen der nicht vorhandenen Gleichzeitigkeit von Events wesentlich komplizierter, da man den korrekten Ablauf mit Hilfe von order- und value-Modulen kontrollieren muss. Die Speicherung des aktuellen Wertes geschieht mit einem einfachen snap-Modul, das in einem loop wieder zurückgeführt wird; da dieser loop nur mit Hilfe eines Triggers wirklich stattfindet, ist er nicht wirklich vorhanden und wird auch nicht angezeigt.
Dieselbe Idee habe ich auch gehabt, habe dies aber noch erweitert, indem ich einen Default-Wert nicht nur abrufen kann (das hat Mike ebenfalls genauso eingebaut), sondern ich kann auch ohne Eingriff in die Struktur einen neuen Defaultwert definieren.
Interessant ist die Idee, den Regler auch Midi-Learn-fähig zu machen. Da trickst er ein wenig und definiert einen zusätzlichen Regler über dessen Textfeld (label) der ersatzweise dann seine Werte übergibt. Dies hat allerdings den kleinen Nachteil, dass dieser die mit Maus eingestellten Werte direkt überschreibt. Das hätte man geschickter lösen können, wenn man den eingespeisten Wert ebenfalls durch ein increment/decrement-Modul abgerufen hätte.
Mike bietet zwei Panellösungen an, eine mit rechts/links-Maus und die andere mit links-Maus aber mit einem geteiltem Bedienfeld (hatte ich ebenfalls mal angedacht aber eher unpraktisch gefunden (sowari und rick scott sind meine Modular-Betatester).

Die Lösungen sind insgesamt völlig sauber und präzise programmiert.

PS: ich habe in Deiner vorangegangenen Post den download gelöscht; ich denke aber, wenn Du ihn ursprünglich aus der user-library oder einer öffentlichen Post selbst kopiert hast, dann können wir dieses interessante Modul auch hier durchaus legal einbinden. Dann verstehen die anderen auch unsere Diskussion. Bitte gib mir Antwort.

Meine Beschreibung zum Regler sind in Arbeit, ich möchte sie eigentlich auch in der library allgemein zur Verfügung stellen. Ich suche allerdings dazu noch eine tga-Bilddatei, die ich mal von NI bekommen habe, die deren Normalregler zeigen. Dazu muss ich alle meine Backups durchsuchen. Ich habe allerdings wenig Hoffnung; naja dann gibt es noch die Lösung über ein IC-send.

[helmsklamm]

mit andern worten: ne möglichkeit das zu modul-verkürzen, siehst du also auch nicht?

gut, dann gibts bei mir fein/grob eben nur bei 2,3 handverlesenen reglern.

die midifizierung hat noch ne andre schwachstelle: sie ist so nicht remote-fähig. das kann man aber ganz schnell mit nem hintendran-send "back to midi-knob" lösen (jup, zum preis eines kleinen schleifchens;) welches aber völlig unproblematisch ist)

was den dwn betrifft: mir is das völlig wuscht, ich gabe aber zu bedenken, dass die user-lib nicht von ungefähr nur nach registrierung benutzt werden kann, ganz im gegensatz zu hier - von dato könnte NI uU anders als du darüber denken

[herw]

mit andern worten: ne möglichkeit das zu modul-verkürzen, siehst du also auch nicht?

gut, dann gibts bei mir fein/grob eben nur bei 2,3 handverlesenen reglern.

die midifizierung hat noch ne andre schwachstelle: sie ist so nicht remote-fähig. das kann man aber ganz schnell mit nem hintendran-send "back to midi-knob" lösen (jup, zum preis eines kleinen schleifchens;) welches aber völlig unproblematisch ist)

was den dwn betrifft: mir is das völlig wuscht, ich gabe aber zu bedenken, dass die user-lib nicht von ungefähr nur nach registrierung benutzt werden kann, ganz im gegensatz zu hier - von dato könnte NI uU anders als du darüber denken

zu "verkürzen":
die core Lösung ist etwas übersichtlicher und lässt sich einfacher strukturieren, aber im Prinzip lässt es sich nicht viel einfacher machen. Nun gut, einmal erstellt, kann man es gut benutzen.
zum download:
ja du hast recht, die user library ist ja nicht prinzipiell öffentlich, obwohl ich nicht glaube, dass NI etwas dagegen hätte aber Mike natürlich. Ok, dann war es nur ein disput zwischen uns beiden. Meinen Vorschlag werde ich aber noch erörtern.

[herw]

Struktur und Funktionsweise des Normalreglers (1)

Normalregler 1.gif

Ich ergänze hier noch einmal die Grobstruktur, damit ihr nicht zurückblättern müsst.
Im gelben Rahmen habe ich das Macro Normalregler ergänzt, damit man sieht, dass er sich nach außen in der Struktur wie ein NI-Regler darstellt (Ausgabewerte als einzige Information). Da es sich letztendlich um ein MausArea-Modul handelt, lässt er sich nicht über MidiLearn direkt midifizieren. Wenn man mit dem kleinen Kompromiss, wie ich ihn in der vorangegangenen Diskussion zu Mike Daliots Regler erwähnte, abfindet, ist dies aber auch möglich. Ich halte diese Lösung aber im Moment nicht für völlig sauber, insofern habe ich sie weggelassen und warte auf eine entsprechende Midifizierung des MausAreas in R6.

Ich werde entgegen meiner obigen Ankündigung den Regler nicht in der user-library veröffentlichen, da ich einen ziemlichen Aufwand betreiben müsste, um seine Funktionsweise und seine Umstellmöglichkeiten (auf Englisch) zu erklären. Viele würden dann noch (auf Englisch) Nachfragen stellen und ich wäre nur damit beschäftigt, Spezialwünsche zu erfüllen. Ich werde hier also die gesamte Strukur bis in jedes Detail erklären und veröffentlichen, so dass ihr ihn nachbauen könnt und für Eure eigenen Zwecke verändern könnt. Ich möchte nur darum bitten, bei Veröffentlichung mich als Ideengeber zu erwähnen. Falls Ihr Anpass-Schwierigkeiten habt, stehe ich natürlich hier zur Verfügung. Öffentlich und leicht verfügbar wird das ganze natürlich, wenn ich den Modular hochlade.

In der Abbildung gibt es einen zweiten Bereich (grüner Rahmen), der nur indirekt zu dem Regler gehört. Dieser Teil steht im Modul init zentral allen Reglern zur Verfügung und stellt über eine interne Verbindung die so genannte Display-Clock zur Verfügung. Sie gibt etwa 25 mal in der Sekunde ein Clock-Signal aus, ist also wesentlich langsamer als die beiden anderen Clockraten Controlrate (meistens 400Hz) und die Samplerate (z.B.44100Hz). Die Display-Controlrate ist die Rate, mit der Panelanzeigen aktualisiert werden. Daher kann man leider zum Beispiel MausAreas nicht beliebig schnell regieren lassen. Hier habe ich aber auf einfache Art und Weise eine zusätzliche Clock-Quelle. Natürlich hätte ich auch selbst einfach einen Clock-Generator einbauen können und jedem Regler mitgeben können. Aber bei einigen -zig oder gar einigen hundert Reglern dürfte dann doch viel zusätzliche CPU-Last auftreten. Und die möchte ich natürlich so klein wie möglich halten, also eine zentrale Clock-Quelle. Wozu ich dieses Clock benutze, erkläre ich später.
Im unteren Teil sieht man das eigentliche grobe Innere des Normalreglers, das ich schon in einer zurückliegenden Post dargestellt habe. Dazu mehr in der nächsten Post.

[herw]

Struktur und Funktionsweise des Normalreglers (2)

Zunächst ein Überblick über die Struktur, ehe wir ins Detail gehen:
Links sehen wir die beiden MausAreas, die als Bedienelemente fungieren.
Die obere MausArea liegt im Panel über dem Multidisplay, das den Regler zeigt, die untere dagegen über dem Multidisplay der numerischen Anzeige:

mouseareas.gif

Die obere MausArea benutzt den PY-Ausgang, um Mausbewegungen nach oben und unten zu übertragen. Der Linksklick triggert diese Ausgaben und auch die Umschaltung der numerischen Anzeige. Der Doppelklick lässt den Regler und die numerische Anzeige auf einen Defaultwert zurückspringen.
Die untere MausArea definiert den aktuell angezeigten Wert als neuen Defaultwert (abspeicherbar für Snaps und auch für jeden Snap unterschiedlich!). Außerdem schaltet man mit dem Linksklick die numerische Anzeige um auf a) Daueranzeige (nur Anzeige der Zahlenwerte) oder b) zeitweise Werteanzeige während des Linksklicks auf der oberen MausArea (also während einer Werteänderung) und automatischen Rücksprung auf das Label des Reglers.
Warum so kompliziert? Nun ich möchte mein Vintage-Ensemble möglichst auch Vintage aussehen lassen. Ein Moog oder Buchla oder Döpfer haben keine numerischen Anzeigen, sondern nur die Reglerskalen. Also lasse ich sie verschwinden (trotzdem bleibt natürlich während der Einstellung die numerische Anzeige sichtbar). Nach der kleinen Anzeigedauer erscheint nur das Label des Reglers und der Benutzer kann aufgrund der Reglerstellung den Wert einschätzen. Ich spare damit auch zusätzlich Platz in den Modulen (vergleiche dagegen den Platzverbrauch im MM2).

Normalregler 2.gif

rechts finden wir zwei einfache Module (snaps und display).

Das DISPLAY-Makro

Normalregler 3.gif

Das Display-Makro enthält drei Multipictures, nämlich für die Abbildung des Reglers (KNOB), für die numerische Anzeige (INT) und für das zeitweise sichtbare Label (LABEL), das über der numerischen Anzeige liegt. D.h. die letzten beiden Multipictures überdecken sich gegenseitig. Sie werden so angesteuert, dass beim Anzeigen der numerischen Anzeige das Label vollständig transparent ist, beim Anzeigen des Labels dagegen die numerische Anzeige völlig transparent ist. Das könnte man auch in ein Multipicture zusammenfassen, würde aber wieder zusätzliche Logik erfordern. Dazu hatte ich keine Lust, also habe ich diesen Weg gewählt. Wer dies in einem einfacheren Regler nachstellen will, kann stattdessen ja auch eine normale numerische Anzeige verwenden, die ständig sichtbar ist. Dann fällt auch Vieles in der später erklärten Logik weg.

Das SNAP-Makro

Normalregler 4.gif

Das Snap-Makro ist genauso simpel. Es fasst alle zu speichernden Werte zusammen. Zusätzlich zu den Anzeigewerten ist dort noch der Ausgabewert VAL zu entdecken. Man muss bedenken, dass ich mit diesem Makro ja einen kompletten NI-Regler ersetze (und noch etwas ergänze). D.h. ich muss solche selbstverständlichen Eigenschaften wie das Speichern der letzten Reglerposition und des Ausgabewertes in einem Snap simulieren, daher die vielen Snap-Module. Nun, REAKTOR hat der Anzahl der Snap-Module wohl keine Beschränkung oder eine genügend große Maximalzahl mitgegeben, so dass es (hoffentlich) keine Probleme gibt.
Die Bezeichnungen PY und BL sind vielleicht etwas verwirrend oder auch ungeschickt von mir gewählt. PY bezeichnet die Position, den der Regler einnehmen soll. Diese entspricht der absoluten Mausposition im oberen MausArea. Beide Werte stimmen aber nicht überein, da ich die Werteverwaltung selbst in einem eigenständigen Makro organisiere.
BL (Mausbutton links) ist die Position der numerischen Anzeige, die sich aufgrund des Ausgabewertes Val ergeben soll. Die Bezeichnung Button-Links ist durch Abspeckung des Grob/Fein-Reglers entstanden, der ja auch eine Werteänderung mit Rechtsklick ermöglicht. Dort gibt es einen entsprechenden Signalweg BR.

[herw]

Struktur und Funktionsweise des Normalreglers (3)

Nun der eigentlich spannende Teil, auf den insbesondere helmsklamm wartet . Du sollst nicht enttäuscht werden.

Normalregler 5.gif

Zunächst die Betrachtung von außen:

MEMORY

Wie die Bezeichnung schon erkennen lässt, handelt es sich um ein Speichermodul. Es bekommt über den Eingang MEM den letzten Ausgabewert geliefert und speichert diesen mit jedem Snap ab, so dass er beim Snapaufruf alle notwendigen Informationen an die darüber liegende eventcore-Zelle übergibt. Die beiden anderen Eingänge rDefault und wDefault (die vollständigen Namen sind hier nicht zu sehen), empfangen die beiden Doppelklicks der MausAreas, die das Lesen und Schreiben eines neuen Default-Wertes emöglichen. Dieses Feature besitzt kein NI-Regler, denn dieses Setzen neuer Defaultwerte erfolgt auf dem Panel!

Das Innere des Speichers:

normalregler.gif

Es besteht aus zwei Snap-Modulen und einem temporären Speicher.
Schaut man nochmal auf die Außenstruktur, dann fällt auf, dass eigentlich ein eventloop auftreten müsste, denn der aktuelle Ausgabewert MEM der darüberliegenden CoreCell wird über die Signaleverbindung SET wieder zugeführt. Auch der Blick in die oben stehende Struktur lässt dies vermuten denn der Eingangswert MEM wird über das obere SnapModul direkt wieder an SETübergeben. ABER das Snapmodul hat eine wichtige eigenschaft deaktiviert: events thru was bedeutet, dass niemals Eingangswerte des Snapmoduls direkt weitergegeben werden, sondern nur dann, wenn der Snap aufgerufen wird. Das Snap-Value-Modul registriert also alle ankommenden Werte und speichert sie auch eventuell ab, gibt sie aber nur bei einem explizitem Snapaufruf ab.
Beim zweiten Snap-Value-Modul ist diese Eigenschaft nicht deaktiviert, da der eventloop durch die Schreib- und Lesetrigger wDefault und rDefault und - was noch wichtiger ist - durch den temporären Corespeicher unterbrochen ist. Nur derjenige Wert, der gerade beim Doppelklick des oberen MauAreas aktuell ist, wird an das folgende Snap-Value-Modul weitergegeben, der dann als neuer Defaultwert gespeichert wird. Beim Aufruf eines Snaps wird dagegen nur der Wert des rechten Snap-Value-Moduls übernommen, während das Snap-Value-Modul des Defaultwertes auf den entsprechenden Doppelklick der unteren MausArea wartet.

Entscheidend für die Entstehung eines eventloops ist, dass es nicht zu einem Automatismus kommt, bei dem ständig neue Eingangswerte und neue Ausgangswerte sich gegenseitig zu weiteren Rechenaktionen in einem endlosen Rechenprozess aufbauschen.
Der temporäre Speicher ist viel zu aufwändig, ein einfaches Latch-Modul oder auch ein Trigger-Value-Modul hätte es auch getan. Ich werde dieses Makro auch noch entsprechend vereinfachen. Der Array-Memory ist völlig übertrieben; aber ich wollte es einfach mal ausprobieren.

Zusammenfassung:
Das Memory-Makro registriert über den Eingang MEM alle aktuellen Werte und kann sie mit Hilfe des rechten Snap-Moduls auch abspeichern. Durch die Unterbrechung der event-thru-Option kommt es dabei zu keinem Eventloop. Das linke Snapmodul registriert ebenfalls alle ankommenden Werte, speichert aber nur solche ab, die über den wDefault-Trigger übergeben wurden und gibt auch nur über den rDefault-Trigger diesen Wert aus.
Mit Hilfe der zwei Snap-Value-Module ist es tatsächlich möglich, mit einem Snap sowohl einen aktuellen Wert als auch eine Defaulteinstellung abzuspeichern. Ich könnte mir vorstellen, dass man vielleicht sogar Range-Einstellungen auf diese Weise vom Panel aus erreichbar machen könnte (nur so eine Idee). Das ufert dann aber ziemlich aus und ich denke, das sollte man den Entwicklern von REAKTOR 6 überlassen.

[helmsklamm]

nö, ich hab mehr auf das PY gewartet, aber indirekt haben wir das ja schon geklärt;)

trotzdem interessant und wieder lehrreich (snap - event thru kannte ich bspw. noch garnicht).

das die snap-module "unbegrenzt" einsetzbar sind, mag ja theoretisch stimmen, in der praxis handeslst du dir aber ne menge zusätzlich nötigen speichers ein. ich bin mal gespannt, wie dein ens "wächst" wenn du erstmal n paar snaps erstellt hast. ne, für mich riecht das alles n bissl nach golf-tuning: sicher kann man den auf porsche-geschwindigkeit bringen, aber zu welchem preis? aber das ist auch geschmäcklerisch, wenn du das absaven variabler defaults für nötig erachtest, gehts halt nich anders. interessant isses jedenfalls allemal.

sorry, das wird jetzt echt in bissl durcheinander, aber ich muss nochmal ganz zum anfang des freds springen: zum bussystem, bzw. der "matrix".
ich stehe grad vor nem ähnlichen prob des "vermatrixen" und habe definitiv zu viele qeullen/ziele so das ne herkömmliche matrix zu unübersichtlich bzw. platzfressend ist.
ich finde deine kabellösend sehr inspirierend, leider ist mir die technick dahinter absolut nicht klargeworden: du musst doch für jede qeulle dutzende an MDs haben, die sich ja eigentlich überdecken. wie händelst du das? und wie funzt das initsystem, wie zählt das teil die module??

[herw]

nö, ich hab mehr auf das PY gewartet, aber indirekt haben wir das ja schon geklärt;)

trotzdem interessant und wieder lehrreich (snap - event thru kannte ich bspw. noch garnicht).

das die snap-module "unbegrenzt" einsetzbar sind, mag ja theoretisch stimmen, in der praxis handeslst du dir aber ne menge zusätzlich nötigen speichers ein. ich bin mal gespannt, wie dein ens "wächst" wenn du erstmal n paar snaps erstellt hast.

naja da mache ich mir keine Sorgen angesichts der fast 500 snaps in MM2 und einem funktionierenden Testensemble von vierfacher Größe

ne, für mich riecht das alles n bissl nach golf-tuning: sicher kann man den auf porsche-geschwindigkeit bringen, aber zu welchem preis? aber das ist auch geschmäcklerisch, wenn du das absaven variabler defaults für nötig erachtest, gehts halt nich anders. interessant isses jedenfalls allemal.

Das wird von einigen schwer "gewichtigen" Reaktor-Konstrukteuren gefordert. Das Definieren von Defaultwerten ist doch nützlich, wenn man schnell mal einen Standardpatch aufbauen möchte, oder möchtest jeweils einzeln in die Struktur eingreifen und in den Properties Änderungen vornehmen?.

sorry, das wird jetzt echt in bissl durcheinander, aber ich muss nochmal ganz zum anfang des freds springen: zum bussystem, bzw. der "matrix".
ich stehe grad vor nem ähnlichen prob des "vermatrixen" und habe definitiv zu viele qeullen/ziele so das ne herkömmliche matrix zu unübersichtlich bzw. platzfressend ist.
ich finde deine kabellösend sehr inspirierend, leider ist mir die technick dahinter absolut nicht klargeworden: du musst doch für jede qeulle dutzende an MDs haben, die sich ja eigentlich überdecken. wie händelst du das? und wie funzt das initsystem, wie zählt das teil die module??

ja trenne solche Fragen am besten! Ehe ich antworten kann: was bedeutet die Abkürzung MD (Multidisplay? das verstehe ich in diesem Zusammenhang nicht). Falls Du Multidisplay meinst; ich benutze nur ein Multidiplay, das das gesamte Panel im Hintergrund überdeckt.

Das Durchzählen der Ausgänge habe ich doch ausführlich beschrieben (Seite 2 post 24.11.06 18:33, Seite 3 post vom 21.1.07 17:59). Es werden nicht die Module gezählt, sondern die Zahl der Signalquellen (Ausgänge).


ciao herw

PS: ruhig nachfragen!

[helmsklamm]

ich muss mir wohl seite2 nochmal in aller aller ruhe durchackern. am besten wenn dein teil dann fertig ist und ich alles auch tatsächlich vor mir hab. so isses doch n bissl abstarkt.

zu snpas:

bei mir entpüppen sich die snap- und sva teile schon als gravierende speicherfreser bei jedem zusätzlichen snap. sofern ich das weiß, haben die ne dynamische verwaltung, was ja auch sinnvoll ist, andrerseits natürlich das ens auch bei veielen snaps deutlich vergrößern. wieviele snap/sva hast du denn so übern daumen?

[herw]

ich muss mir wohl seite2 nochmal in aller aller ruhe durchackern. am besten wenn dein teil dann fertig ist und ich alles auch tatsächlich vor mir hab. so isses doch n bissl abstarkt.

das kannst Du auch im MM2 nachsehen; die Ein- und Ausgänge befinden sich in einem Modul jeweils oben. Der Aufbau ist fast identisch nur eben primary.

zu snpas:

cpu.gif

bei mir entpüppen sich die snap- und sva teile schon als gravierende speicherfreser bei jedem zusätzlichen snap. sofern ich das weiß, haben die ne dynamische verwaltung, was ja auch sinnvoll ist, andrerseits natürlich das ens auch bei veielen snaps deutlich vergrößern. wieviele snap/sva hast du denn so übern daumen?

Jeder Regler und jeder zirkulare Schalter hat zwei snap-Module, beim MM2 sind das dann 100·2=200, dazu kommt ein SVA (für die Kabel).
Die Version MM2 v1 umfasste etwa 20MB mit nur 73snaps, die Version MM2 v3.2 etwa 22MB mit 479 snaps. Wo ist das Problem?
Eine Testversion des großen MODULAR-ZWEI erreicht bei vierfacher Größe etwa 43MB. Das sind aber doch keine problematischen Größen angesichts von 4GB RAM (bei windows-Rechnern mit standard 2GB).

[helmsklamm]

naja, 43 mb für nen teil ohne samples finde ich schon zeimlich deutlich. aber eigentlich hast du recht, bei heutigen ram is das völlig irrelevant und luxus kostet nunmal ne bissl was - ich bin da wohl ne nummer zu "schwäbisch" - ich freu mich eben, wenn der ladevorgang 1,5 sekunden schneller vonstatten geht, andrerseits is das völlig idiotisch, weil (zumindest bei mir) die samples das teil richtig fett machen und die zeit, die man dann am gerät spart das tausendfach wieder reinholt.
und auch das bissl rechenzeit, das das mehr kostet steht angesichts heutiger rechner in keinem verhältniss zum gewinn an ergonomie. ich sollt mal nen gezielten schlag gegen meine bausparkassen-denke durchführen.

[herw]

Heute habe ich die Module, die der MM1 enthalten soll, festgelegt:

• MIDI wie in der alten Version
• LFO (dual) zwei MultiwaveGenartoren einer davon mit veränderbarer PW
• SCO zwei Multiwave-Oszillatoren wie in MM1 aber zusätzlich synchronisierbar
• Ringmodulator (dual) wie in MM1
• NOISE (dual) wie in MM1 aber nun zwei Rauschgeneratoren
• ADSR zwei Hüllkurvengeneratoren
• SCF nun zwei umschaltbare Multifilter
• MIXER 3-facher Panoramamixer
• SCA (stereo) zweifacher Verstärker
• DELAY Stereo-Delay wie in MM1
• OUT Master-Ausgang
• virtuelles Keyboard mit sechs Oktaven (im sreenshot sieht man erst fünf)

vorkucker2.gif

Wie man unschwer erkennen kann, ist der neue Modular noch eine Baustelle; es handelt sich aber nicht um ein Potjomkinsches Dorf; hinter allen Modulen steckt auch schon eine Struktur; ich bin jetzt schon eindeutig im schönen Teil meiner Arbeit; ich höre es schon fast klingen.

Durch etwas schmalere Module kann ich einen zweiten Filter und einen Mixer zusätzich einbauen.

ciao herw