der MODULAR

[herw]

Struktur und Funktionsweise des Normalreglers (4)

MausArea.gif

zentral in der Mitte erkennen wir den Wertespeicher, wobei es sich nur um eine eigenständige Verwaltung der "Position" des Mauszeigers in der MausArea handelt. D.h. ich lasse die Mausposition (in diesem Fall nur in y-Richtung) nicht von dem Modul selbst verwalten, sondern nehme dies selbst vor, Warum? nun es liegt nur an den zusätzlichen Eigenschaften, die ich dem Regler zuweisen möchte: programmierbare Vorgabe-Werte, direktes Zurücksetzen auf den Vorgabe-Wert, verbunden mit einer Einteilung in Grob- und Feinregulirung und Vielfach-Messbereichen, kommt man nicht drumherum.
Das Modul MausArea ist sehr vielseitig einsetzbar, da es alle Mausereignisse berücksichtigt und auch sogar Cursortasten.
Ich stelle sie hier in einer Liste vor (ich habe die MausArea in y-Richtung mit einer Step-Weite 1 und 100 Schritten, Mausauflösung 101 und mit 100 Pixeln in y-Richtung gewählt):

• Maus-klick LINKS BL
  Der Mausklick LINKS ergibt schon allein fünf Ereignisse:
  MA_LINKS1.gif
  1. Port 2: 54
     Ausgabe der absoluten Positon auf der Area
  2. Port 1: Wertausgabe, die sich aus dem eingestellten Range der MausArea und dem angeklickten Bereich errechnet. Wie in einem anderen Thread schon erwähnt und diskutiert, ist dies nicht unproblemtisch, da je nach Auflösung die relative Mausposition etwas kompliziert ausgewertet wird. Ich habe hier den Range 0..1 gewählt, so dass der Wert wie ein prozentualer Wert erscheint.
  3. Port 3: 1
     erst jetzt wird der Maus-Klick LINKS ausgegeben
  4. Port 2:
     Ausgabe der absoluten Mausposition und
  5. Port 3: 0
     Abschluss beim Loslassen der Maus
  Die letzten beiden Ausgabewerte hängen logisch zusammen, wie man beim Ziehen der Maus erkennen kann:
  
  Der Links-Klick ist ein Gate-Befehl; vor jeder Gate-Zustands-Änderung wird die absolute Mausposition ausgegeben.
  
  Zieht man nun die Maus, so werden dazwischen relative (Y, hier Port 1) und absolute Koordinaten (PY, hier Port 2) ausgegeben. Das Ziehen mit der Maus ist nicht ganz unproblematisch, da die Mausposition nur mit DisplayClockRate abgefragt wird (also 25Hz), so dass beim schnellen Ziehen einige Werte überschritten werden:
  MA_LINKS2.gif
  Das kann problematisch sein, da man ja nicht weiß, wie ein User seine ComputerMaus behandelt. Daher übernehme ich die Verwaltung der Werte immer selbst (sei es nun anhand der Werte Y oder PY). Was nämlich erhalten bleibt ist die Tatsache, dass die Maus nach oben oder unten gezogen wird, unabhängig davon, wie schnell diese Bewegung ist. Dies nutze ich aus, um selbst eine dekerement/inkrement-Funktion zu erstellen. Zu bemerken bleibt noch, dass nach dem Ziehen zuätzlich noch die letzte absolute Mausposition ausgegeben wird, so dass es zu einem zusätzlichen Event kommt; eine nicht unwesentliche Tatsache. Dies muss man unter Umständen durch einen Stepfilter unterbinden.

[herw]

MA_RECHTS1.gif

Struktur und Funktionsweise des Normalreglers (5)

