Pure Data | Organelle | Max/MSP | Q&A

[_thomas_]

"wenn die vorletzte 60 war, und die letzte 62, dann wird die neue 64".

Verstehe Hätte man auch von selbst drauf kommen können.

Erstmal vielen Dank für deine Erläuterungen. Mit den Wahrscheinlichkeiten zu jonglieren ist ganz nett. Aber ich habe selbst gemerkt, dass das nicht so furchtbar viel bringt.

Aktuell sitze ich bereits an einer Abstraction um die Noten (MIDI Daten) zu verwalten. Wobei ich [setnote] und [getnote] wahrscheinlich noch auf ein Inlet/Outlet umbauen werde. Das ist einfach eleganter.



Mehrdimensionale Array gibt's in PD leider nicht. Also musste ich es "plattklopfen".

Was mich allerdings auch noch zu einer Frage bezüglich der Platzierung einer Note im Takt/Rythmus jenseits des Clock-Signals (irgendwo zwischen zwei Triggern) in einem "Sequencer" bringt. Da komme ich dann aber nochmal wenn es so weit ist. Meine Idee fordert dem Benutzer da vielleicht zu viel (Rechnerei) ab, denke ich.

 

[_thomas_]

Und da sind sie nun, alle meine Entchen. Mit Notenlieferant und Sequencer.

Die Noten


Der Sequencer


Alles zusammen + Delay


Der Song
Anhang anzeigen pd_session_0.wav



Wundere mich gerade, dass ich das so schnell zusammen geschustert bekommen habe.

Der Sequencer ist absichtlich so gebaut, dass die Noten von außen angeliefert werden müssen. Dafür gibt er unten rechts rechtzeitig ein Event aus damit man es oben mittig anliefern kann. Auch die Clock kommt von außen. So kann ich dann bei der Anlieferung die Markov-Analyse berücksichtigen ohne, dass der Sequencer irgendwelche krassen Sachen machen muss. Alles bleibt schön modular. Gefällt mir.

 

[einseinsnull]

und genau wie du die entchen jetzt fest eingebaut hast, kannst du als nächstes dann das importieren von midifiles und die möglichkeit den user eine melodie manuell einstellen zu lassen ergänzen, so dass diese notenmenge dann dynamisch ist.

diese import- oder einstell-prozesse erzeugen dann mit jedem zustand auch gleich die transitions mit.

danach kommt das auslese-dings, und fertig ist die markov chain.


modular ist pflicht - und freut nicht nur den anwender, sondern auch den entwickler.


p.s.:
ich würde allerdings nicht die kompletten midi bytes mit in die register schreiben, sondern immer möglichst wenig daten, was man sonst noch so braucht kann man auch später dranhängen.

der ideale entchen-markov-betonmischer würde natürlich korrekterweise auch die beiden pausen als state enthalten (könnte man z.b. mit notennummer -1 kodieren) und nicht wie bei mir oben stattdessen einfach halbe noten benutzen, denn damit würde man das original ja verändern.

[geheimcode]

[/geheimcode]

 

[einseinsnull]

das scheiß bild ist ja D-Dur, das habe ich in der vorschule aber anders gelernt.

aber es ging ja nur darum die sache mit den pausen als ereignisse darzustellen.

 

[_thomas_]

Alle meine Entchen, D-Dur, bitte sehr
Anhang anzeigen pd_session_0.wav

der ideale entchen-markov-betonmischer würde natürlich korrekterweise auch die beiden pausen als state enthalten

Pause haben ja eigentlich alle Noten. Die meisten halt eine 1. Wobei das natürlich alles relativ ist. Prinzipiell stehen die ja jetzt auch in der DB und können genauso im Mischer landen wie alles andere auch. Der Algorithmus lässt sich ja nun auf alle Zahlen anwenden. Vielleicht nicht alle aber doch sehr viele.

