send / ic-send / internal connection

[Thala]

hallo.
mag mir bitte jemand den unterschied, vor- und nachteile und typische einsatzgebiete erklaeren?
auch in bezug auf massiven einsatz im ensemble (tauchen probleme auf, wenn man 100+ davon verwendet.
und das verhalten bei copy/paste und speichern von makros mit solchen verbindungen.

vielen lieben dank schon mal!
thala

[herw]

hallo.
mag mir bitte jemand den unterschied, vor- und nachteile und typische einsatzgebiete erklaeren?
auch in bezug auf massiven einsatz im ensemble (tauchen probleme auf, wenn man 100+ davon verwendet.
und das verhalten bei copy/paste und speichern von makros mit solchen verbindungen.

vielen lieben dank schon mal!
thala

IC-Send-IC-receive-Verbindungen sind grundsätzlich monophon und zur Übertragung von Controllerdaten gedacht.
Send-Receive-Verbindungen können auch polyphon sein und auch Audiodaten übertragen.

Das Kopieren bei Send-Receive-Verbindungen ist eine Katastrophe, da die Eintragungen sich verschieben und man sie von Hand ändern muss, falls es auf die Reihenfolge ankommt (siehe im Modularensemble RUHR). Seit Jahren mahne ich dieses Dilemma an, ohne dass etwas geschieht.
Wenn man nur mal eben eine entfernte Verbindung wünscht und Kabelsalat vermeiden möchte, dann ist das sehr praktisch.
Wegen des Kopiermankos benutze ich send-receive überhaupt nicht mehr und bin auf das Bussystem von partials framework umgestiegen (nur Kontrollerevents).
Die Audioverarbeitung geschieht bei mir ausschließlich in Core, wo dies alles kein Problem ist, seit es bundles gibt.

[Quietschboy]

Ich pflege mit beiden so eine art Hassliebe.
IC brauch man halt unbedingt, wenn man ein GUI Element fernsteuern, oder drahtlos in ein anderes Instrument übertragen möchte.
Nachteil: nur mono, Step-Filter eingebaut, Ringeldingdong mit den Ranges..., keine Alternative!

Send-Receive ist eigentlich superpraktisch. Erstmal... Bis man dann irgendwann (viel) später da Ens mal wieder aufmacht und dabei voll gegen die Wand fährt, weil man absolut keine Chance hat die Verbindungen nachzuvollziehen. (R6.2).

Deswegen bleibe ich mit Send Receive immer nur in einem Macro. Ausnahmen die global abrufbar sein sollen, wie z.B. Clocks oder wirklich essentielle, globale Parameter, bestimmen die Regel.
Weiterer, saudoofer Nachteil: CUT/Paste macht die Verbindung futsch!

[Quietschboy]

Ach ja, Audio bei Send-Receive:
Einmal Audio, immer Audio. Und zwar global auch für eigentlich als Event-gedachte Send-Receives!
Also entweder oder! Musst du entscheiden.

[herw]

Ach ja, Audio bei Send-Receive:
Einmal Audio, immer Audio. Und zwar global auch für eigentlich als Event-gedachte Send-Receives!
Also entweder oder! Musst du entscheiden.

Ja, das finde ich auch verwirrend. Ich denke, dass NI das dermaßen vermurkst hat, dass sich keiner der Entwickler wieder daran traut.
REAKTOR dürfte am Ende der Fahnenstange sein, und wenn es gut (für uns) läuft, dann schreibt NI eine entsprechende Software von Grund auf neu.
Übrigens gibt es für dieses Problem einen umständlichen Trick:
Du legst zu Beginn einen event-receive mit Hilfe einer Eventtable an.

event receive 1.jpg

Wenn du später audio receives erzeugt hast, kannst du immer noch die receive-Eventtable-Verbindung duplizieren, neu verkabeln und dann (!) die überflüssige eventable löschen.

event receive 2.jpg

event receive 3.jpg

[Thala]

vielen lieben dank ihr beiden.
gibt es auch besonderheiten beim internal connection protokol?

@quietschboy
du sprichst oben explizit reaktor 6,2 an. war das frueher mal besser oder seid ihr schon 6,3 am testen :E

[Quietschboy]

du sprichst oben explizit reaktor 6,2 an. war das frueher mal besser oder seid ihr schon 6,3 am testen :E

haha, nene, aber die Hoffnung stirbt ja bekanntlich zuletzt.

[128bpm]

...und wenn es gut (für uns) läuft, dann schreibt NI eine entsprechende Software von Grund auf neu.

Das wird wohl nie passieren. Ich glaube kaum, dass NI da jemals einen positiven Kosten-/Nutzenfaktor sieht.