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

[banalytic]

sieht spannend aus! lass mal,was hören

 

[_thomas_]

Das lässt sich bestimmt einrichten. Sobald die Schrauberei ein Ende gefunden hat. Ist halt blöd, wenn man dauernd neue Ideen hat.

Mittlerweile sieht es so aus. Da PD ja nicht sonderlich integrativ ist habe ich zumindest mal einen Recorder eingebaut.

 

[einseinsnull]

irgendwann kommt dann der tag, an dem es einem egal ist, dass man keine alben mehr aufnimmt. hautpsache der code stimmt.

 

[_thomas_]

Ich habe das Gefühl, dass ich gerade kurz vor diesem Punkt stehe...

Allerdings: man lernt auch viel.

Auch den Fehler in meinem Karplus-Teil habe ich dank eines uralten Patches (anderer Thread) gefunden: es war ein Fließkomma-Problem mit PDs [expr]. Man sollte damit einfach keine kleinen Zahlen durch große Zahlen teilen. 1 durch egal was haut ein dermaßen ungenaues Ergebnis raus. Was hat der Herr Pucket-Miller, ähhh Miller Puckette, sich dabei bloß gedacht??

Jetzt läuft das Ding endlich. Auf Lautstärke habe ich da nicht geachtet.

Anhang anzeigen recording_0.wav

 

[_thomas_]

Jetzt hab ich mal den Karplus fertig gemacht und eingebaut.



Anhang anzeigen karplus.mp3

Das ist alles komplett generisch. Finde ich gar nicht so schlecht. Ein paar schiefe Töne sind noch dabei. Leider hatte ich vergessen das Reverb auszuschalten...

Das GUI ist jetzt aber unglaublich träge. Also Spaß macht das nicht. Aber der Patch ist sowieso dazu gedacht komplett generisch zu arbeiten. Quasi als Ambient-Schleuder.

 

[_thomas_]

Generativ übrigens. Nicht generisch. War schon etwas spät gestern für einen alten Mann.

 

[_thomas_]

Ich sitze gerade an meiner "Abschlussarbeit" in Pure Data, einem generativen Brian-Eno-mäßigen Ambient-Patch. Bevor ich mich Supercollider zuwende.

Schaut schon ganz gut aus. Die Markov-Analyse bleibt da leider außen vor, da das nur für bestimmte Szenarien geeignet ist. On-the-fly-Analyse mit PD kann man knicken. Und das, obwohl die Datenmenge überschaubar ist. Aber egal...

Eine Frage habe ich. Die ist allerdings nicht PD-relevant. Aber einen Thread will ich dafür auch nicht extra öffnen.



Ist das auf Dauer kacke für Lautsprecher? Das entstammt einem lustigen Wave-Folder. Ein randomisierter Mix aus Sinus, noch 'nem Sinus, Saw und Faltungstiefe.

Das war's auch schon.

 

[marco93]

Ich sitze gerade an meiner "Abschlussarbeit" in Pure Data, einem generativen Brian-Eno-mäßigen Ambient-Patch. Bevor ich mich Supercollider zuwende.

Schaut schon ganz gut aus. Die Markov-Analyse bleibt da leider außen vor, da das nur für bestimmte Szenarien geeignet ist. On-the-fly-Analyse mit PD kann man knicken. Und das, obwohl die Datenmenge überschaubar ist. Aber egal...

Eine Frage habe ich. Die ist allerdings nicht PD-relevant. Aber einen Thread will ich dafür auch nicht extra öffnen.

Anhang anzeigen 229156

Ist das auf Dauer kacke für Lautsprecher? Das entstammt einem lustigen Wave-Folder. Ein randomisierter Mix aus Sinus, noch 'nem Sinus, Saw und Faltungstiefe.

Das war's auch schon.

Warum sollte das schlimm fuer die Lautsprecher sein? Ich denke nicht. Schlimm ist nur extreme Uebersteuerung oder wenn du einen hohen Sinus in richtig hoher Lautstärke und ueber längere Zeit spielst.

 

[_thomas_]

