Phrasendrescher

[herw]

Ah, mit Privatleher macht das doch gleich viel mehr Spass;-) Danke!

Das Problem ist, das ich meine gedruckte Bibliothek in meiner alten Bude (Lagerhalle)
0,8 megameter von meinem jetzigen Standort habe und das Core-PDF nur auf englisch
(beim letzen Update gabs wohl nur das GetStart lokalisiert, oder ich hab beim PDF-Aufräumen fäslchlicherweise die Deutschen gelöscht?) verfügbar ist.
Und da Core und English simultan zuviel meine Synapsen ist, werde ich also wohl schon bald deine Geduldskapazität sprengen;-)

naja, ich habe auch mein eigenes Projekt laufen und da möchte ich schon weiterkommen; ich antworte also nur auf prinzipielle Fragen, die möglichst viele Leser interessieren könnten; ganze Ensembles oder große Teile davon kann ich nicht mal eben erstellen; dazu fehlt mir die Zeit und Lust. ich kann dann nur allgemeine Hinweise geben.

-----
Aber mal weg von Core. Zu meinem Projekt drängt sich mir grad ne Frage auf, die ich bislang nur testweise und äusserst unbefriedigend gelöst bekam:
Ich habe diverse monofone Seqeunzer-Einzelstränge die am Signalkettenende monofon Pitch und Gate ausgeben. Die Pitch/Gate Daten münden in ein Note-Out-Modul.
Ich habe also verschiedene "monofone" Sequenzer (defacto ist jeder 32ig-stimmig aber die Voices werden horizontal für Positions-Daten, etc. verwendet - es gibt also keine vertikale Gleichzeitigkeit sprich "Akkorde" pro Unit) wobei jeder sein eigenes Note-Out speist.
Im polyfonen Test-Synth kommen also gleichzeitig über die diversen Note-Outs unterschiedlcihe Pitches und Gates an. Das arbeitet natürlich so präzisse wie ein 6-mal geflicktes Midi-Kabel. Die Gates werden munter durchwürfelt, teilweise verschluckt, vergessen… In der Praxis also unbrauchbar.

Im Prinzip bräuchte ich einen soliden Stimmen-Vereiner, der die diversen monofonen Signal-Paare (Pitch+Gate) zusammenfasst und dann sauber polyfon (als zusammengehörige Paare) ausgibt, also ein invertiertes Event-All.

tut mir leid; du kommst nicht darum, englische Quellen zu lesen: trotzdem jetzt hier der Lösungshinweis
dein Problem lässt sich lösen, indem man jedem Eventpaar (pitch|gate) (wir sprechen von einer Nachricht (message)) zusätzlich eine Adresse mitgibt, also zum Beispiel eine Adresse (Nummer) für den sendenden monophonen Sequenzerausgang. Das sieht dann folgendermaßen aus (#,2,p,g), also ein 4-Tupel wie der Mathematiker sagt.
Diese Nachricht enthält also die Adresse #, die Anzahl 2 der folgenden Daten und die eigentlichen Daten p (pitch) und g (gate).
Diese kann man in eine EventCorecell senden und dort abhängig von der Adresse wieder auf einzelne monophone Eventausgänge routen. Außerhalb der Corecell muss man diese wieder über to-voice-Module einem polyphonen eventsignal zuordnen.
Ich habe hier den Datentyp Nachricht erwähnt, weil er die normalerweise riesige Kabelharfe in der Struktur vermeidet. Der Datentyp Nachricht (message) wird vom partials framework von unserem Mitglied Max Zagler (Entwickler bei NI (unter anderem auch Mitentwickler am MONARK)) behandelt. Dazu musst du dich aber in die englischen Begleittexte (speziell multiplexing) einlesen. Leicht verständlich, aber das ganze Handling ist schon anspruchsvoll. Es gibt hierzu auch einen thread im DRF: eventbus mehr konkrete Tipps kann ich nicht geben, da dein Projekt nicht mal so eben nebenbei gelöst werden kann.
Ich würde für mich selbst schätzungsweise eine Woche Arbeit veranschlagen, wenn ich es so durchführen würde.

Ich hab jetzt 3 Stunden nachgedacht, der beste Gedanke war hier nachzufragen:-(

im Prinzip schön, aber es ist dein Projekt; ab hier ist Eigenarbeit angesagt.
Manche Projekte laufen über Jahre (siehe Projekt von MvKeinen und mein „kleines” Projekt des modulars). Manche Lösungen wachsen auch; wenn ich vergleiche, mit welchem Ansatz ich 2004 gestartet bin und wo ich jetzt stehe, dann darf man das nicht in Stunden rechnen. REAKTOR-Programmierung muss man halt als ein dauerhaftes Hobby sehen.

ciao herw und viel

[Eventmanager]

Was? Hier ist Eigeninitiative gefordert?? Also ehrlich!!!

Jut, dann werd ich wohl wohl oder übel simultan mein englisch mit updaten:-)
Hat ja auch was!

Bei meinem Problem bin ich übrigens doch noch ganz gut weiter gekommen - mit ner Armada Value/StepFilter/Router/Order lässt sich auch ohne Core so einiges bewerkstelligen:-)

