Wer arbeitet mit pd?

[bohor]

hallo,

ich versuche, mich innerhalb von pd zurecht zu finden. Hab vor 20 Jahren viel mit Max gearbeitet, bin also sicher kein Anfänger. Ich hab mir nun purr data heruntergeladen, wegen des Objekts coll, das aber nicht so funktionieren will, wie ich aus der Doku erwarte. Gibt es hier jemanden, der ebenfalls mit pd arbeitet (oder kämpft) und sich mit mir austauschen möchte?

EDIT:
Link zu puredata.info hinzugefügt, weil natürlich nicht jeder wissen kann, wovon hier die Rede ist.

 

[einseinsnull]

ich hege sehr viel sympathie dafür, aber ich mags nicht benutzen (im vergleich zu max 4)

die umgewöhnung von right to left order auf "welches kabel zuerst da war" ist einfach zu groß.

p.s. und mach erst mal vanilla. dem third party zeugs ist nicht unbedingt immer zu trauen.

 

[bohor]

Ja, die Regel "Welches Kabel war zuerst" ist ein schwerer Designfehler in pd. Ich hab aber starke Gründe, Max nicht zu nutzen.

Für das, was ich vorhabe, brauche ich eigentlich ein zweidimensionales Array. Das coll-Objekt ist da schon ein schmerzhafter Kompromiss. Ich sehe nicht, wie ich das noch kleiner geschnitten kriege.

 

[lacuna]

@bohor
die order of operations bestimmen zu können ist eine Stärke und kein Designfehler.
Dafür musst du [trigger] [t] verstehen. Es ist nicht welches Kabel zuerst, sondern right to left. Hot and cold inlet.
[float] [f] ist auch sehr nützlich.

2D array kannst Du in vanilla z.B. machen, in dem Du entweder, zwei arrays nimmst - oder besser, in einem array die Dimensionen in gerade und ungerade "Spalten" unterteils und entsprechend adressierst.
Wenn Du dir einen Multiplexer baust, kannst Du n-dimsionale arrays machen.

Ich würde @einseinsnull mit vanilla zustimmen, dort kannst Du mit Deken Externals aus dem Netz laden und installieren. Purr Data läuft aber auch.
[coll] kenne ich nicht.
[store] gibts noch.

 

[einseinsnull]

der nachteil ist halt, dass man es nicht sieht welches zuerst verlegt wurde. man muss das immer auswendig wissen, was man zuvor gemacht hat. oder jemand anderes...

die meisten leute die das eine lange benutzen haben, haben große probleme sich von einem auf das andere umzugewöhnen.

ein art [coll] könnte man sich aus [text] zusammenschustern. wenn man sich für die indices aus 1, 2, 3, 4, 5,... beschränkt (zeilennummer)

für databases gibts nix? wäre doch naheliegend, vor allem unter linux.

 

[snowcrash]

der nachteil ist halt, dass man es nicht sieht welches zuerst verlegt wurde. man muss das immer auswendig wissen, was man zuvor gemacht hat. oder jemand anderes...

Im vorherigen Post stehts eigentlich, aber nochmals, da du es wahrscheinlich überlesen hast: Die *zeitliche* Reihenfolge, wann du die Verbindung gezogen hast ist irrelevant, die *Position* der Inlets/Outlets ist ausschlaggebend, eben *von rechts nach links*. Da muss man nix auswendig wissen...

 

[einseinsnull]

das wäre aber dann neu^^

 

[mnb]

Ja, die Regel "Welches Kabel war zuerst" ist ein schwerer Designfehler in pd.

war wohl als kleineres von zwei uebeln (statt "reihenfolge ergibt sich aus der graphischen darstellung") angesehen,
aber man kann ja jederzeit mit triggern die reihnefolge explizit festlegen.
ich faende die graphische reihenfolge zwar elegant fuer eine graphische programmiersprache, aber sehe auch ein,
dass es nervt, wenn man durch "aufraeumen" den patch kaputtmachen kann.

einen wirklichen 'designfehler' sehe ich eher in der blockortientierten arbeitsweise...auch wenn das zum glueck nur
sehr selten ein wirklicher 'showstopper' ist.