Warum sollte das schlimm fuer die Lautsprecher sein?

Na ja. Es hört sich halt manchmal (zumindest aktuell noch) an, als würden die Lautsprecher vergewaltigt. Aber das fließt später eh in einen Mix ein. Ich wollte nur sicher gehen. Will ja nicht Schuld am Spulentod Unschuldiger haben. Danke!

 

[marco93]

Na ja. Es hört sich halt manchmal (zumindest aktuell noch) an, als würden die Lautsprecher vergewaltigt. Aber das fließt später eh in einen Mix ein. Ich wollte nur sicher gehen. Will ja nicht Schuld am Spulentod Unschuldiger haben. Danke!

Ich glaube ein Audiointerface kann kein Signal ausgeben, was wirklich schlecht für die Monitore ist. Auch wenn sich digitales Clipping so anhört wie ein Rechteckpuls, so gibt es da Unterschiede.

Reddit - Dive into anything

www.reddit.com

Vielleicht kann das jemand mal richtig erklären.

 

[einseinsnull]

Vielleicht kann das jemand mal richtig erklären.

das hatten wir schon ein paar mal, u.a. beim thema "hochtöner brennen durch".

in einem setup, bei dem nirgendwo irgendwelche limiter oder filter drin sind und ein extrem hoher frequenzgang transportiert und ausgegeben werden kann, kann folgendes problem autreten: digitale rechteckwellen bekommen nach dem DAC - je nach dessen oversampling faktor - peaks an den kanten, durch die der maximalpegel um bis zu 11 db ansteigt.

der hochtöner bekommt dann davon sowas hier ab...



... wobei diese spitzen bis weit über 3,0 hinausgehen (die rechteckwelle ging vorher nur bis 1, also bis unten und oben im GUI)

wenn jetzt das rechteck schon 5 kHz hatte, dann sind das entsprechend viele solcher spitzen, die sich zu einer energie aufsummieren, die sich durchschnittlich weit oberhalb eines rechtecks befindet, also quasi mehr energie hat als überhaupt vorgesehen.

außerdem gelangt bei 5kHz natürlich auch das rechteck selbst auch zum hochtöner, was ja alleine schon den maximalpegel hat. und die maximale ernegie...

hinzu kommt, dass man das alles kaum gescheit messen kann und man es auch nicht wirklich hört. und auch nicht, dass es verzerrt.

dadurch kann der speaker dann kaputtgehen weil er z.b. zu heiß wird.

das ist aber alles graue theorie, denn mit "normalem" gear wie wir es üblicherweise haben kommt man nicht in den genuss.

von hässlichen wellenformen in komischen programmen passiert das nicht, die beleidigen maximal meinen sprichwörtlichen guten geschmack.

 

[_thomas_]

das hatten wir schon ein paar mal

Denk ich mir. Man schnappt sowas irgendwo auf und denkt, na ja, ist da was dran oder nicht? Hohe Frequenzen mit viel Energie könnten ja vielleicht... Ich selbst habe da von den physikalischen Vorgängen in einer Leistungs-Spule nicht so den Plan.

Bei mir klippt auch nichts. Das ist einfach die generierte Wellenform, die teils extrem hohe und laute Frequenzen erzeugt. Ein Lowpass hat dem aber nun ein Ende gemacht. Es hörte sich auch einfach nicht gut an.

Passt also. Danke euch!

 

[einseinsnull]

die energie ist einfach nur die fläche der wellenform. rechteck hat 100%, sinus hat 70%, dreieck 50%.

das gemeine ist aber, dass man nicht davon ausgehen darf, dass aus einem DAC das rauskommt, was man digital sieht.

das ist so ein bischen wie das mit den lausprechern, bei denen rechnerisch die leistung stimmen sollte, sie dir aber plötzlich den verstärker kaputthauen weil sie nur 3 ohm haben.

vor vertragsabschluss immer das kleingedruckte lesen.

 

[_thomas_]

Long time no see...

Ich bastel gerade an einem Stutter-Effekt. Was in Pure Data mit dem Delay-Puffer eigentlich ja recht einfach. Aber...

