der MODULAR

[herw]

MODULE (2)

MD-01 MIDI [p]

MD-01.gif

Natürlich unbedingt das erste Modul.
Nach langen Überlegungen und Vergleichen habe ich eine neue (hoffentlich endgültige) Nummerierung vorgenommen. Das [p] gibt an, dass es sich um ein polyphones Midimodul handelt, was gleich einschließt, dass ich auch ein monophones Modul erstellen möchte.
Es besitzt genauso wie sein Vorgängermodul sieben Ausgänge.

• pitch: der MIDI-Wert der jeweils angeschlagenen Tasten
• pitchbend: Midi-Wert des Pitchbend-Rades (ich gehe von der Norm 0 aus (Wertebereich 0 .. 127). Leider empfängt REAKTOR nicht die hochauflösende Version. Der zugehörige Regler hat einen Wertebereich von 0 .. 12,0 und legt damit den gesamten Werteberich des Pitchbendrades fest. Ein Wert 1 entspricht einem Halbton. Die Einstellung 7,0 definiert also das Pitchbend-Rad für -7,0 .. +7,0. Voreingestellt ist der Wert 2. Das Pitchbend ist natürlich monophon.
• contr. : Es kann ein beliebiger Controller als Quelle gewählt werden, voreingestellt ist 7 (volume)
• gate : das gate signal gibt beim Anschlag den VelocityOn-Wert aus beim Loslassen 0
• vl on : velocity on gibt beim Anschlagen einer Taste den VelocityOn-Wert aus, also die Anschlagsstärke
• vl off : velocity off gibt beim Loslassen den VelocityOff-Wert aus, d.h. wie schnell die Taste losgelassen wird. Die meisten Keyboards geben diesen Wert nicht aus sondern nur den genormten Wert 0. Es gibt aber auch Masterkeyboards, die dies beherrschen.
• aftt : aftertouch. Verändert man den Druck auf eine angeschlagene Taste, dann wird dieser Wert polyphon gesendet. Eine sehr sinnvoll einzusetzende zusätzliche Information.

[helmsklamm]

Struktur und Funktionsweise des Normalreglers (10)

Ich erkläre es an einem Beispiel.
Der Trick ist, dass ich Zahlen (und auch Texte) in REAKTOR mit den Textmodulen erzeuge, also schwarze Schrift auf weißem Hintergrund, dann einen screenshot erstelle und diesen dann in den alpha-Kanal eines einfarbigen TGA-Files hineinkopiere. Klingt einfach? Ist es auch, wenn man ein wenig Geduld und sinnvolle Vorplanung vornimmt.

Ich erstelle mir ein Ensemble, das nur Makros mit z.B. 128 Textmodulen enthält. Jedes Textmodul hat eine gewünschte Breite (z.B. 40 Pixel) und eine Höhe von z.B. 8 Pixeln....
Ich ordne diese Textmodule nun untereinander so dicht wie möglich an, stelle den Hintergrund auf transparent, die Textanordnung auf zentriert.
....
Die Anordnung der Textmodule ist schnell gemacht, und hat man sich einmal ein Makro mit 128 Textmodulen erstellt, dann fällt dies in Zukunft weg. Jetzt geht es ans Ausfüllen. Man darf davor nicht zurückschrecken. ...

ich versteh den aufwand nicht. ging es dir darum die reaktor typo als bitmap zu clonen oder warum das sonst das alles?
aber auch dann bist du doch mit photoshop oder gimp oderodermacshop viel viel schneller.
abgesehen davon halt ich ja ne 0-9 reihe (vielleicht auch 2 davon, jeweils mit nen 2 pic versatz fürs 4x4 austricksen) und vorgeschalteten modulos für weitaus effizienter als son unnötig fettes tga.

sorry, das is natürlich dein projekt und dein stil - aber das klingt hier alles n bissl nach allgemeiner empfehlung und da beanspruche ich mein veto-recht;)

schlisslich wurde der fred hier fast 3000 mal gelesen - jut, davon dürfte n drittel auf deine eigenen aufrufe entfallen, aber immerhin.

[herw]