Für das, was ich vorhabe, brauche ich eigentlich ein zweidimensionales Array.

wenn es wirklich ein array (fuer floats?) sein soll, dann geht doch auch ein 1dimensionales, und index ist dann
x+(breite*y). fuer text koennte man sich was mit textfile bauen, und dann gibts ja auch noch die data structures...

 

[lacuna]

wohl ein Missverständiss:

Es ist nicht welches Kabel zuerst, sondern right to left. Hot and cold inlet.

soll heißen: right to left inlet. Der linke Inlet ist hot.

aber man kann ja jederzeit mit triggern die reihnefolge explizit festlegen.

Ja, dies sollte man auch tun.

einen wirklichen 'designfehler' sehe ich eher in der blockortientierten arbeitsweise...auch wenn das zum glueck nur
sehr selten ein wirklicher 'showstopper' ist.

Jede digitale (Echtzeit)Audioverarbeitung (mit klassischen CPUs) basiert auf Blocks, - wie sollte man es auch anders machen?
Schön wäre, wenn man die übergeordnete globale Blocksize kleiner als 64 Samples haben könnte und es etwas wie Interrupts geben würde. Mit [fexpr~] bzw. in Subpatches kann man die untergeordnete Blocksize ändern [block~] [switch~].
Falls Du nur in der Control-Ebene rechnen möchtest und kein Audio brauchst, kannst du mit -noaudio flag PD ohne starten.
Mit [pd~] kannst Du via Multithreading mehrere Blocks parallel laufen lassen.

Der Vorteil von Vanilla ist unter anderem auch, dass Du erstmal die begrenzte Sprache lernst, mit der Du alles machen kannst. Und dann eventuell noch fertige Libraries dazu laden kannst.

fuer text koennte man sich was mit textfile bauen

Der Datentyp von "Text" heißt symbol.
[textfile], [writesf~], [readsf~] ect speichern und lesen von der Festplatte, was für einige Anwendungen zu langsam ist.
arrays, [var] [v], [float] [f], [delwrite~] ect speichern im Ram, welcher für einige Daten zu klein sein kann.

@bohor um welchen Datentyp geht es? Wie schnell müssen die Daten verarbeitet werden? Auf welcher Hardware läuft dein PD?

 

[einseinsnull]

naja, ob nun gleich design fehler oder nicht, das hauptproblem ist halt einfach, dass es komplett ander ist als in max.

in max braucht man ja auch hin und wieder trigger, aber meist in komplett anderen situationen.

besonders verwirrend finde ich übrigens wie das dann mit subpatcher weitergeht in pd. in max hast du right to left, davor noch bottom to top, und davor noch low level to high level. wenn man dann etwas in pd macht, wo alles nach der reihenfolge geht, steht man erst mal vorm berg, wenn man eine abstraction lädt. oder 2. denn was geht jetzt im zweifelsfalle vor?

ein max user hat in pd eigentlich permanent das bedürfnis trigger zu benutzen, oder er patcht lustig vor sich hin und plötzlich funktioniert alles nicht mehr wie es sollte. das stört auch beim portieren fast mehr wie ein paar abweichende oder fehlende objekte. (auf die könnte man sich schon vorher einstellen)



bringt max user an den rand der verzweiflung: die fehlende right to left order in pd.

________________

mit größeren arrays und datenbanken zu arbeiten ist defintiv ein problem in pd.

es wäre zwar ungerecht es mit max zu vergleichen, aber in max hast du neben coll noch sql, cellblock, dict, oder missbrauchst einfach eine jit.matrix - die zumindesten für nummern bis 64 bit eine prima multidimensionale datenbank ergibt.
wenn das das alles immer noch nicht langt, kannst du mit java oder javascript weitermachen oder benutzt audio buffer.

für macos9 (achtung: insiderwitz!) hat man sogar [fileout] ❤ und kreiert einfach eigene binäre datenformate.

in pd hast du nur coll und das nur mit purr und da gehts nicht richtig, und auch audiobuffer als 1D lookup table zu verwenden wird ganz schnell kriminell instabil.