Ich möchte natürlich weitere Feature einbauen. Dafür habe ich mir etwas Ähnliches wie einen Ringpuffer gebastelt in dem ich dann vor, zurück, etc. gehen kann. Der Puffer besteht aber in Wirklichkeit aus bis zu vier Puffern, zwischen denen ich zu bestimmten Zeitpunkten switche.

Problem: das übliche Geknackse. Was ja relativ leicht behebbar ist, indem man den einen Puffer ausblendet und anschließend den anderen einblendet. Der Nachteil ist allerdings, dass man da einen hörbaren Break hat. Egal, wie kurz die Zeit ist. Ein Mal mit der Amplitude auf Null runter ist immer hörbar.

Als zweites könnte man überblenden. Aber selbst, wenn das nur wenige Millisekunden sind: die addieren sich. Ich halbiere die Zeit und lese den zweiten Puffer um vom ersten dann sauber in den zweiten Puffer überblenden zu können. Macht bei jedem Switch ein paar Millisekunden, den ich den zweiten Puffer früher starten muss.

Ich frage mich gerade, wie man das am besten hinbekommt damit sich nichts verschiebt? Elektron bekommt das doch auch hin. Und Waldorf.

Vielleicht den Puffer um die Überblendzeit verlängern und dann bereits beim Einlesen überblenden? So gibt's dann keine Verschiebung und es bleibt bei 400ms Gesamtzeit.

 

[einseinsnull]

du sagst nicht genau, was du konkret machst, aber wenn stutter bedeutet, dass man vorher nicht weiß, wo als nächstes hingesprungen wird, dann reicht windowing alleine nicht, sondern du müsstest zusätzlich einen globalen latenzbuffer einbauen, der den (von was auch immer) gestarteten sprung verzögert.

da du aber ja live spielst ist es wahrscheinlich anders herum besser: sorge einfach dafür, dass jeder sprung immer im derzeit geschlossenen window landet. dann kommt also sozusagen die modulationsquelle zwar rechtzeitig an, wird aber erst später hörbar.

unnötig zu erwähnen, dass es mit 3 windows manchmal einfacher zu realisieren ist (und mit einer funktion, bei der die amplitude eine weile 0 beträgt...) als mit 2, und dass die windowing funktion natürlich nach den song BPM bemessen sein sollte, so dass z.b. alles immer eine 32tel note später einsetzt...

 

[einseinsnull]

5ms ist recht kurz (denk mal, das sind 200 hertz). und... ist das ein trapez? das hat dann immer noch knackse-ecken. würde eher ein hanning oder irgendwelche s-kurven benutzen.

 

[_thomas_]

hanning

Ja stimmt, war mal wieder etwas durcheinander. Für den X-Fade nutze ich eine berechnete Hanning. Nicht superperfekt, aber für mich okay. In der Mitte gibt es noch einen Anstieg von ca. 1 dB.

Das Problem war einfacher zu lösen als erwartet. Ich hänge einfach 100ms an jeden Puffer. Die sind dann identisch mit den ersten 100ms des nächsten Puffers. So kann ich den nächsten Puffer zeitlich passend loslegen lassen und den davor einfach noch 100ms weiterlaufen lassen. Läuft total smooth. Ob es jetzt perfekt ist sei mal dahin gestellt.

Die Zahlen oben sind nur Beispiele. Der X-Fade kann dann vom Benutzer mit bis zu 100ms eingestellt werden. Für einen Stutter hält sich der Playhead immer im selben Puffer auf. Der neue Puffer wird nur zwischen zwei Stotterern gewechselt. Der Puffer der gerade beschrieben wird, wird auch nicht ausgewählt. Kann natürlich immer noch passieren, dass es dann zeitlich doch mal zusammen fällt. Die Entscheidung ist ja immer nur für den Moment gültig. Das ist dann später mal eine Optimierungsaufgabe.

 

[einseinsnull]

