WORKSHOP 3 : Send->Receive , IC-Send->IC-RECEIVE(X)

Workshops für Reaktor-Anfänger

Moderator: herw

WORKSHOP 3 : Send->Receive , IC-Send->IC-RECEIVE(X)

Beitragvon herw » So 13. Aug 2006, 10:50

Übersicht über das dritte Workshop

3.1 Send-Receive
3.2 Receive-Modul als Schalter
3.3 Tücken der Send-Receive-Module
3.4 IC-Send-IC-Receive
3.5 Tücken der IC-Send-IC-Receive-Module
3.6 IC-Send steuert Receive(X)
3.7 Tricks zu den internen Verbindungen
3.8 ...

ciao herw
Zuletzt geändert von herw am Sa 30. Sep 2006, 16:56, insgesamt 7-mal geändert.
Benutzeravatar
herw
moderator
 
Beiträge: 3043
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: WORKSHOP 3.1

Beitragvon herw » So 13. Aug 2006, 10:53

3.1 Send-Receive post #1

Dem Titel dieses Workshops entnimmt man, dass hier drei unterschiedliche Arten der kabellosen Verbindungen untersucht, verglichen und unterschieden werden sollen.

Eine sehr grober Unterschied besteht schon in den Voraussetzungen:
  • SEND->RECEIVE übertragen polyphone Audio- und Eventsignale
  • IC-Send->RECEIVE und IC-Send->X übertragen monophone Eventsignale
Zunächst gehe ich auf die Send->Receive-Verknüpfung ein.
Wir öffnen das folgende ensemble:
03.01.ens.zip Es handelt sich um einen kleinen modularen Synthesizer.
Bild
Nur wenn die Struktur komplex genug ist, lohnt sich der Einsatz von Send-Receive-Modulen. Wir schauen in die Struktur:
Bild
Ich habe sie so gestaltet, dass es keine Makros gibt und man alle Module gleichzeitig beobachten kann. Normalerweise muss man sich die einzelnen Strukturteile weit verstreut in Makros gepackt vorstellen. Strebt man eine modulare Struktur an, d.h. man möchte viele Quellen mit vielen Zielen verknüpfen und das eventuell noch schaltbar machen, so kann man zwischen einem Kabelwirrwarr und den Send-Receive-Verbindungen wählen. Send-Receive-Module bilden eine virtuelle Verbindung ohne Kabel (wires) und schaffen so Übersicht. Nebenbei haben die Receive-Module den Vorteil, dass sie noch als Schalter wirken. Die „Schalter“ werden im Panel als anklickbare Liste dargestellt.
Wir erkennen in der Struktur drei Untergruppen, die ich farbig gekennzeichnet habe:
  • einfache Modulationsquellen
  • Oszillatoren und
  • Hüllkurve

Die Strukturteile sind im Panel durch unterlegte Bilderrahmen zusammengefasst.
Wir rufen den Snap 2 auf und beobachten, dass im Panel im Modul Hüllkurve die Verbindung tri >> aufgerufen wurde. Einge Tastendrücke auf die QWERTZ-Tastatur gibt uns den typischen Dreiecksklang. Klickt man nun mit der Maus auf saw >> oder pulse >> (cursortasten funktionieren auch), dann hören wir die anderen Oszillatoren.
Bild
Beobachten wir parallel dazu in der Struktur die Oszillatoren; wir stellen fest, dass diese nur bei einer existierenden Verbindung arbeiten. D.h. die Receive-Module schalten wirklich auch um, damit sind sie CPU-schonend, da nicht benötigte Strukturgruppen deaktiviert werden.
Wir wählen snap 3: Hier wurde sogar der LFO als Audioquelle missbraucht, allerdings nur scheinbar. Abgesehen davon, dass der LFO nicht durch den Tastendruck in seiner Tonhöhe verändert wurde, ist für uns viel entscheidender, dass es sich bei dem LFO um eine Event-Quelle handelt. Man erkennt dies an dem rot gekennzeichneten Ausgang des LFO (siehe Strukturbild).

