InterPHase by MvKeinen

[MvKeinen]

die Polydisplays machen mich fertig

ich werd morgen mal hier mein Problem in form eines kleinen Ensembles posten... hab mich jetzt 3 Tage lang im Kreis gedreht. ich muss irgendwie eine Mouse area in 2 Zonen aufteilen. das klappt zwar, aber immer wenn ich die Zone wechsle gibt es "Datenmüll"...

[herw]

ja ein einfaches Problemensemble wäre jetzt nicht schlecht.

bin gespannt

[MvKeinen]

Ich hab jetzt mal ein kleines Testensemble gemacht um das Problem einzugrenzen.

test_Seq01.ens

Die Grafik zeigt das Panel in den zwei Edit-zuständen:

Seq_test_panel.jpg

weiss: Pitch
gelb: Gate
türkis: Velocity

die Darstellung wird mit 2 Multidisplays und 3 Polydisplays realisiert:

Parent.jpg

Die Linien werden von den beiden unteren Multidisplays dargestellt. Hierzu werden die Indices bei Betätigung der Regler "Lng->" (Anzahl der Steps -> Anzahl der vertikalen Linien) bzw. "Rng->" (Tonumfang -> Anzahl der Horizantalen linien) per Iteration durchgezählt. siehe nächstes Post.

[MvKeinen]

Als Beispiel für die Makros links von den Polydisplays erläutere ich mal das Pitchmakro. Dies ist im Letzter Anhang des vorigen Posts zwischen "Routing" und dem Pitch-polydisplay zu sehen:

pitch.jpg

Corecell "User Input":

- Interpretation des Userinput. Die daten der Mousearea werden umgerechnet und stehen an den Ausgängen "i" (Index/X-Achse) und "W" (Wert/Y-Achse)
- die anderen Ausgänge bedienen ein Iterationsmodul welches für die "right-drag" funktion die Indices liefert. Wenn man auf dem panel mit der rechten Maustaste die Sequenz editiert kann man vielen Steps den gleichen Wert zuordnen. So kann man sehr schnell lange Noten eingeben, bzw. bei vielen Steps hintereinander die exakt gleiche Gatezeit oder Velocity einstellen. Dies funktioniert in beide richtungen.

2 Snap Valua Arrays?:

Dies ist notwendig, weil die Operationen die im "Großen" Sequenzeresemble getätigt werden vom "Brain" kommen, welches wiederum von den SVAs befüttert wird. Um einen Loop zu vermeiden muss hier ein zweites SVA her das die Events die am Eingang anliegen nicht durchschickt. (No Thru) Den Trick hab ich im Modularthread gelernt . In diesem Testensemble hab ich das mal drinnen gelassen, damit es später einfacher wird das wieder zu übertragen.

Ob die Multidisplays dargestellt werden oder nicht wird über die Transparenz der Balken geregelt. Liste "->Edit"

Jetzt zum Problem:

Die Corecell Routing (Zu sehen im letzten Anhang "Parent" des vorigen Posts) routet die Events die von der Mousearea kommen an die jeweiligen Verarbeitungsmakros die die Werte an die Polydisplays weitergeben.

routing.jpg

Die Liste "Edit->"(Eingang:ED) auf dem Panel routet sozusagen die Events X,Y,bl,br von der Mousearea entweder zu Pitch (Ausgänge 1-4) oder zu Gate&Velocity (Ausgänge 5-12). Gate&Velocity teilen sich also eine Mousearea was für die Platzsparende Darstellung wichtig ist.

Wenn man nun auf Dem Panel Gate/Velo zum editieren aktiviert (Liste "Edit->") funktioniert zwar die Dateneingabe, jedoch wird beim Wechsel zwischen Gate und Velocity fast immer der neue Wert bzw. Index noch zu dem vorher editierten Bereich geschickt:

um das zu rekonstruieren bitte folgendes machen:
- Liste "Edit->" auf Gt/Velo stellen
- Velo editieren (untere Hälfte)
- Gate editieren (obere Hälfte)

beim letzten schritt passiert es fast immer, dass ein velocitywert verändert wird.

GRUND:
die Ausgänge bl und br der Mousearea geben immer erst NACH den Ausgängen X und Y Daten aus. Dh die Umschaltung erfolgt erst nachdem die ersten Werte von X und Y kommen. Ich brauche aber bl oder br um zu bestimmen in welcher Zone (Oben oder unten) der Mousearea sich die Maus in dem Zeitpunkt der ersten betätigung befindet. sonst würde bei einem "überstreichen" der Maus von der einen in die andere Zone innerhalb eines Editierungsvorganges das jeweils andere polydisplay mit daten beschickt. Dann wäre das gemütlichen "Alles auf Maximal bzw. Minimal" nicht mehr möglich.