die zeiten den user einstellen zu lassen ist auch nie verkehrt. für percussives material solltest du trotzdem mal eine 32tel note gesamtverzögerung ausprobieren.

so stutter teile waren einige meiner ersten plug-ins überhaupt (und die ersten stutter plug-ins).

die hatten eine gesamtlatenz von einem ganzen takt, so dass man in der zeit nach vorne springen kann, da hin, wo man noch gar nicht ist.



das knacksen blieb einfach drin und wurde zum feature deklariert.

windowing UND upsampling UND stereo wird schnell teuer für so ein bischen delay effekt, da musste man seinerzeit abstriche machen, sonst wurde das CPU meter grantig.

 

[einseinsnull]

ach und was die teile auch machen ist, dass du die sprünge linear interpolieren kannst, für ein bischen extra blödsinn. (klicks vermeiden und stattdessen portamento kostenlos dazu bekommen !!einself!!!)

vielleicht auch was für dich? ist ja schnell gemacht.

 

[_thomas_]

eine 32tel note gesamtverzögerung

Das würde ja voraussetzen, dass ich so etwas wie eine Clock habe. Die gibt's aber nicht. Jedenfalls noch nicht.

Das Knacksen stört bei einem Stutter nicht wirklich. Das stimmt. Das Ding habe ich eigentlich nur gebaut, da ich da nichts Ordentliches gefunden habe. War mal wieder ganz spannend, all die Probleme zu lösen. Und wenn ich ein Knacksen wegbekommen kann, dann mache ich das auch.

Aber hauptsächlich ging es mir um den Puffer. Man kann zwar Vieles mit dem Delay-Puffer machen und das ist auch unproblematisch. Aber eben nicht alles.Vorwärts, rückwärts, schneller, langsamer, 20 Playheads (moduliert natürlich), links, rechts, Hüllkurven, usw. usf.

Endlich kann ich auch live granular, was mit dem PD Delay etwas lahm ist.

die sprünge linear interpolieren

Weiß grad nicht, was ich mir darunter vorstellen soll. Ich weiß zwar, was interpolieren ist, aber nicht, wie mir das bei Sprüngen weiterhilft. Oder was man da cooles machen kann.

 

[einseinsnull]

na so wie bei einem echo effekt auch, wenn man die zeiten ändert. die position des readheads wird nicht ruckartig verändert, sondern rübergefahren, und der buffer inhalt währenddessen entsprechend gepitcht wiedergegeben. bei ganz kleinen veränderungen kann man das als verfahren betrachten um das knacksen wegzubekommen, bei größeren veränderungen wird es zum spezialeffekt mit eigenem charakter. das ist natürlich nur eine zusatzoption zum normalen modus, die vor allem interessant wird, wenn das input material gerade mal kein drumloop ist.

 

[_thomas_]

Also während der Play/Readhead den Stutter liest ihn von=>nach interpolieren bezüglich Lese-Geschwindigkeit? Etwas Ähnliches ist bereits eingebaut. Inklusive Rückwärtsgang.

Wäre vielleicht mal ganz witzig eine Playhead Geschwindigkeit-Leserichtung-Kurve einzubauen.

Was ich noch eingebaut habe ist ein Feedback. Das sendet Audio aus dem aktuellen Puffer in den der gerade geschrieben wird. Auch ganz schick.

Es gibt ja unendliche Möglichkeiten. Bisher gefällt mir der Effekt ganz gut. Verrückt, welche Klangartefakte entstehen. Dieses Herumspringen in den einzelnen Puffersegmenten ist echt ganz cool. Das Konzept werde ich noch etwas ausbauen, denke ich. Nur, so wie du in die Zukunft, werde ich es nicht schaffen. Aber in unterschiedliche Versionen der Vergangenheit hüpfen zu können um sie neu anzuordnen ist auch schon ganz nett.

 

[einseinsnull]

#zukunft geht nur wenn #dasding mit #demrestvomsetup getrennt verzögert werden kann.

außerhalb der plugin/host welt ist das nur sehr theoretisch möglich.

wie groß ist dein buffer?


