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

[einseinsnull]

was meinst du mit "es ist korrekt"?

 

[Tonerzeuger]

Es ist rein mathematisch Teil der Sinusfunktion, Pure Data macht da alles richtig.

 

[Tommi]

der halt nur bis 1 geht

Nur, wenn ich das so will


Du hast schon Recht, im Grunde erzeugt das (hier z.B. $f1=20) ein Clipping.



Im Grunde also wahrscheinlich auch nicht großartig anders als die PD clip-Funktion. Und es hört sich ja auch ziemlich ähnlich an. Ich würde sogar so weit gehen und sagen, dass ich keinen Unterschied hören kann. Dass die Amplitude hier kleiner wird je höher $f1 ist, ist ja nicht weiter wild da man sie ja auch wieder beliebig vergrößern kann.

(tanh(20*sin(x))/20)*20



Aber: das ist ja alles nur ein wenig herumrechnen. Mich interessiert viel eher die Frage was bei Änderung der Amplitude eines Samples mit dem Audiosignal passiert und warum.

die könnten sehr CPU-hungrig sein

Also da achte ich ehrlich gesagt eher weniger drauf. Da gibt es andere CPU-Fresser. Und den kleinen Raspi 3 in der Organelle habe ich bisher noch nicht ans Limit gebracht. Expressions sind auch einfach eleganter als z.B. ein if-then-else mit PD-Kästchen zu bauen. Ich arbeite mittlerweile ziemlich viel damit statt diese ganzen Kästchen und Verbinder zu haben.

Jetzt muss ich aber los...

 

[einseinsnull]

Es ist rein mathematisch Teil der Sinusfunktion, Pure Data macht da alles richtig.

ach so, ja das denke ich auch.. andererseits weiß man bei max und pd nie... vertrauen ist gut - kontrolle ist besser!

mir schien nur, dass er es auch nicht kontrolliert hat, was sin() macht. denn für da anvisierte ziel eine tanh() funktion einem beliebigen wertebereich überzustülpen funktioneirt es halt nicht sonderlich gut (bzw. nur bis +2,99 dezibel. )

Nur, wenn ich das so will

was ich meinte ist, dass du nur 1. reinschickst.

Du hast schon Recht, im Grunde erzeugt das (hier z.B. $f1=20) ein Clipping.

20 wäre auch ziemlich viel. und dennoch wäre das ergebnis dann "richtig" so.

wobei ich nicht ganz verstehe, warum das bei dir funktioniert, denn wegen dem sin trick dürfte es das nicht.

Aber: das ist ja alles nur ein wenig herumrechnen. Mich interessiert viel eher die Frage was bei Änderung der Amplitude eines Samples mit dem Audiosignal passiert und warum.

salopp gesagt entstehen einfach ein paar obertöne.

zum visualisieren bieten sich reine töne eigentlich immer ganz gut an. so als alternative zu einer ramp.

in pd ist mir das zu umständlich sonst würde ich dir mal eine vorlage machen.

Also da achte ich ehrlich gesagt eher weniger drauf.

expr an sich kann auf dem scheduler oder bei audio CPU sparen, weil man dadurch weniger verbindungen macht.

andererseits rechnet das objekt in pd und max 4.x intern immer mit 64 bit. dann ist es wieder eine ecke teurer.

im zweifelsfall musst du es halt messen und dann abwägen, was gerade besser funktioniert. (aber nicht, dass du nachher noch so anal wirst wie ich und auch die kommata optimierst.)

if, regexp und sprintf sind dann die luxusklasse, die brauchen über 30 liter in der stadt.

wenn du zum aufteilen von wertebereichen arithmetik benutzen willst und wenn du expr~ sowieso benutzt, bieten sich comparison operators oder min() und max() an, um das teurere expr~ if einzusparen.

was du mit zahlen kannst besorgen...

 

[Tommi]

Da gibt es andere CPU-Fresser

Wie z. B. 8-fach polyphon mit FM-Synthese:



Da geht der kleine Raspi dann doch in die Knie....

 

[Tommi]

Tja, schon interessant was so geht. Und das mit recht einfachen Mitteln, nur entsprechend eingesetzt.


https://youtu.be/eK-eWrYt5-k


Eine Minute Sturm, erzeugt mit Pure Data. Hier ist nur ein Noise Generator, eine Feedback Schleife und zwei Filter am Werk. Mehr nicht. Faszinierend...

 

[haesslich]

Tja, schon interessant was so geht. Und das mit recht einfachen Mitteln, nur entsprechend eingesetzt.


