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

[marco93]

Extrem cooles Zeug hier mit PD.

https://www.youtube.com/@artiomconstantinov

Befürchte das ist nicht ganz trivial.

 

[einseinsnull]

in dem schwarzen bild da verwendet er eigentlich nur vorgefertige sachen aus helpfiles u.ä., das könntest du auch nach 3 tagen, aber darauf kommt es bei solche leuten auch nicht an.

"one patch one song" ist eine philosophie, bei der denkarbeit auf ganz anderen ebenen benötigt wird als viel akademisches hintergrundwissen zu haben oder seine programmiersprache perfekt zu beherrschen.

das, was man patcht, muss dabei zwar so automatisch wie möglich gehen, aber im vordergrund brauchst du vor allem eine hohe entscheidungsfreudigkeit und musst dich aufs konzept und vor allem aufs hörbare ergebnis konzentrieren.

wer so wie ich alles drei mal entwirft, implementiert und optimiert, der will sich damit meist nur vor der entscheidung drücken, welchen sound er für das erste spontane bimbam wählt. dann bist du irgendwann erfinder, lehrer oder philosoph aber machst keine musik mehr.

du denkst jetzt seit 3 tagen darüber nach ob das was für dich wäre - wann fängst du an?

 

[marco93]

in dem schwarzen bild da verwendet er eigentlich nur vorgefertige sachen aus helpfiles u.ä., das könntest du auch nach 3 tagen, aber darauf kommt es bei solche leuten auch nicht an.

"one patch one song" ist eine philosophie, bei der denkarbeit auf ganz anderen ebenen benötigt wird als viel akademisches hintergrundwissen zu haben oder seine programmiersprache perfekt zu beherrschen.

das, was man patcht, muss dabei zwar so automatisch wie möglich gehen, aber im vordergrund brauchst du vor allem eine hohe entscheidungsfreudigkeit und musst dich aufs konzept und vor allem aufs hörbare ergebnis konzentrieren.

wer so wie ich alles drei mal entwirft, implementiert und optimiert, der will sich damit meist nur vor der entscheidung drücken, welchen sound er für das erste spontane bimbam wählt. dann bist du irgendwann erfinder, lehrer oder philosoph aber machst keine musik mehr.

du denkst jetzt seit 3 tagen darüber nach ob das was für dich wäre - wann fängst du an?

Ich schau mir VCV Rack nochmal genauer an.

 

[_thomas_]

Also dann habe ich mal den Organelle UI "released".



Hier verfügbar: https://patchstorage.com/organelle-ui-for-desktop/

Nochmals vielen Dank an @lacuna!

 

[_thomas_]

Problem:

Ich habe hier einen Patch mit 80 Parametern (8 Rythmus-Generatoren mit jeweils 10 Parametern)

Die Masse an Parametern halbwegs komfortabel für Benutzer und UI zu bewältigen ist natürlich nicht ganz so einfach. Jeder Generator nimmt seine Parameter über Symbole entgegen. Das ist effizient. Im UI zwar kompliziert, aber über Abstractions auch effizient lösbar wenn man mal für alles eine Lösung gefunden hat.

Nun aber:



Der Parameter "steps" spackt herum. Den will PD anscheinend nicht. Ansonsten haben bisher alle Parameter funktioniert. Auch nachfolgende Parameter wie status z.B. funktionieren. Hätte ja sein können, dass route auf eine bestimmte Länge reduziert ist.

Nur der steps will (bisher) nicht. Interessanterweise wird da anscheinend der Wert aus dem Name-Wert-Paar für das Routig herangezogen. Siehe unten.

Incoming... wird direkt am inlet abgegriffen. Das passt. Unknown... ist die Meldung die am letzten outlet von route hängt.

Mit "status":
incoming: status 1
incoming: status 0
incoming: status 1
incoming: status 0
incoming: status 1
incoming: status 0
incoming: status 1
incoming: status 0
incoming: status 1
incoming: status 0
incoming: status 1
incoming: status 0
incoming: status 1
incoming: status 0
incoming: status 1
incoming: status 0
Kein Fehler

Mit "steps":
unknown setting on rythm: 42
incoming: steps 42
unknown setting on rythm: 41
incoming: steps 41
unknown setting on rythm: 40
incoming: steps 40
unknown setting on rythm: 39
incoming: steps 39
unknown setting on rythm: 38
incoming: steps 38
unknown setting on rythm: 37
incoming: steps 37
unknown setting on rythm: 35
incoming: steps 35
unknown setting on rythm: 34
incoming: steps 34

Ich stehe vor einem Rätsel...

Zwischen inlet und rooute passiert übrigens nix. Das geht direkt rein.

 

[_thomas_]

Kleiner Nachtrag: Der Wert kommt aber an. Das hatte ich bisher nicht überprüft.

 

[einseinsnull]

klingt nach einem typo, sollte das evtl. "step" heißen?

auch wenn es code-mäßig nicht wirklich relevant ist, aber ich persönlich benutze keine keywords sondern nummeriere die dinge einfach durch. einfach weils kürzer ist.
wobei ich bei nur 8 sogar zu getrennten inlets tendieren würde.


