Hallöchen!
in meinem derzeitigen Sequenzerprojekt bin ich auf eine Schwierigkeit gestossen wofür ich ein kleines Testensemble gebaut habe. Das Ensemble versuch ich in diesem Thread mal zu entwickeln. Ich erstelle dafür einen eigenen Thread, weil das vielleicht leute interessiert, die meinen "Großen" Projektthread Interphase nicht verfolgen.
Ziel:
Ich möchte innerhalb eines Snapshots mehrere "Patterns" für den Sequenzer haben, da ich später eine Art "Songmodus" haben will in dem man eine Abfolge verschiedener Patterns (Sequenzen) erstellen können soll. Hierfür verwende ich 2 SVAs.
(SVA=SnapValueArray)
Für das Testensemble hab ich die Länge der Sequenzen auf 8 beschränkt damit der Eventwatcher (danke an Clist) nicht überladen wird
SVA1: "Edit buffer": hier wird der User input hineingeschrieben welcher von der Mouse area kommt. Die Größe entspricht der Länge der Sequenz =8
SVA2: "Memory": hier werden die Daten der 4 abgespeicherten Patterns hineingeschrieben. Die größe ist daher 4*8=32. Pattern 1 hat also die Indices 1-8, Pattern 2 = idx 9-16 usw.
die addressierung der SVAs erfolgt durch eine beim Schreibvorgang ausgelößte Iteration und ist bei SVA1 immer idx1-8 und bei SVA2 abhängig vom gewählten Zielpattern Wr#. [(Wr# -1) * 8] + idx
nun zum Panel:
Damit man Übersicht und Kontrolle über das Ergebnis hat habe ich im Testensemble 6 Eventtables angelegt: (Beim fertigen Sequenzer soll da natürlich nur eins (polydisplay) sein.
1. Editbuffer
2. Brain (das was an die Sequenzerengine geschickt wird)
3.-6. Memory 1-4
Im Bedienfeld "control" wird der schreibvorgang ausgelößt. die Liste "Wr#" bestimmt das Zielpattern, der Button "write" startet dann den kopiervorgang (hier steckt mein aktuelles Problem, dazu unten mehr), die Liste "Ptn#" soll später Daten aus dem "Memory"- SVA ins "Brain" schreiben, also ein Patternwahlknopf. Dieser hat bisher aber noch keine Funktion, weil ich bevor ich das mache das aktuelle Problem lösen will und ich die Übersicht behalte. Bis hierhin will ich es nur schaffen, dass die 4 memory"Slots" korrekt beschrieben werden.
jetzt zur Struktur:
Eingänge I,V: Index und Value des User input (parent)
Makro "control" beinhaltet Panelelemente und von ihnen ausgelößte Iterationen
Corecell: Edit feed: bereitet die Daten für das EditSVA auf
Corecell: Memory feed: bereitet die Daten für das MemorySVA auf
Corecell: Brain feed: bereitet die Daten für die Sequencerengine auf
Macreo "Tables" beinhaltet die Event tables.
im angehängten Ensemble funktioniert die sache auch mit dem Richtigen Ergebnis, aber nur, weil die Iteration IT'wr zweimal durchläuft. dies erreiche ich, indem der Button "Wr" im Gatemodus arbeitet und so die Iteration einmal beim anklicken startet und einmal beim loslassen. wenn man draufklickt und nicht loßlässt sieht man, dass nur der erste Step des Zielpatterns mit einem (falschen) Wert beschrieben wird. Das ist unbefriedigend, weil ich für die Stukturhygiene lieber so wenig Events wie möglich haben will. Die Indices werden schon beim Anklicken korrekt durchgezählt, wie im Eventwatcher dargestellt. (Siehe panelscreenshot) Die Werte jedoch sind beim ersten Durchlauf die falschen.
mein Ziel ist es nur eine Iteration zu tätigen und gleich die korrekten Werte aus SVA1 auszulesen.
Jemand ne Idee?
Snap value arrays befeuern sich untereinander
Moderator: herw
-
- meister
- Beiträge: 168
- Registriert: 10. August 2006, 14:06
- Wohnort: Berlin
Snap value arrays befeuern sich untereinander
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Reaktor Befürworter
- herw
- moderator
- Beiträge: 3123
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: Snap value arrays befeuern sich untereinander
Ich mach gerade meine Steuererklärung, aber ich lese mit und teste das mal in den nächsten Tagen.
ciao herw
ciao herw
-
- meister
- Beiträge: 168
- Registriert: 10. August 2006, 14:06
- Wohnort: Berlin
Re: Snap value arrays befeuern sich untereinander
danke das wär super.herw hat geschrieben:Ich mach gerade meine Steuererklärung, aber ich lese mit und teste das mal in den nächsten Tagen.
ciao herw
Reaktor Befürworter
-
- meister
- Beiträge: 168
- Registriert: 10. August 2006, 14:06
- Wohnort: Berlin
Re: Snap value arrays befeuern sich untereinander
Ich glaub ich hab die Lösung, war ganz schön knifflig für meine Verhältnisse
Das obere Ensemble kann man jetzt getroßt vergessen
Das Problem bei dem oberen Testensemble war, dass ich die Visuelle Ausgabe der Speicherinhalte hinter die SVAs geschaltet habe. Da diese aber unbedingt nicht auf "Events thru" geschaltet sein dürfen musste ich immer wenn ich einen visuellen Output haben wollte den "R" Eingang der SVAs beschicken. Das hatte zur folge, dass beide SVAs mit fehlerhaften Daten von dem jeweils anderen beschrieben wurden.
Jetzt hab ich die visuelle Ausgabe des "Edit buffers" SVA und des "Memory" SVA quasi paralell geschaltet und musste dann nur darauf achten, dass die Tables immer genau mit den gleichen Werten beschickt werden wie die SVAs. Dann musste ich nurnoch dafür sorgen, dass die einzelnen Memory tables 1-4 bei Snapshotwechsel richtig beschrieben werden. Dies erfolgt durch die Selbstiteration des memory SVAs bei der die Daten abhängig vom Index (1-8:pattern1, 9-17_pattern2, usw.) in die Tables 1-4 geschrieben werden. Jetzt kann man pro Snapshot 4 Patterns abspeichern. Natürlich hmuss man dazu nach dem man das Memory SVA mit den 4 Patterns gefüllt hat erst noch das Snapshot speichern. Im Marco "Control" befinden sich die Bedienelemente und die von ihnen ausgelößten Iterationen. Diese werden per IC-sends in das parent macro geschickt (Das ist notwendig weil in meinem "grossen" Sequencer die Bedienelemente weiter weg sind und vor allem Iterationen sehr problemlos über IC-sends zu schicken sind) Ich habe die zusammengehörenden Send/Recieve Paare mal farblich gekennzeichnet.
Die beiden Corecellen "Edit feed" und "Memory feed" versorgen die jeweiligen SVAs:
Es gibr im Ganzen 2 Vorgänge:
Vorgang A: Schreibvorgang (schreibt den Inhalt des "Edit buffers" in das gewählte Zielpattern des "Memory" SVA)
Vorgang B: Lesevorgang (schreibt den Inhalt des gewählten Patterns des "Memory" SVA in den "Edit buffer")
Diese Vorgänge werden in den "Feed"-zellen folgendermaßen weitergegeben:
Edit feed:
Hier wird erstmal der User input weitergegeben Index "i'UI", Wert "V'UI" um den "Edit buffer" zu füllen
Vorgang A: Schreibvorgang:
Die Indizes werden durchgezählt (IT'wr) und die Werte werden ausgelesen (Ausgang "R") um ins "Memory" SVA zu gelangen.
Vorgang B: Lesevorgang:
Die Indizes werden durchgezählt (IT'rd) und die Werte kommend vom "Memory" SVA werden in den "Edit buffer" geschrieben.
Memory feed:
Hier ist es wichtig die korrekten Indizes zu addressieren weil das "Memory" SVA eine grösse von 8 Steps * 4 Patterns = 32 hat. die Adresse richtet sich bei Vorgang A: nach wr# (Zielpattern des Schreibvorganges und bei Vorgang B: ptn# (Quellpattern des Lesevorganges)
Vorgang A: Schreibvorgang:
Die Indizes werden durchgezählt (IT'wr) und die Werte kommend vom "Edit buffer" werden ins "Memory" SVA geschrieben.
Vorgang B: Lesevorgang:
Die Indizes werden durchgezählt (IT'rd) und die Werte werden ausgelesen (Ausgang "R") um in den "Edit buffer" zu gelangen.
"Brain feed" versorgt dann die Sequencerengine:
Hier werden Indizes und Werte des "user inputs" weitergegeben (i'UI, V'UI). Diese werden gemerged mit den Werten des "Memory" SVAs (V'my), allerdings nur wenn ein Pattern gewählt wird. Die Daten des Selbstiteration bei Snapshotwechsel dürfen hier nicht durchgehen, was ich mit dem Gate der Read Iteration (IG'rd) verwirklicht habe. Dass bei Snapshotwechsel trozdem die korrekten Daten ausgegeben werden liegt an der Iteration die durch den Patternwahlschalter ausgelößt wird.
So, das war für mich ein hartes Brot
Dafür hab ich jetzt aber ne Grundlage für ne sehr variable Sequenzer pattern steuerung.
Weitere möglichkeiten wären:
- Undo/Redo
- Abkopplung von aktuell gespieltem pattern und angezeigtem (editiertem) pattern (eine Art "Edit follow")
- "Live Edit": jede editierung wird sofort ins aktuelle Pattern geschrieben
ich freu mich schon wenn ich das endlich in meinen Sequenzer pflanzen kann, das wird ziemlich genial, Undo/Redo und "Live edit" versuch ich jetzt mal zu integrieren. "Edit follow" hat ohne Songmodus noch keinen sinn.
Jetzt kann man schonmal nach herzenslust patterns abspeichern und aufrufen...
wenn da jemand mal lust hat das kurz durchzutesten ob noch fehler drin sind (Also ob patterns unter irgenwelchen Umständen falsch geschrieben oder gelesen werden) wärs super. Ich selber kann grad keinen finden.
Das obere Ensemble kann man jetzt getroßt vergessen
Das Problem bei dem oberen Testensemble war, dass ich die Visuelle Ausgabe der Speicherinhalte hinter die SVAs geschaltet habe. Da diese aber unbedingt nicht auf "Events thru" geschaltet sein dürfen musste ich immer wenn ich einen visuellen Output haben wollte den "R" Eingang der SVAs beschicken. Das hatte zur folge, dass beide SVAs mit fehlerhaften Daten von dem jeweils anderen beschrieben wurden.
Jetzt hab ich die visuelle Ausgabe des "Edit buffers" SVA und des "Memory" SVA quasi paralell geschaltet und musste dann nur darauf achten, dass die Tables immer genau mit den gleichen Werten beschickt werden wie die SVAs. Dann musste ich nurnoch dafür sorgen, dass die einzelnen Memory tables 1-4 bei Snapshotwechsel richtig beschrieben werden. Dies erfolgt durch die Selbstiteration des memory SVAs bei der die Daten abhängig vom Index (1-8:pattern1, 9-17_pattern2, usw.) in die Tables 1-4 geschrieben werden. Jetzt kann man pro Snapshot 4 Patterns abspeichern. Natürlich hmuss man dazu nach dem man das Memory SVA mit den 4 Patterns gefüllt hat erst noch das Snapshot speichern. Im Marco "Control" befinden sich die Bedienelemente und die von ihnen ausgelößten Iterationen. Diese werden per IC-sends in das parent macro geschickt (Das ist notwendig weil in meinem "grossen" Sequencer die Bedienelemente weiter weg sind und vor allem Iterationen sehr problemlos über IC-sends zu schicken sind) Ich habe die zusammengehörenden Send/Recieve Paare mal farblich gekennzeichnet.
Die beiden Corecellen "Edit feed" und "Memory feed" versorgen die jeweiligen SVAs:
Es gibr im Ganzen 2 Vorgänge:
Vorgang A: Schreibvorgang (schreibt den Inhalt des "Edit buffers" in das gewählte Zielpattern des "Memory" SVA)
Vorgang B: Lesevorgang (schreibt den Inhalt des gewählten Patterns des "Memory" SVA in den "Edit buffer")
Diese Vorgänge werden in den "Feed"-zellen folgendermaßen weitergegeben:
Edit feed:
Hier wird erstmal der User input weitergegeben Index "i'UI", Wert "V'UI" um den "Edit buffer" zu füllen
Vorgang A: Schreibvorgang:
Die Indizes werden durchgezählt (IT'wr) und die Werte werden ausgelesen (Ausgang "R") um ins "Memory" SVA zu gelangen.
Vorgang B: Lesevorgang:
Die Indizes werden durchgezählt (IT'rd) und die Werte kommend vom "Memory" SVA werden in den "Edit buffer" geschrieben.
Memory feed:
Hier ist es wichtig die korrekten Indizes zu addressieren weil das "Memory" SVA eine grösse von 8 Steps * 4 Patterns = 32 hat. die Adresse richtet sich bei Vorgang A: nach wr# (Zielpattern des Schreibvorganges und bei Vorgang B: ptn# (Quellpattern des Lesevorganges)
Vorgang A: Schreibvorgang:
Die Indizes werden durchgezählt (IT'wr) und die Werte kommend vom "Edit buffer" werden ins "Memory" SVA geschrieben.
Vorgang B: Lesevorgang:
Die Indizes werden durchgezählt (IT'rd) und die Werte werden ausgelesen (Ausgang "R") um in den "Edit buffer" zu gelangen.
"Brain feed" versorgt dann die Sequencerengine:
Hier werden Indizes und Werte des "user inputs" weitergegeben (i'UI, V'UI). Diese werden gemerged mit den Werten des "Memory" SVAs (V'my), allerdings nur wenn ein Pattern gewählt wird. Die Daten des Selbstiteration bei Snapshotwechsel dürfen hier nicht durchgehen, was ich mit dem Gate der Read Iteration (IG'rd) verwirklicht habe. Dass bei Snapshotwechsel trozdem die korrekten Daten ausgegeben werden liegt an der Iteration die durch den Patternwahlschalter ausgelößt wird.
So, das war für mich ein hartes Brot
Dafür hab ich jetzt aber ne Grundlage für ne sehr variable Sequenzer pattern steuerung.
Weitere möglichkeiten wären:
- Undo/Redo
- Abkopplung von aktuell gespieltem pattern und angezeigtem (editiertem) pattern (eine Art "Edit follow")
- "Live Edit": jede editierung wird sofort ins aktuelle Pattern geschrieben
ich freu mich schon wenn ich das endlich in meinen Sequenzer pflanzen kann, das wird ziemlich genial, Undo/Redo und "Live edit" versuch ich jetzt mal zu integrieren. "Edit follow" hat ohne Songmodus noch keinen sinn.
Jetzt kann man schonmal nach herzenslust patterns abspeichern und aufrufen...
wenn da jemand mal lust hat das kurz durchzutesten ob noch fehler drin sind (Also ob patterns unter irgenwelchen Umständen falsch geschrieben oder gelesen werden) wärs super. Ich selber kann grad keinen finden.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Reaktor Befürworter
-
- meister
- Beiträge: 168
- Registriert: 10. August 2006, 14:06
- Wohnort: Berlin
UNDO
Grad läufts wie geschmiert
die Undo-funktion läuft.
dazu musste ich 2 weitere Iterationen einrichten.
1. IT'bl: Wird vom Linksklick ausgelößt. Sie passiert bevor die X und Y Werte von der mouse area kommen. Herw hat mir im InterPhase Thread da sehr auf die Sprünge geholfen, denn die Ausgänge der mouse area schicken in der Rheienfolge von oben nach unten ihre Werte. Da ich aber der undo buffer mit den alten Daten des Edit buffers beschrieben will, also bevor ich via X & Y neue Werte in den Edit buffer schreibe muss die Iteration vorher passieren. Lösung, auch wenn der Zweck damals ein anderer war, ist hier: InterPhase thread posting 33 Danke nochmal dafür
2. IT'nd: wird vom "undo" knopf ausgelößt.
wieder gibt es zwei Vorgänge:
Vorgang A: Schreibvorgang (schreibt den Inhalt des "Edit buffers" in den "Undo buffer")
Passiert bei Linksklick
Vorgang B: Lesevorgang (schreibt den Inhalt des "Undo buffer" in den "Edit buffer")
Passiert bei Betätigung des "Undo" Knopfes
Was mir etwas Kopfzerbrechen bereitet hat ist die Frage, wie ich den Patternwechsel und die Undofunktion zusammenbringen soll. Ich hab das bisher so gelößt, dass bei patternwechsel der Undo Buffer ebenfalls neu beschrieben wird, so dass man bei Betätigung von "Undo" das "alte" Pattern erhält. Und bei Snapshotwechsel müsste man auch überlegen. So wie es jetzt ist kann man mittels der Undo funktion eizelne Patterns in den neuen Snapshot verfrachten, was ich eigentlich sehr gut finde.
Auch stellt sich nun die Frage wie man mehrere Undostufen realisieren könnte. Für jede ein eigenes SVA? die bei Editierung ihren Inhalt in das jeweils nächste schreiben? Oder könnte man innerhalb eines SVAs eine art "Index Shift" verwirklichen?
die Undo-funktion läuft.
dazu musste ich 2 weitere Iterationen einrichten.
1. IT'bl: Wird vom Linksklick ausgelößt. Sie passiert bevor die X und Y Werte von der mouse area kommen. Herw hat mir im InterPhase Thread da sehr auf die Sprünge geholfen, denn die Ausgänge der mouse area schicken in der Rheienfolge von oben nach unten ihre Werte. Da ich aber der undo buffer mit den alten Daten des Edit buffers beschrieben will, also bevor ich via X & Y neue Werte in den Edit buffer schreibe muss die Iteration vorher passieren. Lösung, auch wenn der Zweck damals ein anderer war, ist hier: InterPhase thread posting 33 Danke nochmal dafür
2. IT'nd: wird vom "undo" knopf ausgelößt.
wieder gibt es zwei Vorgänge:
Vorgang A: Schreibvorgang (schreibt den Inhalt des "Edit buffers" in den "Undo buffer")
Passiert bei Linksklick
Vorgang B: Lesevorgang (schreibt den Inhalt des "Undo buffer" in den "Edit buffer")
Passiert bei Betätigung des "Undo" Knopfes
Was mir etwas Kopfzerbrechen bereitet hat ist die Frage, wie ich den Patternwechsel und die Undofunktion zusammenbringen soll. Ich hab das bisher so gelößt, dass bei patternwechsel der Undo Buffer ebenfalls neu beschrieben wird, so dass man bei Betätigung von "Undo" das "alte" Pattern erhält. Und bei Snapshotwechsel müsste man auch überlegen. So wie es jetzt ist kann man mittels der Undo funktion eizelne Patterns in den neuen Snapshot verfrachten, was ich eigentlich sehr gut finde.
Auch stellt sich nun die Frage wie man mehrere Undostufen realisieren könnte. Für jede ein eigenes SVA? die bei Editierung ihren Inhalt in das jeweils nächste schreiben? Oder könnte man innerhalb eines SVAs eine art "Index Shift" verwirklichen?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Reaktor Befürworter
-
- meister
- Beiträge: 168
- Registriert: 10. August 2006, 14:06
- Wohnort: Berlin
Re: Snap value arrays befeuern sich untereinander
Nächste Überlegung wäre zuerst einmal das Undo Array in core zu machen. Die Struktur wird dadurch einfacher und der Undo buffer wird ja eh nicht mit dem Snapshot gespeichert, das wäre sonst verwirrend. Eigentlich könnte ich theoretisch den Edit buffer auch in core machen, da bin ich aber nichzt ganz sicher, weil dieser ja in einer Art Loop mit dem Undo und Memory buffer steht, der nur durch das abgeschaltete "Events thru" in den SVAs durchbrochen ist.
kann das jemand so aus dem Ärmel geschüttelt sagen? die arrays in core kann man ja sozusagen durch die Beschaltung auf Thru oder nicht thru stellen. jetzt wo ich die Beschaltung habe müsste ein Versuch relativ schnell gehen. Vorteil wäre, dass ich dann ein großes Macro für die "feeds" und die arrays hätte.
kann das jemand so aus dem Ärmel geschüttelt sagen? die arrays in core kann man ja sozusagen durch die Beschaltung auf Thru oder nicht thru stellen. jetzt wo ich die Beschaltung habe müsste ein Versuch relativ schnell gehen. Vorteil wäre, dass ich dann ein großes Macro für die "feeds" und die arrays hätte.
Reaktor Befürworter
- herw
- moderator
- Beiträge: 3123
- Registriert: 13. März 2006, 18:28
- Wohnort: Dortmund
Re: Snap value arrays befeuern sich untereinander
Aus dem Ärmel schütteln geht nicht, dazu fehlt mir im Momemt die Zeit. Dein Projekt ist auch schon so weit, dass man nicht mehr direkt folgen kann.MvKeinen hat geschrieben:Nächste Überlegung wäre zuerst einmal das Undo Array in core zu machen. Die Struktur wird dadurch einfacher und der Undo buffer wird ja eh nicht mit dem Snapshot gespeichert, das wäre sonst verwirrend. Eigentlich könnte ich theoretisch den Edit buffer auch in core machen, da bin ich aber nichzt ganz sicher, weil dieser ja in einer Art Loop mit dem Undo und Memory buffer steht, der nur durch das abgeschaltete "Events thru" in den SVAs durchbrochen ist.
kann das jemand so aus dem Ärmel geschüttelt sagen? die arrays in core kann man ja sozusagen durch die Beschaltung auf Thru oder nicht thru stellen. jetzt wo ich die Beschaltung habe müsste ein Versuch relativ schnell gehen. Vorteil wäre, dass ich dann ein großes Macro für die "feeds" und die arrays hätte.
Rein formal erkenne ich, dass du Datenblöcke in bestimmter Reihenfolge abarbeiten möchtest. Hier ist wirklich ein Ansatz mit Eventbus schon zwingend nötig; d. h. Man muss durch Iterationen und zusätzliche Abschlussevents erzwingen, dass diese Blöcke jeweils als eine Einheit bearbeitet, das geht am besten durch ein Wechselspiel von primary (Iteration) und core. Eventblöcke haben in ihrem Kopf in der Regel eine Identifikationsadresse und dann die Anzahl der Elemente, dann folgen die eigentlichen Daten; die Anzahl dient gleichzeitig als Startwert für eine Index, der bei jedem eintreffenden Event heruntergezählt wird.
Ehe du dich an solche Datenstrukturen heranwagst, sind umfangreiche Tests und Forschungsarbeit nötig.
ciao herw
-
- meister
- Beiträge: 168
- Registriert: 10. August 2006, 14:06
- Wohnort: Berlin
Re: Snap value arrays befeuern sich untereinander
Ja, da hab ich noch einiges vor mir. Allerdings bin ich jetzt schonmal froh, dass es so funktioniert wie ich das will und die Struktur einigermaßen übersichtlich ist.
Bin gerade dabei die aktuelle Version der Patternverwaltung in den Sequenzer zu integrieren. bin gespannt wie sich das macht. Vor allem kann ich dann durch Ausprobieren besser rausfinden was unter musikalischen Aspekten noch wichtig ist.
Bin gerade dabei die aktuelle Version der Patternverwaltung in den Sequenzer zu integrieren. bin gespannt wie sich das macht. Vor allem kann ich dann durch Ausprobieren besser rausfinden was unter musikalischen Aspekten noch wichtig ist.
Reaktor Befürworter