[herw]

Was? Hier ist Eigeninitiative gefordert?? Also ehrlich!!!
[...]

jau, und dann kann ich endlich auch mal für mich was tun; ich denke nämlich, dass mein modular framework version 3.0 dieses Wochenende zum ersten Mal für einige Container laufen wird.

PS: Durch deine 10 Beiträge bist du schon mal zum „user” aufgestiegen!

[Eventmanager]

PS: Durch deine 10 Beiträge bist du schon mal zum „user” aufgestiegen!

Du weisst worauf sich der Titel reimt;-)

Na dann, frohes Schaffe! Hast du eigentlich ne kleine Core-Basis-Bibliothek - also Makros, von denen du meinst, die sollte man unbedingt anstelle Prim verwenden,
oder die Prim gut aufbohren wie bspw. das FlipFlop?

Aber ich glaube ich werde dieses WE ne ziemlich rigide Computer-Diät halten! Hab leider nen Hang zur Prokrastination und das Monatsende naht, auweia

[herw]

PS: Durch deine 10 Beiträge bist du schon mal zum „user” aufgestiegen!

Du weisst worauf sich der Titel reimt;-)

Na dann, frohes Schaffe! Hast du eigentlich ne kleine Core-Basis-Bibliothek - also Makros, von denen du meinst, die sollte man unbedingt anstelle Prim verwenden,
oder die Prim gut aufbohren wie bspw. das FlipFlop?
[...]

ja : core additions v2.3 und irgendwo habe ich auch mal einige mathematische Logik-Funktionen in die library gestellt, aber auch wieder gelöscht. Ich müsste mal selbst meine Library ordnen.

[Eventmanager]

hab mir deine Zellen gelutscht, aber das sind ja nur Ossis, oder?
Ich dachte eher an kleine Event-Helfer (Module). Trotzdem danke.

[Eventmanager]

So, hab mir mal das 2te Makro angeschaut:
Das Latch verzögert einfach, bis ein Event via Write ans Read gelangt.
Warum eigentlich nicht direkt am Read? Und warum hast du das Write nicht mit 0-Konstante versehen?

Die Sorts dürften klar sein, analog zu Prim.

Das große Mysterium sind die beiden "Ranger".
Erst dachte ich, die invertieren die Signale also bspw. bei 0-128 wird die 128 zur 0, die 127 zu 1…
aber das tun sie nicht. Ich hab ein bisschen mit den Brüdern rumexperimentiert, aber BEIDE schleifen
sowohl isoliert als auch im Verbund schnöde die Values durch, völlig egal was ich am Latch oder Compair für Konstanten eingebe. Wozu die Teile also?

-------------------

Woran ich mir gerade die Zähne ausbeisse, ist ein Konstrukt, das den Note-Pitch separiert (0-23) NICHT zu diesen Modulen, alles darüber ja.
Meine ganzen Pitch/Gate/Voice-Seperator/Stepfilter Konstrukte werden im Eventwatcher NICHT als Trigger gelistet (in der infobox am wire passiert zwar was, aber der eventwatcher listet diese rotation nicht als eigenständige trigger), in deinem Teil kommt aber trotzdem immer irgendwas an, resp. hinten raus. Wie geht denn sowas? Magie???

[herw]

So, hab mir mal das 2te Makro angeschaut:
Das Latch verzögert einfach, bis ein Event via Write ans Read gelangt.
Warum eigentlich nicht direkt am Read? Und warum hast du das Write nicht mit 0-Konstante versehen?

Bild 1.jpg

Latch-Module sind fast die wichtigsten Module in Core, die es gibt; sie sorgen dafür, dass die Gleichzeitigkeit von Events erhalten bleibt oder erzeugt wird. Gleichzeitigkeit ist etwas, das es nur auf Core-Ebene gibt: es bedeutet, dass alle Berechnungen, die zeitgleich erzeugt werden, auch zeitgleich durchgeführt werden. In primary ist das zum Beispiel niemals erfüllt. Eine einfache Addition desselben Werts zum Beispiel bewirkt zwei Events:

Bild 3.jpg