• Maus-Klick RECHTS BR
  
  Das Verhalten beim Rechtsklick ist genauso, wie beim Linksklick, der Gate-Befehl taucht nun beim Ausgang BR (hier Port 4) auf..
  Das MausArea-Modul ist deshalb praktisch, da es im Panel vorrangig vor allen anderen Panelelementen auch bei Überlappung von Panelelementen desselben Makros immer aktivierbar ist. Es hat allerdings in der Version REAKTOR 5.1.2 den Nachteil, dass es nicht midifizierbar ist und wie alle anderen Panelelemente auch zum Teil nicht zuverlässig arbeitet:
  MA_unzuverlaessigkeit.gif
  man sieht sehr schön, wie hier nicht immer die Werte Y und PY abwechselnd übergeben werden, sondern es auch zur Doppelausgabe (Eventnummern 54 und 55) kommen kann. Das ist sicherlich in 99% aller Anwendungen nicht problematisch, aber doch unbefriedigend.
• DOPPEL-KLICK Db
  Der Doppelklick ist immer ein Linksklick mit einem zusätzlichen Triggerbefehl am Ausgang Db.
  MA_DOPPELKLICK1.gif
  Bei einem Doppelklick mit der rechten Maustaste handelt es sich einfach um einen zweifachen Rechtsklick.
  MA_DOPPELKLICK2.gif

[herw]

Struktur und Funktionsweise des Normalreglers (6)

FALLEN:

auch die gibt es leider; kleine Ungereimtheiten und Besonderheiten, die kaum jemanden auffallen, aber dann doch irgendwann einmal auftauchen und zu unerklärlichen Reaktionen führen. Ich gebe nur diejenigen an, die für dieses Projekt relevant waren und sind.
Wer genau beim Rechts-Doppelklick in die Eventwatcher-Anzeige geschaut hat, der wird bemerkt haben, dass zwar der Rechtsklick zweimal aktiviert wurde, dabei der PY-Wert auch ausgegeben wird, aber nicht noch einmal der Y-Wert. Ich führe mal mehrfach einen Links- und Rechtsklick durch:
zunächst klicke ich links zweimal auf dieselbe Stelle, dann auf eine andere

MA_mehrfach1.gif

dasselbe für rechts

MA_mehrfach2.gif

Bei beiden Abbildungen erkennt man im Event-Watcher, dass nur der PY-Ausgang denselben Wert noch einmal aussendet. Wollte man also nur den Y-Ausgang als Trigger benutzen, dann wird man verwundert feststellen, dass kein solcher Event ausgesendet wird. Das hat auch nichts damit zu tun, ob dazwischen ganz andere Panelelemente bedient wurden. Der Y-Ausgang besitzt also einen stepfilter. Normalerweise fällt das nicht auf, da bei hohen Auflösungen die Wahrscheinlichkeit, denselben Wert nochmals zu treffen, klein ist, aber man kann sich ja zum Beispiel auch ein MausArea vorstellen, das z.B. 100 Pixel Höhe umfasst und nur eine grobe Einteilung in z.B. 4 Bereiche hat. Hat man daraus etwa einen Mehrfach-Trigger-Button gebastelt, dann würde man allein durch den Y-Ausgang nur veränderte Werte übertragen - kein Beinbruch, aber man muss es wissen.
Eine kleine Besonderheit ist auf den beiden Abbildungen noch zu erkennen: Ich habe das MausArea so eingestellt, dass im aktivierten Modus die Mausfläche hellblau ist, bei Nichtaktivierung dagegen bleibt es dunkel blau (nicht aktiviert).
Beim Mausklick-LINKS wird das MausArea aktiviert, beim Rechtsklick dagegen nicht.
Dadurch ergibt sich ein kleines Feature. Im aktivierten Zusatnd (also nach Linksklick oder Doppelklick) kann man die relative Mausposition mit den Cursortasten verändern:

MA_Cursor.gif

Ich habe zuerst einen Linksklick durchgeführt, die MausArea bleibt aktiviert und dann mehrfach die Cursortasten down bzw. up gedrückt. Nur der Y-Ausgang sendet nun seine Daten aus.

Nun das mag als Vorinformation zum MausArea-Modul genügen.

[herw]

Kommentar von meiner Seite dazu:

Ich stelle mir gerade die vielen Klagen in den verschiedenene REAKTOR-Foren vor, die das Handbuch für oberflächlich und unvollständig halten.
Wenn ich zurückblicke auf die letzten drei posts zur MausArea, in denen ich nur zu diesem einen Modul schon so viel geschrieben habe, wobei noch längst nicht alles gesagt ist, dann würde ein wirklich ausführliches Handbuch wohl zehnmal so dick sein wie das derzeitige.
Man erkennt sehr deutlich an manchen Ungereimtheiten und fehlenden oder "komischen" Features, dass REAKTOR in die Jahre gekommen ist und durch mehrfaches Nachbessern nicht in allen Teilen konsequent ist.
Hier muss aufgeräumt werden und zwar in Blick auf Eindeutigkeit und "Fehlerfreiheit", wobei ich manche unverständliche Verhalten nicht unbedingt als Fehlverhalten oder gar Bug ansehen würde, da man ja nicht weiß, wie intern manche Zustände erkannt werden. Da müsste man mit dem verantwortlichen Programmierer mal sprechen, ein solches Gespräch wäre sicherlich interessant.

Ist jemand unter Euch, der einen direkten Draht zu den Programmieren von REAKTOR hat?

Ich ärgere mich über die Ungereimtheiten eigentlich nicht wirklich, weil ich sie selbst entdeckt - oder durch Forendiskussionen angeregt - untersucht habe, was so ein wenig Entdecker- und Forscher-Stolz hervorruft.

Diese Erkenntnisse sind für mich in unserer Umfrage zu REAKTOR 6 ein Grund gewesen, warum ich eine Neuprogrammierung mit Bruch mancher Kompatibilität zu R5 befürworte.

[helmsklamm]

danke herw.
wahrscgheinlich hast du recht, das das handbuch dann auf halbe brockhausgröße anwüchse, was wahrscheinlich zumindest in gedruckter form, kaum praktikabel wäre. aber ne tiefergelegte deatil-pdf is sicher nich zuviel verlangt.
noch besser wär natürlich ne VERBINDLICHE logik im modulverhalten oder zumindest ne kennzeichnung von modulen die uU etwas anders als erwartet arbeiten können (das Y und PY anders triggern, is zeimlich das exakte gegenteil von intuitiv) , zumindest sollte es allerwenigstens hinweise in den modul-properties geben, wie die einzelnen ports trigger verarbeiten/senden - ohne mühselige eventwatcher forschung is man sonst tatsächlich aufgeschmissen. etcpp

[herw]

ja da ich gebe Dir völlig recht, für den unbedarften User, der Panelelemente benutzen möchte, darf es eigentlich solche Ungereimtheiten nicht geben. Andererseits kennen wir nicht die Beweggründe, warum bestimmte Panelelemente gerade so gestaltet werden, d.h. welche Vorstellungen von Anwendungen dem Entwickler im Kopf geisterten.
Für mich persönlich allerdings finde ich es immer wieder spannend, ein Modul vollständig selbst zu erforschen. Die Ungereimtheiten stören mich letzendlich auch, aber es reizt mich andererseits dann erst Recht, ihnen die Eigenschaften aufzuprägen, die ich haben möchte.

[herw]

Struktur und Funktionsweise des Normalreglers (7)

Aus dem oben beschriebenen Verhalten habe ich nach langen Versuchen und auch manchen Fehlschlägen die Konsequenz gezogen, dass ich mit Hilfe der MausArea nur die verschiedenen Klicks und Positionsveränderungen verarbeite. Da ich auch Klicks auf dieselbe Stelle verarbeite, benutze ich statt des Y-Ausgangs den PY-Ausgang. Dabei verliere ich allerdings das Feature der Cursor-Veränderung; das ließe sich zwar auch noch durch eine zusätzliche Y-Abfrage einbauen, dann wird es aber übertrieben kompliziert.

INC-DEC.gif