jetzt wo es offiziell ist bin ich ein wenig beunruhigt, dass man demnächst das H-9000 mit maxmsp programmieren können wird. das ist dann, anders als die heute unterstützten kistchen nicht weniger, sondern mehr rechenleistung als am host computer.
sollte ich etwa mal langsam auf den "box" zug aufspringen? für einen gewissen teil der user (performance) ist das ja ein echter angriff auf die pacarana...

 

[_thomas_]

klingt nach einem typo, sollte das evtl. "step" heißen?

Nee, es heißt schon steps in der Route. Das sollte eigentlich passen. Da der Wert ankommt ignoriere ich einfach die Meldung am letzten Route-outlet. Ich habe dafür keine Erklärung. Trotzdem danke für den Tipp.

Ja, aber es sind insgesamt 8x8. Das sind doch sehr viele Verbinder. Da ist das mit den Symbolen schon eine gute Sache. Und funktioniert auch gut. Heute Nacht bin ich aus einem Traum aufgewacht mit weiteren Ideen. Da werden also noch ein oder zwei weitere Parameter dazu kommen.

jetzt wo es offiziell ist

Jetzt wo was offiziell ist? Welcher Box-Zug?

 

[einseinsnull]

Jetzt wo was offiziell ist?

das, was im zweiten teil des satzes steht.

Welcher Box-Zug?

solche externen kisten wie das organelle eben, weil es ganz neue möglichkeiten bietet im vergleich zum PC programm.
sexy fand ich die idee eine programmierbare hardware zu haben schon immer (kenn ich halt von kyma) und habe mich gefreut, dass max letztes jahr nachgezogen ist, weil das bislang pd-feld war.

so ein H-9000 kostet zwar so viel wie 10 organelle, aber du kannst halt auch nochmal ganz andere sachen damit machen. leider hat es auch nur 2 ausgänge...


...sieht man in pd nicht, welches objekt die fehlermeldung ausgibt?

 

[_thomas_]

H-9000

Ah verstehe. Das ist natürlich eine ganz andere Hausnummer. Beim Organelle und Pure Data lebst du mit ganz vielen Krücken. Ich sitze gerade an einem 8-fach-Poly-Rythmus. Nicht weil ich glaube, dass die Welt noch sowas braucht sondern mehr, weil es mich interessiert.

Da kommt es echt auf Nachkommastellen an. Mach das mal mit den Potis vom Organelle. Haptisch finde ich die ganz toll, aber die Werte die die liefern... Aber in der Einschränkung liegt ja auch Kreativität. Man muss immer neue Lösungen finden. Dazu das sehr eingeschränkte UI des Organelle. Man sucht häufig nach Lösungen für das UI. Z. B.: Wie starte ich am effektivsten die Clock und die einzelnen Stimmen? Ich habe einen Knopf: die AUX-Taste. Damit verdödelt man schon auch viel Zeit bis mal alles passt.

Aber trotzdem mag ich die kleine Kiste natürlich. Ist halt handlich.

 

[einseinsnull]

Ah verstehe. Das ist natürlich eine ganz andere Hausnummer.

es fängt schon damit an, dass in RNBO viele objekte 64 bit fixed point verwenden. aber das hauptaugenmerk liegt natürlich auf dem thema "gesamtrechenleistung".

vom marketing gag mal abgesehen.

Beim Organelle und Pure Data lebst du mit ganz vielen Krücken.

das organelle finde ich nur hässlich. ansonsten hat es eigentlich alles, was man so braucht.

bau dir mal die mechanik für eine art fine/coarse potis und nimm dann immer eines der 5 an der hardware als "fine" regler für den zuletzt bewegten parameter. ich mach das so mit midi, und zwar selbst dann wenn encoder als eingabedings zur verfügung stehen. wenn dir msb/lsb zu umständlich ist oder man das "fine" nicht immer braucht, dann lass das "fine" einfach 101 schritte zu je 0.01 machen, die du dann addierst. (oder 64 für deine beat geschichten? oder für jeden parameter anders?)

Aber in der Einschränkung liegt ja auch Kreativität.

einerseits: ja, genau. andererseits, häng doch einen 16 poti midi controller dran und inkludiere das in dein workflow.

Man muss immer neue Lösungen finden. Dazu das sehr eingeschränkte UI des Organelle.

like a wise man once said: "es gibt größere displays".

 

[_thomas_]

häng doch einen 16 poti midi controller dran

Ja, ich nutze einen Faderfox M12. Aber wenn du ein wenig für die Allgemeinheit patcht kannst das nicht machen. Soll ja schließlich auf der die das Organelle laufen. Das führt dann zu Konstruktionen wie dieser. Wenn du "exakte" Werte in einer bestimmten Range brauchst geht das halt nicht. Also bietet man eine sinnvolle Auswahl daraus an. Einen Wert 25 in einer Range von 0-200 bekommt man nicht gesichert getroffen.



Ich zerbreche mir schon ewig den Kopf darüber wie man das mit vier Potis und einem Encoder hinbekommen kann.

 

[einseinsnull]

okay, 16 fader oder regler setze ich immer als so eine art minimalanforderung voraus, aber ich verstehe auch warum du bei einer existierenden hardware willst, dass es auch ohne "erweiterung" sinnvoll zu bedienen ist.

vier Potis und einem Encoder

