DISKUSSION zum WORKSHOP 3

[herw]

Hier können wir wieder diskutieren

[helmsklamm]

wieder großes dankeschön.

klitzekleine kritik: 3.2. is ja nett zu lesen, aber als lehrer würd ich sagen: n bissl am thema vorbeigeschippt. (aber trotzdem sehr interessant ich hatte die nyqusits - oder wie auc immer- freuqeunz immer als "echtes" audiophänomen betrachtet, und nich als "beschreibungs-varibale" des audiozustands - vielleicht könnte man ja seine ganzen "smoother" danach optimiren - aber fred für sich, rück zum thema).

jedoch bin ich ja speziel auf 3.3 gespannt, irgendwie sind die teile, milde gesprochen, etwas anarchisch in ihrem verhalten. ich glaube da könnte vieles simplifiziert, bzw. intuitiver gestaltet werden - auf jeden fall nervt es wie sonstwas, wenn scheinbar billige "ein-bit-module" resp. value x/ value y "ausgeber/empfänger" nen 2tägigen labor aufenthalt verlangen, nur weil das handbuch auf definitive stolperfallen, bzw. modul-interne-unlogikkeiten nich eingeht.

grrrrrrrrrr!!!!!!!!!!!

siehe auch hier: http://reaktor.approx.de/phpBB2/viewtopic.php?t=146 (post #4).

da hab ich pi x daumen ca. 3x2 stunden verschewendet, um festzustellen, das das eigentliche prob ganz woanders (idF bei den ICs liegt).

(hattest du nich mal gesagt, das das value nen eingebauten stepfilter hat? bei direkter übertragung hab ich nich den eindrück, bei indirekter allerdings schon).

[herw]

wieder großes dankeschön.

gerne geschehen. Vielleicht gefällt es manchen nicht, dass die Workshops nicht zügig sprudeln (es sind jetzt zwei Workshops noch offen). Leider habe ich nicht immer Zeit und Lust etwa zwei Stunden an einer Workshop-Seite zu arbeiten. Meistens entstehen sie wirklich live, d.h. ich schreibe daran und experimentiere gleichzeitig in R5.

klitzekleine kritik: 3.2. is ja nett zu lesen, aber als lehrer würd ich sagen: n bissl am thema vorbeigeschippt. (aber trotzdem sehr interessant ich hatte die nyqusits - oder wie auc immer- freuqeunz immer als "echtes" audiophänomen betrachtet, und nich als "beschreibungs-varibale" des audiozustands - vielleicht könnte man ja seine ganzen "smoother" danach optimiren - aber fred für sich, rück zum thema).

ja, das mit nyquist. Es ist eine typische Erkenntnis, die beim detaillierten Experimentieren zufällig erfolgt. Mir ist einfach der störende Ton aufgefallen, der nicht sein sollte und dann habe ich frei probiert. Natürlich trägt das zum direkten Verstehen der Send-Receive-Module nicht bei, doch wo soll eine solche Feststellung denn aufgeschrieben werden? Ich finde, solche Kleinigkeiten, die man entdeckt und dann auch noch nach endlich langem Recherchieren halbwegs erläutern kann, dürfen nicht verloren gehen.
Eine Frage ist natürlich, wer findet jemals diese "Randbemerkung" später wieder? Ich habe mir schon überlegt, ob man eine Art Stichwortverzeichnis für die Foren Reaktor (kreativ) und Workshops aufstellen sollte.

jedoch bin ich ja speziel auf 3.3 gespannt, irgendwie sind die teile, milde gesprochen, etwas anarchisch in ihrem verhalten. ich glaube da könnte vieles simplifiziert, bzw. intuitiver gestaltet werden - auf jeden fall nervt es wie sonstwas, wenn scheinbar billige "ein-bit-module" resp. value x/ value y "ausgeber/empfänger" nen 2tägigen labor aufenthalt verlangen, nur weil das handbuch auf definitive stolperfallen, bzw. modul-interne-unlogikkeiten nich eingeht.

