multitimbral

[herw]

... aber ein wenig konkreter könntest Du doch mal werden. Was genau hast Du jetzt eigentlich konstruiert?

[KlangRaum]

...ja stimmt; manchmal sieht man allerdings auch nicht den Wald vor lauter Bäumen...

das kommt dann auch noch dazu.......

beispiel:
ich bastle grad an nem arpeggiator, der die mutlitimbrale klangerzeugung füttern soll. nebenbei hat der arpeg einige feinheiten... er nudelt nicht nur einfach hoch&runter, sondern bildet quasi nach programmierbaren vorgaben harmonische reihen via lookup-tables: ich geb ein triggerpattern als basisrythmus vor und spiel einen akkord aufm keyboard an.... dann wird aus mehreren tabellen ein zirkel gebildet, der über X takte läuft........

ich lese zb einen tabellen-tastaturpuffer mit dem iteration aus - der entsprechende GATE (event-out) geht während der iteration von 0 auf 1... danach wieder auf 0.
jetzt hast du 2(!) verschiedene informationen: einmal den logikzustand und zum anderen den event (die flanke). wenn du nur den event benötigst weil du gewisse abläufe sncronisieren musst, bekommst du ab einer gewissen *schachtelungstiefe* recht schnell probleme mit der initialisierungsreihenfolge -also die signallaufzeit....
statisch gesehen mit ihren logikzuständen mag die schaltung ja ganz gut funktionieren, aber..... .... ....... ....

.... ich lese ja eine reihe lookuptables aus. das komplizierte daran ist einfach den überblick(!) über die schreib-lesesyncronisation in einer längeren kaskade zu behalten und dabei die rückkopplungen/eventloops korrekt zu handhaben. mir sind da schon abundzu einige denkfehler unterlaufen.... und ruckzuck fängt wieder ne stundenlange suchererei&grübelei an.
dafür hat das ganze ding traumhaft wenig cpu-last. das ist entschädigung genug...



*argh* isch beissss mirrr gleich ins holzbein

[herw]

...ich bastle grad an nem arpeggiator, der die mutlitimbrale klangerzeugung füttern soll. nebenbei hat der arpeg einige feinheiten... er nudelt nicht nur einfach hoch&runter, sondern bildet quasi nach programmierbaren vorgaben harmonische reihen via lookup-tables: ich geb ein triggerpattern als basisrythmus vor und spiel einen akkord aufm keyboard an.... dann wird aus mehreren tabellen ein zirkel gebildet, der über X takte läuft........

ich lese zb einen tabellen-tastaturpuffer mit dem iteration aus - der entsprechende GATE (event-out) geht während der iteration von 0 auf 1... danach wieder auf 0.
jetzt hast du 2(!) verschiedene informationen: einmal den logikzustand und zum anderen den event (die flanke). wenn du nur den event benötigst weil du gewisse abläufe sncronisieren musst, bekommst du ab einer gewissen *schachtelungstiefe* recht schnell probleme mit der initialisierungsreihenfolge -also die signallaufzeit....
statisch gesehen mit ihren logikzuständen mag die schaltung ja ganz gut funktionieren, aber..... .... ....... ....

.... ich lese ja eine reihe lookuptables aus. das komplizierte daran ist einfach den überblick(!) über die schreib-lesesyncronisation in einer längeren kaskade zu behalten und dabei die rückkopplungen/eventloops korrekt zu handhaben. mir sind da schon abundzu einige denkfehler unterlaufen.... und ruckzuck fängt wieder ne stundenlange suchererei&grübelei an.
dafür hat das ganze ding traumhaft wenig cpu-last. das ist entschädigung genug...
...

