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

Es ist rein mathematisch Teil der Sinusfunktion, Pure Data macht da alles richtig.
 
der halt nur bis 1 geht
Nur, wenn ich das so will ;-)
1672740910964.png

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

1672742411569.png

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

1672744940071.png

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

1673430015262.png

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.
 

Anhänge

  • Storm.zip
    4,5 KB · Aufrufe: 1


Neueste Beiträge

News

Zurück
Oben