Worüber ich noch sehr froh bin ist, dass ich mit diesem Vorgehen nun endlich (wahrscheinlich jedenfalls) eine Möglichkeit gefunden habe, Noten auf dem Organelle, mit den eingeschränkten Möglichkeiten, halbwegs komfortabel verwalten zu können. Das wird dann halt eher MIDI-Tracker-Style statt Piano-Role. Aber das passt viel besser zu den Möglichkeiten des Organelle. Selbst die weiter oben erwähnten Micro-Timings lassen sich so wahrscheinlich gut abbilden. Das Nachdenken über die Markovkette hat mir doch sehr viel gebracht, muss ich sagen.

 

[einseinsnull]

wenn du das mit den notenwerten dann mal bis zum boss level durchgespielt hast kann ich als level 2 dann die rythmus realm empfehlen, bei der man (nur) die delta zeiten in die markov menge schreibt.

auch hier wieder bieten sich beide methoden zum befüllen an: einen fertigen rythmus laden oder den user einen einstellen lassen. nur 4 on the floor geht damit nicht mehr so wirklich.

eine externe clock braucht das nicht, aber das wirst du dann merken.

 

[einseinsnull]

ist dir bei deinem wahrscheinlichkeiten-einstellen approach eigentlich noch nicht aufgefallen, dass man dabei relativ vorsichtig sein muss um loops zu vermieden? (wenn 60 nur zu 65 springen darf und 65 nur zu 60, dann ist da ganz schnell feyerabend.)

das ist - neben der authentizität - einer der anderen gründe, warum es besser ist, den benutzer eine melodie einspielen zu lassen und diese dann zu analysieren, denn damit passiert das nicht. (rauschen != KI)

 

[_thomas_]

Boss Level. Weit, weit entfernt davon. Ich sitz noch am 2D-Array



Es ist so krass, das PD keine mehrdimensionalen Arrays unterstützt. So viel Rumgehampel, inklusive dynamic patching, für eine einfache Datenstruktur. Es gibt zwar ein Array-Objekt, aber das ist auch nur eine Liste von Zahlenwerten. In Zukunft soll sich das angeblich ändern (steht wischiwaschi in der Doku). Aber wann die sein wird...

Aber jetzt kann ich wenigstens mit der 1. Ordnung anfangen. Für alles weitere brauche ich dann noch n-Tupel als Index. Das kann heiter werden...

Danke für den Tipp mit dem Loop des Todes. Ich wäre bestimmt darüber gestolpert. Ich werde direkt darauf achten.

Mal sehen wo ich morgen dann stehe. Die Frage die sich stellt ist allerdings, bis zu welcher Ordnung es überhaupt Sinn macht. Wahrscheinlich ist das auch abhängig von der Anzahl der Noten.

 

[_thomas_]

Was ich mich gerade auch noch frage ist, ob es Sinn ergeben würde, optional die Menge der Werte durch Aufteilung in Werteblöcke einzuschränken.

Man denk ja immer so im klassischen 4er-Block. Also könnte man die Menge der Noten z.B. auf 8 (4 wird viel zu wenig sein) oder 16 aufteilen und daraus, z. B. im Falle von Alle meine Entchen, zwei Blöcke (16 und 11 Werte) zu erzeugen. Das würde die Wahrscheinlichkeiten eingrenzen und dann dem Original ähnlicher sein. Keine Ahnung, ob das dann auch wirklich so ist.

Nochmal zum Loop des Todes:

60, 62
62, 60
64, 65 64 67
65, 67 65 62 65 64
67, 67 69 69 65 60 67 67 60
69, 69 60 69 67 69 62 67

Den Loop muss ich entfernen und auch alle Referenzen darauf. Damit würde das Ergebnis doch ganz schön verfremdet. Je nachdem, wie viele Noten das betrifft.

 

[einseinsnull]

Es ist so krass, das PD keine mehrdimensionalen Arrays unterstützt.

vielleicht kannst du clone dafür missbrauchen? (stimme 7 == zeile 7)

einfach [l!st] benutzen und das dann halt mehrstimmig.

haha, list kann ich nicht schreiben, das wird zu bbcode.

Den Loop muss ich entfernen

du musst nur dafür sorgen, dass sowas erst gar nicht entsteht.

beim einlesen von entchen und schäfchen, oder wenn du dem user eine pianoroll oder drehregler gibst, kann das nicht passieren.
das einzige was dann noch passieren kann ist, dass nichts auf die erste note zeigt und nichts der letzten folgt, falls die erste oder die letzte nur ein einziges mal in dem stück auftauchen. dann stoppt das abspielen wenn man dort ankommt.
die erste und die letzte programmatisch anders zu behandeln ist aber kein problem.