D.h. eine Send-Receive-Verbindung kann wahlweise Audio- als auch Event-Signale übermitteln.
Dateianhänge
03.01.ens.zip
(4.32 KiB) 279-mal heruntergeladen
03.01.gif
03.01.gif (10.17 KiB) 3004-mal betrachtet
03.02.gif
03.02.gif (16.44 KiB) 3013-mal betrachtet
03.03.gif
03.03.gif (2.95 KiB) 2998-mal betrachtet
Zuletzt geändert von herw am So 13. Aug 2006, 11:02, insgesamt 2-mal geändert.
Benutzeravatar
herw
moderator
 
Beiträge: 3043
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: WORKSHOP 3.2

Beitragvon herw » So 13. Aug 2006, 10:55

3.2 Receive-Modul als Schalter post #2

Wir spielen nun ein wenig mit den verschiedenen Snaps. Wir rufen nochmals Snap 3 auf und drücken auf der Qwertz-Tastatur verschiedene "Töne". Da der LFO so beschaltet ist, dass er keine Midi-abhängige Schwingungsdauer hat, hören wir immer denselben dumpfen Ton bei 65Hz. Wir lassen nun einen Ton gedrückt und regeln gleichzeitig den Frequenz-Regler nach oben. Dies geht nur bis 200Hz. Danach reagiert der LFO nicht mehr mit einer Tonhöhenänderung, obwohl er doch durchaus höher schwingen könnte. Wer aufmerksam zugehört hat, wird bemerken, dass der LFO sogar zwei Töne sendet (deshalb sagte ich in der ersten Post "scheinbar"), die sich bei Frequenzerhöhung immer mehr annähern, bis sie bei 198Hz in eine Schwebung übergehen und dann schließlich bei 200Hz sich gegenseitig auslöschen oder überlagern, in jedem Fall gibt es bei Frequenzerhöhung keine Änderung mehr. 200Hz ist eine auffällige Frequenz! Ein Blick in die Systemeinstellungen gibt eine erste Ahnung:
Bild
Dort steht Control Rate=400Hz (eventuell habt Ihr andere Einstellung, dann gibt es diesen Effekt auch schon früher oder später). Wir ändern mal auf 800Hz und wiederholen unseren LFO-Versuch. Aha, nun können wir die Frequenz des LFO weiter erhöhen, doch tritt nun dasselbe Problem bei 400Hz auf. Ich gebe hier als Stichwort mal nur Nyquist-Shannon-Abtasttheorem an; wer Lust hat, kann dort das Problem der Abtastung ausführlich nachlesen. Grob gesprochen passiert folgendes: die Control Rate legt fest, wie oft ein Event-Signal pro Sekunde abgetastet wird. Hat das abzutastende Signal die halbe Abtastrate (Nyquist-Frequenz) erreicht, ist eine Rekonstruktion des Signals nicht mehr möglich. Dies gehört zwar nicht direkt hier in diesen Workshop, doch sollte man sich bei der freien Schaltbarkeit und der sehr komfortablen Verwendung von Audio- und Eventsignalen durch die Receive-Module über solche Effekte im Klaren sein. Nebenbei bemerkt ist dies auch ein Grund, dass man für echte Frequenzmodulationen unbedingt Audioquellen nimmt und diese dem Audioeingang FM eines Oszillators zuführt.
Wir probieren noch einige andere ControlRates, um diesen Effekt zu bestätigen und stellen schließlich wieder den üblichen Wert von 400Hz (oder auch 200Hz) ein.
Wir probieren nur noch die anderen Snaps durch. Ich habe sie erstellt, damit man die Möglichkeiten der Umschaltungen erkennen kann, und dafür typische Beispiele angeführt. Gedacht sind diese Snaps als Ausgangspunkt, um selbst an den Schalterstellungen zu spielen.
Snap 4: Pitchänderung. Wir drehen am Pitchregler und ändern damit die Stiimung des Oszillators in Vierteltönen. Im Receive-Modul >> P tri ist die Schalterstellung knob >> aktiviert.
Snap 5: Vibrato, leichte regelmäßige Tonhöhenänderungen durch den LFO
Snap 6: Der Pitchregler wird zur Pulweitenänderung der Rechteckschwingung missbraucht. Da eine Pulsweitenänderung nur in Prozenten angegeben wird, arbeitet der Regler nur im Bereich von -1 bis +1.
Snap 7: Pulsweitenänderung durch LFO, die Amplitude sollte klein sein
Snap 8: Pulsweitenänderung durch LFO, die Amplitude kann relativ groß sein
Snap 9: Synchronisation ; wir erkennen an den Schalterstellungen, dass der eigentliche Sägezahnoszillator die Schwingungsform vorgibt und um 11,5 Töne nach oben transformiert ist. Jedoch wird er synchronisiert durch den Rechteckoszillator. Dadurch erhält man zusätzliche Obertöne und der Klang wird "schmutzig" und "aggressiv" vor allem in den tiefen Tonbereichen. Die Tonhöhe wird durch den synchronisierenden Oszillator, in diesem Fall den Rechteckoszillator, bestimmt.
Dateianhänge
03.04.gif
03.04.gif (17.17 KiB) 3021-mal betrachtet
Zuletzt geändert von herw am So 13. Aug 2006, 11:03, insgesamt 3-mal geändert.
Benutzeravatar
herw
moderator
 