Den wichtigsten Part übernimmt das Increment/Decrement-Modul. Es registriert nur, ob der Mauszeiger nach oben oder unten bewegt wurde.
Dazu vergleicht es die ursprüngliche Position mit der durch Mausziehen erzeugten neuen Position.
Wie schon im vorangangenen Abschnitt beschrieben, wird bei jedem Mausklick die absolute Position PY der Maus ausgegeben. Wenn ich nun die Maus gedrückt halte oder ziehe, so wird die Positionänderung direkt über PY ausgegeben. D.h. ich muss nur den neuen Wert mit dem alten vergleichen vergleichen und ich erkenne, ob er sich erhöht hat oder nach unten verändert .
Eine entscheidende Rolle spielt dabei das unscheinbare Makro z^-1 ndc.
Es ist nichts anderes als eine Kombination aus einem write- und read-Befehl für eine gemeinsamen Speicher.
Die Reihenfolge, inder diese Module angeordnet sind, sind für diese Anwendung entscheidend.
Wie man der Bezeichnung schon entnehmen kann, soll auf eine Information, die zurückliegend ist ( in DSP mit z^-1 bezeichnet), zugegriffen werden. Was bedeutet z^-1? Nun es bezeichnet den Wert, der eine Zeiteinheit vorher angenommen wurde. Eine Zeiteinheit ist in DSP in der Regel die Zeit, die für ein Sample vergeht, also wie in REAKTOR meistens t=1/44100Hz=0,000022675...s also etwa 2/100 ms.
Audiosignale werden mit der SampleRate verarbeitet, was zunächst sehr schnell erscheint. Wenn man aber bedenkt, dass ein Rechner ja mittlerweile mit - na sagen wir großzügig - 2,5GHz arbeitet, d.h. mehr als 50000 mal so schnell, dann ist das nicht viel. Nebenbei bemerkt kann man dann innerhalb der Zeiteinheit, die ein Sample braucht, jede Menge Events dazwischen packen und übermitteln. CList hat so etwas schon gemacht und Krümelmonster denkt sehr gerne darüber nach . Aber ich schweife ab.
Ic h benutze die z^-1-Idee ganz einfach. Man erkennt unten den so genannten Clock-Eingang. Über die Latchelemente regelt er die Weitergabe der Werte an den Speicher.
Wir erkennen, dass beide Eingänge des z^-1-Makros dieselbe Information (gleichzeitig) erhalten. der neue PY-Wert wird als Wert übergeben und erzeugt auch den Clock-Befehl zur Verarbeitung des Wertes.
Auch wenn beide Informationen gleichzeitig das Modul erreichen, so gibt es doch in Core eine festgelegte Reihenfolge, wie diese "gleichzeitigen Informationen verarbeitet werden. Dies wird durch die Anordnung der Speicherbearbeitungsmodule geregelt. Wir erkenn hinter dem Klockeingang den read-Befehl, hinter dem Werteeingang den write-Befehl. Es soll also in den gemeinsamen Speicher (erkennbar an der OBC-Verbindung (hier rot markiert)), sowohl gelesen wie auch geschrieben werden. Das ist natürlich mehrdeutig. In Core ist dies klar geregelt: Das read-Modul ist mit seinem Master-Ausgang mit der OBC-Verbindung mit dem Slave-Eingang des write-Moduls verbunden. Das Master-Modul hat Vorrang. Also wird zunächst der read-Befehl und dann der write-Befehl ausgeführt. Im Handbuch wird das mit einem Strom verglichen, das Mastermodul ist weiter stromaufwärts als das Slave-Modul. Das ist in den meisten Core-Konstruktionen eindeutig, aber es gibt problematische Grenzfälle, die ich aber hier nicht diskutieren möchte.
Jedenfalls wird zuerst der aktuelle Speicher ausgegeben und erst dann wieder neu überschrieben.
Nun, der Rest ist schnell erklärt. Der aktuelle Wert PY wird mit dem alten Speicherwert verglichen (Differenz), aus der man durch Vorzeichenvergleich erkennt, ob der Mauszeiger nach oben oder unten gezogen wurde.

[herw]

Struktur und Funktionsweise des Normalreglers (8)

Schaut man nun wieder in die übergreifende Struktur, so verarbeitet ein Akkumulator diese Information weiter:
Ich gebe hier noch einmal das passende Bild an:

Inc-dec-akku.gif

