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.