insofern freue ich mich ebenfalls auf die kommenden lösungen.

 

[einseinsnull]

wenn es wirklich ein array (fuer floats?) sein soll, dann geht doch auch ein 1dimensionales, und index ist dann
x+(breite*y).

100x100 zeugse in eine zeile schreiben zu wollen bringt neue probleme mit sich, die gelöst werden wollen.

mit audio kann man das so machen, aber mit symbolen, hm.

 

[mnb]

100x100 zeugse in eine zeile schreiben zu wollen bringt neue probleme mit sich, die gelöst werden wollen.

mit audio kann man das so machen, aber mit symbolen, hm.

ich wuerde das eher in ein text schreiben, und ich hab spasseshalber gerade mal 1.3 mb buch da rein geladen: stresst nicht im geringsten.
kommt halt drauf an was man da machen will, pro sample die haeufigkeit von schimpfworten auswerten koennte eng werden...
aber zb. aus den zeilen irgendwelche notenwerte berechnen sollte kein problem sein.

und 10k audio ist ja nichts.

...aber natuerlich haette ich auch gerne eine elegante moeglichkeit mit dem fall 'sparse matrix' umzugehen, etwa um einen sequenzer zu bauen
der sowohl direkten zugriff auf eine position bietet, als auch trotz hoher aufloesung vernuenftig mit dem speicher umgeht...

ansonsten hab ich vor ein paar jahren mal gedacht ich koennte ja mal ein paar m4l patches basteln. bin aber mit max so garnicht
warm geworden, zumindest nicht in den 30 tagen demo-zeitfenster. (hatte da aber auch nicht so viel zeit wie ich gerne gehabt haette...)
geht also auch andersrum (schief)

 

[mnb]

Jede digitale (Echtzeit)Audioverarbeitung (mit klassischen CPUs) basiert auf Blocks, - wie sollte man es auch anders machen?

mit samples.

aber da man in pd recht stressfrei auf 1 reblocken kann, (im gegensatz zu max!) ist das auch nur dann aergerlich, wenn man
etwa 1 sample feedback fuer einen komplexen patch haben will. dann muesste man alles auf blocksize 1 setzen, was aber doch unnoetig rechenzeit kostet.
fuer kleinere subpatches (etwa fm-ops mit feedback, waveguides,...) geht es ja gluecklicherweise problemlos.

 

[einseinsnull]

gibt es denn in pd kein limit, wie lang eine liste überhaupt sein darf?

in max 4 unterstützen fast alle objekte nur die entgegennahme von 255 zeichen (8 bit), insofern macht es da nur wenig sinn, längere listen in ein wie auch immer geartetes array-objekt zu schreiben (auch

• oder [coll] sind in max daher auf 255 listenelemente beschränkt - versenden könnte man theoretisch viel mehr)
  
  man will ja unter umständen die datenbank auch mal zeilenweise auslesen (und wenn es nur ist um die einträge alphabetisch zu sortieren oder +7 zu machen), das ginge dann mit 10,000 einträge nicht mehr.
• 
  
  lustig, "list" in klammern [] kann man hier natürlich gar nicht schreiben (ich doof) ... und ich bekomms auch nicht wieder weg.

 

[einseinsnull]

mit samples.

aber da man in pd recht stressfrei auf 1 reblocken kann

wenn du in max nummern aus einem signal buffer liest, geht das viel schneller wie in echtzeit, und die vectorsize ist insofern egal.

es ist allerdgins recht teuer, daten als samples zu schreiben oder zu lesen, bei 1000 auf einmal könnte sich der scheduler verabschieden.

und audio oder video formate zu benutzen um nummern (oder gar strings) zu speichern ist auch zugegebenermaßen eine notlösung für leute, die gerne frickeln.

einer meiner markov generatoren basiert auf einer matrix, und das war ein ziemlicher krampf bis das halbwegs lief, da formatiert man mehr datensalat zum lesen und schreiben wie für den eigentlichen algorithmus.

wenn bohor eingangs sagt eigentlich sei ihm coll schon zu klein, weiß ich genau was er meint. :/

 

[einseinsnull]