https://youtu.be/eK-eWrYt5-k


Eine Minute Sturm, erzeugt mit Pure Data. Hier ist nur ein Noise Generator, eine Feedback Schleife und zwei Filter am Werk. Mehr nicht. Faszinierend...

Würdest du den Patch teilen?
Den würde ich gern versuchen in C nachzubauen.

 

[Tommi]

Würdest du den Patch teilen?

Klar. Zip hängt am Beitrag. Im Wesentlichen ist es der Patch "storm~". Der Rest ist nur etwas Modulation.



Wichtig ist halt, dass man einen resonanten Filter zur Verfügung hat. In PD ist das "bob~". Der wird allerdings ab einem Wert von 4 dann auch langsam schrill. Deswegen die Einschränkung auf ein Max von 3.9.

 

[BurKeyBoarderLinerX]

Na, ihr Geilen! Das ist ja richtig nerdig hier! Ich hab vor ein paar Wochen auch mit PD angefangen und mir gleich mal eine Organelle gekauft.

Ich will ein bisschen granularen Kram programmieren. Bis jetzt auch schon ziemlich geil!




Anhang anzeigen Untitled.MP4
Das wird noch weiter aufgedröselt, so dass ich Samples laden oder auch direkt in den Buffer recorden kann.

 

[Tommi]

direkt in den Buffer recorden kann

Etwas, dass ich leider nicht hinbekomme. In einen Buffer recorden ist ja recht simpel. Kontinuierlich in einen Puffer zu schreiben und gleichzeitig zu lesen geht leider nicht. Jedenfalls nicht so ohne Weiteres.

Klar kann man delwrite und delread nehmen. Allerdings hat man hier nicht die Möglichkeiten wie mit tabwrite und tabread. Wie z.B. den Pitch zu ändern auch einfach mal rückwärts zu lesen.

 

[sushiluv]

Etwas, dass ich leider nicht hinbekomme. In einen Buffer recorden ist ja recht simpel. Kontinuierlich in einen Puffer zu schreiben und gleichzeitig zu lesen geht leider nicht. Jedenfalls nicht so ohne Weiteres.

Klar kann man delwrite und delread nehmen. Allerdings hat man hier nicht die Möglichkeiten wie mit tabwrite und tabread. Wie z.B. den Pitch zu ändern auch einfach mal rückwärts zu lesen.

Das geht schon, Du darfst nicht lesen, wo du noch nicht geschrieben hast im Buffer, du brauchst also ein kleines Delay vor dem Lesen.

Ansonsten:

 

[einseinsnull]

Wie z.B. den Pitch zu ändern auch einfach mal rückwärts zu lesen.

das geht schon mit tapping buffern, z.b. in max und sc, nur leider nicht mit dem delread pd objekt. vielleicht findest du third party objekte, die genau das erlauben.

und man muss bei der berechnung der readhead geschwindigkeit schon extrem um die ecke denken.

dass es bei "schneller" oder "rückwärts" gewisse limits gibt, die dann mindestens mal windowing erfordern, liegt in der natur der sache.

mit windowing zwischen parallen buffern kannst du übrigens auch mit normalen buffern zumindest ein bischen mehr machen als mit nur einem buffer.

 

[Tommi]

du brauchst also ein kleines Delay vor dem Lesen

Da fehlt mir gerade die Phantasie wie das funktionieren könnte.

man muss bei der berechnung der readhead geschwindigkeit schon extrem um die ecke denken

Ich verbrachte Tage damit die Timings hinzubekommen. Letztendlich ist PD für diese Zwecke nicht gerade das optimale Tool. Und auch wenn es dann irgendwann so halbwegs in gewissen Grenzen funktionierte, hatte ich immer noch ein Problem mit den Knacksern wenn man vom Ende zum Anfang springt. Hier dann auch noch Hüllkurven in die sowieso schon komplexen Timings einzubauen war dann wirklich kein Spaß mehr.

Hier gibt es ein paar ganz gute Ansätze:

3.4 Sampling

Hier ganz explizit die Granularsynthese:

3.7 Granularsynthese

Aber eben dann wieder mit delwrite/read...

 

[sushiluv]

Da fehlt mir gerade die Phantasie wie das funktionieren könnte.


Ich verbrachte Tage damit die Timings hinzubekommen. Letztendlich ist PD für diese Zwecke nicht gerade das optimale Tool. Und auch wenn es dann irgendwann so halbwegs in gewissen Grenzen funktionierte, hatte ich immer noch ein Problem mit den Knacksern wenn man vom Ende zum Anfang springt. Hier dann auch noch Hüllkurven in die sowieso schon komplexen Timings einzubauen war dann wirklich kein Spaß mehr.

