Pure Data / PD - Austausch - Automatonism

[Drumfix]

So gehts bei Ubuntu:

Im Pd Hauptfenster:

Medien->ALSA-MIDI auswaehlen
Medien->Midi Einstellungen Anzahl Midi In und Out festlegen.
Anschliessend die so erzeugten Alsa Midi Ports mit aconnect, qjackctl etc mit den physikalischen Ports verbinden

 

[mnb]

also ich starte mein pd immer mit einem script, das sieht so aus:

/home/mnb/pd048/bin/pd -noautopatch -alsamidi & sleep 4s
aconnect 'nanoKONTROL' 'Pure Data'
aconnect 'nanoPAD' 'Pure Data'
aconnect 'MIDISTART MUSIC 25' 'Pure Data'
aconnect 'M Audio Audiophile 24/96' 'Pure Data'
aconnect 'Pure Data':1 'M Audio Audiophile 24/96'

ich verwende also die namen der geraete, nicht die numerischen ids (damit hatte ich auch dauernd probleme)
mit den namen klappt das aber voellig stressfrei.

 

[tholan]

Hi und Danke soweit,
Ich starte pd:
"pd -noautopatch -alsamidi"
-pfundst
dann:
"aconnect 'USB MIDI Interface' 'Pure Data' "
-Fehlermeldung:
"ungültige Ziel-Adresse Pure Data"

" 'USB MIDI Interface' " hat aconnect klaglos gefressen,

"Pure Data " müßte nach dem Start mit Parameter "-alsamidi" wohl auch als Client
bei "aconnect -l" auftauchen?
-tuts aber leider nicht, das taucht da nirgendwo auf.

 

[tholan]

Sooo, ich habs mit der guten alten OSS-Methode zum Laufen gebracht:
Leider gibts unter Raspbian kein /dev/midi[x] mehr
und pd scheint auf Selbiges zu bestehen, wählt man für den Midiport "oss".
"ln -s /dev/snd/midiC1D0 /dev/midi1" tuts und im Audio- Miditestfenster
von pd habe ich endlich ne Reaktion auf Tastendruck.
Irgendwas muß hier unter Raspbian sauer sein mit Alsa und MIDI.
Den Midiport von Qsynth, bzw. fluidsynth habe ich auch nur mit "oss-Ansprache" zum Laufen bringen können.

 

[Drumfix]

Deine Kommandozeile sollte in etwa so aussehen:

pd -noautopatch -alsamidi -midiindev 1 -midioutdev 1

Falls du mehrere Alsaports erzeugen willst, muessen die dan via Komma getrennt werden, z.B.

pd -noautopatch -alsamidi -midiindev 1,2 -midioutdev 1,2,3,4

=> 2 inports, 4 outports

 

[tholan]

Hi Drumfix,
mit dem Aufruf, wie Du ihn beschreibst:

 pd -noautopatch -alsamidi -midiindev 1 -midioutdev 1

bekomme ich leider nur folgende Meldung im Startfenster bei PD:

Opened Alsa Client 128 in:1 out:1

Keine Ahnung, was "Client 128" sein soll,
der erscheint nicht bei "aconnect -l"
und funktionieren tut MIDI leider nicht.

Ich habe das nochmal in der Shell mit dem Zusatzparameter "-verbose"
gestartet, da erscheint beim Start in der Shell folgender Text:

Pd-0.47.1 ("") compiled for Debian (0.47.1-3) on 2016/11/28 at 20:56:10 UTC
port 5400
TCL_LIBRARY="/usr/lib/puredata/lib/tcl/library" TK_LIBRARY="/usr/lib/puredata/lib/tk/library"   wish "/usr/lib/puredata/tcl//pd-gui.tcl" 5400
Waiting for connection request...
/usr/lib/puredata/bin/pd-watchdog
... connected

Nochmal, nach Helpfile das:

pd -noautopatch -alsamidi -midiaddindev 'USB MIDI Interface' -midiaddoutdev 'USB MIDI Interface'

und das:

pd -noautopatch -alsamidi -midiaddindev 'USB MIDI Interface 1' -midiaddoutdev 'USB MIDI Interface 1'

probiert.
Ergebnis leider nur Fehlermeldung:

Couldn't find MIDI input device: USB MIDI Interface
Couldn't find MIDI output device: USB MIDI Interface

bzw. :

Couldn't find MIDI input device: USB MIDI Interface 1
Couldn't find MIDI output device: USB MIDI Interface 1

Der symbolische Link bei meiner OSS-Methode "ln -s /dev/snd/midiC1D0 /dev/midi1"
wird leider auch bei jedem Raspbian Start vom OS gelöscht.

Hab jedenfalls vielen Dank für Deine Bemühungen,
irgendwie hatte ich das auch schonmal hingekriegt,
über diesen besch.. "systemd" einen persistenten /dev/midi-Link hinzukriegen.

 

[Drumfix]

Willst du mich veraeppeln?

pd -noautopatch -alsamidi -midiindev 1 -midioutdev 1

dann

aconnect -l

Client 0: 'System' [Typ=Kernel]
    0 'Timer           '
    1 'Announce        '
Client 14: 'Midi Through' [Typ=Kernel]
    0 'Midi Through Port-0'
Client 24: 'MidiSport 2x4' [Typ=Kernel]
    0 'MidiSport 2x4 MIDI 1'
    1 'MidiSport 2x4 MIDI 2'
    2 'MidiSport 2x4 MIDI 3'
    3 'MidiSport 2x4 MIDI 4'
