Karplus-Strong und Pitch?

[_thomas_]

Ich stehe ein wenig auf dem Schlauch bezüglich einer halbwegs exakten Tonhöhe bei der Karplus-Strong-Synthese.

An sich ist das ja ein ziemlich einfacher Aufbau:

• Eingangssignal schreibt in einen Puffer
• Für das Ausgangssignal wird der Puffer gelesen, Lowpass gefiltert und sowohl ausgegeben als auch wieder in den Puffer geschrieben (Feedback)
• Den Pitch kann man mit der Delay-Zeit steuern

Als Eingangssignal nehme ich White Noise um irgendwelche Einstreuungen irgendwelcher Grund/Obertöne zu verhindern.

Mit dem tonalen Ergebnis bin ich sehr zufrieden (Haken Audio/EaganMatrix lässt schön grüßen).

Problem: die Tonhöhen. Ich bekomme es näherungsweise mit einer statischen Formel schon hin. Aber nur über eine bestimmte, ziemlich kleine Range an Tonhöhen. Und es spielt sich tatsächlich im µs-Bereich ab.

Das kann es also irgendwie nicht so recht sein. Die Frage ist also, ob ich für eine Tonhöhe eine Delay-Zeit herleiten kann? Das beinhaltet wohl auch die Frage warum sehr kurze Delay-Zeiten (hier z.b. 40 ms und weniger) überhaupt eine Tonhöhenänderung herbeiführen.

Tja, weiß auch nicht. Sehr spezielle Frage. chatGPT sagt dazu:



Das werde ich jetzt erstmal testen. Aber vielleicht hat ja jemand von euch noch eine Meinung dazu. Und wenn nicht war es den Versuch wert.

 

[Summa]

Aber vielleicht hat ja jemand von euch noch eine Meinung dazu.

Keine Ahnung ob dir das weiter hilft, ein wenig aus Sicht eines Sounddesigners der die Tools nur nutzt, meist einen gestimmten Kammfilter.

Als Eingangssignal nehme ich White Noise um irgendwelche Einstreuungen irgendwelcher Grund/Obertöne zu verhindern.

Eingangssignal nur einen kurzen Impuls, zumindest wenns nach gezupften Saiteninstrument klingen soll.
Kleine Anmerkung, kurze Impulse die aus div. Frequenzen/Formante als Eingangsquelle funktionieren meiner Erfahrung nach besser, ich nehme gerne eine Mischung aus div. pitchmodulierten Oszillatoren bei mehr oder weniger fester Frequenz als "Clicks". Die kann man dann auch von der Lautstärke und Tonhöhenverlaufhr mit leichtem Keyscaling an die gespielte Tonhöhe ein wenig anpassen, um auf diese Weise Einfluss auf den Klangchakter abhängig von der gespielten Tonhöhe zu bekommen.
Ansonsten irgendwas das langsam die Tohnöhe verändert sorgt ebenfalls für spannende Verläufe dabei muss die Frequenz mit der Kammfilterfrequenz harmo- bzw. resonieren.

 

[Cain-Synthesizers]

Ich bin leider im Urlaub und habe keinen Zugriff auf meinen Code vom CPP Oszillator, eine Karplus Strong Implementierung für *logge. Aber zur Berechnung der Delays habe ich ein Lookup für die 12 Grundtöne gemacht und dann für die restlichen Oktaven verdoppelt / halbiert. Ich bin mir nicht sicher ab welcher Frequenz es Probleme gab, wegen der Samplefrequenz von 48000. Ich kann ab dem 02.06. genaueres sagen.

 

[_thomas_]

Ich kann ab dem 02.06. genaueres sagen

Cool! Und schönen Urlaub! Ich denke auch, dass die Sample-Rate sowie Blockgröße eigentlich mit in die Berechnung rein muss. Dass GPT mir da eine logarithmische Funktion anbietet hätte ich jetzt nicht erwartet. Getestet habe ich es aber noch nicht.

Kammfilterfrequenz