im grunde genommen kannst du auch eine zu wiederholende sequenz als daten eingeben (i.e. die erste folgt einfach wieder der letzten, und das wird dann so in die datenbank geschrieben. also immer, nicht nur dann wenn diese singuläre werte haben.)

 

[_thomas_]

Deine Voraussage:

60, 62
62, 64
64, 65 64 67
65, 67 65 65 65 64
67, 67 69 69 65 67 67 67 60
69, 69 69 69 67 69 69 67

Meine Wahrscheinlichkeiten:

PROBS: 60: 1
PROBS: 62: 1
PROBS: 64: 3
PROBS: 65: 5
PROBS: 67: 8
PROBS: 69: 8

Passt eigentlich bis auf den letzten Wert der bei dir 7 ist. Ich scheine auf dem richtigen Pfad zu sein. Mit SC wäre ich wahrscheinlich schon lange fertig.

 

[_thomas_]

PROBS: 60: (P:1) 62 0 0 0 0 0 0 0 0
PROBS: 62: (P:1) 64 0 0 0 0 0 0 0 0
PROBS: 64: (P:3) 65 64 67 0 0 0 0 0 0
PROBS: 65: (P:5) 67 65 65 65 64 0 0 0 0
PROBS: 67: (P:8) 67 69 69 65 67 67 67 60 0
PROBS: 69: (P:8) 69 69 69 67 69 69 69 67 0

Ich überlege, ob man die Wahrscheinlichkeiten vom Auftauchen der Folgewerte abhängig machen sollte. Hier im Beispiel wird, bei der 69 bei gleicher Verteilung, zu 75% wieder die 69 ausgewählt werden... Die 69 ist echt eine ganz üble Zahl hier in dem Song. Die Pausen habe ich jetzt nicht markovisiert sondern die Markov-Note in die vorgegebene Reihenfolge eingesetzt. So bleibt hier die Melodie erhalten.

Anhang anzeigen pd_session_0.wav

Der Algo hat es tatsächlich mal geschafft für 45 Sekunden zwischen der 67 und der 69 hin und her zu springen. Gähn².

 

[einseinsnull]

Deine Voraussage:

Meine Wahrscheinlichkeiten:

die rechnung verstehe ich nicht, denn das ergibt ja nicht den gleichen output.

Mit SC wäre ich wahrscheinlich schon lange fertig.

alleine schon der unterschied zwischen max 8 und max 4 ist frappierend. vieler meiner abstractions, die aus 10 objekten bestehen, könnte ich heute mit einem objekt ersetzen.

man lernt so aber eine menge.

 

[_thomas_]

die rechnung verstehe ich nicht

Du hast einfach eine 69 als Folgewert zur 69 vergessen. Ich hab's nachgezählt.

man lernt so aber eine menge.

Hauptsächlich lernt man bei Vanilla sich einzuschränken. Die allermeiste Zeit hab ich mit den Arrays verballert. Na ja. Was soll's. Jetzt hab ich das auch. Ob ich noch die höheren Ordnungen umsetze... Reizen täte es mich, aber ich hab nu etwas Angst vor dem Aufwand nur für das Handling der Daten.

 

[einseinsnull]

ach so ja, meine daten können auch falsch sein.

etwas Angst vor dem Aufwand

ja, aber mach das zuerst. durch den langweiligen und schwierigen teil musst du durch, dann hast du hinterher viel spass damit wenn das erst mal funktioniert.

die state/transition table sollte und kann nämlich immer gleich aussehen, und wenn es mit ints funktioniert, dann kann man sich später schritt für schritt durch data formatting unterschiedliche analysier- und abspielgeschichten dafür bauen.

ich kenn die unterschiede zwischen den distros nicht auswendig, weiß auch nicht, was man alles auf den organelle laden kann, und habe derzeit hier nur extended installiert. habt ihr wenigstens regexp und sprintf? wie würdest du in pd z.b. die liste "60 65" oder den string "60_65" wieder zurück in zahlen konvertieren?

 