Was ich besonders doof finde ist, dass ich den Grund des Problemes kenne, aber keine Lösung finden kann.

Ich hoffe ich konnte das irgendwie rüberbringen was ich meine.

Gruss

[herw]

Ich gehe im Folgenden nur auf das Problem der event-Sortierung ein.

Das Maus-Feld (mouse area) reagiert im Original so, dass zunächst die X- und Y- Koordinaten gesendet werden und dann der MausOn-Event; danach werden, solange die Maus gedrückt gehalten wird, nur noch X- und Y-Werte gesendet und letztendlich der MausOff event.

Es soll umgekehrt gesendet werden: zunächst der MausOn-Event, dann alle X-, Y-Events und zum Schluss der MausOff-Event.
Die folgende EventCoreCell wird direkt hinter das Maus-Feld ergänzt.

test_seq01.jpg

Wichtig ist hierbei, dass die Ausgänge bl und br mit den MausOn/Off-Events oben liegen und erst darunter die X-Y-Ausgänge.
Kritisch ist eigentlich nur der allererste MausOn-Event. Er erledigt zweierlei Aufgaben:
zum einen filtert er alle Daten aus, die vor dem MausOn-Event erfolgen. Die ersten X-Y-Werte werden zunächst durch Latch-Module abgelegt. Dann schickt der MausOn-Event diese nun fehlenden Daten durch ein Latch-Modul nachträglich auf die X-Y-Ausgänge.
Durch das Latch-Modul erreicht man, dass beim MausOn-Event die eingegangenen X-Y-Werte und der MausOn-Event logisch zeitgleich behandelt werden. Damit der MausOn-Event als erster gesendet wird, muss sein Ausgang oberhalb der X-Y-Ausgänge liegen. Der Rest ist dann nicht mehr problematisch.

Trotzdem funktioniert die Schaltung insgesamt noch nicht richtig; das ist aber ein anderes Problem; ich denke du solltest darüber nachdenken, dass bl und br gate-Events sind und insofern eventuell zweifach in den folgenden Makros Werte-Events forcieren.

ciao herw

[MvKeinen]

Wow, Jetzt wo ich das sehe, frage ich mich warum ich mir daran so die Zähne ausgebissen habe und ich nicht selber drauf gekommen bin. Aber so ist das bei mir, weil ich mit Core noch nicht solange zu tun habe. Super. ich habe das mal so implementiert und es funktioniert genauso wie gewünscht. Vielen Dank für den Tipp.

Trotzdem funktioniert die Schaltung insgesamt noch nicht richtig; das ist aber ein anderes Problem; ich denke du solltest darüber nachdenken, dass bl und br gate-Events sind und insofern eventuell zweifach in den folgenden Makros Werte-Events forcieren.

OK das ist mir noch nicht ganz klar. Durch den Einsatz des Seperators in deiner Lösung erfolgt also die Umwandlung von Gate in Trigger, da das "Gate-off", also der Wert Null von br und bl rausgefiltert wird. Nun verwende ich im folgenden Makro "routing" bl und br um das korrekte Folgemakro mit den Daten zu beschicken. Hier wird wieder eins UND null geschickt, was nun aber durch die gewährleistete Gleichzeitigkeit keine Auswirkung hat. Ich werde trozdem jetzt die null rausfiltern, weil mir das dann "sauberer" erscheint. Ist es das was Du meinst, oder fehlt mir da was im Verständnis von Trigger und Gate?

Vor allem vielen Dank für die Hilfe.

Gruß

[herw]

bl und br werden immer noch wie gewünscht durchgelassen, d.h. beim Loslassen der Maus erfolgt noch der 0-Event. Lediglich der MausOn-Event ist der erste (statt bisher der dritte Event).
Ob Du die Null herausfiltern kannst, hängt von der angehängten Logik ab. Über den zu erwartenden Signalfluss, insbesondere beim Wechsel des Mausbereichs, musst du dir vorher grundsätzliche Gedanken machen; beides, ob als gate-event (1 und 0) oder nur als trigger (nur 1-event), kann sicherlich zu einer erfolgreichen Lösung führen. Das ist Geschmacksache und Programmierstil.

Durch den häufigen Gebrauch des Eventbusses denke ich eigentlich nur noch in Adressen und Werten oder Werteblöcken.

[herw]