das ist das, was er/sie/es hat? was genau senden die? was sendet das "keyboard"?


das wäre sicherlich für "deine zielgruppe" auch wieder nur weltfremd, aber ich hab das mit dem "werte genau treffen" teilweise mit audio feedback gelöst.

das kann sogar für ganz normale 7 bit midi controller, die von der zielsoftware auch also solche in empfang genommen werden können, schon sinn machen.

jeder wert macht dann einfach klick und die 10, 20, 30 machen klack, und dann kann man einstellungen ganz gezielt vornehmen und braucht keinerlei display mehr dafür (bzw. in meinen fall: betreibt den rechner headless)

um ganz grob zu wissen, wo man ist, kann man natürlich dann auch noch zusätzlich für die 10er positionen markierungen auf dem gehäuse aufbringen.
von circa 50 auf genau 87 zu drehen wird so zum kinderspiel - jedenfalls dauert es nicht länger, wie das gleiche mithilfe eines displays zu erreichen.


dein patch versteh ich nicht. was soll erreicht werden?

 

[lacuna]

"steps"

funktioniert hier:



schau mal mit [print] was ankommt?

Organelle UI "released"

chic!

Die fader scheinen linear zu sein!? Du drehst ein wenig an der lautstärke und es wird gleich viel lauter. Und im bassbereich kannst du die frequenzen nicht genau einstellen, in den höhen passiert nicht mehr viel.
Besser ist nicht-linear, dann kannst du auch genauer einstellen
Siehe help > Patch Browser > Pure Data > 3.audio examples > D04.envelope.quartic.pd
oder auch mit [mtof] oder [pow] oder [dbtorms] den frequenz- bzw lautstärkeverlauf anpassen.

Wenn du genaue werte eingeben möchtest, geht vielleicht ein number-pad anzuschließen, oder die tasten irgendwie mit shift doppelt zu belegen.

 

[_thomas_]

das ist das, was er/sie/es hat? was genau senden die? was sendet das "keyboard"?

Genau, mehr gibt der Organelle nicht her. Plus einer sogenannten AUX-Taste, Footswitch und Expression Pedal. Das Keyboard hat zwei Oktaven beginnend mit dem mittleren C/c' und sendet die entsprechenden MIDI-Werte sowie on/off.

"deine zielgruppe"

Die Zielgruppe erwartet halt irgendwelche fancy Sound-Generatoren die ein wenig über die Potis, AUX und Keyboard getweakt werden können. Da muss man sich schon ein wenig anpassen.

chic!

Danke! Ich nutze das jetzt nur noch und packe es zum Schluss auf den Organelle. Funktioniert hervorragend.

Die fader scheinen linear zu sein!?

Die Fader sind deswegen linear weil die Potis auf dem Organelle es auch sind und das Verhalten natürlich genau so erwartet wird. Wer es logarithmisch haben möchte muss das im eigenen Patch machen. Der Patch zum UI ist ja nur ein einfacher Show-Case. Falls sich das auf den Organelle Desktop-Patch bezog.

Einzig die LED hätte ich gern noch in der passenden Farbe. Da habe ich in der von dir geposteten Doku zu den Messages bisher noch nichts gefunden. Eigentlich muss man ja nur einen Bang oder Toggle mit dem entsprechenden Farbcode der Organelle-LED als Hintergrund basteln. Jetzt ist es halt nur ein Toggle der halt mal an oder aus ist. Passt für mich aber auch erstmal als ganz einfacher LED-Indikator.

 

[einseinsnull]

ich wollte die eigentlich mit dem zahlensalat auf die sprünge helfen und das prinzip der range conversion im stammhirn implementieren - das ist vermutlich alles viel einfacher als du denkst - aber dazu müsste ich wissen, was diese 10-200 sein sollen.

das "keyboard" lässt sich ja notfalls auch für parametersteuerung missbrauchen, z.b. für inc/dec.

 

[_thomas_]

zahlensalat auf die sprünge helfen

Also ich habe das jetzt mit einer Kombi aus Poti und Tastatur gelöst damit sich der Patch nur mit den Benutzerelementen des Organelle bedienen lässt. Mit dem Poti in 10er-Schritten und den genauen Zielwert kann man dann mit der Tastatur einstellen.

Danke für eure Unterstützung in der Sache!

Noch etwas zum Thema "Farbe" in Pure Data (für das Archiv sozusagen):

Man kann die Farbe nicht in RGB-Werten angeben. Das wäre zu einfach. Stattdessen wird eine Float-Repräsentation dieser Werte für den Farbcode berechnet:

n = -1 - (B + (G * 256) + (R * 256²)

Für einen roten Hintergrund dann: color -1.67117e+07

Da muss man erstmal drauf kommen.



Für Vordergrund und Beschriftung muss sind dann zwei weitere Parameter für die color-Nachricht.

Also: color $1 $2 $3

Was natürlich vorher mittels "pack" zusammengeführt werden muss da Message nur einen Parameter kann.

Puh, da muss man erstmal drauf kommen. HEX-Werte waren wahrscheinlich zu einfach. Oder Miller Pucket zum Zeitpunkt seiner PD-Implementierung unbekannt war.

Patch hängt am Beitrag.

 

[einseinsnull]

Also ich habe das jetzt mit einer Kombi aus Poti und Tastatur gelöst damit sich der Patch nur mit den Benutzerelementen des Organelle bedienen lässt.

nah, ich meinte eigentlich das bild aus #72.

dinge wie range conversion und -distortion braucht ja man ständig, da solltest du wohl demnächst mal eine handvoll abstractions dazu bereit haben, was aber vorraussetzt zunächst mal die relevanz des thema "wertebereiche" zu erkennen.

trial and error ist prima für 3 projekte, beim fünften müssen dann aber andere lösungen her.

deswegen habe ich gefragt, was den die 1-30 und die 10-200 darstellen sollen, dann hätte man™ das mal richtig™ gemacht und dabei etwas gelernt, was wir nächste woche sowieso wieder brauchen.

 

[lacuna]

Puh, da muss man erstmal drauf kommen. HEX-Werte waren wahrscheinlich zu einfach.

welche Pd version? Es gab schon immer 30 preset farben und seit 0.47 auch rgb in hex.
schau mal in den helpfile vom toggle-gui
rot:
[color #ff0000(
|
[x]

Und du kannst mit [pack] eine list packen, die dann in einer message gemeinsam abgeschickt wird. [color $1 $2 $3( hat drei werte. Kannst die werte aber auch z.B. mit [list ] packen oder alle oder auch teilweise direkt in die message schreiben.
Mit messages werden die (meist in C geschiebenen) objects (programme) quasi 'bedient', und wie siehst du in dem jeweiligen help-file.
...bin jetzt wieder raus hier, ciao

 

[_thomas_]

bin jetzt wieder raus hier

Wie jetzt, für immer?

Tja, ich hätte es mal mit einer Raute davor probieren sollen. Auf die einfachsten Dinge kommt man ja häufig nicht. Ob das auf dem Organelle auch funktioniert muss ich aber noch testen. Da ist im Allgemeinen eine etwas ältere Version installiert.



Und es steht tatsächlich auch in der Hilfe. Ohne Raute.



Das nächste Mal werde ich genauer hinschauen wenn ich ein Problem habe.

was den die 1-30 und die 10-200 darstellen sollen

Die Frage ist doch wie man mit einer vorgegebenen Hardware (in diesem Fall Organelle-Potis) sein Ziel erreicht. Jetzt hat man diese Anforderungen:

• Wertebereich abdecken (wie hier in Duration 0 - 10.000 da ein Millisekunden-Wert als Extrembeispiel, Filter-Cutoff ist auch ein gutes Beispiel)
• Werte müssen durch den Benutzer exakt, zügig und sicher auswählbar sein

Mit Potis ist das nur sehr eingeschränkt bis gar nicht machbar. Die funktionieren mit drei Dezimalstellen ganz gut. Organelle Potis liefern zwischen 0-1 in einer Auflösung die bis zwei Dezimalstellen taktil (0, 0.01, 0.02, ... , 0.98, 0.99. 1) gut eingestellt werden kann. Ab der dritten Stelle muss man sensibel sein, aber ab der vierten Stellen muss den Poti nur ansehen damit sich der Wert ändert. Wahrscheinlich ist es das was du mit Range Distortion meinst?

Also kann ich realistisch gesehen nur diese 100 Steps nutzen (es sei denn, es kommt nicht so darauf an) um einen exakten Wert einzustellen. Beim Filter ist es jetzt nicht so wichtig ob ich bei 10.000 oder 11.000 abschneide. Bei der Notenlänge ist das schon wichtiger. Aber es ist mehr als ausreichend auf 10ms genau zu sein.

Mein obiges Beispiel mapt also Poti-Werte 0 - 0.3 (* 100, konvertiert auf Ganzzahl) auf sinnvolle Werte zwischen 10 und 200.

Eine sinnvolle Abstraction wäre dann z. B.:
oder
Von 0/-100 - 10000/100 in 100/10er Schritten.

Für z. B. die Duration habe ich mich aber zu einer Kombi aus Poti (500er Schritte) und vier Keyboard-Tasten (+/- 50, +/- 10) entschieden. Damit kann man zügig bis zu einer Genauigkeit von 10 ms seinen Wert einstellen und muss nicht endlos fummeln bis man die 450 ms mit dem Poti erwischt hat.

Man muss halt jeden Fall einzeln betrachten und schauen wie man mit den Limitierungen am besten zum Ziel kommt. Encoder statt Potis wären cool gewesen.

 

[lacuna]

Das nächste Mal werde ich genauer hinschauen

Eine sinnvolle Abstraction wäre dann z. B.:

oder

das sind sub-patches, keine abstractions, und nur abstractions können arguments (-100 100 10) haben, subpatches nicht.

 

[_thomas_]

Die letzten drei Wochen habe ich sage und schreibe 3 relativ komplexe Patches für den Organelle gemacht. Aktuell ist dieser hier:



Eine Simulation von atmosphärischen Störungen. Irgendwo hier im Forum kamen mal Vintage Mikros zur Frage. Das war im Grunde die Inspiration zu diesem Patch. Ich wollte schon immer mal klingen wie in einer alten Radiosendung aus den Anfangszeiten. Und mit Stimmen wird es wahrscheinlich am besten funktionieren. Mit Instrumenten (linker Eingang) habe ich es bisher noch nicht getestet.



Bisher noch nicht auf dem Organelle getestet. Daher ist das auch noch nicht auf Patch Storage. Das kommt dann nächste Woche. Allerdings gehe ich davon aus, dass das ohne Probleme auch dort laufen wird. Das Video habe ich der Einfachheit halber mit dem GUI und OBS gemacht. Immer die Kamera rausholen ist etwas aufwändig.

Was steckt dahinter?

Im Wesentlichen drei Komponenten:

• Ein Delay im Feedback-Modus (bis zu 100%)
• Ein Rauschgenerator mit angehängtem Bandpass-Filter (da ist noch ein Bug drin glaube ich)
• Ein resonanter Notch-Filter
• Zusätzlich das PD-Reverb, das hängt aber nur hinten dran

Der Patch ist ziemlich unberechenbar, daher habe ich auch auf konkrete Bezeichnungen wie Feedback, Resonanz, etc. verzichtet und habe mir Begrifflichkeiten herausgesucht die "irgendwie" elektromagnetische Wellen "beeinflussen".

Wer das mal testen will: Der Patch hängt inklusive Organelle GUI am Beitrag. Dreht mal ein wenig an der Antenne oder spielt mit der Gravitation oder der Hintergrundstrahlung aus dem Weltraum herum. Es ist ein Sample hinterlegt welches man mittels AUX starten und stoppen kann.

Wer das auf dem Organelle laufen lässt sollte vorab das GUI aus main.pd entfernen! Die einzelnen Screens werden mit dem Encoder gewechselt. Ins Hauptmenü kommt man zurück wenn man den Encoder mindestens eine Sekunde gedrückt hält.

 

[_thomas_]

Wenn man sich nicht so ganz sicher ist wie PD funktioniert, muss man auch mal einen Langzeittest machen



Und wie in der Entwicklung üblich muss man auch auf die Grenzbereiche schauen und auch das Unerwartete erwarten.

Ok, nicht wirklich interessant, aber ich dachte, ich schreib mal wieder was. Aktuell sitze ich an einem Langzeitprojekt zum Thema Polyrythmus. Bin gespannt, was letztendlich dabei herauskommen wird...

 

[_thomas_]

Hier nun der erste Teil meines MIDI-fähigen Poly-Rythmus-Patches für den Organelle, allerdings noch ohne Organelle:



Clippt leider ein wenig...

Es fehlt eigentlich nur noch ein Feature, das ich von den Elektrons kenne. Kommt vielleicht auch noch. Halte ich aber erstmal nicht für wichtig. Jeder von den vier Tracks erhält noch einen Euclid und einen Bernoulli. Damit habe ich schon jede Menge lustiges Zeug hinbekommen.

Das Organelle-GUI ist auch schon recht weit. Es gibt dann zwei Piano Roles die den einzelnen Kanälen zugewiesen und in verschiedenen Play-Modes abgespielt werden können. Mal sehen, wann ich das fertig habe. Vielleicht erweitere ich auch noch auf 8 Kanäle. MIDI ist natürlich konfigurierbar und das Ziel ist es auch, die Patches speichern zu können.

 

[_thomas_]

Was mir immer fehlte war die Kontrolle des totalen Chaos. Vor einigen Monaten hatte ich mal angefangen eine konfigurierbare Markov Chain zu implementieren. Mein damaliger Ansatz war allerdings viel zu komplex, als das man den mit PD hätte umsetzen können.

Mein neuer Ansatz ist dabei noch variabler und auch viel einfacher umzusetzen.



Allerdings: was mache ich nun damit? Also klar, ich kann jetzt den Zufall steuern. Nur ist diese Steuerung leider statisch. Mehr oder weniger. Es ist ja alles im "Code" verdrahtet. Es gibt zwar eine Würfelfunktion (wird im Video alle 8 Trigs ausgelöst), allerdings ist das nicht steuern, sondern halt würfeln.

Und so ganz prinzipiell frage ich mich, ob es überhaupt Sinn macht, solch eine Chain, mal abgesehen von den Kantenwahrscheinlichkeiten, zur Laufzeit ändern zu wollen. Hat da vielleicht jemand eine Idee? Es gibt ja mehr als genug Generatoren die auf der Markov Chain basieren. Vermute ich jedenfalls mal.

Markov Chain Abstraction | Patchstorage

What I was missing was an abstraction to implement variable Markov Chains for Pure Data...

patchstorage.com

 

[einseinsnull]

das wichtigste zuerst: wie geht´s eigentlich dem schaf? vergiss bei dem wetter nicht ihm genug wasser hinzustellen!


klar, du kannst den output einer markov chain funktion auch als so eine art segmentiertes verteiltes rauschen betrachten.

aber eine der klassischen anwendungen in unserer welt dürfte sein eine bereits bestehende melodie phrase zu analysieren und anhand ihrer die state/transition table zu erstellen. dann kannst du neue versionen davon da rausholen, oder die muster mehrerer stücke miteinander mischen.

in ermangelung des array objects kann ich nicht genau schauen, was du machst, aber ich sehe da irgendwas mit "chance".

wahrscheinlichkeiten in prozentwerten zu setzen ist der eine ansatz - der andere ansatz wäre, alle wahrscheinlichkeiten gleich hoch zu haben und doppelt auftretende identische ereignisse dann eben doppelt in die datenbank zu schreiben, so wie das supercollider .choose(1, 2, 3, 3, 5, 5, 5) macht.


ich nehme an, du machst dort 1st order und hast nur einzelne werte. hast du dich mal mit dem sinn und der implementierung von höheren ordnungen aueinandergesetzt?

 

[_thomas_]

vergiss bei dem wetter nicht ihm genug wasser hinzustellen

Dem Schaf geht's gut. Trockenheit ist diesen Sommer zum Glück nicht so das Problem. Den 1en und 0en hoffentlich auch. Man erzählt sich ja, dass Intel einen ziemlich kapitalen Bock mit der Prozessorenspannung ihrer Ix Prozessoren geschossen hat.

in ermangelung des array objects

Das existiert auch nicht. Die Wahrscheinlichkeiten für jede Kante gehen direkt in eine Berechnung. Siehe [markov] => [pd calc chances]. Die bis zu neun Chancen (für bis zu acht Zielknoten plus eigener Knoten) werden mit jeweils einem Minimum und einem Maximum zwischen 1 und 100 verteilt. Den Rest erledigt dann [random 100] + 1, womit der Zielknoten in [pd g1], [pd g2]...[pd self] ausgewählt und ausgegeben wird. Straight forward.

eine bereits bestehende melodie phrase zu analysieren

Analysieren in welcher Hinsicht? Für mich ist das erstmal ein einfacher diskret endlicher oder gerichteter Graph mit dem Ziel, Knoten mit einer Wahrscheinlichkeit zu erreichen um dann, was immer auch am Knoten "hängt", auszulösen. Da fehlt mir der Turn zu "Notenwerte analysieren". Jede Note ein Knoten? Die Häufigkeit ergibt die Wahrscheinlichkeit und dadurch dann zwangsläufig Variationen? Aber ich werde dazu mal recherchieren. Hört sich so ganz grundsätzlich interessant an.

alle wahrscheinlichkeiten gleich hoch zu haben und doppelt auftretende identische ereignisse dann eben doppelt in die datenbank zu schreiben

Da fehlt mir einfach der Hintergrund. Ich weiß halt nicht, was das nun bringen soll. Über die Zeit sollte das doch sowieso zu einer Gleichverteilung führen? Wenn ich 1000 Mal die Münze werfe habe ich zwischen Kopf und Zahl eine annähernd gleiche Verteilung der Zustände. Zumal eine Markovkette sich eigentlich auch nichts merkt sondern immer nur einen Ausgangszustand, eine Wahrscheinlichkeit und einen daraus resultierenden Endzustand hat.

du machst dort 1st order

Wahrscheinlich spricht du von Differenzialgleichungen. Klar. Ich habe Informatik studiert. Ist aber a) schon ein halbes Menschenleben her und b) bin ich seitdem in der IT-Beratung. Das war also alles für die Katz. Und wir reden hier auch über Pure Data. Das hat so seine Grenzen in der Machbarkeit. Eine DGL kommt hier nicht zum Einsatz. Siehe oben. Als Alternative fällt mir zum Graphen auch eher die Matrizenrechnung ein. Weniger DGLs. Graphen sind halt anschaulich und einfach umzusetzen.

Na ja. Jetzt geht's ab ins Bett.

 

[einseinsnull]

Analysieren in welcher Hinsicht?

das legst du selbst fest.

Für mich ist das erstmal ein einfacher diskret endlicher oder gerichteter Graph mit dem Ziel, Knoten mit einer Wahrscheinlichkeit zu erreichen um dann, was immer auch am Knoten "hängt", auszulösen. Da fehlt mir der Turn zu "Notenwerte analysieren". Jede Note ein Knoten? Die Häufigkeit ergibt die Wahrscheinlichkeit und dadurch dann zwangsläufig Variationen? Aber ich werde dazu mal recherchieren. Hört sich so ganz grundsätzlich interessant an.

so ein markov chain system ist sehr variabel und besteht oft aus eine reihe paralleler ketten. du kannst das aber aus simplen kernels bauen, die sich immer wiederholen und so funktionieren, wie du bock hast.

wie der code nachher genau aussieht, hängt vor allem davon ab, was man damit erreichen will.

(keine sorge, die null kommt gleich zum punkt und sagt dem schaf "bescheid".)

Da fehlt mir einfach der Hintergrund. Ich weiß halt nicht, was das nun bringen soll.

im grunde genommen weißt du es schon....

Und wir reden hier auch über Pure Data. Das hat so seine Grenzen in der Machbarkeit.

ich weiß. mit [coll] wäre das easy herzuzeigen, aber selbst vanilla hat nur [text]


im fogenden benutze ich trotzdem mal so ein "datenbank" format, auch wenn du das nicht 1:1 so umsetzen könne wirst, aber zum verstehen sollte es auslangen.

das, was man analysieren will sind ja musikalische ereignisse. dazu eigent sich die grammatik und semantik von MIDI ganz hervorragend, weil das ja auch dafür gedacht ist: zeit des beginns, zeit des endes, deltazeit zum nächsten ereignis, velocity/lautstärke, kanal/stimme.


nehmen wir einfach nur mal die note ons von alle meine entchen. (darf gerne in schäfchen umgedichtet werden)

die liest du nun wie folgt in die bislang noch leere "datenbank" ein.

das erste event ist die note 60. also erzeugst du eine zeile, die diesen wert einmal zur verfügung stellt, damit ihn später wieder von dort auslesen kann.

60

dann kommt die wezite note, die bekanntermaßen eine 62 ist.
wird die nun eingelesen, passieren 2 dinge. zum einen wird ein neuer eintrag für den state (zustand) "62" erzeugt, und zum anderen eine transition (übergang) vom erstem zun zweiten zustand, die dem ersten zustand als attribut zugeordnet wird:

60, 62
62,

zum jetzigen zeitpunkt kann man wahlweise die werte 60 oder 62 aus der datenbank auslesen.

sofern 60 gewählt wird, wird als nächstes automatisch die 62 kommen, weil ein einzelner übergang von 60 nach 62 dort "konkurrenzlos" (also mit 100% wahrscheinlichkeit) verzeichnet ist.
sofern 62 ausgewählt, endet das lied.

komplett sehen die entchen dann nachher so aus:

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

diese state transition table enthält nunmehr die gesamte information darüber, mit welcher wahrscheinlichkeit welcher wert einem anderen folgt. hingegen wissen wir nicht mehr, in welcher reihenfolge das beim original der fall war.

beim abspielen musst du nun nichts mehr weiter tun als immer wenn ein wert aufgerufen und gespielt wird, einen der dahinterstehenden per zufall auszuwählen und den dann als den nächsten festzulegen, und schon kannst du endlos lange entchen-ähnliche intervalle hintereinander abspielen.


das spiel lässt sich dann in 2 dimensionen erweitern.

zum einen die ordnung.

eine analyse zweiter ordnung würde nicht nur schauen, welche note nach der jetzigen zu spielen ist, sondern auch noch die letzte mitberücksichtigen.

ein zustand besteht jetzt also gleich aus 2 werten:

60, 62
"60 62", 64
"62 64", 65

2.-5. ordnung sind musikalisch sehr sinnvoll - 1. oder 15. ordnung ziemlich albern.


die andere dimension sind parallele chains.

z.b. könnte es sinn machen, akkorde als solche zu speichern, oder die länge der noten und die zeitlichen abstände zwischen den noten ebenfalls zu analysieren, sei es zusammen, sei es getrennt von den notenwerten.

das ist der rythmus unserer enten:

8 8 8 8 4 4 8 8 8 8 2 8 8 8 8 2 8 8 8 8 4 4 8 8 8 8 8

in die tabelle eingelesen ergibt das dann folgende datenmenge:

2, 8 8
4, 4 8 8 8 4 8
8, 8 8 8 4 8 8 8 2 8 8 8 2 8 8 8 4 8 8 8 8

bei sehr großen datenmengen würde man dann am ende der analyse die möglichen übergange dann eventuell aufakkumulieren und die wahrscheinlichkeiten als wert mit in die tabelle schreiben.

der erste wert ist die gesamtanzahl der übergänge.

2, 2 "8 2"
4, 6 "4 2" 8 4
8, 19 "2 2" "4 2" "8 15"

letzte zeile bedeutet: wenn aktueller notenwert ist achtelnote, dann spiele als nächstes mit wahrscheinlickeit 2 von 19 als nächstes eine halbe note, mit 2 von 19 eine viertelnote und mit 15/19 eine achtelnote.

die zeitwerte werden dann zuerst errechnet, und die trigger dann die zweite chain mit den notenwerten.


beim programmieren fängst du mit dem "datenbank" format an, und erst danach machst du den "einleser" und den "abspieler".

 

[_thomas_]

Alle meine Entchen schwimmen auf dem See, schwimmen auf dem See, Köpfchen in das Wasser, Schwänzchen in die Höh.

MIDI: 60 KEY: C4
MIDI: 62 KEY: D4
MIDI: 64 KEY: E4
MIDI: 65 KEY: F4
MIDI: 67 KEY: G4
MIDI: 67 KEY: G4
MIDI: 69 KEY: A4
MIDI: 69 KEY: A4
MIDI: 69 KEY: A4
MIDI: 69 KEY: A4
MIDI: 67 KEY: G4
MIDI: 69 KEY: A4
MIDI: 69 KEY: A4
MIDI: 69 KEY: A4
MIDI: 69 KEY: A4
MIDI: 67 KEY: G4
MIDI: 65 KEY: F4
MIDI: 65 KEY: F4
MIDI: 65 KEY: F4
MIDI: 65 KEY: F4
MIDI: 64 KEY: E4
MIDI: 64 KEY: E4
MIDI: 67 KEY: G4
MIDI: 67 KEY: G4
MIDI: 67 KEY: G4
MIDI: 67 KEY: G4
MIDI: 60 KEY: C4

Ich muss es mal eben durchdenken.

Mögliche Folgenoten jeder in der Phrase vorhandenen Note (copy&paste von dir):

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

Wahrscheinlichkeiten, welche der möglichen Folgenoten als nächstes kommt kann ich hier gerade nicht erkennen. Darstellung als Graph:



Aber die kann man ja "irgendwie" ermitteln. Wahrscheinlichkeit/Unwahrscheinlichkeit nach Häufigkeit, Gleichverteilung, zufällig, wie auch immer. Aber im Grunde habe ich momentan ja genau das. Also, erste Ordnung. Du hast Recht.

Für diese ja noch recht einfach Form der Analyse ist mein Ansatz allerdings schon viel zu statisch. Der Graph ist aktuell statisch, nur die Wahrscheinlichkeiten lassen sich zur Laufzeit ändern. Ich hatte da eher so was wie einen 32er Step Sequencer im Kopf. Der hat halt 32 Zustände. Die verdrahtet man dann halt nach Belieben. Feddisch.

Prinzipiell sehe ich den Ansatz auch in PD als machbar an. Aber das ist pain in the ass. Wahrscheinlich muss ich dann wahrhaftig auf Werte/Wahrscheinlichkeit Matrizen wechseln. Damit wäre es einfacher zu dynamisieren. Diese allerdings in PD zu implementieren... Mal schauen. Aber erstmal schon ganz nett der Ansatz. Ich werde meinen da wohl nochmal überdenken.

eine analyse zweiter ordnung würde nicht nur schauen, welche note nach der jetzigen zu spielen ist, sondern auch noch die letzte mitberücksichtigen.

Prinzipiell natürlich kein Thema, nur was genau meinst du mit "berücksichtigen"?

"60 62", 64 => Ausgangszustände 60 und 62 ergeben Endzustand 64?
"62 64", 65 => Ausgangszustände 62 und 64 ergeben Endzustand 65?

Nun taucht die 62 als Ausgangszustand hier aber zwei Mal auf. Was mache ich damit? Und korrekt wäre die zweite Zeile wahrscheinlich eher so:
"62 64", 65 64 67

Und weiter

"64 65", 67 65 65 65 64

Oder?

 

[einseinsnull]

Wahrscheinlichkeiten, welche der möglichen Folgenoten als nächstes kommt kann ich hier gerade nicht erkennen.

findest du etwas verklausuliert weiter unten in meinem text:

wahrscheinlichkeit ist entweder, wenn du 1.) entweder gleiche werte gesondert aufführst, dann list du das einfach mit einem random() aus und die verteilugn ergibt sich durch die werte aus der tabelle - oder 2.) du errechnest anzahl_dieserwert / anzahl_gesamt