Beiträge: 3043
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: WORKSHOP 3

Beitragvon herw » So 13. Aug 2006, 10:56

3.3 Tücken der Send-Receive-Module post #3

Für die Send-Receive-Verbindungen schauen wir uns das folgende Ensemble an: 03.02.ens.zip
Es ist eine Vereinfachung des eingangs vorgestellten Ensembles. Wir erkennen drei wesentliche Bestandteile wieder: rechts oben ein Oszillator mit Dreieckswellenform, unten links nachgeschaltet ein Hüllkurvengenerator, der über ein Multiplikationsmodul mit dem Audioausgang verbunden ist und oben links eine kleine Modulationssektion.
Bild Bild
Das Ensemble ist modular gestaltet, d.h. die einzelnen Aus- und Eingänge werden über interne Verbindungen (Send-Receive) hergestellt.
Schauen wir genauer hin, so erkennen wir vier Send-Module
  • knob >>
  • lfo tri >>
  • lfo pls und
  • tri >>
Bild
und zwei Receive-Module
  • >> P tri und
  • >> audio.
Im Panel sind die beiden Receive-Module wieder durch jeweils ein Listen-Menu dargestellt.
Bild
Dateianhänge
03.02.ens.zip
(3.44 KiB) 256-mal heruntergeladen
03.05.gif
03.05.gif (6.45 KiB) 3013-mal betrachtet
03.06.gif
03.06.gif (8.72 KiB) 3011-mal betrachtet
03.07.gif
03.07.gif (4.47 KiB) 3007-mal betrachtet
03.08.gif
03.08.gif (3.95 KiB) 2995-mal betrachtet
Zuletzt geändert von herw am Sa 30. Sep 2006, 16:20, insgesamt 4-mal geändert.
Benutzeravatar
herw
moderator
 
Beiträge: 3043
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: WORKSHOP 3

Beitragvon herw » Sa 30. Sep 2006, 15:37

3.3 Tücken der Send-Receive-Module post #4