[einseinsnull]

habs doch grad mal angeschaut. regexp und itoa scheinen im urlab zu sein, die anderen kollegen packen alle mit an.

links normal, rechts mit ein bischen datashaping (=alles schön gleich lang)

 

[einseinsnull]

so, jetzt ist abgestützt, dann gibt es eben keinen gute nacht screenshot mehr.

sprintf symout %.3ld mag pd nicht, dann geht es direkt schlafen.

 

[_thomas_]

was man alles auf den organelle laden kann

Du kannst alles auf den Organelle laden was du willst. Ist ja nichts anderes als ein stark abgespecktes Linux irgendwas mit Vanilla auf einem 3er Raspi.

Aber: das ist halt wie es ist. Klar könnte man jetzt dem User sagen, dass er für diesen Patch dieses oder jenes nachinstallieren muss. Aber wer hat da schon Interesse dran? Also versucht man halt, kompatibel zu bleiben um die Hürde zur Nutzung möglichst klein zu halten. Also muss man mit dem arbeiten was auf den allermeisten Organelles zur Verfügung steht.

Was relativ unproblematisch wäre ist, mit dem Patch eigene Extensions mitzugeben. Dafür aber müsste ich mich aber erstmal in die Vanilla-Entwicklung einarbeiten und dann auch noch die Build-Systeme bauen welches zumindest für Windows/Intel und Linux/Arm dann die Extensions raushaut.

Das ist mir einfach zu aufwendig.

 

[_thomas_]

Wahrscheinlichkeiten...

Markov (0ter Ordnung) ist eigentlich relativ unbrauchbar. So aus meiner Sicht.

Lasse ich den Algorithmus allein entscheiden ist das für den Hörer eigentlich auch nur "random", da ein Bezug oder Ähnlichkeit zu "Alle meine Entchen" komplett verloren geht.
Anhang anzeigen pd_session_0.wav
Nur eins ist sicher: Es werden Noten aus dem Lied gespielt.

Wenn ich jetzt aber eine Wahrscheinlichkeit einbaue mit der ich steuern kann ob Markov oder Original gespielt wird, bleibt das Ganze schon noch erkennbar.
Anhang anzeigen pd_session_1.wav
Aber: "Alle meine Entchen" ist vielleicht ein gutes Beispiel, kann es durchaus vorkommen, dass die eine aufgrund ihrer hohen Wahrscheinlichkeit am häufigsten gespielte Note immer und immer wieder gespielt wird. Ab Sekunde 26.

Was könnte ich machen? In die Vergangenheit schauen und die Wahrscheinlichkeiten, je nach Häufigkeit des Auftauchens über irgendeinen Zyklus, so gestalten, dass andere Noten einen Vorrang haben. Aber da wären wir wahrscheinlich bei einer Analyse 2ter Ordnung.

Im Großen und Ganzen ist es für den Hörer kaum ein Unterschied welche Random-Note er nun hört.
Anhang anzeigen pd_session_2.wav
Es ist dann allerdings irgendwie unharmonisch. Kann aber mit Markov ebenfalls passieren.

Tja, ich frage mich gerade, ob es einen tieferen Sinn haben könnte jetzt noch die 2te Ordnung zu bauen.

Oder ich investiere in das Thema Chord Progression. Das folgt Regeln (die ich mir erst noch aneignen muss), und Regeln kann man implementieren. Das wäre dann (in meiner vielleicht naiven Vorstellung) so etwas wie ein "harmonisches" Random. In VCV gibt es solch ein Modul. Und es hört sich halt immer "gut" an.

 

[einseinsnull]

Lasse ich den Algorithmus allein entscheiden

hm. algorithmus? alleine?

Was könnte ich machen?

ja, die entchen sind schon sehr kurz und enthalten viel content, der komplett unique ist.

als beispiel bzw. zum austesten, ob das ding korrekt läuft sind sie aber genau deswegen ganz gut zu gebrauchen.

Im Großen und Ganzen ist es für den Hörer kaum ein Unterschied welche Random-Note er nun hört.

ich würde es nur "pur benutzen". es gegen das original zu mischen oder irgendeinen random scheiß mit einzubauen sprengt das konzept komplett.