sach mal textfile in pd kann ja gar nicht zeilenweise auslesen?

 

[mnb]

gibt es denn in pd kein limit, wie lang eine liste überhaupt sein darf?

nee, aber sollte ins ram passen, denke ich.

wenn du in max nummern aus einem signal buffer liest, geht das viel schneller wie in echtzeit, und die vectorsize ist insofern egal.

in pd gibts bang~, damit kann man auch fuer jeden block beliebige dinge mit messages machen. da das alles "zwischen" den bloecken
passiert, darf man es nicht uebertreiben. alle 64 samples 1000 werte in eine table schreiben geht, gibt aber schon ausschlaege auf der cpu-anzeige.
fuer einen pink-noise(artigen) patch hab ich die blocksize auf 4096 gesetzt, und rechne da mit entsprechend vielen zufallswerten. geht auch.

sach mal textfile in pd kann ja gar nicht zeilenweise auslesen?

sorry, ich meinte "text" also ohne file. textfile kann nur durchsteppen, text kann auch suchen und so.

 

[einseinsnull]

ich auch sorry... [text]? hab ich nicht gefunden... in pdextended... hat mich schon gewundert... in max gibts auch beides und da isses auch so, dass nur eines davon zeilennummern hat, die man aufrufen kann (bei max ist es allerdings das text object )

das mit bang~ verstehe ich nicht. laut helpfile kann das weder schreiben noch lesen.

in max haben wir hierzu [peek~] (gibt es sowas für pd?), was nummern in buffer schreibt oder davon lesen kann. ich hab zwar nie ausprobiert, ob das threadsafe ist, aber vom grundsatz her ist es dazu geeignet, z.b. auch mehrere samples gleichzeitig auszulesen (was man bei "datenbank" anwendungen ja öfters mal braucht.)

oh je, mit list processing sieht es aber auch mau aus in pd...

 

[mnb]

ich auch sorry... [text]? hab ich nicht gefunden... in pdextended...

pdextended ist schon viele jahre tot, das sollte man heute eigentlich nicht mehr benutzen. vermutlich gibts die funktionalitaet da in irgendeinem external (iem...?)

im aktuellen vanilla kann man via "deken" eigentlich sehr stressfrei alle externals installieren die man so braucht. nur das "vergroesserungsglas" fuer die werteanzeige
von "kabeln" vermisse ich etwas...

das mit bang~ verstehe ich nicht. laut helpfile kann das weder schreiben noch lesen.

bang~ kann eine iteration (ueber den aktuellen block) anstossen (until mit "int+1"-counter), und da kann man dann alles machen was man so moechte.
und das ergebnis dann in eine table screiben und mit tabreceive~ nach "draussen" schicken.

in max haben wir hierzu [peek~] (gibt es sowas für pd?),

tabread und tabwrite(ohne tilde!)?

 

[einseinsnull]

pdextended ist schon viele jahre tot, das sollte man heute eigentlich nicht mehr benutzen.

ohm, ich dachte immer die sind gleich alt. hab zu testzwecken ein extenden auf jedem rechner hier, "falls mal was ist" also vanilla ist neuer?

bang~ kann eine iteration (ueber den aktuellen block) anstossen

ich seh den kontext zur aufgabenstellung nicht. warum willst du mit audiorate daten auslesen wenn das mit metro oder mit der maus viel schneller geht.

tabread und tabwrite(ohne tilde!)?

ja, das scheint zumindest ähnlich zu sein. aber schreibt es auch in audio buffer? oder nur in table...

 

[einseinsnull]

wohl nur in table und array.

 

[lacuna]

table und array sind das Gleiche, nur zwei Namen für das Gleiche.
Das sind (32-Bit)Floats, (binär) im Ram gespeichert. Diese kannst Du auch als Audio ausgeben, bzw. Audio darin speichern.
[tabsend~] [tabreceive~], [tabwrite]] [tabread] [tabread4] [tabwrite~] [tabread4~] usw.
Der Unterschied zwischen Audio- (mit ~)und Control-Rate (ohne ~) ist die Zeit, wann etwas berechnet und ausgegeben wird, und ob die Priorität bei der synchronen Ausgabe (und hier bei CPU-Auslastung etwas fallen lassend, um in Sync zu bleiben, i.e. Xrun),
oder dem schnellen Abarbeiten aller Daten, - auch zu einem späteren Zeitpunkt, ist (nicht in Sync mit dem Sample-Stream und geschieht zwischen den Blocks).