ja da hast Du völlig recht; ich beschäftige mich mit diesen interen Verbindungen schon seit R4. Da ist die jetzige Handhabe schon Gold gegen. Sie ist aber immer noch nicht klar im Handbuch definiert und wird deshalb von vielen nicht benutzt. Das ist schade; viele Ensembles werden dadudrch unnötig unübersichtlich. Man werfe nur mal einen Blick in die Verdrahtung der hervorragenden Ensembles von Ernest Meyer. Aus seinen zahlreichen Posts über seine Schwierigkeiten zu den internen Verknüpfungen, kann man ermessen, wie schwer sich selbst ein solch erfahrener Reaktor-Gestalter daran die Zähne ausbeißt.

grrrrrrrrrr!!!!!!!!!!!

siehe auch hier: http://reaktor.approx.de/phpBB2/viewtopic.php?t=146 (post #4).
da hab ich pi x daumen ca. 3x2 stunden verschewendet, um festzustellen, das das eigentliche prob ganz woanders (idF bei den ICs liegt).
(hattest du nich mal gesagt, das das value nen eingebauten stepfilter hat? bei direkter übertragung hab ich nich den eindrück, bei indirekter allerdings schon).

nein, das IC-send hat einen eingebauten stepfilter.

ciao herw

[helmsklamm]

ja, das mit nyquist. Es ist eine typische Erkenntnis, die beim detaillierten Experimentieren zufällig erfolgt. Mir ist einfach der störende Ton aufgefallen, der nicht sein sollte und dann habe ich frei probiert. Natürlich trägt das zum direkten Verstehen der Send-Receive-Module nicht bei, doch wo soll eine solche Feststellung denn aufgeschrieben werden? Ich finde, solche Kleinigkeiten, die man entdeckt und dann auch noch nach endlich langem Recherchieren halbwegs erläutern kann, dürfen nicht verloren gehen.
Eine Frage ist natürlich, wer findet jemals diese "Randbemerkung" später wieder? Ich habe mir schon überlegt, ob man eine Art Stichwortverzeichnis für die Foren Reaktor (kreativ) und Workshops aufstellen sollte.
ciao herw

ajF (auf jeden Fall ) sollten derartige erkenntnisse nich im nirwana verschwinden. stichwortverzeichniss is ne feine sache, allerdings müsste das schon strukturierter sein, als sone foren-such-automation. mit anderen worten, das sieht nach ner menge arbeit aus und sollte auch von allen membern mitgepflegt werden. ich glaub ioch hab da 1,2 ideen zu - ich mach mal nen neuen diskusions-fred dazu.


mach dir bloß kein stress wegen der WS. ich glaube niemand bemängelt ernsthaft die "geschwindigkeit". das is n freiwilliger (und ziemlich zeitraubender) service von dir und alle sind froh, das es das überhaupt gibt und keiner käme auf die idee von dir da mehr eifer zu fordern.

ob sends nun mehr übersicht bringen, wage ich anzuzweifeln. zugegebn sieht die struktur übersichtlicher aus, aber alles unsichtbare is andrerseits schwiriger nachzuvollziehen.
ich wünsche mir da echt 2 dinge:
ne alternativ-view, die die normalen kabel ausblendet und dann temporär die send "kabel" zeigt, inclusive der im normalfall erforderlichen in/outs (die automatisch den namen der sends haben).

ausserdem wäre eine "go to" funktion absolut hilfreich. du rechtsklickst auf nen recive und im contextmenü gibt s die option go to send und schwupps bist du dort und vice versa (bei mehrfachverdrahtungen natürlich auch mehrfach-"reiseziele").

undnochmal danke: ich hab keine lust in die tifen solcher "billig-module" abtauchen zu müssen und bin wirklich heilfroh das du uns hier dein wissen zur verfügung stellst.

[herw]

...
ob sends nun mehr übersicht bringen, wage ich anzuzweifeln. zugegebn sieht die struktur übersichtlicher aus, aber alles unsichtbare is andrerseits schwiriger nachzuvollziehen.
ich wünsche mir da echt 2 dinge:
ne alternativ-view, die die normalen kabel ausblendet und dann temporär die send "kabel" zeigt, inclusive der im normalfall erforderlichen in/outs (die automatisch den namen der sends haben).