Ich experimentiere auch mit diversen Klangquellen wie z. B. ebenfalls White Noise durch eine Reihe hochresonanter Band Passes geschickt. Die dadurch entstehenden Harmonien lassen sich in einzeln in Resonanzfrequenz und Amplitude konfigurieren. Ist schon spannend was da an Sound entsteht. Falls du das mit Kammfilter meinst. Mit dem klassischen Kammfilter habe ich noch nicht getestet.



Nur mal ein wenig herum gespielt.

Anhang anzeigen karplus.mp3

Aber ohne halbwegs passende Tonhöhen (also "irgend"-eine Diatonik im weitesten Sinne, ich bin da flexibel) kann das ja nur experimentell bleiben. Auch nett und spannend, keine Frage. Aber irgendwie wäre es doch ganz gut zuverlässig die angestrebte Tonhöhe dann auch erzeugen zu können. Daher arbeite ich erstmal mit Rauschimpulsen um da überhaupt mal Fuß fassen zu können.

 

[Mindtraveller]

Für tiefere Frequenzen kann die Grundfrequenz des Karplus-Strong Algorithmus einfach mit
Grundfrequenz = 1 / (Delayzeit in Sekunden) = Samplingfrequenz / (Delayzeit in Samples) berechnet werden.
Für die Delayzeit also: Delayzeit in Sekunden = 1 / Grundfrequenz

Bei höheren Frequenzen gibt es jedoch zwei Probleme:
1. Wenn die Delayzeit in Samples auf ganze Zahlen gerundet wird, können nur bestimmte diskrete Grundfrequenzen erreicht werden. Es tritt also ein Rundungsfehler auf. Dieser ist für sehr kurze Delayzeiten (= hohe Grundfrequenzen) relevant.
2. Der Tiefpassfilter bewirkt eine zusätzliche Zeitverzögerung welche zu der Delayzeit mit hinzugerechnet werden muss. Beim originalen Karplus-Strong ist der Tiefpassfilter einfach eine Mittelung über zwei benachbarte Samples. In dem Fall beträgt das zusätzliche Delay -0.5 Samples, ist also sehr klein und kann einfach in der Formel kompensiert (oder vernachlässigt) werden. Bei einem komplexeren Tiefpassfilter kann die zusätzliche Verzögerung jedoch Frequenzabhängig sein, was dazu führt, dass unterschiedliche Obertöne unterschiedlich stark Verzögert werden. Dadurch wird das Spektrum leicht inharmonisch. Das kann man leider nicht so einfach kompensieren.

 

[_thomas_]

1 / Grundfrequenz

Krass, also das funktioniert schon mal. Wow, ich bin begeistert. Bei ca. 678 Hz kippt es dann allerdings und wird chaotisch. Das entspricht in etwas der genutzten Blockgröße von 64 Sample oder auch 1.45 Millisekunden bei 44.1 Khz. Kleinere Delay-Zeiten sind so gar nicht möglich. Somit auch kein höherer Pitch.

Mit der Blockgröße kann ich bis 1 runter. Funktioniert super, allerdings kostet das dann ordentlich Prozessor. Up-Sampling auf 352,8 KHz habe ich mal getestet. Das sieht von der Tonhöhe her gut aus. Allerdings hört es sich nicht allzu gut an.

Anhang anzeigen untitled.mp3

Da muss ich dann morgen weiter schauen...

Was die Rundungsproblematik angeht: Ich rechne komplett mit Fließkomma-Arithmetik. Das sollte kein Thema sein.

Schon mal vielen Dank für eure Tipps! Das hat mir echt weitergeholfen. Mal sehen wo das hinführt.

 

[fanwander]

Ich denke ein wichtiger Aspekt ist auch, dass man die Rückkoppelungsdämpfung an die Tonhöhe anpassen muss, bzw dass die wahrgnommene Tonhöhe von der Rückkoppelungsdämpfung abhängt.

 

[Summa]

Falls du das mit Kammfilter meinst. Mit dem klassischen Kammfilter habe ich noch nicht getestet.