lacuna schrieb:


Jede digitale (Echtzeit)Audioverarbeitung (mit klassischen CPUs) basiert auf Blocks, - wie sollte man es auch anders machen?

mit samples.

dann muesste man alles auf blocksize 1 setzen, was aber doch unnoetig rechenzeit kostet.

ähm...


Und

das mit bang~ verstehe ich nicht. laut helpfile kann das weder schreiben noch lesen.

in max haben wir hierzu [peek~] (gibt es sowas für pd?), was nummern in buffer schreibt oder davon lesen kann.

wenn du in max nummern aus einem signal buffer liest, geht das viel schneller wie in echtzeit, und die vectorsize ist insofern egal.

ja, das scheint zumindest ähnlich zu sein. aber schreibt es auch in audio buffer? oder nur in table...

ich seh den kontext zur aufgabenstellung nicht. warum willst du mit audiorate daten auslesen wenn das mit metro oder mit der maus viel schneller geht.

*hust*

Und

right to left inlet. Der linke Inlet ist hot.

aber man kann ja jederzeit mit triggern die reihnefolge explizit festlegen.

Ja, dies sollte man auch tun.

bringt max user an den rand der verzweiflung: die fehlende right to left order in pd.

hallo? merkst Du was?

besonders verwirrend finde ich übrigens wie das dann mit subpatcher weitergeht in pd.

mit [trigger b b f b f f] wird die gesamte Kette der Control-Ebene des rechtesten Outlets zuerst vollständig abgearbeitet, dann 2. Outlet von rechts usw.



Vanilla wird von Miller Puckette (Erfinder von Max und PD) aktiv weiter entwickelt.

"Note that the libraries that were available in Pd extended 0.43 are availkable in 'deken' as “v00-extended”" (und ist trotzdem dead).

 

[mnb]

also vanilla ist neuer?

ja, viel! und mit dem deken-plugin kriegt man auch (fast) alles was man so an externals braucht einfach auf den rechner.

ich seh den kontext zur aufgabenstellung nicht. warum willst du mit audiorate daten auslesen wenn das mit metro oder mit der maus viel schneller geht.

um daten "schneller als in echtzeit" innerhalb eines blocks zu bearbeiten.
man kann sich (im rahmen der 'blockorientiertheit', bzw. in einem block(*)) alles bauen was man will (also auch komplette eigene klangsynthesen), mit allen
message-objekten die es so gibt. die effizienz ist aber eher so mittel...

(*) der in diesem fall aber leider nicht < 64 samples sein darf! vielleicht ein erbe von max?

ja, das scheint zumindest ähnlich zu sein. aber schreibt es auch in audio buffer? oder nur in table...

in table, aber, wie gesagt, mit tabreceive~ kriegt man das dann zum audio-out.

 

[einseinsnull]

um daten "schneller als in echtzeit" innerhalb eines blocks zu bearbeiten.

aber data rate ist doch viel "schneller".

 

[einseinsnull]

mit [trigger b b f b f f] wird die gesamte Kette der Control-Ebene des rechtesten Outlets zuerst vollständig abgearbeitet, dann 2. Outlet von rechts usw.

ich denke du hast fundemantal missverstanden was "right to left order" überhaupt ist.

irgendwelche "inlets" haben mit scheduling und reihenfolge rein gar nichts zu tun und ein trigger ist in meinem beispiel überhaupt nicht zu sehen. und für verschiedene subpatches ist es nicht mal eine notlösung.

 

[lacuna]

ich denke du hast fundemantal missverstanden was "right to left order" überhaupt ist.

lol, achso und ich dachte Du seist der jenige, der nicht verstanden hat?

irgendwelche "inlets" haben mit scheduling und reihenfolge rein gar nichts zu tun