ist nur lokal möglich

ausserdem wäre eine "go to" funktion absolut hilfreich. du rechtsklickst auf nen recive und im contextmenü gibt s die option go to send und schwupps bist du dort und vice versa (bei mehrfachverdrahtungen natürlich auch mehrfach-"reiseziele")...

ja das ist praktisch; mach den Vorschlag doch mal hier

[helmsklamm]

mit lokal meinst du innerhalb eines rechners? nu ja, das wär doch schon n anfang.

DORT hab ich schon, ob das allerdings jemand liesst

[herw]

mit lokal meinst du innerhalb eines rechners? ...

nein, nein sondern ganz einfach innerhalb eines Makros.

[helmsklamm]

ups, hatte die antwort völlig überesehen:

bislang ist das werden send"kabel" auch nicht lokal (macrointern) geezeigt - oder bhab ich da was übersehen?
aber wieso du drauf beharrst, das das nicht gehen sollte, ist mir schleierhaft: es wäre nur ne frage der view-option: ein klick drauf und schwupps würde reaktor alle send kabel meinietwegen in grün darstellen. (angefangen im ursprangsmacro, send bekommt gleich nen temporäres view-out dahinter, das out (mit sendnamen) bekommt im level-höher macro wiederum nen out uswusf. - was is daran unmöglich? aber gut, zumindest sind wir uns beim go-to einig, immerhin

aber danke für die forstsetzung: das nen "audio" send auch audio ausgibt, halte ich für logisch und ich hätte auch einfach am recieve nen a/e hintergeklemmt - das man es sorum austricksen kann is natürlich auch nich uninteressant.

aber eine bitte:
könntest du vielleicht ne tabelle machen, wo die unterschiede IC/normal send/slave-master panel etc. liegen? ich komm da jedesmal durcheinander, bspw. beim rangen: das eine teil überträgt absolut, das nächste skaliert, eins reagiert auf "umgekehrete" ranges, das andere nicht, dazu ob die prop-range der jeweiligen sendart ne rolle spielt oder nicht... also ich taste mich da jedes mal von neuem ran und sone tabelle in der fundgrube wär da schon echt hilfreich.

[herw]

...aber danke für die forstsetzung: das nen "audio" send auch audio ausgibt, halte ich für logisch und ich hätte auch einfach am recieve nen a/e hintergeklemmt - das man es sorum austricksen kann is natürlich auch nich uninteressant.

In der Regel gehe ich den umgekehrten Weg und mache alle Eingänge zu Audio-Eingängen. Manche Synthese Möglichkeiten sind nur mit Audio möglich (z.B. FM)

aber eine bitte:
könntest du vielleicht ne tabelle machen, wo die unterschiede IC/normal send/slave-master panel etc. liegen? ich komm da jedesmal durcheinander, bspw. beim rangen: das eine teil überträgt absolut, das nächste skaliert, eins reagiert auf "umgekehrete" ranges, das andere nicht, dazu ob die prop-range der jeweiligen sendart ne rolle spielt oder nicht... also ich taste mich da jedes mal von neuem ran und sone tabelle in der fundgrube wär da schon echt hilfreich.

Oh beim Rangen werden Dir meine Beispiel nur so um die Ohren fliegen; man glaubt gar nicht, was für Gemeinheiten alles möglich sind. Das umgekehrte Rangen ist übrigens nur scheinbar umgekehrt; man muss nur wissen wo und warum es auftaucht.
Eine Tabelle kann ich für den "Normalfall" sicherlich erstellen.
Interessant sind aber gerade die Ausnahmen (kommt noch in den nächsten Tagen). Im Moment läuft die Feder.

ciao herw

[helmsklamm]

Oh beim Rangen werden Dir meine Beispiel nur so um die Ohren fliegen; man glaubt gar nicht, was für Gemeinheiten alles möglich sind. Das umgekehrte Rangen ist übrigens nur scheinbar umgekehrt; man muss nur wissen wo und warum es auftaucht.
Eine Tabelle kann ich für den "Normalfall" sicherlich erstellen.
Interessant sind aber gerade die Ausnahmen (kommt noch in den nächsten Tagen). Im Moment läuft die Feder.

ciao herw

die tabelle für den normalfall wär schon mal echt knüllig - denn intuiotiv ist das alles nicht gerade insbesondere mit punkto: umkehrung und bspw. switch/lists die scheinbar/tatsächlich invertiert empfangen. list-stelle 0 wird bei midi mit 127 und list-stelle 127 bei midi = 0 gewählt, unabhängig der range oder prop-einstellungen, ganz abgesen von den anderen tretminen und sonstigen wahnsinnigmachern in diesem kontext

[herw]

...die tabelle für den normalfall wär schon mal echt knüllig - denn intuiotiv ist das alles nicht gerade insbesondere mit punkto: umkehrung und bspw. switch/lists die scheinbar/tatsächlich invertiert empfangen. list-stelle 0 wird bei midi mit 127 und list-stelle 127 bei midi = 0 gewählt, unabhängig der range oder prop-einstellungen, ganz abgesen von den anderen tretminen und sonstigen wahnsinnigmachern in diesem kontext

ja das ist wohl nötig. Irgendwie scheint REAKTOR in diesem Punkt anders zu denken als Otto-Normalverbraucher

[carloskleiber]

Hallo, Herw, herzlichen Dank fuer das grossartige Workshop. Ich weiss viel mehr ueber die ganze Geschichte als vorher, wann ich mit diesem Thread angefangen habe:

http://www.nativeinstruments.de/forum_u ... hp?t=52177

Also ich finde die Moeglichkeiten von einfachen Send-Receive Module sehr interessant, und freue mich, sie irgendwann zu benutzen. Aber im konkreten Fall scheint mir doch besser, IC Sends anzuwenden. Ich meine das, weil ich ein seblstaendiges Instrument bauen will, erstmals wegen den Snapshot-Moeglichkeiten. Und auch, weil ich in diesem konkreten Fall (alle Parameter von einem Aerobic-Sound aus einem externen Instrument, via Knopfdruck, in Aerobic's Synth, in die oberstliegende Stimme, reinzuladen) keine Receptors brauche, die aus mehrere Quellen auswaehlen koennen, sondern Sender, die entscheiden koennen, wohin sie senden.
Leider faellt mir nichts einfacheres auf als 21 Distributors mit je 6 Ausgang (die 21 Parameter von einem Aerobic-Sound, (ohne Modulation und Sequencer), fuer alle 6 Stimmen) aufzuwaenden.
Gibt es aber vielleicht doch was eleganteres?
Gruesse,
carloskleiber

[herw]

Hallo, Herw, herzlichen Dank fuer das grossartige Workshop. Ich weiss viel mehr ueber die ganze Geschichte als vorher, wann ich mit diesem Thread angefangen habe:

http://www.nativeinstruments.de/forum_u ... hp?t=52177

Also ich finde die Moeglichkeiten von einfachen Send-Receive Module sehr interessant, und freue mich, sie irgendwann zu benutzen. Aber im konkreten Fall scheint mir doch besser, IC Sends anzuwenden. Ich meine das, weil ich ein seblstaendiges Instrument bauen will, erstmals wegen den Snapshot-Moeglichkeiten. Und auch, weil ich in diesem konkreten Fall (alle Parameter von einem Aerobic-Sound aus einem externen Instrument, via Knopfdruck, in Aerobic's Synth, in die oberstliegende Stimme, reinzuladen) keine Receptors brauche, die aus mehrere Quellen auswaehlen koennen, sondern Sender, die entscheiden koennen, wohin sie senden.
Leider faellt mir nichts einfacheres auf als 21 Distributors mit je 6 Ausgang (die 21 Parameter von einem Aerobic-Sound, (ohne Modulation und Sequencer), fuer alle 6 Stimmen) aufzuwaenden.
Gibt es aber vielleicht doch was eleganteres?
Gruesse,
carloskleiber

Ich sortiere mal das, was ich aus dem NI-Forum und aus Deiner Post entnehme:
Du möchteset Event-Signale zwischen zwei Reaktor-Instrumenten mit Hilfe der IC-Send austauschen.
Die Distributoren sind in der Tat sehr ermüdend und nervig, weil sie nicht wirkliche elegant für größere Entfernungen sind. Bei den IC-Sends muss man generell beachten, dass Sie einen Stepfilter eingebaut haben. D.h. jeder gesendete Event muss sich vom vorangegangenen unterscheiden. Das ist nicht wirklich ein Problem: man kann durch einen zusätzlichen (unbenutzten) Event diese Information ankündigen (Wert, z.B. -999999) und beim Empfang wieder ausfiltern.
Ohne Distributoren kann man mit einem Eventbus arbeiten. Ich habe einen solchen Bus entwickelt, der Eventsignale beliebig vieler Quellen für beliebig viele Empfänger über eine (!) Leitung (das kann wohl auch ein IC-Send sein) verarbeiten kann. Der Bus ist getestet und liegt auf meinem Laptop. Da ich das Konzept in der nächsten Woche veröffentlichen will, muss Du Dich noch ein paar Tage gedulden. Es hat keinen Zweck, diesen Bus ohne Beispiel (ein modularer Synthesizer) und ohne Anleitung herauszugeben. Du findest hier im Forum einen Thread darüber: eventbus

ciao herw

[herw]

I habe gerade nochmals mit einem anderen Ensemble versucht über IC-send/receive events zu übertragen. Das ist problematisch, da IC-Send in der Tat nur wechselnde events versendet. D.h. würde man einen Strom von 1er Triggern senden, dann kommt nur einer an. Das kann man mit dem oben geschilderten Trick umgehen. Ein weiteres Problem scheint zu sein, dass das IC-Send nicht richtig übersetzt: ich habe sowohl IC-send wie auch IC-Receive auf denselben Bereich eingestellt und abwechselnd die Werte 1 und -99 gesendet: Bei der Anzeige wurde dann daraus "krumme Werte". Den Bereich muss man auf -9999 ... +9999 begrenzen. Dann funktioniert es. Die genaue Grenze habe ich noch nicht ausprobiert.
Also solange Du nicht ganz abartige Werte sendest (100000 ), sollte das funktionieren.


ciao herw

[carloskleiber]

Hallo,
ich freue mich sehr auf den Eventbus, und warte geduldig...
Schoen, Dein Umweg wegen dem Stepfilter-Problem, hat mich diese Begrenzung zwar noch nie gestoert, werde mir aber merken. (Hoechtens werde ich ein bisschen enttaeuscht sein, dass ich die Loesung nich alleine gefunden habe )

Ein weiteres Problem scheint zu sein, dass das IC-Send nicht richtig übersetzt: ich habe sowohl IC-send wie auch IC-Receive auf denselben Bereich eingestellt und abwechselnd die Werte 1 und -99 gesendet: Bei der Anzeige wurde dann daraus "krumme Werte". Den Bereich muss man auf -9999 ... +9999 begrenzen. Dann funktioniert es. Die genaue Grenze habe ich noch nicht ausprobiert.
Also solange Du nicht ganz abartige Werte sendest (100000 ), sollte das funktionieren.

Meinst Du, dass IC Send-Receive mit den Werte nicht immer praezies umgehen? Das allerdings habe ich auch erfahren! Ich habe halt nicht mit so extremen Wechel ausprobiert, einfach ein Knopf solle der Bewegung vom einem anderen durch internen Verbindung folgen... und oft ist die zweite Wert (eins) daneben. Und die Loesung waere, die Grenzwerte von ICSends auf -9999 und 9999 zu stellen? Hm. Habe etwas falsch verstanden.

Uebrigens, ja, es stimmt, was ich zu bauen versuche: ein Instrument, einfach um Events (Werte.. Parameter..) zu sparen, und durch interne Verbindung hin und zurueck zu senden.

Danke fuer die Ideen,
carloskleiber