Vielleicht ein kleiner Tipp beim Gebrauch der mouse area:
Wenn ich dein Konzept richtig verstehe, möchtest du die mouse area zweifach benutzen: einmal zeigt sie nur eine Balkengrafik, ein anderes Mal zwei Balkengrafiken.
Du unterscheidest beim zweiten Fall durch die rechte und die linke Maustaste.
Ich habe bei meinem modular m1 festgestellt, dass die Normalbenutzer dies nicht „verstehen” und offenbar nicht gerne benutzen.
Eine Alternative wäre es, die gesamte mouse area unabhängig vom Gebrauch als ein Koordinatensystem (mit ganzen Zahlen) aufzufassen und dann in Abhängigkeit des gewählten Modus und der angezeigten Koordinaten entsprechende Werte in die zugehörige Eventtable zu schreiben.
Aus den gewählten Koordinaten lässt sich durch eine einfache Abfrage die jeweils zu bedienende Eventtable auswählen. Es muss dann lediglich beim y-Wert eine Wertebereichsanpassung berechnet werden. Dies erscheint mir sicherer und einfacher zu händeln.

Aber ich habe mich noch nicht tief in dein Konzept hineinbegeben, daher nur dieser oberflächliche Tipp.

Ich arbeite gerade an einem sehr einfachen Sequenzer, ähnlich Doepfers Dark Time.

ciao herw

[MvKeinen]

Vielleicht ein kleiner Tipp beim Gebrauch der mouse area:
Wenn ich dein Konzept richtig verstehe, möchtest du die mouse area zweifach benutzen: einmal zeigt sie nur eine Balkengrafik, ein anderes Mal zwei Balkengrafiken.
Du unterscheidest beim zweiten Fall durch die rechte und die linke Maustaste.

nicht ganz: im zweiten Fall unterscheide ich durch die Position der Maus im Zeitpunkt des Links- ODER Rechtsklicks (obere/untere Hälfte der Mouse Area) deswegen war die Gleichzeitigkeit von X,Y,bl und br so wichtig, was jetzt wunderbar funktioniert mit Deiner Lösung. Der Rechstklick ist nur für eine Spezialfunktion da: Per Rechtsklick und Ziehen kann man über mehrere Steps den gleichen Wert eingeben. Da wird eine Iteration ausgelöst die auf alle Steps innerhalb des Bereiches den aktuellen Y-Wert schreibt.

Durch die Lösung oben Ich hab jetzt die Polydisplays viel besser im Griff, war aber viel Arbeit und wird auch weiterhin noch viel Tuning bedeuten. Arbeite gerade auf ne spielbare Version hin und muss dann noch ein Version des Sequenzers ohne Pitch bauen. Denn In dem Projekt InterPHase sind 2 Pitch/Gate/Velo und 4 Gate/Velo Sequenzer vorgesehen.

In einem Späteren Versuchsaufbau müssen dann Interaktionen zwischen Sequenzern getestet werden:
- Restart nach X Durchläufen
- "One-shot" Modus (Interessant für Sequenzen die "restarted" werden)

- Unterscheidung Sync und "Triggermodus" (Die Steps werden zB durch einen LFO weitergeschaltet)

Was mich dann auf einen Teilaspekt des Projektes bringt, (LFOs) wo ich am meisten Probleme haben werde. Die Sachen die danach kommen sind schon viel ausgereifter aber an den LFOs habe ich in Reaktor seit 4 Jahren nichts mehr gemacht.

Aber im Sequenzer gibts immernoch ne ganze Menge zu tun.

[MvKeinen]

Ich bin jetzt Fan von den Multidisplays. Nach anfänglichen Schwierigkeiten bin ich jetzt (etwas) besser in der Behandlung von Polyphonen Events, was ja bei den Displays nicht unpraktisch ist

Bin jetzt aber in eine "Falle" geraten in der ich mich bei Reaktor schon oft befunden habe:

Je früher man bei einem Projekt die GUI mit einbezieht desto Aufwändiger ist jeder Schritt den man tut und dauert teilweise das 5fache der Zeit. Ich muss das aber so machen, weil meiner Meinung nach die GUI entscheidet, ob das Ergebnis ein Musikinstrument wird, oder eine Ansammlung von Knöpfen. Auch im Entwicklungsprozess ist die GUI entscheidend. Ich beschäftige mich dann ausschließlich mit dem Panel und versuche Reaktor als das was es ist zu vergessen und nur das Instrument und das musikalische Spielen zu sehen. Nach einiger Zeit fällt mir dann oft eine bessere (musikalischere) Plazierung der Bedienelemente oder eine effizientere Funktionalität ein. Was die "Projektdauer" betrifft muss ich also meine Erwartungen etwas herunterschrauben, was OK ist.

So sieht das Ding jetzt aus. Im Betrieb sieht man noch ein Lauflicht.

Seq1119P.jpg

Seq1119.jpg