Hier gibt es ein paar ganz gute Ansätze:

3.4 Sampling

Hier ganz explizit die Granularsynthese:

3.7 Granularsynthese

Aber eben dann wieder mit delwrite/read...

Ich dachte es geht um Max, sorry.

 

[einseinsnull]

Ich verbrachte Tage damit die Timings hinzubekommen. Letztendlich ist PD für diese Zwecke nicht gerade das optimale Tool.

hauptsächlich, weil das mit delread nicht geht.

das equivalent in max hat einen signal eingang, in den man einfach einen eigenen akkumulator reinstecken kann, den man so designt wie man ihn gerade braucht.

beispielsweise könntest du für einen rudimentären tape echo effekt einen leichten "LFO" auf den selbstgemachten readhead legen.

das pd object hat nur einen "eingebauten" readhead, der nur fest an einer stelle steht.

wie diese ganze geschichte funktioniert, muss man im prinzip erlebt haben um es zu verinnerlichen, weil die theorie dazu nicht reicht. mehrere anläufe oder mehrere tage bis das klappt sind da ganz normal, keine sorge.


einen tapping buffer könne wir uns so vorstellen, dass dort drinnen ein tonband permant im kreis läuft, wie man das eben von einem tape echo oder enem mellotron so kennt.

dieses sich bewegenden tonband wird nun von einem lesekopf gelesen, der sich mit folgender geschwindigkeit bewegt: er steht immer auf 0.

soll das band also nun doppelt so schnell abgefahren werden wie normal (also wie reingeschrieben wird), muss der readhead sich mit einer ramp bewegen, die bei 0 anfängt und innerhalb der zeitspanne (delayzeit/2) bis auf 1 geht.

denn die "0" im normalzustand steht ja für geschwindigkeit x1, geschwindigkeit x2 is demzufolge "1".

selbstredend geht das dann genau (delayzeit/2) lange gut bis es gegen die wand fährt, was man beim design schon vorher berücksichtigen muss.

halb so schnell wie normal ist dann eine ramp von 0 bis -0.5, bei konstant -1 kommt gar keine musik mehr raus, und bei rückwärts wird es dann ganz kalt.

ich empfehle hier trial and error bis alles funktioniert, und dann findest du auch die mathematische funktion, die dir künftig komfortabel geschwindigkeit oder tonhöhenverschiebung in "readhead bewegung" übersetzt.

Problem mit den Knacksern wenn man vom Ende zum Anfang springt

du weißt sicher vom delay design, dass es verschiedene anforderungen geben kann:

1. man erlaubt, dass es knackst, (sinnvoll unter anderem beim preset umschalten: alles ist sofort korrekt eingestellt)

2. man erlaubt es nicht, interpoliert die modulation, und dann glitcht und pitcht es stattdessen (doppler effekt), oder

3. man will die delayzeit ändern ohne dass es pitcht. das erledigt man dann sinvollerweise mit 3 oder mehr windows, deren größe der user je nach material selbst einstellen kann.

wenn du ein variables delay a la 3. jetzt noch in einem kreativen buffer-lese-spielzeug kombinieren willst, hast du keine chance, wenn du nicht erst mal jedes teil davon einzeln funktionsfähig bekommen und verinnerlicht hast, um überhaupt die zusammenhänge zu erkennen. break down the problem into smaller parts.

ich könnte dir jetzt irgendein zeug hier reinkippen, aber bei den themen delay und filter sind max und pd so dermaßen verschieden, da hättest du wenig davon. ich habe vorhin mal nachgeschaut und keinen dynamischen tappingbuffer für pd gefunden. was nicht heißen muss, dass es keinen gibt.

 

[mnb]

mit delread4~ kann man eigentlich das machen was man so moechte, man muss nur samples in ms umrechnen, und sich dessen bewusst sein,
dass man sich nicht auf einem buffer bewegt, sondern in der nach oben durch ein sample begrenzten vergangenheit.
(und am anderen ende begrenzt duch die delaylaenge).

stillstand geht da also nur durch bewegung...

der "kopf durch die wand ansatz" mit einer table muesste auch irgendwie gehen, hab damals aber die lust verloren, weil ueber
die bloede 64-sample blockgroesse gestolpert. (tabwrite~ startet nur an blockgrenzen, nach unten durch 64 samples begrenzt. argh!)
mit tabsend/receive liesse sich vielleicht auch was machen, bei hochgesetzter blockgroesse und entsprechender verzoegerung.