...ich versteh den aufwand nicht. ging es dir darum die reaktor typo als bitmap zu clonen oder warum das sonst das alles?
aber auch dann bist du doch mit photoshop oder gimp oderodermacshop viel viel schneller.
abgesehen davon halt ich ja ne 0-9 reihe (vielleicht auch 2 davon, jeweils mit nen 2 pic versatz fürs 4x4 austricksen) und vorgeschalteten modulos für weitaus effizienter als son unnötig fettes tga.

sorry, das is natürlich dein projekt und dein stil - aber das klingt hier alles n bissl nach allgemeiner empfehlung und da beanspruche ich mein veto-recht;)

schlisslich wurde der fred hier fast 3000 mal gelesen - jut, davon dürfte n drittel auf deine eigenen aufrufe entfallen, aber immerhin.

Um Gottes Willen, ich will in keinem Fall eine Empfehlung geben. Mein Ziel war es, einen kleinen Zeichensatz zu haben, der gut lesbar ist. Ich habe mit anderen Grafikprogrammen experimentiert, bisher war die Lesbarkeit in Reaktor nicht besonders (photoshop besitze ich nur für OS 9, was ich nicht mehr installieren will. Daher habe ich mich zu diesem Schritt entschlossen. Die beiden Verfahren (Komplettsatz aller Zahlenwerte oder Ziffernsätze) sind beides Kompromisse bis NI endlich von sich aus transparente numerische Zahlanzeigen in verschiedenen Farben anbietet.
In der aktuellen Version habe ich die Ziffernmethode angewendet. Man benötigt dann nur die Ziffern und eventuell die Ziffern mit Dezimalpunkt. Das ist ein sehr kleiner Aufwand. Allerdings ist die Ansteuerung aufwändig, da man eventuell wegfallende Führungsnullen und zentrierte Ausgabe berücksichtigen muss. Das kannst Du Dir im MM2 ansehen. Ich probiere jetzt die andere Methode, insbesondere, weil ich den sehr kleinen Zeichensatz benutzen möchte (was natürlich bei der Ziffernmethode auch geht). Entscheidend war, dass ich die ewigen Fallunterscheidungen leid war. Der Aufwand ist wie oben beschrieben nicht sehr groß.
Ich brauche wahrscheinlich 5 bis 6 TGA-Files, wobei die meisten einen Umfang von ca. 120kB haben. Nur eines ist größer, etwa 400kB. Also auch kein Ding.
Vielleicht fertige ich auch noch Anzeigen nach der anderen Methode an und verwende dann die zweckmäßigere.

ciao herw

PS: Danke für das Veto ; es gibt mir die Sicherheit, dass überhaupt jemand diesen Thread liest.

[helmsklamm]

ich kann dir auf jeden fall die typo "copperate" empgehlen . das ist ne sogenannte pixelschrift und selsbt kleinstformatig noch hübsch UND lesbar und zeimlich leker.

ich bin mir grad nich so sicher, ob ich auch tatsächlich die "rechte" auf die schrift habe, ups. jedenfalls is die hübscher un teilweise auch besser lesbar als die reaktot - sys - schrift, und privat darf ich die wohl verwenden.


aber die frage bleibt: was ist günstiger??

ein fettes tga-file in einem MP, oder mehrere kleinere "MPs", die via modulos die richtigen werste ausgeben``

[herw]

...aber die frage bleibt: was ist günstiger??
...

probiere ich hiermit aus

[herw]

...aber die frage bleibt: was ist günstiger??
...

die Zweifel, was wirklich günstiger ist, sind nicht so leicht wegzuwischen.
Ich muss von dem ausgehen, was ich will. Natürlich kann man die numerische Anzeige gestalten, wie es etwa in Massive geschieht: vier Stellen, die immer angezeigt werden mit einer Mausarea, die die grobe Einstellung und eine andere, die die feine Einstellung ermöglichen.
Dann hat man mit unschönen Führungsnullen zu leben. Das will ich aber nicht; ich möchte eine zentrierte Ausgabe, d.h. ich muss darauf achten, ob eventuell Führungsnullen wegfallen, ich muss darauf achten, wo das Komma sitzt etc.. Das erfordert mehr als nur einfache Stellen, sondern sogar Einrückungen. Das ist mir alles viel zu umständlich; ein Multipicture mit ganzen Ziffernbildern oder höchstens zwei Multipictures ist wesentlich einfacher zuverwalten.
Trotzdem werde ich immer wieder abwägen, ob die Stellenlösung nicht günstiger ist. Ein Kriterium sind sicherlich Wertebereiche, die in ihrer Auflösung wechseln: Feineinstellung für kleine Werte, grobe Einstellung für große Werte - nicht so leicht.

[herw]

MODULE (3)

Wie geht es nun sinnvoll weiter? Betrachtet man das Datum der letzten Post, so könnte man meinen, ich hätte die Lust verloren, oder der Frust hätte mich übermannt.
Nun ganz so schlimm ist es nicht. Natürlich war ich von der Funktionsweise der Regler begeistert. Aber ich wusste, dass die Offenbarung noch bevorsteht: Paneldesign ist eine Sache, aber die dahinter stehende Struktur muss auch funktionieren. Dabei sind nicht nur die eigentliche Signalverarbeitung zu überprüfen, sondern auch die virtuellen Kabel (sowohl Paneldarstellung als auch IC-Schaltung).
Die bisherigen Modularen funktionierten bis auf einen ganz kleinen Bug (im LFO) reibungslos. Also warum sich Sorgen machen? Nun zum einen habe ich die Darstellung der Kabel auf dem Bildschirm geändert, sie sind schmaler. Dann habe ich die Positionierungsmöglichkeiten erweitert. Ein-und Ausgänge lassen sich nun überall positionieren, unterliegen also nicht mehr einem groben Raster. Die Verschaltungen über die IC-Sends waren perfekt. Eigentlich sollten die nächsten beiden Module innerhalb eines Wochenendes vorliegen, doch ist daraus ein arbeitsreicher Monat geworden.
Ich veröffentliche die Ergebnisse erst jetzt, da ich ständig Schaltungen neu aufgestellt und wieder verworfen habe. Es hätte ein ständiges Hin und Her gegeben.
Rückblickend habe ich die Schwierigkeiten erahnt und mich auch ein wenig vor der Arbeit gedrückt. An den letzten beiden Tagen waren mindestens 10 Stunden der Wahrheit zu bewältigen und es ist geschafft.
Die virtuellen Kabel funktionieren auch mit der neuen Struktur .
Zurück zur Eingangsfrage: wie geht (ging) es weiter?
Die mittlerweile lange Erfahrung mit großen Projekten lehrt mich immer wieder, dass es keinen Zweck hat, eine große Struktur aufzubauen, ohne an wichtigen Zwischenstellen die grundsätzliche Funktionsweise zu testen.
Es hat keinen Zweck, zum Beispiel das schöne neue Panel komplett aufzubauen und noch gar nicht zu wissen, ob der Zusammenhang auch funktioniert. Treten dann Fehler auf, so ist überhaupt nichts mehr sinnvoll nachzuvollziehen.
Also musste nach dem Midimodul unbedingt ein Ausgabemodul her, zweckmäßigerweise das letzte Modul in der Kette, und natürlich eine Audioquelle. Da habe ich "einfach" mal den LFO ausgewählt, da dieser ja bis in den Audiobereich hinein arbeiten sollte und somit auch als Audioquelle dienen kann.
Ich stelle zunächst die beiden Module vor.

[herw]

MODULE (4)

IO-01 (IO = Input/Output für Audioquellen)

IO-01.gif

Der Aufbau ist schon fast selbst erklärend: Zwei Anzeigen für das Audiolevel der beiden Kanäle, der Volumenregler und die beiden Eingänge.
Alles klar.

Nichts klar! Denn damit sollte die Feuertaufe für die Verkabelung geschehen. Wie ich schon weiter oben beschrieben habe, wurde die Eventstruktur fast komplett in ein einziges Event-Core-Makro gesteckt. Ich hatte schon verschiedene Testwerte in die Struktur eingegeben und die Berechnungen und die IC-Sendwerte wurden richtig ausgegeben. Doch dann kam der Hammer: Das Bussystem hat die Struktur eines Datenkette deren Ende wieder am Beginn in einen anderen Eingang zurückgeführt wird. Einen Eventloop glaubte ich vermieden zu haben, da die Werte, die ich in der Kette ausgebe, nicht mit den wieder eingeführten Werten zusammenarbeiten. Trotzdem meckerte REAKTOR über einen Eventloop. Natürlich kann REAKTOR die Struktur nicht dermaßen durchschauen, dass er wirklich jeden Eventloop erkennt. Grundsätzlich ist es problematisch, wenn man Daten aus einem Core-Makro wieder demselben Makro zuführt. Ich gehe mal davon aus, dass REAKTOR dies einfach grundsätzlich erst einmal als loop deklariert; mittlerweile glaube ich aber, dass REAKTOR sogar die zeitliche Abfolge (Eventloop während desselben Samples) erkennen kann. Natürlich ging es zunächst schief. Ich habe es dann ungewöhnlich gelöst: einfach ein Single-Delay vor der Wiedereingliederung mit etwa 3ms bis 10ms Dauer. 1 ms ist zu kurz, wohl weil es sich um Eventsignale handelt.

event delay.gif

Ein anderer Bug hat mich viel Nerven gekostet; ich war schon fast so weit, die alte Struktur wieder einzubauen.
Hatte ich erfolgreich eine Verknüpfung über die IC-Sends geschaltet, so wurde diese beim Betätigen eines (beliebigen) Schalters wieder unterbrochen. Der Fehler war schwer zu finden. Ursache war der GSR (Globaler-System-Reset); alle Schalter (auch die Receive-Module) bewirken einen GSR. Dieser sendet einfach mal Nullen aus allen möglichen Ecken und schaltete mir so die IC-Sends auf 0 um. Damit war das virtuelle Kabel unterbrochen. Also musste ich diesen GSR unterbinden. Null Ahnung, wie man das anstellen sollte. Ich wusste von langen Diskussionen (vor allem CList im englischen Forum), dass es keine generelle Lösung gibt, sondern man von Fall zu Fall entsprechende Vorkehrungen treffen muss und kann. Letzlich ging es relativ einfach: Ich habe die Ausgänge bei der Übergabe um 1 erhöht, dann einen Separator dahinter geschaltet, der den Wert 0 des GSR ausfiltert und anschließend wieder 1 subtrahiert. Dabei ist unbedingt zu beachten, dass man für die Rechenoperation die Modulatioen benutzt, sonst senden die Konstanten doch wieder einen Wert aus:

anti GSR.gif

Ich habe hier als Beispiel mal das Innere für zwei IC-Sends-Switches abgebildet.

Damit waren die wichtigsten Hürden überwunden. Der Rest machte schon wieder Spaß: Anpassung der Koordinaten für die Aus- und Eingänge, Korrektur des Kabelpanels und das ist das Resultat:

virtuelle Kabel.gif

Ich habe den Zwischenraum zwischen den Modulen gelöscht; die Kabel haben natürlich eine durchgehende Verbindung.

Damit ist die wichtigste Hürde genommen, alle neuen Module können davon zehren.

[helmsklamm]

na, das wurde ja langsam zeit hier;)