Der min-max-Akkumulator ist ein etwas veränderter Akkumulator (Addierer), der lediglich durch seine min- und max-Werte begrenzt ist:

min-max-akkumulator.gif

Wir erkennen wieder die zentrale Speicherstruktur aus read- und write-Befehl mit der OBC-Verbindung, die in so vielen Core-Modulen eine entscheidende Rolle spielt (grüner Rahmen).
Durch den Change-Wert wird ein Readbefehl ausgeführt, der den ankommenden Changewert zu dem Speicherinhalt addiert. Dieser wird ausgegeben und gleichzeitig als neuer Wert in den Speicher geschrieben.
Man stelle sich einmal nur den Aufwand vor, den man in primary-level dafür ausführen müsste. Die Gleichzeitigkeit, die es in Core gibt, vereinfacht so viele Strukturen und entspricht genau der Denkweise desjenigen, der eine solche Struktur ausheckt. Daher benutze ich, wenn es irgendwie geht, Core (ich hoffe überzeugende Argumente für einen Wechsel zu Core zu liefern ). Damit wird der vom MausArea ausgegeben Wert (eigentlich nur die Mausbewegung) in einem Speicher verwaltet. Dies übernehmen in der Regel die Panelelemente (wie zum Beispiel Regler, Fader auch MausArea selbst; aber nichjt mit den Reset- und Default-Möglichkeiten, die ich nun selbst steuern kann. Es ist nur eine kleines Feature, dass ich durch das Clip-Modul den Speicher auf einen Wertebereich beschränken kann. Das hat den Vorteil, dass ich diese Struktur auch für andere Wertebereiche verwenden kann.
Wir erkennen links vom Read-Befehl noch ein weiteres Write-Modul, das seinen Wert vom Reset-Eingang erhält. Damit habe ich die Möglichkeit, von außen den Speicher zusätzlich zu überschreiben.
Dies geschieht, wie wir noch sehen werden, durch einen Doppelklick.
Der Rest der gesamten Struktur ist nur die Umrechnung der Mauspositionen in die auszugebenenden Werte (oberster Ausgang, hier nur mit 1 multipliziert, da die Ausgabewerte ebenfalls ganzzahlig sind), die Auswahl des richtigen Multipictures (die Regleranzeige) und die Werteanzeige, die über ein eigenständiges Multipicture geregelt ist. Das ist aber nur ein Luxus, den ich mir aus Designgründen erlaube. Einer Werteausgabe über den Value-Ausgang an ein normales numeric readout steht nichts im Wege.

[herw]

Nur um mich und Euch heiß zu machen, ein weiterer Vorkucker für ein größeres Ensemble. Natürlich ist dies noch nicht funktional, aber doch ein erster Eindruck, wie eine größere Struktur aussehen könnte.
Konstruktive Kritik erwünscht!

vorkucker.gif

Auf kleineren Bildschirmen muss man das Browser-Fenster nach links verschieben und dann vergrößern, damit man alle Bilder in der richtigen Anordnung sieht. (sorry Bernhard )

[herw]

Enders, Bernd:
Die Klangwelt des Musiksynthesizers
interessant zum informellen Zeitvertreib und zur Grundlage; sehr angenehm zu lesen. Auch wenn hier ein echter Vintage-Modularer (boehm soundlab) beschrieben wird, so ist alles völlig aktuell und direkt auf andere Systeme übertragbar.

[herw]

Struktur und Funktionsweise des Normalreglers (9)

Zahlanzeige.gif

Ich gehe hier mal exemplarisch auf die Nummernanzeige ein, um zu zeigen, wie man mit multipictures eine farbige (oder weiße) Zahlanzeige mit transparentem Hintergrund erzeugt.

Hierbei verwende ich auf meinem Mac das Grafik-Programm GraficConverter. Es ist mir in den letzten Jahren zu einem immer wichtigeren Helferprogramm geworden, wenn es darum ging, Bilder in verschiedenen Formaten abzuspeichern und umzuwandeln. Es hat viele Tricks drauf, die einem beim Erstellen von Multipictures helfen. Da es ein Sharwareprogramm ist, kann man es getrost ausprobieren. Es hat eine Schaltuhr eingebaut, mit der sich die Ladezeit von Tag zu Tag verlängert, bis man es schließlich kaufen möchte. Die wenigen Euros lohnen sich aber allemal, da der Entwickler sich sehr um seine Kundschaft kümmert und auf Anfragen per eMail noch am selben Tag gewissenhaft und ernsthaft antwortet (genug Reklame - ich hab's jedenfalls gekauft und bekomme seit Jahren kostenlose Updates).
Natürlich kann man auch teure Profiprogramme wie photoshop benutzen. Für den PC gibt es sicherlich ähnliche Programme; die Vorgehensweise ist sicherlich vergleichbar.

Nun zu den beiden gezeigten Bildern. Man wird sich fragen, warum so viel Aufwand, wo doch die Ziffernanzeige das numeric-readout-Modul oder auch ein Regler selbst eine Ziffernanzeige besitzt?
Links seht ihr die Lösung mit einer numerischen Anzeige, rechts mit einem Multipicture. Das besondere ist der transparente Hintergrund und die Möglichkeit durch einen einfachen Füllbefehl die Schrift in einer anderen Farbe erscheinen zu lassen. Ich hoffe mal, dass NI in der Version R6 ein Einsehen mit mir hat und mir eine farbige transparente Zahlanzeige stiftet. Etwas ähnliches habe ich ziffernweise in der alten (jetzigen Modularversion) schon erstellt. Ich bin aber dazu übergewechselt, mit einem kleineren Schriftsatz zu arbeiten und zwar mit dem von NI. Wie das?

[herw]

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.

Schritt 1

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. Dazu muss man wissen, dass Reaktor seine Grafik- und Textanzeigen nur mit einer Genauigkeit von vier Pixeln positionieren kann; ich hatte es ganz zu Anfang dieses Projektes mal erwähnt. Es ist also günstig, jeweils Vielfache von vier für die Größen zu wählen.
Ich ordne diese Textmodule nun untereinander so dicht wie möglich an, stelle den Hintergrund auf transparent, die Textanordnung auf zentriert.

ZAHLENANZEIGE 3.gif

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. Für unser Beispiel möchte ich einen Wertebereich von -12,0 bis +12,0 in Zehntel-Schritten. Das sind 241 Zahlentexte und ist in erträglicher Zeit zu schaffen. Für den Grob/Fein-Regler musste ich mir mit seinen 15401 verschiedenen Zahlen natürlich etwas anderes überlegen .

[herw]

Struktur und Funktionsweise des Normalreglers (11)

Schritt 2

Wie bekomme ich die auf dem Panel angezeigten Zahlen in mein Grafikprogramm? Ich mache einfach einen screenshot. Auf dem Macintosh geht das mit der Tastenkombination [apfel][ctrl][shift]4. Erscheint ein veränderter Mauszeiger und man kann ein Rechteck aufziehen, das beim Loslassen der Maus in den Zwischenspeicher übernommen wird. Das ist/ sind dann in der Regel ein oder mehrere Zahlenstreifen. Ich öffne nun mein Grafikprogramm und erstelle mit [apfel]j aus dem Zwischenspeicher ein Bild (in der Regel im Pict-Format). Das sieht dann etwa so aus:

ZAHLENANZEIGE 5.gif

Da REAKTOR einen Zeichensatz mit 7 Pixel Höhe benutzt, ist im Screenshot bei engster Anordnung zwischen den Zeilen jeweils nur eine Pixelreihe Zwischenraum. Ich vergrößere das erste Bild gleich in seiner Länge, da ich ja insgesamt 241+1 Textzeilen mit jeweils 8 Pixeln Höhe habe, grob auf die entsprechende Größe. (ich habe hier nur beispielhaft um 1500 Pixel vergrößert).

Ein wenig muss man noch bei der Anordnung von negativen und positiven Zahlen durch entsprechendes Hin- und Herschieben ganzer Bildbereiche für eine ordentlich zentrierte Anordnung sorgen; man markiert ganze Bereiche und kann diese pixelweise verschieben. Das ist Minutensache und kann in einer entsprechenden Vergrößerung leicht geschehen.
Hier mal als Beispiel das Verschieben eines kleinen Ausschnitts in der Vergrößerung 1000%:

ZAHLENANZEIGE 4.gif

[herw]

Struktur und Funktionsweise des Normalreglers (13)

Schritt 3

Nun muss man aus dem Pict-Format in das TGA-Format konvertieren. Das ist leicht gemacht:
Ich wähle durch [apfel]a den gesamten Bildbereich aus und bringe ihn durch [apfel]x in den Zwischenspeicher und lösche den ganzen Bereich. Nun füge ich einen Alphkanal hinzu, öffne den Alphakanal und füge den gerade ausgeschnittenen Bereich wieder ein. Im Alphakanal sieht man nun dasselbe Bild. Versteckt man nun den Alphakanal, so sieht man fast nichts, da die transparenten Fläche durch ein kariertes Muster angezeigt wird. Damit man versteht, was geschehen ist, habe ich den normalen Zeichenbereich komplett rot ausgefüllt.

ZAHLENANZEIGE 6.gif

Man erkennt jetzt die roten Zahlen. Im Alphakanal befand sich dagegen ein weiß-grau-schwarzes Bild. Der Alphakanal funktioniert folgendermaßen: an den weißen Stellen ist das Bild später völlig transparant an den schwarzen Stellen dagegen stellt es den normalen Zeichenbereich dar. Grautöne sind je nach Stärke mehr oder weniger transparent. Daher sieht man jetzt an den im Alphakanal geschwärzten Stellen nun den roten Bereich an den anderen nichts.
Man muss nun noch das erweiterte Bild so zurecht schneiden, dass es eine Länge von 241·8 Pixel hat und fertig.
Ich speichere jetzt das ganze als TGA-File ab und kann es dann in multipictures benutzen.

Nachtrag: Wer beim vorletzten Bild genau hinschaut, sieht, dass ich zwischen den Textzeilen einen zwei-Pixel-Abstand habe; dies kann man im GraficConverter durch so genannte Mehrfachkonvertierung für alle Teilbilder gleichzeitig ergänzen. Dies ist aber nur für das Design des Reglers wichtig, also hier für die grundsätzliche Behandlung nicht relevant.

[herw]

MODULE (1)

Bevor ich die einzelnen Module vorstelle, ein paar Vorbemerkungen.
Alle Module haben genormte Aus- und Eingänge, soweit es sinnvoll ist.
D.h. sie haben einen Wertebereich von -1..+1 oder 0..+1 oder -1..0. Alle Eingänge sind darauf genormt und sind grundsätzlich Audioeingänge. Falls Events verlangt werden, so werden sie intern dann konvertiert. Das hat den Vorteil, dass man wirklich ohne Bedenken alles mit allem verbinden kann; natürlich ist nicht alles sinnvoll. Manchmal aber sind es doch die Experimente, die eine neue Erkentnis bringen; z.B. schon mal einen Rechteckoszillator durch ein core ADSR-Modul (mit Audioeingang) gejagt?
Trotz der Normierung besitzen alle Bedienelemente sinnvolle Wertebereiche, so dass der Benutzer sich auch ohne Handbuch schnell zurechtfinden kann.
Alle Regler haben unterhalb des Reglers eine numerische Anzeige. Wenn man den Regler dreht, wechselt das Label unterhalb des Reglers zur Zahlanzeige. Etwas eine Sekunde nachdem der letzte Wert verändert wurde wechselt die Anzeige wieder zum Label. Wer lieber dauerhaft oder vorübergehend den Zahlwert angezeigt haben möchte, kann dies durch einen Linksklick auf die Zahlanzeige jeweils umstellen. Der Doppelklick definert den aktuellen Wert als Defaultwert. Er kann in jedem Snap einen anderen Wert haben.
Der Regler wird wie gewohnt bedient. Ein Doppelklick auf den Regler ruft den Defaultwert auf.