Tja, ich frage mich gerade, ob es einen tieferen Sinn haben könnte jetzt noch die 2te Ordnung zu bauen.

2. und 3. ordnung machen normalerweise am meisten sinn.

und dann switchst du mal zu "für elise" als testmaterial, wo du dann ja in einigen fällen 2 noten gleichzeitig hast, die du dementsprechend als ein ereignis abspeicherst.

hast du schon eine lösung für beginn und anfang gefunden? fürs erste gib der letzten note einfach eine transition zur ersten oder neustarte von der ersten alle soundsoviel takte (bei den entchen: alle 32 achtel)


ich mach die tage mal mit wenn der mac wieder für musik frei ist, zur zeit macht er was anders.

 

[_thomas_]

hm. algorithmus? alleine?

Schon. Schließlich sucht ja ausschließlich der Algorithmus die nächste Note aus. Oder habe ich da was falsch verstanden?

hast du schon eine lösung für beginn und anfang gefunde

Anfang ist aktuell immer die erste Note.

 

[_thomas_]

Jetzt habe ich das ganze Ding auf Tupel umgebaut, was scheißaufwendig war.

Jetzt sitze ich gerade an der zweiten Ordnung:

60: 62
62, 60: 64
64, 62: 65
65, 64: 67
67, 65: 67
67, 67: 67, 69, 67, 60

usw... ist jetzt nicht vollständig und wahrscheinlich nicht mal vollkommen korrekt.

Eine Speicherung von 60 als Startwert macht eigentlich fast keinen Sinn. Da ich, außer vielleicht zum Start der Ausgabe, nur noch mit 2er Tupeln arbeiten werde. Das betrifft ja auch alle größeren Ordnungen. Die fünfte Ordnung hat dann vier Einträge, die niemals wieder getroffen werden können. Davon mal abgesehen würden die auch immer in derselben Abfolge arbeiten da sie immer nur eine Wahrscheinlichkeit, nämlich die direkt folgende Note, haben können. Stört aber auch nicht, wenn man die mitlaufen lässt.

Schwieriger finde ich die Entscheidung was passieren soll, wenn ich in der Ausgabe ein Tupel generiere, dass gar nicht existiert.

Die beiden Noten: 67,67 können die 60 als nächste Note ausgeben. Das resultiert in ein neues Tupel 60,67. Das gibt's aber nicht in der Datenstruktur. Also irgendein Tupel als neuen Startwert nehmen? Oder von vorne beginnen (hier 60)? Verhindern, dass so was passieren kann?

So ganz durchdacht ist das von meiner Seite jetzt noch nicht.

Edit: oder ich hab's nicht kapiert. Der Folgetupel ergibt sich vielleicht gar nicht aus der letzten und aktuell gelieferten Note?

 

[einseinsnull]

ja das ist dieses problem mit dem start und dem ende. implementier das erst mal für erste ordnung, da blickt man es leichter.


bei der generischsten version würde man ja den user die startnote frei festlegen lassen wollen, indem er aus allen enthaltenen eine dafür auswählen darf, und dann soll das ganze endlos lang rennen.

zusätzlich muss man nur noch austesten, ob der letzte zustand singulär ist - wenn es den wirklich nur einmal gibt, muss man da u.u. noch gewisse vorkehrungen dafür treffen, damit es nicht stoppt wenn man dort ankommt.

ach ja, und die erste 60 bei den entchen, das ist so eine sache. im grunde genommen existiert die bei zweiter ordnung nicht, weil nur die beiden ersten noten zusammen den ersten zustand darstellen. dann aber kann man zu ihr auch gar nicht mehr springen... welche schlussfolgerung du daraus ziehen willst ist deine sache.

 

[einseinsnull]

wenn das zielformat regelmäßig eine 4-on-the-floor 64 32tel sequencer phrase werden soll, könntest du einfach die letzte mit der ersten note zu einem zustand verbinden, also quasi das input material zu einem "loop" deklarieren.

das löst nahezu alle oben genannten probleme.

für ein bach oratorium würde ich das so aber nicht machen wollen.

 

[_thomas_]