ja, feedback ist natürlich prima. und zwar einzeln, pro readhead (falls du mehrere hast, wovon ich ausgehe)

falls timing wichtig ist (percussion) im zweifelsfall einfach für das feedback recording einen zweiten, parallelen readhead nehmen, der zu dem, den man hört, identisch ist, aber immer einen audio vector früher ausliest (um den fehlenden vector der schleife auszubügeln.)

 

[_thomas_]

wie groß ist dein buffer?

20 Sekunden x Samplerate. Aber eigentlich kann der so groß sein wie der kleine Raspi es zulässt.

einen audio vector früher

Ich weiß jetzt nicht genau, was du mit Vektor meinst. Die Amplitude auf der Zeitachse? Aber das kannste mit Pure Data vergessen. Auf dem Level hat man keinen Zugriff auf den Audio-Puffer. Mindestverarbeitungsgröße sind 64 Samples. Also irgendwas zwischen 1und 2 Millisekunden. Man kann die Blockgröße zwar auf 1 Sample stellen, das allerdings packt PD einfach nicht.

 

[orgo]

Du könntest Doch

Problem: das übliche Geknackse. Was ja relativ leicht behebbar ist, indem man den einen Puffer ausblendet und anschließend den anderen einblendet. Der Nachteil ist allerdings, dass man da einen hörbaren Break hat. Egal, wie kurz die Zeit ist. Ein Mal mit der Amplitude auf Null runter ist immer hörbar.

Hast Du überlegt die Einblendungen mit den Nulldurchläufen des Buffers zu synchronisieren? Das sollte das Knacksproblem lösen. Der digitale VCA von WMD macht das z.B. auch so.

 

[_thomas_]

Nulldurchläufen

In PD hast du die Möglichkeit Sample-genau auszuwerten und auch den Nulldurchlauf zu verarbeiten. Aber Timings auf dieser zeitlichen Ebene sind schwierig. Bevor der nächste Puffer benutzt wird muss dann klar sein, wo sein erster Nulldurchlauf ist. Und man muss den letzten Nulldurchlauf des aktuellen Puffers kennen und das dann synchronisieren. Knifflig. Im Bereich von Millisekunden bekommt man alles noch ganz gut hin. Alles was kleiner aufgelöst ist wird schwierig.

Außerdem gehen dann zwangsläufig Samples verloren. In dem winzigen Bereich aber wahrscheinlich nicht relevant. Ich werde mal schauen, was da geht. Cross-Fade ist halt total einfach.

 

[einseinsnull]

Ich weiß jetzt nicht genau, was du mit Vektor meinst.

die blockgröße. die in einem feedbackloop ja immer noch zu allen zeiten dazukommt, und seine "mindestlänge" darstellt.

Mindestverarbeitungsgröße sind 64 Samples.

genau das.

wenn du also nach 10000 samples spieldauer die letzten 5000 samples wieder aufnehmen willst, indem du sie am "eingang" dazumischst, dann liest du die einfach schon nach -9926 samples aus und deine musik im feedbackloop hat eine logische latenz von 0.

das, was hinten am ausgang rauskommen soll, liest ein zweiter lesekopf mit den normalen -10000 aus.

das einzige, was dich das kostet ist, dass du auf die allersten 64 samples im buffer keinen solchen zugriff zum wieder-zurückschreiben hast, weil diese mindestgröße des loops von einem block natürlich immer bliebt.

 

[mnb]

ich hab mir nicht alles komplett durchgelesen, aber "bang~" ist bekannt?
da kann man dann "zwischen den bloecken" in aller ruhe nulldurchgaenge suchen und sowas.
oder eben auf 1 re-blocken, das dann aber wieder ohne "bang~"...

 

[_thomas_]

Also das hätte alles schon was. Ich bin grad zwar sehr zufrieden, allerdings würde das möglicherweise ein paar Dinge erleichtern.

Also vielleicht gehe ich das noch an. Allerdings habe ich mir geschworen, mehr Musik zu machen als Effekte zu basteln. Schon mal Danke für euer Feedback.