nee, im ernst: was konkret is der GSR? die initialisierung nach bspw. nem switch? ich hab das auch schon oft "debugen" müssen - sachen die sonst anstandslos liefen, waren nach nem switch in nem kilometerweit entfernten macro plötzlich "genullt"?
redest du davon? is das der termini? und warum gibts dasüberhaupt? weil die gesamte engine während eines switch mal kurzeitig (ich spekuliere: mindestens ein sample) aussetzen und reinitialiseirt werden MUSS (es is nur unhörbar, weil gebufffert?)?
n switch is ja technisch was entschieden anspruchsvolleres als ne 0-multiplikation, ergo n bypass - beim switch stöpselst du ne ganze einheit regelrecht aus, anstelle sie nur zu muten. in dsp impliziert das, das du alle berechnungen zu dieser einheit tatsächlich deaktivierst, anstelle schnödem stumm-schalten, das ja weiterhin leistung fordert.
was ich sagen will: jeder GSR is doch nix andres als n ultrakurzes beedende/neustarten deiner engine - demzufolge müsstest du exakt die gleichen probleme doch bereits auch dort schon haben, oder? also alles n fall für die liebe;) event-init-order, oder?

was sagt meister clist?

[herw]

...was sagt meister clist?

dasselbe:

GSR

The EventValue module itself does not send a value on start-up, but any module that takes no input parameters does. This includes constants. It probably also includes whatever "useinterface element" you're talking about. After all, what's the difference between when the user moves a knobs and when it sends it's value on startup - OTHER THAN the fact that other knobs, switches, buttons, and constants may not have initialized yet? Nothing.