Der Regler hatte vorher den Wert 0. Erhöhe ich ihn auf 0,1, dann wird zunächst an einem Eingang 0+0,1=0,1 gerechnet und anschließend noch der Wert des anderen Eingangs addiert. Würde man vom Ausgang des Addierers irgendwelche Verzweigungen abhängig machen, dann könnte es passieren, dass, bevor die Rechnung vollständig ausgeführt, ist, schon in folgenden Rechnungen Verzweigungen geöffnet werden usw.. Hinzu kommt noch, dass noch nicht einmal klar ist, welcher Addiereingang zuerst behandelt wird; das hängt nämlich davon ab, in welcher Reihenfolge der Programmierer die beiden Kabel gesetzt hat. Meistens ist das nicht folgenschwer aber im Prinzip chaotisch. Daher vermeide ich, so weit es geht, Rechnungen in primary.
Nun auch in Core muss man die Gleichzeitigkeit beachten; wenn man dies allerdings mal erreicht hat, dann sind alle Rechnungen und logischen Entscheidungen so, wie man es sich im Kopf vorstellt; core entspricht dem natürlichen menschlichen Denken, denn wir denken immer parallel, also mit gleichzeitigen logischen Schlussfolgerungen.
Da primary Gleichzeitigkeit nicht kennt, treten die vier Midiwerte der Tonhöhe nicht gleichzeitig an den Eingängen auf. Das ist leider nicht zu vermeiden, da primary und core eigentlich nicht wirklich zusammenpassen. Besser wäre es, auf primary-Ebene würden dieselben Gesetze wie in core gelten.
[klugscheißer-modus an]
mit diesem Grundsatz nerve ich fortlaufend die REAKTOR-Entwickler; da bin ich äußerst hartnäckig; das ist aber nicht einfach zu bewerkstelligen, abgesehen davon, dass es auch bei NI wohl immer noch Verfechter gibt, die auf primary Stein und Bein schwören (siehe manche professionellen Ensembles aus der offiziellen REAKTOR-library, neuere Entwicklungen wie der Monark kommen ohne core gar nicht mehr aus bzw. sind nur dort möglich). Auch bei vielen Usern herrscht unverständlicherweise eine lang gepflegte Abneigung gegen core.
[/klugscheißermodus aus]
Die latch-Module „verzögern” wie du richtig bemerkst die Weitergabe, bis ein gemeinsamer Clockevent sie weitergibt. Dann sind alle vier Midisignale synchron.
Die read/write-Module sind über OBC-Signalwege verbunden. Dabei ist die Reihenfolge wichtig. Beide Module haben dadurch einen gemeinsamen Speicher. Man kann noch mehr soche Module an dieselbe Kette schließen. Der obere Eingang schreibt den Midipitch in diesen Speicher. Der untere Clockeingang liest diesen Wert dann aus.
Auf primary-Ebene entspricht das dem value-Modul, jedoch nicht, wenn man alle vier Midiwerte gleichzeitig takten wollte.

Die Sorts dürften klar sein, analog zu Prim.

wenn man von der Nicht-Gleichzeitigkeit absieht, die in primary eine Unmenge zusätzlicher Events erzeugen würde. Sicherlich kann man das auch anders gestalten. Ich habe es mal so gemacht, dass man mit derselben Anordnung schnell auch acht Midinoten sortieren könnte. Bubblesort wiederum ist nicht so einfach; das geht mit partials framework, müsste ich mich aber auch erst noch hineindenken.

Das große Mysterium sind die beiden "Ranger".
Erst dachte ich, die invertieren die Signale also bspw. bei 0-128 wird die 128 zur 0, die 127 zu 1…
aber das tun sie nicht. Ich hab ein bisschen mit den Brüdern rumexperimentiert, aber BEIDE schleifen
sowohl isoliert als auch im Verbund schnöde die Values durch, völlig egal was ich am Latch oder Compair für Konstanten eingebe. Wozu die Teile also?

Bild 2.jpg

Das ist überhaupt kein Mysterium, denn du hast ja gefordert, dass Midinote OFF (pitch=0) oben stehen soll, also den höchsten Pitchwert 127 noch „übertrumpfen soll”. Daher habe ich ihn durch das erste Makro auf 128 gesetzt, und, damit die Ausgabe wieder ordentlich 0 anzeigt, dann wieder zurückgesetzt. Alle anderen pitch-Werte bleiben unverändert.

-------------------

Woran ich mir gerade die Zähne ausbeisse, ist ein Konstrukt, das den Note-Pitch separiert (0-23) NICHT zu diesen Modulen, alles darüber ja.
Meine ganzen Pitch/Gate/Voice-Seperator/Stepfilter Konstrukte werden im Eventwatcher NICHT als Trigger gelistet (in der infobox am wire passiert zwar was, aber der eventwatcher listet diese rotation nicht als eigenständige trigger), in deinem Teil kommt aber trotzdem immer irgendwas an, resp. hinten raus. Wie geht denn sowas? Magie???

heute abend nicht mehr und nur, wenn du deine Frage durch ein Bild oder kleines Ensemble ergänzt, sonst wird es für mich zu zeitaufwändig