Das hört sich äußerst spannend an. Schade, dass ich bisher noch keine Zeit hatte, mich mit Arpeggiatoren zu beschäftigen; eigentlich müsste es mein Gebiet sein, da ja viel Logik- und Eventverarbeitung darin vorkommt (keine Zeit - keine Zeit).
Ich habe in der letzten Woche mal den Arpeggiator meines Masterkeyboards (KURZWEIL MIDIBOARD 18 Jahre alt) angeworfen (habe ich bisher nur als Zugeständnis einer Einfingerautomatik gesehen) und war echt überrascht, wie modern dieser ist:
Im einfachen Modus (ich muss mal erforschen ob es noch mehr gibt) registriert dieser live, in welcher Reihenfolge Tasten gedrückt und gehalten werden und spielt diese dann wiederholend ab. Ich habe dabei keine Grenze gefunden, wie viele Tasten er erfasst. Das finde ich für ein solch altes Gerät schon erstaunlich.
Wenn ich das richtig verstanden habe, konstruierst Du unter anderem etwas ähnliches, nur mit viel mehr Möglichkeiten - sehr interessant.
Wenn das ganze noch sehr handlich ist (klein), dann würde ich das gerne mal in den modular übernehmen wollen.
Die niedrige CPU-Last ist nicht erstaunlich, da ja wohl nur events verarbeitet werden; das ist dann wirklich mal eine Spielwiese, auf der man sich richtig austoben kann.
Kannst Du mal - nur so als Eindruck - einen screenshot der Hauptstruktur hochbeamen? Falls der screenshot zu groß sein sollte (600·600px), dann kannst Du das Bild ja aufteilen.
Mich interessiert der weitere Fortgang sehr!

ciao herw

[KlangRaum]

wir können das thema apeggiatoren ja mal ausklinken.... wenn ich eine halbwegs endgültige stuktur hab, kann ich mal einige screenshots machen.

einen einfachen arpeg, der nur hoch-runter nudelt, bekommst du relativ einfach hin.
komplexer wirds, wenn du zb eine halbwegs intelligente keyboardsteuerung mit einbauen möchtest, die zb mehrere unterschiedliche tastendrücke sammelt oder wenn du so eine art begleitautomat realisieren willst. richtig fies wirds, wenn die reihenfolge der tastendrücke benötigt wird.

zurzeit hab ich eine 3-stufige queue: P & G schreiben direkt in eine table..... jeder event auf G initialisiert einen transfer in die 2. stufe - hier werden P & G jeweils in eine eigene table geschrieben. zusätzlich (ganz wichtig) werden diese beiden table vor jedem schreibzyklus noch gelöscht...
die 3. stufe der queue ist der arbeitspuffer, auf den die mustergeneratoren zugreifen. der transfer von der 2. zur 3. stufe wird von der globalen midiclock getaktet.

das hört sich jetzt unnötig kompliziert an - ist aber im vergleich zu anderen arpegs relativ transparent, da die noten quasi automatisch via index sortiert werden. dazu kommt das man mit tabellen unterschiedliche schreib/lesezyklen schön sauber trennen kann und sich nichts gegenseitig in die quere kommen kann. die schwierigkeiten liegen aber trotzdem in einigen details (siehe oben- die prozess-syncronisation):
drückt man zb 6 tasten gleichzeitig aufm keyboard, so können die note_on events in einem paket (running-mode) oden schlimmstenfalls in 6 einzelne pakete zersplittert ankommen. der arpeg ahnt nix davon, muss aber in der lage sein, die schreibzyklen in diesem fall zu verwerfen und neu zu beginnen. auch die taktsyncronisation -also die freigabe aus der 3. queuestufe muss in diesem fall verzögert werden, da sonst die mustergeneratoren uU von einer leeren tabelle -oder von einer die grad neu beschrieben werden muss- auslesen wollen....

wie man sieht: viel friemelkram.....

[helmsklamm]

äh, ich hab grad nen hänger - wenn die 2te ebene ständig aktualisiert und die 3 ebene als arbeitspuffer (warum zusätzlich???) genutzt wird, wo hast du denn überhaupt deine algos (phrasen) versteckt?

[KlangRaum]

die 3. stufe ist der eigentliche hold- & arbeitspuffer. ab dem 3. puffer ist zb. alles taktsyncron zum midi, abhängig vom eingabemodus: einzeltasten-gesammelt oder akkord, die letzten X noten....
ich hab mich dazu entschieden um einmal die ganzen schreib- und lesezugriffe sauber(er) zu trennen und um unterschiedliche algos zu realisieren.

es gibt keine pattern als solches... sondern kaskadierte lookup-tables, die einen index auf eine note oder andere tabellenebene berechnen und dann darüber auf den 3. puffer zugreifen.


...das ist zumindet der momentane stand. das ding ist ja noch lange nicht fertig....

[helmsklamm]

klingt äusserst interesant - bin sehr gespannt.