Im vorherigen Post stehts eigentlich, aber nochmals, da du es wahrscheinlich überlesen hast: Die *zeitliche* Reihenfolge, wann du die Verbindung gezogen hast ist irrelevant, die *Position* der Inlets/Outlets ist ausschlaggebend, eben *von rechts nach links*.

das wäre aber dann neu^^

Herzlichen Glückwunsch!

(*) der in diesem fall aber leider nicht < 64 samples sein darf! vielleicht ein erbe von max?

Ja vielleicht. Der scheduler von PD (im main-loop) mag auch die 64. [bang~] z.B. arbeitet auch bei kleineren Blocksizes als 64. Messages werden nicht öfter weitergereicht.

um daten "schneller als in echtzeit" innerhalb eines blocks zu bearbeiten.

aber data rate ist doch viel "schneller".

oh ja so ist es. schneller als in echtzeit.

ach übrigends:
mit [trigger] lässt sich die reihenfolge bestimmen. lol

 

[einseinsnull]

lol, achso und ich dachte Du seist der jenige, der nicht verstanden hat?
...
mit [trigger] lässt sich die reihenfolge bestimmen. lol

ja, das ist das, was du und dein mit-troll snowcrash nicht verstanden habt: right to left order hat mit dem trigger objekt nichts zu tun.

unter "right to left order" versteht man, dass diese order in der gesamten runtime automatisch immer vorhanden ist.

das ist in max der fall - und in pd nicht.

in pd benutzt man trigger, um eine right to left order herzustellen - in max benutzt man trigger hingegen um die in der runtime global vorhandene right-to-left order zu durchbrechen, wenn man sie mal nicht braucht.

die right-to-left ausgabe des trigger objects verhilft pd nicht dazu, right to left order zu "haben". sie hilft dir lediglich dabei, einzelne nachrichten zu ordnen, wenn du keinen bock dazu hast, darauf zu achten, in welcher reihenfolge du verbindungen herstellst und erhöht entsprechend die lesbarkeit.

gäbe es in pd right to left order, bräuchtest du das trigger object überhaupt nicht um sicherzustellen, dass das linke inlet von [- ] die "5" zuerst bekommt. du brauchst es nur, weil in pd "first before last" gilt.

das lässt sich übrigens alles in der bedienungsanleitung oder auf den einschlägigen pd foren nachlesen.

oh ja so ist es. schneller als in echtzeit.

wenn du ein signal im RAM als stream ausliest, liest du 44,1 samples pro millisekunde aus.

wenn du es hingegen mit sequentiellen nachrichten ausliest, kannst du je nach rechenleistung deiner CPU hunderte oder tausende samples innerhalb von einer millisekunde auslesen.

im übrigen braucht der threadstarter ja letztlich data rate, und alleine schon derswegen erübrigt sich die frage, was man nehmen würde, wenn man einen buffer als "datenbank" missbraucht.

ansonsten endet die behindertenbetreuung jetzt an dieser stelle.

 

[mnb]

ähm...

samples, und bloecke die samples enthalten sind vom konzept her unterschiedliche dinge. und in der praxis (offensichtlich) ebenfalls.
ich kann mir auch gerade keine implementierung vorstellen, wo beides identisch waere, mag aber auch an der schlafdauer liegen.

was gleich ist, ist das ergebnis was man mit bloecken groesse 1 und samples berechnen kann. im ersten fall eben mit mehr geroedel.
in pd leider mit soviel geroedel, dass das reblocken eines ganzen patches auf 1 meistens nicht praktikabel ist.
will man ja zum glueck auch nicht soo oft.

 

[Soljanka]

Ich arbeite die meiste Zeit mit dg. Manchmal aber auch mit tk oder mit rv wenn xu grad nicht zur H ist.
wk hatte ich ausprobiert, komme mit dg aber am ende besser zurecht.

 

[bohor]

pd = pure data, eine graphische Programmniersprache. Ähnliches Konzept wie Max/MSP, im Gegensatz zu diesem ist es aber umsonst, verlangt keine Registrierung und speichert auch keine Userdaten.

Ich mag die Abkürzeritis auch nicht besonders, aber die Nutzer nennen es wirklich immer und nur "pd".