Alle vier Ausgänge (die Send-Module) werden im Prinzip allen Receive-Modulen als Verbindung angeboten. Wir erkennen das, wenn wir einmal in die Properties der beiden Receive-Module schauen:
Bild
Der Pitcheingang des Dreiecks-Oszillators ist ein Eventeingang (rot), daher kann er auch nur von Event-Signalen gespeist werden; dies sind lediglich der Drehknopf und die beiden LFO-Ausgänge. Daher sind diese in der Propertiesliste aktiviert und im Panelmenu sichtbar. Der Audio-Ausgang des Oszillators selbst kann nicht aktiviert werden (state-Feld zeigt kein OK). Möchte man von den Event-Signalen nicht alle auswählen, so kann man das Kreuzchen löschen.
Beim zweiten Receive-Modul ist dagegen der Knopf nicht aktiviert.
Bild
Obwohl es sich um ein Eventsignal handelt, wäre eine Aktivierung für den Audioausgang möglich, ist aber in diesem Fall nicht sinnvoll, da wir ja den Audioausgang direkt der Audiokarte zuführen und ein quasi "Gleichspannungssignal" nicht hörbar ist. Benutzt man dagegen den Audioausgang als Steuersignal, so wäre eine Aktivierung durchaus denkbar und nützlich. Hier ist nun kein Kreuzchen gesetzt, also ist dieser Signaleingang auch im Listen-Menu nicht sichtbar. Wir setzen einmal kurz das Kreuzchen und sehen im Panel den zusätzlichen Listeneintrag in der Receive-Liste >> Audio.
Die verschiedenen Zuweisungen haben wir schon in der ersten Post ausprobiert, daher gehe ich darauf nicht ein.
Nun die erste Tücke: man möchte die Liste umsortieren: im Menu >> Audio soll der Listeneintrag tri >> an letzter Position stehen.
Wir öffnen die Properties und klicken auf tri>>. Der Eintrag ist grau hervorgehoben. Nun klicken wir auf down. Wie gewünscht tauschen tri>> und lfo tri >> die Plätze. tri >> ist grau hervorgehoben, also klicken wir nochmals auf down. FALSCH!!! Es tauschen nicht tri >> und lfo pls >> die Plätze sondern wieder lfo tri >> und tri >> und alles ist wieder beim Alten.
Ein Bug, der einen schier zur Verzweiflung treiben kann.
Also nochmals richtig:
  • klick auf tri >>
  • klick auf down
  • klick auf tri >> (!!!!)
  • klick auf down

und nun müsste es so aussehen:
Bild
Zum Üben machen wir das ganze wieder entsprechend rückgängig.

Merkregel: Bevor man einen Listeneintrag verschiebt, muss man ihn jedesmal vorher anklicken!

Nun kann man sich auch die Liste durch einen Klick auf die jeweilige Spaltenüberschrift sortieren lassen: Klick auf # sortiert die Eingänge rückwärts, nochmaliger Klick wieder aufwärts; klick auf den Namen gibt ein Sortierung nach Namen usw.. Wichtig ist jedoch, dass für die Menureihenfolge allein die Nummerierungen verantwortlich sind. Das heißt, wenn man schon umsortiert, dann sollte man vorher die Nummernsortierung ausgewählt haben. Da gibt es allerdings den nächsten unschönen "Bug". Geht die Nummerierung über zehn hinaus, so gibt es eine Sortierung wie sie in Linux üblich ist:
also nicht etwas 1,2,3,4,5,6,7,8,9,10,11,12,.. sondern
1,10,11,12,...2,3,4,... also quasi die Telefonbuchsortierung. Mein Rat: Finger davon!! Niemals die Sortierungsoption aufrufen, sondern alles so lassen und nur durch Verschieben umsortieren. Bei vielen und großen Listen, wie sie in modularen Synthesizern üblich sind, ist ein gute Vorplanung eine hervorragende Zeitersparnis. Leider habe ich selbst an diesem Punkt ordentlich Lehrgeld zahlen müssen.
Dateianhänge
03.09.gif
03.09.gif (3.45 KiB) 2991-mal betrachtet
03.10.gif
03.10.gif (3.5 KiB) 2999-mal betrachtet
03.11.gif
03.11.gif (2.22 KiB) 3009-mal betrachtet
Benutzeravatar
herw
moderator
 
Beiträge: 3043
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

Re: WORKSHOP 3

Beitragvon herw » Sa 30. Sep 2006, 16:35

3.3 Tücken der Send-Receive-Module post #5

Nun wollen wir einen zusätzlichen Oszillator einbauen und ihn ebenfalls mit einem Receive-Modul füttern.
Bild
Nach dem Einfügen und einigem Verschieben im Panel sollte es so aussehen:
Bild
Das Listenmenu hat nicht die richtige Größe, daher Ändern wir ihr Aussehen entsprechend:
Bild
Wir ergänzen noch NotePitch und das Additionsmodul und schließen alles an den Oszillatoreingang an:
Bild
Doch was ist das? Der Ausgang des Additionsmoduls und der Pitcheingang wollen partout nicht zusammenkommen???