Der Sequenzer ist nun um einiges weiterentwickelt, die Struktur ist vereinfacht. Später diese Woche werde ich wohl die vorlerst letzte Version des Seq hochladen und eine ausführliche Beschreibung des Konzeptes machen. Danach wird das Testensemble mit den nächsten grossen Teilaspekt, den LFOs erweitert. Hier will ich dann Wechselwirkungen zwischen LFOs und Sequenzer testen:

LFO -> Sequenzer:
- Stepweiterschaltung bei Nulldurchgang des LFOs

Sequenzer -> LFO
- Modulation der LFO rate/Symmetrie
- Gate des Sequenzers restarted den LFO

[MvKeinen]

uiuiui,

Ich muss wohl so einiges neu überarbeiten. Die Polydisplays haben einige Sachen notwendig gemacht die nun Probleme bei der Initialisierung machen. Dazu muss ich wohl sehr weit ausholen, denke aber dass ich dadurch so einiges erfahren werde was mein Reaktorwissen etwas vertiefen wird. Habe in den letzten Tagen viel Zeit mit Beispielen aus der Userlib verbracht, vor allem dieser Plasmasequencer der bei dem genialen mx20 Basslinesynth von James Walker dabei ist hat einige Anlagen die ich noch verstehen muss, scheint sehr interessant zu sein.

Ich vermute auch, dass ein paar Lösungen im Bezug auf Initialisierung im Nachbarthread "Eventbus" interessant für mich sind. Es könnte sein, dass die Lösung mit dem Ordermodul bei dem nur der zweite Ausgang genutzt wird meine Probleme lösen, jedoch muss ich da Grundlagenforschung machen was einige Zeit dauern wird. Auch weil das Manual für mich oft erst dann was bringt wenn ich wirklich viel Zeit damit verbringe. Ich muss da oft Passagen 4-5mal Lesen.

[herw]

[...] Ich muss da oft Passagen 4-5mal Lesen.

öfters nicht? Manches habe ich bestimmt schon 20-mal gelesen. Und dann gibt es von irgendwoher einen Tipp und dann denke ich: ach, so war das gemeint. Es gibt ganz viele interne Vorgaben, die nirgendwo vermerkt sind und die man nur durch Zufall irgendwoher mitbekommt.
Die Initialisierung ist ein ganz böses Thema und je tiefer man eindringt, um so dringlicher wird die Notwendigkeit, dass da mal gründlich aufgeräumt wird - vielleicht in REAKTOR 7.5?

[KlangRaum]

… Manches habe ich bestimmt schon 20-mal gelesen. Und dann gibt es von irgendwoher einen Tipp und dann denke ich: ach, so war das gemeint. Es gibt ganz viele interne Vorgaben, die nirgendwo vermerkt sind und die man nur durch Zufall irgendwoher mitbekommt …

[Ironie]
Es gibt auch gewisse Dinge im Rahmen der Reaktorforschung die niemals fertig werden Egal wie oft man liest... oder welche Tips man noch einarbeitet. Man kann einen Reaktor-Rechner mit einer Art Biotop vergleichen: Einmal kann sich darin ein dynamisches Eigenleben entwickeln, andererseits mutiert es auch mal von Version zu Version

Ich hab mich längst damit abgefunden Täkit Isie

Gruss
Peter

[/Ironie]

[herw]

[[...]

Ich hab mich längst damit abgefunden Täkit Isie

Gruss
Peter

[Altenheim]ach ja [/Altenheim]

[KlangRaum]

[Altenheim]ach ja [/Altenheim][/quote]
Tjaaaaa..... Dann lass uns mal den Seniorenstift rocken und der Altenpflegerin innen Hintern kneifen

Was mich manchmal ziemlich nervt sind so „Randbedingungen“ wie der berühmte Wert von -0 -man vergleicht zB auf das Vorzeichen oder direkt auf die Null ...wundert sich erstmal..... und sucht sich dann einen Wolf............... oder das eine Wandlung von Float nach Integer immer nach oben aufrundet statt nur den Nachkommaanteil abzuschneiden. Dadurch ist man immer gezwungen an bestimmten Stellen zum Teil absolut beknackte Kunstgriffe einzubauen.... Tödlich können manchmal Eventloops werden, wenn sie zwar in einer Corecell mit z-1 aufgelöst werden (müssten) aber Reaktor das auf der Primaryebene absolut nicht erkennt und sich beschwert. Das gibt manchmal ne Kernschmelze (siehe auch die FlipFlop Struktur nach Human-Logik) .....und Reaktor verabschiedet sich. Manche Dinge werden zwar mit der Zeit logisch und man wählt einen anderen Lösungsweg nach Reaktor-Logik, aber es gibt doch etliche Dinge die einfach nur bescheuert bleiben..... Banale Dinge die in Reaktor eben irgendwie anders laufen.

*aaaaarrrrrghh*
Peter