welche schlussfolgerung du daraus ziehen willst ist deine sache

Ich denke mal, dass es eine gute Idee ist Anfang und Ende einfach zu verbinden.

Aber ich stoppe das hier jetzt erstmal. Die erste Ordnung läuft ohne Probleme. Bei der zweiten Ordnung tauchen diverse Fehler auf. Und da die Ursache zu finden ist mehr als schwierig da PD als einziges Mittel zur Fehlersuche eine Konsolenausgabe anbietet. Und die ist nicht mal synchron zu den Events sondern wird wohl gepuffert und dann zu irgendeinem Zeitpunkt ausgegeben. Und dann auch noch in LIFO-Form. Es ist krass schwierig so Abläufe und Zusammenhänge in komplexen Patches zu finden da alles vermischt ist.

Bei jeder Notenanalyse gebe ich "=====..." aus:

==============================================: bang
CURRENT PROB: 0
GET PRO: get 60 67 0 1
TUPEL CREATE: 1731a-60-67
SET PROB: set 60 67 0 1
TUPEL CREATE: 1731a-60-0
==============================================: bang
CURRENT PROB: 0

Korrekt wäre:

==============================================: bang
GET PROB: get 60 67 0 1
CURRENT PROB: 0
SET PROB: set 60 67 0 1
TUPEL CREATE: 1731a-60-67
==============================================: bang
GET PROB: ...
CURRENT PROB: ...
SET PROB: ...
TUPEL CREATE: ...

Elemente, deren Erzeugung gar nicht angewiesen wird:



Es werden Entitäten erzeugt die nachweislich so nicht gar nicht erzeugt werden sollten. Die 65-0, 67-0 und 69-0 gibt's nämlich gar nicht. Ich gehe mal nicht davon aus, dass PD da irgendwas falsch macht sondern das der Patch irgendeinen Fehler hat. Nur: wie finden bei der "Menge" an Daten? Verschluckt die Konsole vielleicht auch Ausgaben? Das müsste irgendwo auftauchen da jedes Event protokolliert wird.

Ich kümmere mich jetzt erstmal wieder um meinen Sequencer-Patch für den Organelle. Für Wahrscheinlichkeiten habe ich eh schon ein paar Schen. Markov wäre halt noch schön gewesen.

Und Musik würde ich auch gern mal wieder machen... Zu wenig Zeit für alles.

 

[_thomas_]

Ach, und vielen Dank für deinen Support!! Das mal zu durchdenken und umzusetzen hat echt Spaß gemacht.

 

[einseinsnull]

die chain selbst kann immer gleich aussehen, egal welche ordnung. für zweite ordnung brauchst du nur ein kleines shift register um statt 1, 2, 3, 4 eben "1 2", "2 3", "3 4" einzutragen. [t f b]->[f]->[pack 0 0]->[tosymbol] oder wie auch immer.

aber gerne! ich werde sicherich mitbekommen wenn du irgendwann wieder aufmachen solltest.

 

[_thomas_]

kleines shift register

Alles Dinge die im Rahmen der Umsetzung entstanden sind.

 

[einseinsnull]

der aufstieg des abfalls zum nebenprodukt.

 

[_thomas_]

Also mittlerweile läuft auch die Markov-Analyse bis zur sechsten Ordnung. Allerdings bringt das nix mehr. Vielleicht, wenn man wirklich viele Noten hätte... Aber mit der vierten Ordnung hört sich sogar alle meine Entchen irgendwie spannend an...

Fürs Testen (man will ja schließlich auch mal was hören) wollte ich mir einen kleinen Synth basteln.



Das ist nun daraus geworden. Acht Delay-Lines die man mit irgendwelchen Klängen bespielen kann. Die Noten werden automatisiert generiert. Skalen können ausgewählt werden (insgesamt 28). Insgesamt 12 FM-Stimmen. Dazu gibt's noch einen Rauschgenerator. Mein Karplus-Dings werde ich wohl auch noch einbauen. Dazu noch einen LFO für den Filter. Aber auch so habe ich schon Stunden mit dem Teil verbracht.

Deswegen heißt er auch Procrastinator...

Mal sehen, ob der Organelle das Teil noch verkraftet.