Hmmm? Es ist doch gar nichts Ungewöhnliches passiert. Allerdings fällt auf, dass der Pitcheingang des Oszillators ja ein Eventeingang ist und das Additionsmodul einen schwarzen (Audio-) Ausgang besitzt. Wir schließen mal eben an den schwarzen f-Eingang an. Alles klappt, aha Fehler gefunden. Wir löschen wieder die Verbindung und schauen nach einer Ursache.
Wir haben doch nur das wiederholt, was oben drüber der Dreiecksoszillator vormacht. Aber es gibt einen Unterschied: das Receive-Modul hat einen Audio-Ausgang. Wir schauen in die Properties und sehen die Ursache:
Bild
Der "Übeltäter" ist der aktivierte Audio-Signal-Eingang tri >>. Sobald irgendein Audioeingang aktiviert ist, wird der Receive-Ausgang zu einem Audi-Ausgang. Wir löschen das Kreuzchen und der Receive-Ausgang wird zu einem Event-Ausgang. Nun können wir das Additionsmodul mit dem Pitcheingang verbinden (grüner Ausgang bedeutet hybrid, kann also sowohl mit einem Event- als auch mit einem Audioeingang verbunden werden).
Bei sehr langen Listen muss man unbedingt im Auge behalten, welcher Art die einzelnen Signale sind.
Dateianhänge
03.12.gif
03.12.gif (4.43 KiB) 2998-mal betrachtet
03.13.gif
03.13.gif (5.03 KiB) 2997-mal betrachtet
03.14.gif
03.14.gif (2.27 KiB) 2997-mal betrachtet
03.15.gif
03.15.gif (4.74 KiB) 2988-mal betrachtet
03.16.gif
03.16.gif (3.7 KiB) 2994-mal betrachtet
Zuletzt geändert von herw am Sa 30. Sep 2006, 18:20, insgesamt 1-mal geändert.
Benutzeravatar
herw
moderator
 
Beiträge: 3043
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund

3.4 IC-Send-IC-Receive post #6

Beitragvon herw » Sa 30. Sep 2006, 16:53

3.4 IC-Send-IC-Receive post #6

- in Arbeit -

Wir kommen nun zu den IC-Verbindungen (IC=internal connection). Man könnte meinen, dass sie doch völlig unnötig sind, da sie ja nur monophone Event-Signale übertragen; das könnten ja die normalen Send-Receive-Verbindungen auch übernehmen!
Das ist richtig, doch haben die IC-Verbindungen trotz der Beschränkung (oder gerade deswegen) zusätzliche Eigenschaften, die die normalen Send-Receives nicht besitzen: 03.03.ens.zip
Bild
Im Unterschied zu den normalen internen Verbindungen, können IC-Verbindungen auch Instrumenten überschreitend sein. Wir sehen einen Drehknopf, dessen Werte mit Hilfe des IC-Send in das untere Instrument übertragen werden und von einem IC-Receive empfangen werden und dann zur numerischen Anzeige kommen. Könnte praktisch sein; obwohl den meisten sicherlich nicht sofort ein Beispiel einfallen würde. Doch könnte man sich ähnlich wie bei der Hardware KORE ein Instrument aus wenigen Reglern bestehend vorstellen, die auf verschiedene Instrumente desselben Ensembles wechselnd zugreifen könnten. Natürlich ließe sich das auch in einem einzigen Instrument anordnen, aber vielleicht lassen sich so verschiedene Instrumente mit ähnlichen Interfaces jeweils austauschen, ohne dass die Steuerungselemente wechseln müssen.
Dateianhänge
03.03.ens.zip
(2.55 KiB) 255-mal heruntergeladen
03.17.gif
03.17.gif (18.35 KiB) 3003-mal betrachtet
Benutzeravatar
herw
moderator
 
Beiträge: 3043
Registriert: Mo 13. Mär 2006, 19:28
Wohnort: Dortmund


Zurück zu WORKSHOPS

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

cron