und wenns eh ein fuer laengere zeit statisches sample sein soll, bietet es sich an 2 buffer abwechselnd zu benutzen.

 

[einseinsnull]

interpoliert das pd objekt wenn man da datarate für die delayzeit einstellt? und wird das nicht trotzdem furchtbar rauschig so?

ich habe mich immer gewundert wie "ihr" das macht mit dem teil und es scheint wohl auch keine alternativen zu geben.

ah, du redest ja von der alternative. also gibt es doch eines.

 

[Tommi]

Aktuell sitze ich gerade an einem Ring Mod. Was ein wenig nervt ist, dass es etwas umständlich ist auf dem Organelle zu entwickeln. Nur dort hat man ja Potis, Encoder und Screen.

Was ich mal versucht habe ist eine Ausgabe von Texten in "irgendeinem" PD-Objekt um darauf basierend dann die Anzeige des Organelle zu simulieren. Eigentlich ist das ja trivial bei einem Ereignisorientierten System.

Aber was soll ich sagen: das geht nicht. Das hier



in einem PD GUI bereitstellen



Es könnte fast funktionieren. Nämlich mit dem Objekt List. Das könnte Nachrichten von "screenLineX" entgegennehmen (Zeile 1 Organelle Screen) und anzeigen.



Das Objekt "Symbol" ist leider nicht in der Lage Zeichenketten anzuzeigen. Ein Symbol ist ja allerdings auch keine Zeichenkette. Aber es ist ein GUI-Objekt das etwas abbilden kann in einem übergeordneten Fenster. Das Objekt List dagegen kann es darstellen. Allerdings List kein UI-Objekt, wird also mittels "Graph on Parent" nicht auf dem Parent angezeigt. Das ganze soll natürlich in einem wiederverwendbaren PD-Objekt stecken.

Hat da vielleicht noch jemand eine Idee? Egal wie abwegig.

 

[Klinke]

Hat da vielleicht noch jemand eine Idee? Egal wie abwegig.

Weiterhelfen kann ich leider nicht, aber Danke sagen für das Hochladen bei PatchStorage. Meine Patches kannst Du übrigens hier finden: https://patchstorage.com/author/klinke/, aber seitdem ich Tunod fertiggestellt habe, habe ich nichts mehr mit PD gemacht, bin da also ziemlich raus.

 

[Tommi]

Gern geschehen. Ich habe keinen Ring Mod obwohl ich das als Effekt sehr mag. Daher habe ich mir einfach einen in PD gebastelt. Und bei der Gelegenheit vielleicht etwas over featured. Da ich keine Vergleichsmöglichkeiten habe reicht mir das so eigentlich.

Danke deinen Link. Das schaue ich mir an. Und dann macht es wohl Sinn sich im Forum anzumelden. Oder vielleicht einen Feature Request im Vanilla Team zu machen. Ich finde so eine einfache Ausgabe von Text ja extrem sinnvoll. Aber anscheinend bin ich da weltweit der Einzige.

 

[Tonerzeuger]

Hat da vielleicht noch jemand eine Idee? Egal wie abwegig.

Nicht wirklich elegant, aber möglich: Leerzeichen durch Trenner wie Unterstrich, Doppelpunkt o.ä. ersetzen. Als Display kann man auch das canvas-objekt benutzen.



Mit einer Variablen in "symbol" kannst Du auch eine Zahl zu einem Wort zufügen, davor oder danach.




Ich hoffe, das ist kein kalter Kaffee für Dich, Du scheinst ja echt Routine zu haben!

 

[Tommi]

Leerzeichen durch Trenner wie Unterstrich, Doppelpunkt o.ä. ersetzen

Genau das wollte ich ja vermeiden. Ansonsten aber eigentlich eine Möglichkeit. Ist halt nur so halbwegs befriedigend. Und ich kapier nicht, warum es so etwas in PD nicht schon gibt. Anscheinend vermisst das außer mir niemand.

 

[lacuna]

Aber was soll ich sagen: das geht nicht. Das hier



in einem PD GUI bereitstellen

Das kannst du zb auch mit dem label des faders machen:



siehe fader-help-file.

Leerzeichen mit backslash, siehe message-help-file.


Oder mit dynamic patching von comments in einem graph-on-parent subpatch. In diesem beispiel heißt das subpatch sub, also [pd sub]:

 

[Tommi]

Das kannst du zb auch mit dem label des faders machen