Ich nutze das was ich hab', keine Ahnung ob z.B. der microQ 'nen klassischen Kammfilter hat, aber alles was in etwa in die Richtung geht nutze ich gerne mal für div. Karplus-Strong Sounds, die ganzen Spezialisten waren mir von den Möglichkeiten immer zu eingeschränkt.
Hier ein paar Beispiele vom microQ aus den 00ern für einen Keys SynthZone Artikel.
Anhang anzeigen mQcomb.mp3

Ich experimentiere auch mit diversen Klangquellen wie z. B. ebenfalls White Noise durch eine Reihe hochresonanter Band Passes geschickt.

Ich kann mich bei der letzten Session daran erinnern dass der Verlauf der Frequenzen des Impuls auch zu Unterschieden beim Ergebnis geführt haben.

 

[_thomas_]

zu Unterschieden beim Ergebnis

Ja, kommt definitiv drauf an was man oben rein wirft. Bin schon gespannt was mit meinen ganzen analogen Klangerzeugern daraus wird. Bestimmte Konfigurationen werde ich mir einfach abspeichern, dann habe ich die Violine oder das Chello immer direkt zur Hand wenn ich es brauche.

Allerdings nur bis knapp 700 Hz aufgrund der 64 Sample Blockgröße/1.45 ms. Das Up-Sampling führt zu hässlichen Artefakten auch wenn man die Rate nur verdoppelt. Das ist also unbrauchbar.

Ich denke, dass ich erstmal bei der Limitierung 64 Samples, 1.45 ms bleiben werden.

Rückkoppelungsdämpfung an die Tonhöhe anpassen muss

Anhang anzeigen untitled.mp3

Da kann ich persönlich jetzt keine Änderung in der Wahrnehmung feststellen. Lediglich in der Amplitude und in der Feedback-Dauer/Länge.



Anders, wenn ich am Lowpass spiele.

 

[Mindtraveller]

Krass, also das funktioniert schon mal. Wow, ich bin begeistert. Bei ca. 678 Hz kippt es dann allerdings und wird chaotisch. Das entspricht in etwas der genutzten Blockgröße von 64 Sample oder auch 1.45 Millisekunden bei 44.1 Khz. Kleinere Delay-Zeiten sind so gar nicht möglich. Somit auch kein höherer Pitch.

Mit der Blockgröße kann ich bis 1 runter. Funktioniert super, allerdings kostet das dann ordentlich Prozessor. Up-Sampling auf 352,8 KHz habe ich mal getestet. Das sieht von der Tonhöhe her gut aus. Allerdings hört es sich nicht allzu gut an.

Anhang anzeigen 216565

Da muss ich dann morgen weiter schauen...

Was die Rundungsproblematik angeht: Ich rechne komplett mit Fließkomma-Arithmetik. Das sollte kein Thema sein.

Schon mal vielen Dank für eure Tipps! Das hat mir echt weitergeholfen. Mal sehen wo das hinführt.

Gerne, so kann ich mein Fachwissen mal anwenden
Das klingt nach starkem Aliasing. Wenn du up-samplest, musst du beim downsamplen die hohen Frequenzen (Frequenzen > halbe Output-Samplingrate) möglichst gut entfernen z.B. durch einen steilen Tiefpassfilter.
Die Rundungsproblematik hat nicht unbedingt mit Fließkomma-Arithmetik zu tun, sondern damit wie ein Delay digital implementiert ist. Für nicht-Integer Delayzeiten muss man nämlich eine Interpolation verwenden, welche entweder rechenaufwendig ist oder auch wieder zu zusätzlichen Tiefpassfilter-Effekten führt. Oder du machst internes Upsampling (mit Antialiasing Filter beim downsampling).

Ich denke aber, dass bei dir der Dämpfungsfilter zu stärkeren Verzerrungen führt. Falls du genau weißt, was für ein Dämpfungsfilter hierbei verwendet wird, und du nur den Grundton korregieren willst (nicht die inharmonischen Effekte), könnte man das reintheoretisch genau berechnen ...
Was für ein Programm/Sprache verwendest du denn für die Implementierung?

 

