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

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?
 
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.
 
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:

1711563144782.png

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.
1711563842008.png
 
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...
 
Zuletzt bearbeitet:
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?
 
Jetzt wo was offiziell ist?

das, was im zweiten teil des satzes steht.


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?
 
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.
 
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".
 
Zuletzt bearbeitet:
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.

1711634744265.png

Ich zerbreche mir schon ewig den Kopf darüber wie man das mit vier Potis und einem Encoder hinbekommen kann.
 
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?
 
funktioniert hier:

steps-test.gif

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.
 
Zuletzt bearbeitet:
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.
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.

1711907681424.png
 
Zuletzt bearbeitet:
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.
 
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.

1712057715303.png

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.
 

Anhänge

  • color-test.zip
    465 Bytes · Aufrufe: 0
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.
 
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
 
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.

1712215143497.png

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

1712215351102.png

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

1712215796154.png

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.:
1712219235146.png oder 1712219202538.png
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.
 
color help.png

Das nächste Mal werde ich genauer hinschauen
Eine sinnvolle Abstraction wäre dann z. B.:
1712219235146.png
oder
1712219202538.png
das sind sub-patches, keine abstractions, und nur abstractions können arguments (-100 100 10) haben, subpatches nicht.
 
Zuletzt bearbeitet:
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.

1712320971886.png

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.
 

Anhänge

  • ATMO DIST.zip
    17,4 MB · Aufrufe: 0
Zuletzt bearbeitet:


Neueste Beiträge

News

Zurück
Oben