Pure Data / PD - Austausch - Automatonism

[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".

 

[einseinsnull]

ich kann mir auch gerade keine implementierung vorstellen, wo beides identisch waere, mag aber auch an der schlafdauer liegen.

in max´s gen und in kyma hast du eine vectorsize von 1 samples. (oder innerhalb des pd externals biquad~ for that matter.) ob es noch sinnvoll ist, das dann "vector" zu nennen, weiß ich allerdings auch nicht.

mit 32 bist du immer gut beraten. 32 samples sind bei 44100 khz samplerate und einem scheduler von 1 ms noch ausreichend, um theoretisch fehlerfreies timing zu haben. 32 ist auch das, was VST/AU/protools usw nutzen.

8 geht mit vielen IOs noch, bei mehr als 64 oder 128 sehe ich persönlich in max/mac kaum noch CPU einsparungen (mit ausnahme von eingeschleiften vst plug-ins)

 

[einseinsnull]

so, bohor, haste denn was datenbankiges gefunden?

wenn du list processing brauchst musst du schreien, dann schicke ich ne schubkarre voll rüber.

 

[mnb]

in max´s gen und in kyma hast du eine vectorsize von 1 samples. (oder innerhalb des pd externals biquad~ for that matter.) ob es noch sinnvoll ist, das dann "vector" zu nennen, weiß ich allerdings auch nicht.

eher nicht.

und mit bang~ kann man, wie ich versucht habe zu erklaeren, auch direkt auf den samples rummachen.
(so wie innerhalb eines externals, nur lahmarschiger)
ist nur doof im zusammenhang eines komplexeren patches, und eben solche will man ja schon bauen.
aber wie gesagt, ist zum glueck eher selten ein ernstes problem.
zb. bei einem patch mit vielen fm-ops die sich alle gegenseitig und selber modulieren, haette ich gerne alles auf 1 reblocked,
habs nach einem blick auf die cpu-anzeige aber gelassen...

mit 32 bist du immer gut beraten.

fuer eine dsp-sprache ist jedes solche unnoetige delay ziemlicher mist, und man verbringt viel zeit damit darum herumzuprogrammieren...
fuer digitale eurorackmodule mag das ok sein...

 

[bohor]

so, bohor, haste denn was datenbankiges gefunden?

Sorry - ich war in den letzten Tagen leider mit komplett anderen Dingen beschäftigt. Erst morgen kann ich mir mal ankucken, was ihr da für mich ausgebreitet habt.

Ich denke aber, trotz heftiger Limitierungen komme ich mit Array klar: Ich muss halt mehrere verwenden.

 

[einseinsnull]

fuer eine dsp-sprache ist jedes solche unnoetige delay ziemlicher mist

es ist halt einfach effektiver, vor allem wenn noch 17 layer OS gedöns drunterliegen. aber es stört auch manchmal, das ist klar. wenn man so wie ich für C++ zu dumm und zu faul ist, dann muss man eben nehmen, was andere gemacht haben.

ich mag es, ausschließlich auf einer ebene zu arbeiten, wo das paradigma immer das gleiche ist. insofern ist mir dann auch gen in max eher suspekt, als dass ich mich über die neuen möglichkeiten freuen könnte.

Erst morgen kann ich mir mal ankucken

lohnt sich glaube ich nicht.

 

[bohor]

lohnt sich glaube ich nicht.

irgendwie kann ich nicht folgen. es muss doch wieauchimmer möglich sein, eine liste mit schlüssel-/wert-paaren zu führen, die ca. 100 zeichen lang ist!? beides müssen im schlimmsten fall nur bytes sein. also 17->100, 18->108, 19->111? So dass ich 19 in das array schicke und 111 rauskriege? mehr will ich doch schon gar nicht mehr!?

 

[einseinsnull]

nein, ich meinte es lohnt sich für dich nicht, den bisherigen thread zu lesen.

deine datenbank bekommen wir schon hin.

was wirds denn, ein transition table? muss es statisch sein oder willst du auch reinschreiben?

mit welchen objekten man das am besten macht, keine ahnung. bei vanilla (also vanilla vanilla) scheint nicht viel listen zeugs dabei zu sein. sowas wie [iter] wird sicher geben, und die uralten james mccartney list operators auch. aber wie siehts z.b. mit [zl] aus?
wenn du sowas findest, kannst du den rest mit meinen max abstractions machen.

mit bytes is nix, in pd ist immer alles float, auch wenns anders aussieht.^^

 

[lacuna]

eine liste mit schlüssel-/wert-paaren

2

die ca. 100 zeichen lang ist

x 100

= 200 Einträge

Eine Tabelle mit 100 Spalten und darin jeweils zwei Werten. = eine Tabelle mit 200 Spalten.

Entweder Du wechselst ab: gerade, ungerade
oder du nimmst für die ersten 0 bis 99 und 100 bis 199 für die zweiten.

beides müssen im schlimmsten fall nur bytes sein

Wenn Dein Ram nicht super klein ist, kannst Du ja bei den 32 Bit (4 Bytes) bleiben.

Hier wird unter einem irreführenden Threadtitel, die Lösung am Ende erklärt:

Arrays in Pure data are not really arrays....

In PD you can only store one value per x step. That means you can not make a sequencer that uses polyphony. In real world, arrays are used to store multiple values and can have even 3 or more dimentions, values could be stored on any point without one aff...

forum.pdpatchrepo.info

Kopiere folgendes in ein Texteditor und speichere es unter 234Matrix.pd

#N canvas -9 -9 1920 976 12;
#N canvas 0 50 450 250 (subpatch) 0;
#X array array1 24 float 3;
#A 0 0 0 0 0 0 0.165468 0.0602878 0 -0.352518 0 0.395683 0 0 0 0 0.400002
0.642861 -0.357145 -0.371431 -0.614286 -0.77143 -0.828573 0 0;
#X coords 0 1 24 -1 200 140 1 0 0;
#X restore 291 159 graph;
#X floatatom 94 161 5 0 1 0 - - -;
#X floatatom 158 161 5 0 2 0 - - -;
#X floatatom 218 162 5 0 3 0 - - -;
#X floatatom 218 301 5 0 0 0 - - -;
#X obj 94 184 * 12;
#X obj 158 184 * 4;
#X obj 158 240 +, f 5;
#X obj 158 212 t b f;
#X obj 218 270 +, f 5;
#X obj 218 241 t b f;
#X obj 218 372 tabread array1;
#X floatatom 218 398 5 0 0 0 - - -;
#X text 136 63 2x3x4 Matrix;
#X obj 66 371 tabwrite array1;
#X floatatom 34 243 5 0 0 0 - - -;
#X obj 34 268 t b f;
#X msg 383 374 pd \; array1 const 0;
#X text 348 328 24 Spalten;
#X obj 497 159 vsl 15 140 -1 1 0 0 empty empty empty 0 -9 0 10 -262144
-1 -1 6950 0;
#X msg 497 129 set \$1;
#X text 75 243 eingabe;
#X text 256 399 ausgabe;
#X obj 497 102 r ausgabe;
#X obj 497 314 s eingabe;
#X obj 34 217 r eingabe;
#X obj 218 421 s ausgabe;
#X obj 367 112 hradio 15 1 0 4 empty empty empty 0 -8 0 10 -262144
-1 -1 0;
#X obj 376 87 hradio 15 1 0 3 empty empty empty 0 -8 0 10 -262144 -1
-1 0;
#X obj 383 63 hradio 15 1 0 2 empty empty empty 0 -8 0 10 -262144 -1
-1 0;
#X obj 291 304 hsl 200 15 0 23 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 0 1;
#X obj 383 413 s ausgabe;
#X text 490 387 clear!;
#X connect 1 0 5 0;
#X connect 2 0 6 0;
#X connect 3 0 10 0;
#X connect 4 0 11 0;
#X connect 4 0 14 1;
#X connect 4 0 30 0;
#X connect 5 0 7 0;
#X connect 6 0 8 0;
#X connect 7 0 9 0;
#X connect 8 0 7 0;
#X connect 8 1 7 1;
#X connect 9 0 4 0;
#X connect 10 0 9 0;
#X connect 10 1 9 1;
#X connect 11 0 12 0;
#X connect 12 0 26 0;
#X connect 15 0 16 0;
#X connect 16 0 4 0;
#X connect 16 1 14 0;
#X connect 17 0 31 0;
#X connect 19 0 24 0;
#X connect 20 0 19 0;
#X connect 23 0 20 0;
#X connect 25 0 15 0;
#X connect 27 0 3 0;
#X connect 28 0 2 0;
#X connect 29 0 1 0;

Wenn Du das Ganze als Abstraction mehrfach nutzen möchtest, benötigst Du $0 bei der Namensgebung des arrays, damit jede Instanz ein eigenes Array nutzt.

Ich denke aber, trotz heftiger Limitierungen komme ich mit Array klar: Ich muss halt mehrere verwenden.

Auch das ist möglich. Bei der Namensgebung kannst Du 1-array und 2-array usw. nehmen und diese mit $1 dann adressieren.
Wenn dann noch $0 zwecks abstraction dazu kommt wird es etwas komplizierter:

#N canvas -9 -9 1920 976 12;
#X obj 359 217 f \$0;
#X obj 359 192 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X floatatom 435 244 5 0 0 0 - - -;
#N canvas 0 50 450 250 (subpatch) 0;
#X array 1-\$0-array 100 float 3;
#A 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0;
#X coords 0 1 100 -1 200 140 1 0 0;
#X restore 12 31 graph;
#X floatatom 330 142 5 0 0 0 - - -;
#X floatatom 611 165 5 0 0 0 - - -;
#X msg 330 308 set \$1-\$2-array;
#X obj 330 277 pack, f 9;
#X obj 643 414 tabwrite;
#X floatatom 696 389 5 0 0 0 - - -;
#N canvas 0 50 896 604 (subpatch) 0;
#X array 2-\$0-array 100 float 3;
#A 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0;
#X coords 0 1 100 -1 200 140 1 0 0;
#X restore 12 185 graph;
#X obj 330 50 vradio 15 1 0 3 empty empty empty 0 -8 0 10 -262144 -1
-1 0;
#X obj 330 111 + 1;
#X text 345 63 2;
#X text 345 77 3;
#X text 345 49 1;
#N canvas 0 50 450 250 (subpatch) 0;
#X array 3-\$0-array 100 float 3;
#A 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0;
#X coords 0 1 100 -1 200 140 1 0 0;
#X restore 12 340 graph;
#X obj 359 165 loadbang;
#X text 273 142 arraynr;
#X obj 611 190 t b f;
#X obj 696 270 f;
#X obj 729 270 + 1;
#X obj 784 272 f \$0;
#X obj 784 247 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X text 801 244 clear;
#X msg 784 297 pd \; 1-\$1-array const 0 \; 2-\$1-array const 0 \;
3-\$1-array const 0 \;;
#X obj 714 140 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X msg 714 160 0;
#X text 730 138 reset;
#X obj 611 87 random 200;
#X obj 611 111 - 100;
#X obj 611 135 / 100;
#X text 654 165 wert;
#X obj 696 303 mod 100;
#X obj 433 280 outlet;
#X obj 611 62 until;
#X msg 611 35 100;
#X obj 611 10 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X text 630 7 zufallswerte;
#X obj 359 244 t b f;
#X text 394 218 individuelle ID dieser abstraction;
#X connect 0 0 2 0;
#X connect 0 0 39 0;
#X connect 1 0 0 0;
#X connect 4 0 7 0;
#X connect 5 0 19 0;
#X connect 6 0 8 0;
#X connect 7 0 6 0;
#X connect 9 0 8 1;
#X connect 11 0 12 0;
#X connect 12 0 4 0;
#X connect 17 0 1 0;
#X connect 19 0 20 0;
#X connect 19 1 8 0;
#X connect 20 0 21 0;
#X connect 20 0 33 0;
#X connect 21 0 20 1;
#X connect 22 0 25 0;
#X connect 23 0 22 0;
#X connect 26 0 27 0;
#X connect 26 0 23 0;
#X connect 27 0 20 1;
#X connect 27 0 9 0;
#X connect 29 0 30 0;
#X connect 30 0 31 0;
#X connect 31 0 5 0;
#X connect 33 0 9 0;
#X connect 35 0 29 0;
#X connect 36 0 35 0;
#X connect 37 0 36 0;
#X connect 39 0 11 0;
#X connect 39 1 7 1;
#X connect 39 1 34 0;

 

[bohor]

Danke an beide!

was wirds denn, ein transition table? muss es statisch sein oder willst du auch reinschreiben?

Nach dem Start muss das gesuchte Objekt per loadbang mit einem leider sehr komplexen Algorithmus gefüllt werden, anschließend wird es nur noch gelesen.

Ich habe eben mit dem Objekt array in purr data herumgespielt; auch das funktioniert nicht, wie ich es mir vorstelle. In den nächsten Tagen sollte ich eigentlich dazu kommen, mir das mal in Vanilla anzusehen.

in pd ist immer alles float, auch wenns anders aussieht.

Ja, leider. Für MIDI-Zwecke normalerweise völlig unnötig.

Eine Tabelle mit 100 Spalten und darin jeweils zwei Werten. = eine Tabelle mit 200 Spalten.

Nach gängiger Terminologie: Einer Tabelle mit 100 Zeilen und zwei Spalten.

Hier wird unter einem irreführenden Threadtitel, die Lösung am Ende erklärt: https://forum.pdpatchrepo.info/...

Der Server scheint grade jetzt nicht erreichbar. Wir wollen sehen, wie sich das entwickelt.

Kopiere folgendes in ein Texteditor und speichere es unter 234Matrix.pd

Werd ich versuchen. Das Beispiel ist sehr aufwändig, normalerweise schreckt mich sowas eher ab. Ich denke, ich krieg das schon hin – sobald ich ein Objekt gefunden habe, bei dem ich Einträge (Schlüssel-/Wert-Paare) anlegen und auslesen kann. Ich hoffe im Moment auf array in Vanilla. Schade, purr data sieht optisch eleganter aus.

Wenn Du das Ganze als Abstraction mehrfach nutzen möchtest, benötigst Du $0 bei der Namensgebung des arrays, damit jede Instanz ein eigenes Array nutzt.

Ja, ich werde ein Dutzend Instanzen meines Objekts brauchen. Auch darum mach ich mir keine Gedanken.

 

[bohor]

[...] sobald ich ein Objekt gefunden habe, bei dem ich Einträge (Schlüssel-/Wert-Paare) anlegen und auslesen kann.

tabread und tabwrite scheinen zu ermöglichen, was ich brauche, allerdings extrem rudimentär, wenn man es mit modernen Programmiersprachen vergleicht. Es wird viel Drumherumcode nötig sein, der die Sache aufbläht und unübersichtlich macht.. - Nunja, alles hat seinen Preis.

 

[lacuna]

das funktioniert nicht, wie ich es mir vorstelle. In den nächsten Tagen sollte ich eigentlich dazu kommen, mir das mal in Vanilla anzusehen.

ist in purr data, pd extended und vanilla das Gleiche

Schade, purr data sieht optisch eleganter aus.

kannst Du ja benutzen. Ist auch active, allerdings gibt es noch hier und da Probleme mit der korrekten Darstellung aufgrund der geänderten GUI.
Vanilla ist schlanker und hat Deken. Spätestens wenn Du PD auf Embedded-Boards nutzen möchtest, brauchst Du Vanilla.
Es ist gut zu wissen, was von deinen Patches Vanilla ist und was Externals sind, damit es überall läuft.

das gesuchte Objekt

sobald ich ein Objekt gefunden habe

wenn Du Vanilla lernst, - also dir die paar Objekte zu eigen machst, brauchst Du nicht mehr "nach Objekten suchen", sondern kannst problemorientiert arbeiten.
In Vanilla: Hilfe > Liste aller Objekte
Wenn Du dann so weit bist, kannst Du dir hier und da Libraries, Externals dazu suchen.

Wenn Du nicht zu Beginn das Basisvokabular lernst (Vanilla), kannst Du nicht in der Sprache denken und suchst immer nach Objekten, die machen sollen, was du möchtest.

Das Beispiel ist sehr aufwändig, normalerweise schreckt mich sowas eher ab.

Ich weiß was Du meinst, aber dieses Beispiel ist nicht kompliziert. Vieles an dem Patch dient zur Veranschaulichung. Das eigentliche Multiplexen besteht nur aus [*] und [+].

Server scheint grade jetzt nicht erreichbar

you can implement multidimensional arrays it by hand,
by having every "dimension" be a multiple of the other dimensions.
so if you have for instance a 2X3X4 matrix you would have 24 entries.
index into the array by multiplying by the lower dimensions:
to get to the first index multiply by 12 (so for instance index 1 of the first dimension actually starts at position 12 in the array),
then multiply the second index by 4 and add it to the first, and finally add the final index with no multiplication.
this is actually the way multidimensional matrices are implemented in c
... or use iemmatrix

ich werde ein Dutzend Instanzen meines Objekts brauchen.

Dann lerne $0 , auch in Verbindung mit arrays und schaau Dir mein zweites Patch an.

$0-my array or using $0 in array names

If I want to work with an array within an abstraction and make it strictly local naming the array $0-my-table or such, it won't work when actually using the abstraction and I continously receive: "error: 0-my-table: no such table" What am I missing?

forum.pdpatchrepo.info

Ja, leider. Für MIDI-Zwecke normalerweise völlig unnötig.

Also geht es darum Midi zu verarbeiten?
Zu Deiner Hardware schweigtst Du.
Wenn es wirklich wichtig ist Ram zu sparen, kannst Du natürlich nach der gleichen Methode die 4-Bytes multiplexen. So wird das Array für Humans immer unleserlicher.

 

[mnb]

irgendwie kann ich nicht folgen. es muss doch wieauchimmer möglich sein, eine liste mit schlüssel-/wert-paaren zu führen, die ca. 100 zeichen lang ist!? beides müssen im schlimmsten fall nur bytes sein. also 17->100, 18->108, 19->111? So dass ich 19 in das array schicke und 111 rauskriege? mehr will ich doch schon gar nicht mehr!?

ist mir nicht klar, ob du nun ein array oder name/value paare willst. (ja, in vielen 'modernen' sprachen wird das gerne vermischt...) geht beides.
array (table) ist sehr einfach/rudimentaer, liefert aber eben nur index->wert. mit "text" (ab pd 0.49) hast
du allerdingas alles schon fertig, und kannst sowohl suchen, als auch eintraege einfuegen. in den help-patches zu "text" finden sich beispiele fuer alles.

gibt es doppelte 'names'? sind die 'names' geordnet?
da midi zeitmaessig eher unkritisch sein duerfte, kannst du dir die funktionalitaet fuer arrays aber auch selber bauen.

als anfaenger muss man natuerlich schon oefter mal "objekte suchen" rechtsklick ins leere/help liefert eine liste.