[_thomas_]

Da es mein Ziel ist möglichst viel für den Organelle zu machen nutze ich Pure Data. Grundsätzlich könnte ich alles mögliche nutzen. Aber die Organelle Hardware ist halt in Pure Data integriert.

Diverse Filter und Delays sind also alles Pure Data Objekte. Diese Limitierung ist halt vorhanden. Prinzipiell lässt sich damit aber eigentlich alles machen. Aber es wird auch sehr schnell chaotisch. Daher ist es ab einem bestimmten Level nicht mehr sinnvoll mit Pure Data zu arbeiten.

Deinen Hinweis mit dem Filter beim Upsampling werde ich mal testen.

Spannendes Thema auf jeden Fall.

 

[fanwander]

Anders, wenn ich am Lowpass spiele.

Das meinte ich.

Falls Du Streicher imitieren willst, dann geh mit einer kontinuierlichen schmalen Pulswelle rein, deren Amplitude du leich mit einem Random-Signal modulierst.

 

[einseinsnull]

Ich stehe ein wenig auf dem Schlauch bezüglich einer halbwegs exakten Tonhöhe bei der Karplus-Strong-Synthese.

An sich ist das ja ein ziemlich einfacher Aufbau:

• Eingangssignal schreibt in einen Puffer
• Für das Ausgangssignal wird der Puffer gelesen, Lowpass gefiltert und sowohl ausgegeben als auch wieder in den Puffer geschrieben (Feedback)
• Den Pitch kann man mit der Delay-Zeit steuern

chatGPT sagt dazu

dieser chatGPT erzählt viel wenn der tag lang ist.

meine festplatte ist da meist die bessere quelle: millisekunden sind nichts weiter als 1000/hertz...




aber es ist leider nicht ganz so einfach, dass man nur notennummern in millisekunden umrechnen müsste (und ggf noch einmal die blocksize abzieht - keine ahnung ob eure pd objekte das automatisch machen)


du musst für korrektes tuning des resonators von der delayzeit auch noch das delay des lowpassfilters bei der jeweiligen frequenz wieder abziehen.

das musst du demzufolge also erst mal ausrechnen.

da man dazu einige der coeffizienten des filters braucht, kann das schnell die modulationsmöglichkeiten der pitch einschränken, weil du natürlich die beiden werte (frequenz des filters und pitch/note) 100% synchron halten musst.

so kann der biquad in pd z.b. kein signal. wenn du also vorhast, einen portamento oder vibrato effekt mit signalen zu machen, ergo die tonhöhe mit signalen steuern willst, baust du dir im idealfall einen eigenen butterworth mit fexpr~, weil du nur dann genau weißt, wie sich dessen delay berechnet.

 

[einseinsnull]

hier stand quatsch

bei einer vectorsize von 8 kann das ding bis 5.5kHz piepsen, das langt dann normalerweise.

mach dinge wie vectorsize und upsampling aber zum schluss, erst mal muss der core funktionieren.

 

[Tonerzeuger]

Aber ohne halbwegs passende Tonhöhen (also "irgend"-eine Diatonik im weitesten Sinne, ich bin da flexibel) kann das ja nur experimentell bleiben. Auch nett und spannend, keine Frage. Aber irgendwie wäre es doch ganz gut zuverlässig die angestrebte Tonhöhe dann auch erzeugen zu können.

In Pure Data hat das bei mir ganz passabel geklappt. Die Verzögerungszeit des Delays (du nennst es "Puffer") ist ganz einfach proportional zum Kehrwert der Frequenz.

Du berechnest also zuerst mit einem Note-zu-Tonhöhe-Tool die Frequenz. Die Verzögerungszeit in Millisekunden ist dann einfach

1000 ms / Frequenz in Hz