64, 65 64 67 ... hier läge die wahrscheinlichkeit für alle 3 folgezustände bei 1/3

65, 67 65 65 65 64 ... hier liegt die wahrscheinlichkeit für die 65 bei 3/5

Der Graph ist aktuell statisch

das darf er, aber natürlich sollte alles mit allem verbunden sein, also auch das, was nachher möglichweise gar nicht vorkommt.

nur die Wahrscheinlichkeiten lassen sich zur Laufzeit ändern.

das hingegen ist nicht wirklich notwendig und sprengt das konzept fast. grundsätzlich sollte der zustandsraum und die wahrscheinlichkeiten festliegen.

nimm nicht zu kleine datensätze um auszuprobeiren, was dabei herauskommen kann. die entchen sind schon sehr grenzwertig zum testen, nimm lieber einen pop song oder für elise oder sowas, was ~100 noten hat.

die noten einlesen, und dann die chain auslesen, indem man z.b. den rythmus des originals als trigger dafür benutzt.

Ich hatte da eher so was wie einen 32er Step Sequencer im Kopf. Der hat halt 32 Zustände. Die verdrahtet man dann halt nach Belieben. Feddisch.

ja, ich verstehe schon. das konzept ist mir auch bekannt.

es wäre allerdings schade, wenn du dieses limit nur deswegen so setzt, damit du dir über die verarbeitung von listen oder das speichern von texten keine gedanken machen musst. beides ist scheiße in pd und ich bin dabei keine große hilfe weil du max vorlagen nicht übertragen könntest, aber wie du selbst sagst, ist es immer irgendwie machbar.

