herw hat geschrieben:Ich will nicht groß stören, aber doch mal sagen: es ist herrlich Euren spontanen und erfrischenden Thread zu lesen
Ich würde mich sehr freuen, wenn Du hier so oft wie Du kannst störst
Ich hab mich jetzt für den Sequencer zum ersten mal mal etwas mit dem Eventbus beschäftigt (Greyhound Tutorial), es gibt 2*12 Kabelgruppen die parallel durch (zu) viele Makros laufen, das versaut die Struktur. Wenn das mit dem EB so klappt wie ich denke dann könnte ich auch die Architektur klarer halten und damit auch klarer denken. Ist aber glaub ich noch zu früh, aber wenns soweit ist wärs schön wenn Du hier viel störst
und vorher natürlich auch.
herw hat geschrieben:
@ MvKeinen: nutze so viel core wie nur irgend möglich. Man hat viel logischere und vorhersehbare Ergebnisse.
ciao herw
Jau, das ist das Ziel. bin gestern auch in eine Primary Sackgasse geraten. Ich wollte ja die eventcorecell "Brain" in eine Audiocorecell verfrachten. Das hab ich erstmal verworfen weil beim kopiervorgang alle corearrays mit iterationsgeschwindigkeit ausgelesen werden und so die Panelelemente aktualisiert werden. Ich will auch nicht auf die Iterationsgeschwindigkeit verzichten. Geht aber nicht mit den Audioausgängen (wohl auch nicht mit dem AudioCoreEventOutput vom Krümelmonster Dacht ich mir: Ok, dann lese ich die Snap value Arrays eben Paralell zu den core arrays aus und beschreibe sie (Was für fast jede neu implementierte Funktion ein neues SVA bräuchte). Kurz: es war ein Desaster. es hätte irgendwie sicher geklappt aber wär eine dermaßen bug-gefährdete sache gewesen.
das lustige ist, dass ich jetzt heute sehr viele fortschritte gemacht habe und garkeine Audiocorecell mehr brauche.
Auch werd ich dem Sequenzer jetzt noch 1-2 Features (von den unten genannten) spendieren und ihn dann erstmal so lassen, vielleicht mach ich mich noch an die Polydisplays zur Visualisierung, aber das kann auch noch warten. Für mich hat sich die parallele Vorgehensweise bewährt. Man schraubt einen Teilaspekt ein paar Versionsnummern höher und geht dann wieder "Spielen" dann merkt man am schnellsten welchen musikalischen Features man noch Arbeit widmen muss.
die weiteren Ideen für den Sequenzer
- Midispeicher (halb fertig): ein Array was mit midinotennummern beschrieben werden kann und per step An/Aus ausgelesen wird
- Den Kopiervorgang permanent aktivieren, so könnten dann evolvierende Patterns entstehen wenn die gewählten Quell und Zielsteps eine Schnittmenge haben. Allerdings muss diese iteration dann Langsam verlaufen, vielleicht ist es auch sinnvoll sie im zB doppelten Tempo zu synchronisieren und gleichzeitig auf den aktuell getriggerten Step zu beschränken (oder auch nicht)
- Quantizer: Polydisplay als pianoroll hochkant wo man einzelne Noten an und ausklicken kann um den Pitchoutput und die Grafikoutput des Sequenzers in gewissen Skalen zu Quantisieren
- Polydisplays wären gut zur Platzersparnis. Vielleicht kann mir jemand die Frage beantworten: Was ist besser? 1 Polydisplay (INS muss dann ca. 500 Stimmig sein) oder 5 polydisplays übereinander mit transparentem Hintergrund (INS muss dann ca. 100 Stimmig sein) Da aber kein Audio und nur wenig Event polyphon verarbeitet wird vermute ich dass es dann eher die größere Anzahl der Polydisplays ist die mehr CPU killt als die größere Anzahl von Stimmen. Aus Schaltungs und strukturgründen würde ich aber eigentlich zu 5 Polydisplays tendieren.
Vielen Dank für eure Beiträge!!
Auch der Thread nebenan
http://reaktor.approx.de/phpbb3/viewtop ... f=16&t=796
kommt mir grad wie gerufen, ich werd da hin und wieder n paar Fragen stellen müssen
Gruß
weitermachen 
) heute mal ne Auszeit gegönnt und und schraub nach langer Zeit wieder mal an meinem Core-OPL weiter rum