Dabei musst Du aber beachten, dass Audio-Software (auch pure data) das Signal immer blockweise verarbeitet. Ein Block ist eine Folge von Samples, i.d.R. ein Vielfaches von 2. Du solltest irgendwo die "block size" definieren können, und das ist entscheidend für die Genauigkeit der Tonhöhe, die Du auf diese Weise erzeugen kannst.

Wenn du z.B. eine "block size" von 64 hast, schont das zwar den Prozessor, aber dann ist die minimale Verzögerungszeit bei 48000 Hz Sampling Rate:

1000 * 64 / 48000 -> 1.33 ms

Das bedeutet aber, dass Du Töne über 750 Hz überhaupt nicht, und darunter auch nur sehr ungenau erzeugen kannst! Eine block size von 1 löst das Problem, erzeugt aber auch mehr Prozessorlast.

Ich hoffe, das ist soweit verständlich?

P.S. @ einseinsnull:
Das Upsampling hab ich nicht ausprobiert, meines Wissens erhöht es aber die Prozessorlast genauso wie eine kleinere Block Size.

 

[einseinsnull]

In Pure Data hat das bei mir ganz passabel geklappt.

ich habe ja gerade erklärt, warum es so nicht klappen kann - wegen dem filter.

man drehe einfach mal während es schwingt an der decay zeit (=der filterfrequenz), dann bekommt man schnell ein gefühl dafür.

P.S. @ einseinsnull:
Das Upsampling hab ich nicht ausprobiert, meines Wissens erhöht es aber die Prozessorlast genauso wie eine kleinere Block Size.

ich habe auch mist geschrieben, weil ich versucht habe mein max-denken auf pd zu übertragen (ihr könnt ja die blocksize nur global verändern, bei uns ist das komplett anders.)

natürlich macht man das mit der blocksize und nicht mit upsampling, ich korrigiere das oben mal besser.

(wenn man in einem subcircuit an beidem herumdreht sollte man natürlich den zusammenhang beachten, aber das ist eine andere frage)

 

[_thomas_]

schmalen Pulswelle

Was verstehst du unter einer "schmalen Pulswelle"? Rauschen mit einer durch einen 10 Hz (Beispiel) LFO modulierten Amplitude? Ich kann dazu leider nichts finden.

An alle anderen: Danke für eure Hinweise und Tippes. Die aber zumindest zum Teil weiter oben auch schon besprochen wurden.

Was Oversampling/Up/Downsampling angeht muss ich mich echt erstmal nochmal schlau machen. Eigentlich ist es ja einfach. Aber angewendet auf Audio dann doch tricky.

vectorsize von 8 kann das ding bis 5.5kHz piepsen

Ja, das langt erstmal. Aber da gibt es in PD ein Problem: Ändert man die Blockgröße auf einen kleineren Wert als 64 führt das zumindest mal zu Fehlerausgaben. Aber an sich ist das die allereinfachste Lösung. Und funktioniert auch ohne hörbare Probleme.

butterworth mit fexpr~

So weit werde ich es nicht treiben denke ich.

ihr könnt ja die blocksize nur global verändern

Da ist erstmal so nicht so ganz klar.

Pure Data - [block~]

pd.iem.sh

Außer block~ gibt es noch switch~, das anscheinend auf Patch-Ebene und nicht global angewendet wird. Die Doku ist da etwas unscharf. Das muss ich also testen.

 

[mnb]

Ja, das langt erstmal. Aber da gibt es in PD ein Problem: Ändert man die Blockgröße auf einen kleineren Wert als 64 führt das zumindest mal zu Fehlerausgaben. Aber an sich ist das die allereinfachste Lösung. Und funktioniert auch ohne hörbare Probleme.

bei mir nicht.
und natuerliche kann man (und muss auch sehr oft) die blockgroesse bis 1 verkleinern
mit block~ oder switch~ und natuerlich pro subpatch.

gibt allerdings einige wenige objekte die die blockgroesse ignorieren, und auf 64 'festverdrahtet' sind.
bang~ waere ein beispiel.

 

[_thomas_]

bei mir nicht