The solution may depend on what it is that should trigger the write (mouse movements from an XY might allow for a different solution from MIDI input), and what's the source for the data being written (just constants, constants and knob values, XY movements, MIDI data, etc).

Like I said, the only difference between an event coming from a knob at start up and "while it's running" is that at startup all of the other values in the instrument have not been initialized yet (or may not have been initialized yet - you don't know for sure). So you need to correct an ordering problem. Perhaps just putting a 10ms delay on the knob (or whatever) that's supposed to trigger the event-value "in" input is the answer, so everything has a chance to settle before the first event hits the structure - but there is no generic solution for this problem, you need to give us more specifics on what's upstream of the "val" input and upstream of the "in" input. So we can see why bogus data would be at "val" when the first event arrives at "in".

- CList

[herw]

...nee, im ernst: was konkret is der GSR? die initialisierung nach bspw. nem switch? ich hab das auch schon oft "debugen" müssen - sachen die sonst anstandslos liefen, waren nach nem switch in nem kilometerweit entfernten macro plötzlich "genullt"?
redest du davon? is das der termini? und warum gibts dasüberhaupt? weil die gesamte engine während eines switch mal kurzeitig (ich spekuliere: mindestens ein sample) aussetzen und reinitialiseirt werden MUSS (es is nur unhörbar, weil gebufffert?)? ...

man kann sich verschiedene Situationen vorstellen, in denen eine Intitialisierung notwendig und sinnvoll ist. Oft wird auf den Wert 0 wohl zurückgesetzt. Ohne einen Reset wäre einige Module ohne Vorabinformation; beispielsweise braucht ein Hüllkurvenmodul einen Anfangswert, damit es überhaupt ins Laufen kommt. Ein Hüllkurvenmodul reagiert auf den Nulldurchgang. D.h. ein Vorabwert 0 ist sinnvoll.
Im oben angegebenen Beispiel (Modular schaltet ungewollt die Wires ab), lässt sich das (im Nachhinein betrachtet) sehr leicht unterbinden, sogar wohl noch einfacher als dort angegeben:

antiGSR.gif

In der Teilstruktur, in der der GSR auftrat, waren nur nichtnegative Werte relevant (ich schalte mit diesen Werten über ein IC-Send eine Receive-Verbindung). Der Wert 0 führt dort zu einem Schalten auf OFF (enable switch off war in den Properties eingeschaltet, bzw. falls diese Option ausgeschaltet ist, führt dies zum Umschalten auf die unterste Switchposition). Andererseits möchte ich natürlich den Wert 0 von Hand selbst abrufen können, um die Verbindung zu kappen.
Darum muss man dem GSR einen Initialisierungswert anbieten, der nicht relevant ist, also zum Beispiel den Wert -1. Beim Einschalten und Umschalten wird nun dieser Wert abgerufen; durch einen anschließenden Separator wird auf einen toten (unteren) Zweig besplittet und somit gelangt dieser Intialisierungswert nicht aus dem Modul heraus.
Damit gehe ich auch auf einen anderen Beitrag von Dir ein über Logiksignale: schaut man sich den Separator mal genau an, dann besteht er nur aus einem Compare und einem Router.

Logiksignale.gif

Du fragtest in dem anderen Beitrag, warum in Core Logiksignale keinen Event senden. Genau dies ist hier erwünscht. Das Umschalten auf den toten Zweig liefert keinen Wert, sondern gibt dem ankommenden Event (in dem Fall die -1) den Weg in den unteren Zweig frei. Würde das Umschalten einen Event erzeugen, dann würde beim Zurückschalten dieser Wert ausgegeben.

ciao herw

[herw]

Nachtrag: GSR ist nicht gleich GSR

schaltet man einen Switch um, so kann ich zwar unerwünschte Ausgaben bremsen. Einen Strich durch die Rechnung machte mir aber das komplette Ein- und Ausschalten von REAKTOR. Da wurden mir alle (!) Receives auf 0 gesetzt. Das konnte ich durch zusätzlich dazwischen geschaltete Snap-Value-Module wieder ausmerzen.

Was für ein Aufstand! Ok ein Reset muss wohl prinzipiell sein, es ist nur sehr anstrengend, an alles zu denken!

[herw]

MODULE (5)

LR-02 (LR = LFO / Random Oszillatoren)

Wider Erwarten eine große und Zeit raubende Angelegenheit.
Zum einen wollte ich unbedingt einen Bug beseitigen: der reset-Eingang des alten LFO-Moduls funktionierte nur im Monobereich und nicht polyphon. Dies wurde berichtigt. Nun kann man die LFOs kontinuierlich synchron durchlaufen lassen oder jeweils für jede Voice neu triggern (Start bei der Nullphase).
Eine große Mühe habe ich verwendet, den LFO zu optimieren. Zunächst gab es die Wahl zwischen dem primary- und dem core-LFO. Ich bin schier verzweifelt, um herauszufinden, warum der primary-LFO so wenig CPU-Verbrauch hat.
Schließlich habe ich mal ein Oszilloscop hinter beide geklemmt und siehe da - der primary-LFO ist nur für gaaanz langsame Schwingung erträglich (maximal einige Herz).

LFO 6Hz.gif

LFO 20Hz.gif

LFO 67Hz.gif

Die Bilder sagen genug aus. Der Primary-LFO kann nur bei sehr niedrigen Frequenzen mithalten. Ich habe mich für den Core-LFO entschieden, letztlich ist es ein ganz normaler Oszillator allerdings ohne das AntiAlaising-Makro. Bei so niedrigen Frequenzen ist es unnötig und spart damit CPU-Verbrauch; trotzdem kostet die Entscheidung einige CPU Prozentteile.

Nun zum Aufbau: Das Panel enthält viele neue Tricks und hat entsprechend lange Zeit in Anspruch genommen. Alle Elemente lassen sich aber wieder leicht in anderen Modulen verwenden und einfach anpassen.

LR-02.gif

Das Modul enthält zwei identische LFOs. Daher die Bezeichnung LFO [d] (d=dual)
Der oberste Regler regelt die Frequenz. Mit der linken Maustaste wird in ganzen Schritten verändert, mit der rechten in 0.01-Schritten. Der Frequenzbereich ist 0Hz-127Hz.
Die Funktionsweise dieses Reglers habe ich schon vor einigen Wochen beschrieben. Ich gehe hier nicht nochmals darauf ein.
Darunter befindet sich der Regler für die Pulsweite der Rechteckschwingung. In einer neueren Version möchte ich damit auch die Symmetrie der Dreiecksschwingung verändern können.
Die Lampe ist eine Spezialanpassung an das Format der Ein- und Ausgänge. Sie arbeitet nur bis 5Hz, darüber wird sie ausgeschaltet, da die Displayanzeige sich ohnehin nur mit 25Hz erneuert.
Rechts danaben findet man die Anzeigen v-rst (im oberen LFO) bzw. cont (im unteren LFO). Es handelt sich hier nicht nur um ein einfaches Textelement, sondern um einen Umschalter. Klickt man auf den Text, so wird vom kontinuierlich schwingenden phasengleichen LFO (monophon) auf polyphone LFOs umgeschaltet. Die letzten werden jeweils durch die letzte benutzte Taste polyphon (also für jede Stimme extra) auf die Nullphase gesetzt. Da man das nicht immer benötigt, schalte ich dieses Feature nicht einfach aus, sondern benutze tatsächlich sowohl eine monophone, wie auch eine polyphone Version.
Unter der Lampe befindet sich der Ausgang. Mit dem Bildelement daneben (ihr ahnt es schon) kann ich durch Anklicken die jeweiligen Wellenformen wechseln: saw up, saw down, pulse, triangle, sinus, random.
Der Schalter ist zyklisch, d.h. ein Linksklick auf den Text lässt ihn vorwärts wechseln, hinter der Random-Auswahl beginnt er wieder von vorne. Mit Rechtsklick erfolgt das ganze rückwärts.
Alle Positionen werden abgespeichert.
Das Modul ist insgesamt nicht so komfortabel wie das des MM1; dieser konnte alle Wellenformen parallel und auch unipolar ausgeben. Für den Nachfolger des MM1 habe ich mir diese etwas abgespeckte Version ausgedacht. Mir war es aber wichtiger, zwei unabhängige LFOs zu haben. Natürlich werden die größeren Modularen beide Versionen enthalten.

[herw]

MODULE (4/5)

Testphasen sind nervig aber leider unbedingt notwendig. Meistens schiebt man sie bis ans Ende der Entwicklung.
FALSCH - denn fast hundertprozentig gibt es dann eine Bruchlandung, aus der man nur schwer wieder hinausfindet. Welche Fehler bewirken andere Fehler. Was ändere ich ab; warum reagiert dann ein Modul nun falsch, während es vorher funktionierte.
Ich muss mich auch jedesmal wieder überwinden, den richtigen Zeitpunkt eines Zwischentest zu erwischen.
Auch wenn die Verbindung zwischen den Modulen sowohl optisch wie auch strukturell funktionierten, kam es doch beim intensiven (internen) Beta-Test zu unschönen Überraschungen. Verwirrend war es, dass ja die Optik des Panels - in diesem Fall die Patchkabel nichts mit der internen Verknüpfung zu tun hat. Das heißt ich musste mühevoll jede Kabelverbindung auf dem Bildschirm und die interne Verknüpfung auf "Parallelität" (angezeigtes Patchkabel entspricht auch der internen Verknüpfung) überprüfen. Das musste nun einmal grundsätzlich überprüft werden. Bei mittlerweile dreizehn Ausgängen und drei Eingängen (der Envelope-Generator ist ebenfalls fertig) ist dies gut möglich. Ein späterer Test wäre zu unübersichtlich geworden. Die Optik war in Ordnung, aber die interne Verknüpfung mit IC-Send-Modulen war nochmals eine reifliche Überlegung wert. Insbesondere muss man bei den gesteurten Receive-Modulen dringendst vorher festlegen, wie man die OFF-Position behandelt (aktiviert oder nicht aktiviert). Danach richtet sich, wie viele Switchpositionen man einkalkulieren muss. Da ich ja die Anzahl automatisch ermitteln lasse, ist dies eine "gefährliche" Schnittstelle. Letztlich habe ich mich entschieden, die OFF-Position zu deaktivieren, dafür eine zusätzliche Quelle einzuführen (Konstante 0) und diese als die erste Schalterposition zu deklarieren. Damit ist ein für alle Mal (hoffentlich) die Umschaltung in der Struktur festgelegt. Seit dem klappt es auch eindeutig und sicher.
Ein zweiter langwieriger und langweiliger Test war der zu den Reglern. Alle Defaultwerte mussten nochmals sauber und sinnvoll gesetzt werden alle vom Panel zu setzende Defaultwerte mussten ebenfalls eingerichtet werden.
Manches stellt sich erst in der Praxis als untauglich heraus und muss im Nachhinein noch geändert werden.
Ich habe zum Beispiel die Position der Modulationsausgänge nochmals korrigiert; das Midi-Modul erhält einen zusätzlichen Ausgang der Gate-Quelle, der nicht von der Velocity abhängt.

MIDI-LFO.gif

Trotz dieser Testphase bin ich sehr zufrieden, dass ich die Zeit investiert habe; ich denke, ich muss mir nun darüber keine Gedanken mehr machen. Die weiteren Module sind in der Entwicklung wesentlich zügiger vorangeschritten (siehe folgende Post).

[herw]

MODULE (6)

EN-01 (EN = Envelope- (Hüllkurven-) Generator)

ein Brot- und Butter-Modul. Mehrere solche Module steuern in der Regel den Lautstärke-, Filter- und Tonhöhenverlauf. Der Wertebereich der einzelnen Phasen reicht von 0,1ms bis zu 10s. Bei solch kurzen Phasenzeiten können sogar die Audiosignale des LFOs noch verformt werden.
Einige Beispielwerte für die Phasenzeiten (logarithmische Skala)
-20 = 0,1ms; 0 = 1ms; 20 = 10ms; 40 = 100ms; 60 = 1s; 80 = 10s

EN-01 Modulbeschreibung.gif

Information zum ADSR-Hüllkurven-Generator