obiges text/datenbank format

"60, 61 62 63"

lässt sich im zweifel einfach in zwei register aufspalten, eines für numbers, eines für listen...

[i ] [array ] ...oder wie auch immer.

und dann machst du halt 32 kopien (oder besser 10124 ), und schon hast du deine "datenbank".

die suche nch eine komplexeren lösung lohnt sich aber, weil du viel weniger geraffel hast wenn das alles in einem einzigen objekt passiert. (das [coll] in max z.b. kann auch direkt presets in dateien speichern und importieren oder mit anderen instanzen in der runtime den gleichen inhalt teilen usw.)

Prinzipiell natürlich kein Thema, nur was genau meinst du mit "berücksichtigen"?

"60 62", 64 => Ausgangszustände 60 und 62 ergeben Endzustand 64?
"62 64", 65 => Ausgangszustände 62 und 64 ergeben Endzustand 65?

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

es werden also schon beim erzeugen der daten in der menge aus 2 aufeinanderfolgenden noten ein einziger zustand gemacht, wohingegen bei 1st order die einzelne note der zustand ist.

Nun taucht die 62 als Ausgangszustand hier aber zwei Mal auf.

der zustand ist 62 gefolgt von 64 - und den gibt es nur einmal.

je höher die ordnung, desto größer wird die anzahl möglicher zustände.