Bei mir schaut das dann bei einer Blockgröße von 2 so aus (ASIO).



Aber das ist auf dem Haupt-Patch und damit vielleicht einfach falsch. Probiere ich noch aus.

Ansonsten habe ich nun noch einen Noise-Burst gebaut. Noise durch mit einem Square modulierten Amp. Square-Breite kann auch noch angepasst werden.

Anhang anzeigen untitled.mp3

Das ist schon ein Unterschied zum durchgehenden Noise-Impuls. Und die Anpassung des LPF an die Tonhöhe ist auch noch wichtig. Bisher habe ich da nicht so das Augenmerk drauf gelegt.

Was die Laufzeit durch den Filter angeht werde ich vielleicht erstmal mit einer Konstanten (von @Mindtraveller angeregt) arbeiten.

Das wird ja zu einer never Ending Story...

 

[mnb]

Bei mir schaut das dann bei einer Blockgröße von 2 so aus (ASIO).

achso. der uebergeordnete patch muss mit dem kompatibel sein, was rauskommt. sollte man also auf standard lassen.
die delayline mit dem feedback ist da in einem subpatch besser aufgehoben, auch schon aus rechenzeit-gruenden.

 

[_thomas_]

Also so ganz ohne ist das nicht.


Allerdings habe ich jetzt einfach mal mit Upsampling in einem Subpatch gearbeitet. Der oberste Patch hat tatsächlich seine 44.1 KHz, der Sub 176.4 KHz.



Ob sich das dann mt dem Delay verträgt... Keine Ahung.

Die Blocksize zu ändern bringt interessanterweise gar nichts. In Abstraction oder Subpatch bleibt es bei den 44.1 KHz.

Irgendwas ist da noch falsch anscheinend. Aber jetzt ist die Mittagspause auch schon wieder vorbei.

 

[einseinsnull]

So weit werde ich es nicht treiben denke ich.

das kannst du voraussichtlich irgendwo abschreiben und die eigentliche kunst ist sowieso immer, die dazu passende formel zur laufzeitberechnung bei F irgendeinem mathematiker aus einem fachforum - oder programmen wie matlab - aus den rippen zu leiern.

man muss da aufpassen, dass nicht zum schluss der wolf dich sucht. denn du musst dazu ja schon halbwegs wissen, was das objekt denn macht, dessen delay du kompensieren willst.

obwohl du nicht der erste wärst der unweigerlich in diese filterfalle läuft ist das komischerweise nirgendwo so ohne weiteres zu finden wie man das in der praxis am besten macht.


solange das tuning komplett off ist wirst du kleinere vectorsizes nicht brauchen, denn das wird ja nach oben immer schlimmer. freut mich aber zu hören, dass das in pd wohl doch auch so ähnlich geht wie in der max welt (mit subpatches). nur so macht es sinn.

 

[einseinsnull]

für send~/receive~ funktkoniert das in max (sofern du aufpasst, dass es innerhalb des subpatches bleibt), und wenn nicht, dann würde sich die frage stellen, warum es für den tapping buffer funktioniert, denn der macht ja auch nichts anderes. den satz im helpfile kann ich nicht einordnen.

 

[_thomas_]

Die Blocksize zu ändern bringt interessanterweise gar nichts. In Abstraction oder Subpatch bleibt es bei den 44.1 KHz.

Eine etwas dümmliche Aussage da die Blockgröße nix mit der Samplingrate zu tun hat.

Ich denke, dass das funktioniert. Ich werde das später noch im KPS-Patch testen. Wenn ich über 700 Hz komme funktioniert es.

denn du musst dazu ja schon halbwegs wissen, was das objekt denn macht

Du hast bestimmt nicht Unrecht. Aber meine Zeit für diese interessanten Themen ist halt auch begrenzt. Und für mich muss es wirklich nicht perfekt sein. Also näherungsweise klappt das ja bereits ganz gut. Wenn ich ein paar Hz daneben liege ist das schon okay.

Ich denke, dass mein Ziel so halbwegs erreicht ist. Und ich habe das Konzept kapiert. Das war mir halt auch wichtig.

 