Erst mal danke für den Tipp. Auf die Idee bin ich natürlich nicht gekommen. Der "\" wird tatsächlich entfernt, siehe Print-Ausgabe. Ob das auf dem Organelle-Display auch so sein würde kann ich nicht sagen. Das könnte ich erst heute Abend testen.

Aber anscheinend kann man Symbole nicht dynamisch generieren => bad arguments...

Möglicherweise werden die "\" bereits entfernt bevor sie die Message erreichen.



Ich schaue es mir heute Abend aber nochmal genauer an.

Okay, wenn man es richtig macht funktioniert es auch:



Wenn jetzt noch der "\" auf dem Display NICHT angezeigt wird haben wir es.

 

[Tommi]

Der "\" erscheint auch auf dem Display des Organelle nicht! Sehr cool! Vielen Dank, @lacuna.

BTW: pd-sub oder pd-subpatch wird anscheinend von meine PD-Version (Windows) nicht unterstützt.

 

[lacuna]

BTW: pd-sub oder pd-subpatch wird anscheinend von meine PD-Version (Windows) nicht unterstützt.

ein subpatch: [pd sub]
mit rechtsklick kannst du daraus ein graph-on-parent machen
und etw. an das subpatch senden mit
[s pd-sub]
oder
[;pd-sub clear, obj 10 20 osc~(

mehr in messages-help.pd > pd messages > dynamic-Patching

oder hier, teilweise auch älter: https://forum.pdpatchrepo.info/topic/10813/collection-of-pd-internal-messages-dynamic-patching

habe kein organelle, aber hier eine display-emulation, als inspiration vielleicht auch so?




Da sind einige sachen drin: dynamic patching, abstractions, coloured canvas, graph-on-parent, hide abstraction name and arguments, $0, $0 as abstraction's argument, list usw.

Wichtig ist noch, dass dynamic patching nicht offiziell untertsützt wird, oder mittlerweile halb offiziell - und somit in zukunft durch änderungen die backward-compatibility (welche ansonsten in pd höchste wichtigkeit hat) evtl nicht gegeben sein wird.

 

[Tommi]

hier eine display-emulation

Vielen Dank dafür!! Das ist genau das was ich vor hatte. Darf ich das benutzen? Ich würde es halt noch ein wenig um- und ausbauen.

Das mit dem sub-patch war ein Missverständnis. Das Konzept ist mir natürlich bekannt.



Ohne das gäbe es ein unglaubliches Patch-Chaos.

Sich mal mit Dynamic Patching auseinanderzusetzen scheint eine lohnenswerte Sache zu. Auch hier vielen Dank für den Anstoß.

 

[einseinsnull]

Das Objekt "Symbol" ist leider nicht in der Lage Zeichenketten anzuzeigen. Ein Symbol ist ja allerdings auch keine Zeichenkette. Aber es ist ein GUI-Objekt das etwas abbilden kann in einem übergeordneten Fenster.

Anscheinend vermisst das außer mir niemand.

GUI ist nicht unbedingt die stärke von PD, um es mal vorsichtig zu sagen, alleine schon die tatsache, dass es erst mal kein "menu" gibt ist irgendwie schräg.

wie wichtig ist dir die graphische darstellung von zeichenketten?

du hast doch sicher einen midi controller da, mit dessen hilfe du das PC patch auf ähnliche art und weise testen kannst wie es später auf der hardware läuft? also mit anfassen und so, das ist ja auch schon mal was.

das problem mit dem ständige hin und her kenne ich auch, wobei es bei mir die betriebssysteme und versionen sind.

 

[einseinsnull]

Dieses Rauf und Runter ist völlig korrekt, die Sinusfunktion setzt sich ab 360° bzw. 2 pi einfach fort - sie wiederholt sich im Abstand von 2 pi.

2pi ist aber nicht 1.6

 

[lacuna]

Subpatches einer Namenskonvention unterliegen

Ja, $0, damit die abstraction mehrmals parallel benutzt werden kann (was du aber gar nicht brauchst?)


in dem folgenden beispiel wird auch $0 von dem parent patch zu der abstraction als agrument durchgereicht [o-dp $0]
die list-GUI-boxen haben $1 (estes argument der abstraction = $0 des parent patches) mit im empfangssymbol.

Ist erstmal kompliziert, aber macht es möglich die display abstraction in meherern patches parallel zu nutzen, weil es sonst zu einem name-clash der empfangssymbole kommen würde.

Das Objekt List dagegen kann es darstellen.

ist einfacher deshalb vermutlich auch besser als dynmaic patching:



allerdings sind dann kommata, $, und worte wie 'symbol' usw dann nicht so einfach darzustellen.