Client 128: 'Pure Data' [Typ=User]
    0 'Pure Data Midi-In 1'
    1 'Pure Data Midi-Out 1'

dann

aconnect  'Pure Data:1' 'MidiSport 2x4:0'
aconnect  'MidiSport 2x4:0' 'Pure Data:0'

 

[tholan]

Ups!
...in der Tat, das hatte ich so noch nicht probiert.
aconnect -l zeigt nach dem Start von pd "client 128"
MIDI pfundst aber trotzdem nicht.
Der Miditest unter Pulldownmenü "Medien"
zeigt keine Reaktion bei MIDI-Tastatureingabe,
wenn ich das mit OSS und /dev/midi1 starte (nachdem ich es angelegt habe)
läufts.

...äääh,
dann mach ich vielleicht nochn "aconnect" :embarrassed:

 

[tholan]

Man, wattn akademischer Schiet...

aconnect 20 'Pure Data:0'

---das isses!
Mein Dank wird Dir auf Ewigkeit nachschleichen!

 

[Orphu]

Ist es eigentlich möglich das ganze per Midi Controller zu bedienen?

 

[mnb]

Ist es eigentlich möglich das ganze per Midi Controller zu bedienen?

ganz klares jein: bei automatonism scheint das nicht vorgesehen zu sein. mit minimalen kenntnissen in pd kann man sich das aber selber bauen.
oder das entsprechende "midi2cv" modul aus meinen "pure modules" oder besser "vvd" reinkopieren. dass das dann ausserhalb der prestverwaltung
steht duerfte ja egal sein (oder vielleicht sogar erwuenscht) suboptimal ist das trotzdem... was man gerne haette waere ein
"learn-button", und dann wie anderswo auch an fader und gui wackeln, und das fuer alles was man 'mappen' moechte. und das midi 0..127 range
wuerde man ja auch gerne auf einen beliebigen wertebereich abbilden... (hab ich aber noch nicht fertig...)

 

[Orphu]

... was man gerne haette waere ein
"learn-button", und dann wie anderswo auch an fader und gui wackeln, und das fuer alles was man 'mappen' moechte. und das midi 0..127 range wuerde man ja auch gerne auf einen beliebigen wertebereich abbilden... (hab ich aber noch nicht fertig...)

+1 für das

Was mir auch noch so ein bissl fehlt ist eine Möglichkeit das erstellte zu einer externen Clock zu syncen. Hatte dazu auch schonmal Kontakt zum Entwickler. Leider gibts bisher kein Modul dafür.

 

[Orphu]

Folgendes hatte Johan auf die Frage bezüglich externe Clock beantwortet:

"
Regarding external syncing, it depends, what exactly are you trying to sync it to? Automatonism has its own variation of the PD signal flow so it will not accept bangs or control messages. If you are trying to send it a bang, you need to do this before patching into a CLOCK input of one of my modules:

[bang( ie. your sync
|
[1 0, 0 1 1(
|
[vline~]
|
into the module
"

Kann ich statt des Bang zum Anfang einfach ein Clock-Signal nehmen oder wie ist das zu verstehen?

 

[Rastkovic]

Mal ein Video zu dem Automatonism Teil.....

 

[mnb]

Regarding external syncing, it depends, what exactly are you trying to sync it to?

genau: hat man irgendein sync-"signal" das aus 'messages' besteht, zb. midi-events, die man in 'bangs'
konvertieren kann, dann braucht man sowas wie da angedeutet: ein vline~ objekt um daraus eine
kurze impuls-huellkurve zu erzeugen. hat man dagegen einen "echten" audio-sync-impuls von der soundkarte oder so, so kann man den direkt an die sync-ins der module anstoepseln, vorausgesetzt, das signal ist halbwegs clean und laut genug. (im zweifelsfall multiplizieren und clippen) die parameter
in den threshhold~ objekten in automatonism finde ich da nicht hunderprozentig gut, eventuell waere
eine 'debounce-time'>0 besser, aber wenn 0 und 1 gut zu unterscheiden sind, sollte es auchso klappen...

 

[Orphu]

Hi,
mache ich irgendetwas verkehrt? Ich benutze den Puls aus der Machinedrum über das External Audio Objekt. Läuft stabil mit dem Trigger-Sequenzer und allen anderen Sequenzer-Objekten. Nehme ich aber das gleiche Puls/Clock-Signal für den ADSR-Generator kommt nix am Eingang an immer nur sporadisch. Folge ist das die ADSR für den VCA natürlich nicht richtig funktioniert. Ist das ein Bug oder hab nur ich das Problem? Gibt es eine Möglichkeit das Puls-Signal nochmal anzuheben/ zu verstärken?

 

[mnb]

mit adsr sollte das auch nicht funktionieren, da die ein "gate" als input erwartet. d, slope und ahr sollten aber auch mit "trigger" gehen.
und ein "trigger to gate" modul scheints da ja nicht zu geben.

 

[Orphu]

mit adsr sollte das auch nicht funktionieren, da die ein "gate" als input erwartet. d, slope und ahr sollten aber auch mit "trigger" gehen.
und ein "trigger to gate" modul scheints da ja nicht zu geben.

Danke dir für den Hinweis. Habe es auch gerade nochmal in der Hilfe-Datei des ADSR-Objekts gelesen.

 

[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? :D

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) ;)