[mnb]

also vielleicht von anfang an:
natuerlich kann man sich ein delay auch selber basteln (mit einem array etwa),
aber ich wuerde einfach vd~ (aka delread4~) nehmen, da hat man
nicht-integer-delayzeiten mit interpolation schon eingebaut.
die tonhoehe haengt von der delaylaenge ab. [mtof]/1000 ist deine delaylaenge fuer die midinote (0..127).
etwas komplizierter wirds, wenn du noch einen filter im feedback hast, muesste man
fuer passende tonhoehe noch kompensieren. kann man auch nach gehoer machen,
muesste aber auch irgendwo stehen wie das ordentlich geht.

mein subpatch fuer die delayline sieht seit 20 jahren oder so
so aus, und klingt fuer mich ok.

 

[fanwander]

Was verstehst du unter einer "schmalen Pulswelle"? Rauschen mit einer durch einen 10 Hz (Beispiel) LFO modulierten Amplitude? Ich kann dazu leider nichts finden.

Nee, im tonalen Bereich. -/+ ein oder zwei Oktaven um die eigentliche Frequenz des Karplus-Strong Gliedes. Damit geht alles von Anfängergeigekratzen bis Flageolets.

Wenn Du einen Nordmodular 1 hast: ich habe einen Karplus-Strong dafür gebaut, dann kannst Du's ankucken (da fehlt allerdings die Random Modulation - der entsprechende Patch ist auf einem Rechner 1200km von hier...).

 

[_thomas_]

aber ich wuerde einfach vd~ (aka delread4~) nehmen

Das habe ich natürlich auch gemacht:



So sieht der Patch aktuell aus. Dein Aufbau ist etwas anders. Für mich funktioniert das in gewissen Grenzen schon ganz gut. Der Lowpass ist halt wichtig. Blockgröße habe ich erstmal auf 4 gestellt. Da stellt sich dann später noch die Frage, was der kleine Raspi dazu sagen wird auf dem es schlussendlich laufen soll.

Ich werde deinen Patch mal nachbauen. Du addierst anscheinend die beiden Samples vom Lowpass und vom Eingang. Dann habe ich halt die Dauer für den Impuls mit eingebaut. Du machst das wahrscheinlich über einen Envelope? Den habe ich allerdings auch nachgelagert zusätzlich noch eingebaut. Das macht das Ergebnis einfach besser da man da etwas mehr Kontrolle hat als nur über die Dämpfung des Delays.

im tonalen Bereich. -/+ ein oder zwei Oktaven um die eigentliche Frequenz des Karplus-Strong Gliedes

Sorry, tonaler Bereich, check. Aber "+/- zwei Oktaven um die Frequenz..." verstehe ich allerdings nicht. Was muss ich da +/- zwei Oktaven um welches Gleid herum machen? Den Nord habe ich leider nicht. Du müsstest es mir Noob etwas genauer erklären.

 

[fanwander]

Nimm einen keyboard gesteuerten Oszillator, der einen Saw oder eine Puls erzeugt. Oszillator und K-S-Element hängen an der gleichen Keyboard "CV". Den Output des Oszillators schickst Du in einen "VCA" der mit einem ASR Envelope angesteuert wird (nicht all zu schnelle A und R Zeiten). Den Output dieses VCAs schickst Du nun wiederum als Erreger ins K-S-Element.
Jetzt probierst Du unterschiedliche Oszillator-Frequenzen für den Erreger Oszillator.

Ich hab hier leider keinen Rechner auf dem der Editor laufen würde, sonst könnte ich Dir einen Screenshot von dem Patch machen

 

[_thomas_]

sonst könnte ich Dir einen Screenshot von dem Patch machen

Passt schon. Das habe ich jetzt kapiert. Danke! Mit Pulse meinst du wahrscheinlich ein Rechteck?

 

[fanwander]

ja,besser ist aber eine schmale Pulswelle. Env gesteuert PWM ist da auch gut