Seite 1 von 1

Speedfaktor zu Pitchwert

Verfasst: 19. April 2014, 15:32
von PrinzThomas
Hi,

ich habe ein kleines Timewarp, was nichts anderes macht als in Echtzeit bei einem Midi-Gate in einer bestimmten Länge den Eingang zu wiederholen.
Also ein Echtzeit-Looper.
Es besteht auch die Möglichkeit die Abspielgeschwindigkeit zu ändern.
Dazu muss am Eingang des Moduls der Speed-Faktor anliegen.
Also z.B. bei doppelter Geschwindigkeit 2 oder bei halber 0.5.
Ich möchte gern ein Knopf der die Speed wie ein Pitchshifter regelt.
Also der Knopf gibt z.B. -12 und daraus muss 0.5 werden.
Aus 24 muss 3 oder aus -24 soll 0.25 werden.
Der Regler soll also -24 bis 24 regeln und am Ende muss korrekt 0.25 bis 3 rauskommen.
Eine einfache Zahlen-Transponierung geht hier schief, weil zb. dann die Mitte also 0 = 1.625 wäre anstatt 1
Die einzige Möglichkeit, die mir einfällt ist ein Selektor mit 5 Eingängen zu nehmen (0.25 / 0.5 / 1 / 2 / 3) und diesen dann mit dem Knopf abzufahren.
Ich würde aber gern eine korrekte Berechnung bzw. Formel dazu anwenden.
Brauche Hilfe! :)

Re: Speedfaktor zu Pitchwert

Verfasst: 19. April 2014, 19:24
von pavel
Habe mit GeoGebra mal eine nährungsweise Funktion berechnet:
Liste1 {(-24, 0.25), (-12, 0.5), (0, 1), (12, 2), (24, 3)}
Polynom[Liste1]
speed-pitch.jpg
f(x) = -0.00000150704x^4 - 0.0000120563x^3 + 0.00195313x^2 + 0.0642361x + 1

und die Funktion dann in einen Macro gepackt:
Pitch-to-Speed.zip
Könntest das ganze aber auch einfacher/gezielter per Event-Table lösen, sprich von -24 bis 24 Werte zwischen 0.25 und 3 auslesen :)

Re: Speedfaktor zu Pitchwert

Verfasst: 19. April 2014, 19:44
von PrinzThomas
Oh danke für die Arbeit, die du dir extra gemacht hast.
Leider ist das leider "nur" geometrisch korrekt.
Man kann sich z.B. leicht im Kopf ausrechenen, dass z.B. der Wert 6 dann 1.5 ergeben müsste.
Es ist eben das anderhalbfache einer Oktave.
Bei deiner Berechnung wäre dieser aber 1.4512
Zwischen den Punkten muss der Graph linear sein, denn die Noten sind ja auch linear innerhalb einer Oktave verteilt.
Zumindest wenn man man von der Frequenz absieht. ;)

Ich habe das jetzt so gelöst, dass ich die -24-24 zu 0-4 transponiere und dann damit einen Selektor mit 5 Eingängen (0.25 / 0.5 / 1 / 2 / 3) ansteure.
Das funktioniert erstmal perfekt.
Allerdings hätte ich gerne eine flexible Lösung gehabt bei der es egal ist welche Werte der Knopf rauswirft.

Re: Speedfaktor zu Pitchwert

Verfasst: 20. April 2014, 03:46
von herw
PrinzThomas hat geschrieben:[...]
Also der Knopf gibt z.B. -12 und daraus muss 0.5 werden.
Aus 24 muss 3 oder aus -24 soll 0.25 werden.
Der Regler soll also -24 bis 24 regeln und am Ende muss korrekt 0.25 bis 3 rauskommen.
Eine einfache Zahlen-Transponierung geht hier schief, weil zb. dann die Mitte also 0 = 1.625 wäre anstatt 1
Die einzige Möglichkeit, die mir einfällt ist ein Selektor mit 5 Eingängen zu nehmen (0.25 / 0.5 / 1 / 2 / 3) und diesen dann mit dem Knopf abzufahren.
Ich würde aber gern eine korrekte Berechnung bzw. Formel dazu anwenden.
Brauche Hilfe! :)
Wieso muss bei +24 die Zahl 3 ausgeworfen werden?
Wenn ich deinem Ansatz folge, müsste die Reihe wegen der Verdoppelungsregel doch folgendermaßen lauten:
(-24|0,25), (-12|0,5), (0|1), (12|2), (24|4).
Bild 1.jpg
Bild 2.jpg
ciao herw

Re: Speedfaktor zu Pitchwert

Verfasst: 20. April 2014, 09:51
von pavel
PrinzThomas hat geschrieben:Oh danke für die Arbeit, die du dir extra gemacht hast.
Leider ist das leider "nur" geometrisch korrekt.
Zwischen den Punkten muss der Graph linear sein, denn die Noten sind ja auch linear innerhalb einer Oktave verteilt.
Zumindest wenn man man von der Frequenz absieht. ;)
Allerdings hätte ich gerne eine flexible Lösung gehabt bei der es egal ist welche Werte der Knopf rauswirft.
Also ich glaube, folgender Makro funktioniert jetzt so wie von dir gewünscht:
Pitch to Speed linear.zip
Habe zum Vergleich mal noch einen Selector mit Werten für -168 bis 12 reingepackt..
Ab 0 aufwärts vervielfacht sich die Geschwindigkeit ja sowieso linear mit konstanter Steigung und konstantem y-Achsen-Abschnitt, sprich pro Oktave vervielfacht sich die Geschwindigkeit um 1..

Jetzt kann die österliche Freudenzeit aber hoffentlich beginnen :lol:

Re: Speedfaktor zu Pitchwert

Verfasst: 20. April 2014, 14:02
von PrinzThomas
Du begehst einen Denkfehler!
Ich möchte ja Pitchwert zu Faktor! und nicht Pitchwert zur ständigen Verdoppelung.
Dass sich bei den ersten 2 Werten quasi erstmal Verdoppelungen oder Halbierungen einstellen ist ja klar, aber die Reihenfolge geht natürlich nicht so weiter. ^^
Bei Verdoppelungen würde ich ja ständig Pitchwerte auslassen - wie eben z.B. bei einer Verdreifachung.
Dann wäre ja der Pitchregler völlig falsch.
Nach deiner Theorie müsste ja dann z.B. + 36 = das 8fache einer Oktave sein usw...

Die Faktoren bei einfachen Oktaven sind aber logischerweise keine Verdopplungen sondern:
Faktor 1 = original (einfach abgespielt)
Faktor 2 = doppelt (doppelt abgespielt)
Faktor 3 = dreifach (dreimal schneller abgespielt)
usw..

Ergo:
Pitchwert 0 = einfach = Faktor 1
Pitchwert +12 = Doppelte Oktave = Faktor 2
Pitchwert +24 (nur eine Oktave dazu) also dreifach = Faktor 3
usw...

Genau das wollte ich als Formel und nicht mit einem Selektor, der ja immer nur einen Bereich absteckt und die Werte streng genommen nur dahinzwingt wo sie sein müssen anstatt sie nach einer Formel korrekt zu berechnen.
Mit einem Selektor hatte ich das ja von Anfang an selber erst einmal gelöst.

Im Grunde reden wir ja von einem Speedfaktor - siehe Titel!

Es wird z.B. ein Audiofile mit dem bestimmten Faktor abgespielt.
Folglich entspricht z.B. eine Dreifache Abspielgeschwindigkeit einem Pitchwert von + 24 ganzen Noten.
Nimm einen Sinus auf C3, speichere ihne als Audiofile und spiele das Audiomateriel 3 mal schneller ab.
Dann erhältst du gehört einen Ton C5 - ergo + 24 ganze Noten.
Ich hatte gehofft so etwas gibt es auch als mathematische Formel.

Re: Speedfaktor zu Pitchwert

Verfasst: 20. April 2014, 14:39
von PrinzThomas
Ich hatte nur zu einem ersten Post geantwortet - da hattest du das ja wahrscheinlich noch nicht verstanden, was ich wollte.
Dein zweiter Post mit dem Macro und der Berechnung ist korrekt.
Genau das wollte ich.
Dank dir!
Ich bin jetzt nicht so das Matheass.
Die Formel lautet also wie das Macro heisst: "y=mx+c"?
Könntest du das näher erläutern für was die einzelnen Variablen stehen und wie du auf den Lösungsweg gekommen bist?
Das genau war ja mein Problem - ich habe es mathematisch logisch nicht herleiten können, um daraus eine feste Formel zu machen.

Re: Speedfaktor zu Pitchwert

Verfasst: 20. April 2014, 17:48
von pavel
PrinzThomas hat geschrieben:Ich hatte nur zu einem ersten Post geantwortet - da hattest du das ja wahrscheinlich noch nicht verstanden, was ich wollte.
Dein zweiter Post mit dem Macro und der Berechnung ist korrekt.
Genau das wollte ich.
Dank dir!
Ich bin jetzt nicht so das Matheass.
Die Formel lautet also wie das Macro heisst: "y=mx+c"?
Könntest du das näher erläutern für was die einzelnen Variablen stehen und wie du auf den Lösungsweg gekommen bist?
Das genau war ja mein Problem - ich habe es mathematisch logisch nicht herleiten können, um daraus eine feste Formel zu machen.
Kein Thema, hatte die Rechnung gestern Abend schon fertig, aber hatte noch ein par strukturelle Fehler gemacht, die ich zu später Stunde nicht mehr bewältigen konnte und wollte.
Und ich wusste beim ersten Post in der Tat nicht genau, was du wolltest - hoffe der Makro macht sich jetzt auch praktisch nützlich und ist keine reine Theorie :)

Also zunächst habe ich in GeoGebra die Punkt-Liste erweitert (passender x-Pitch-Wert n-mal -12|y-Wert n-mal halbiert | )
und dann anschließend die Funktion "Gerade - wähle zwei Punkte" genutzt, um damit Geraden durch jeweils zwei Punkte zu zeichnen.
pitch-speed-1.jpg
Dann habe ich aus den Geraden-Formeln y=m*x+c jeweils die Steigung m und den y-Achsen-Abschnitt/Versatz c passend zum Pitchwert wieder in Listen eingetragen
und mit der Funktion trendExp2 eine exponentielle Funktion "gefunden", die das Verhältnis von Geradensteigung und Pitch zum Glück exakt widerspiegelt.
Hätte ich hier keine Gesetzmäßigkeit gefunden wäre ich nicht mehr weiter motiviert gewesen..
pitch-speed-2.jpg
Sprich gesuchte Funktion f(x) = h(x) * x + c
Und das c habe ich dann per Punktprobe (praktischerweise erkennt man in Grafik 1, dass die Gerade immer dann die x-Achse schneidet, wenn man von dem Pitchwert der die Steigung definiert, 12 abzieht, also Testpunkt T(x°-12|0) ). Habe einfach nach c aufgelöst also aus 0 = h(x°)*(x°-12) + c --wird--> 0 - h(x°)*(x°-12) = c

Der Rest sorgt dafür, dass von 0 abwärts immer in 12er-Schritten ein Pitchwert übermittelt wird (0, -12, -24, -36,..) und von 0 aufwärts immer der Pitchwert 0 zur Berechnnung von Steigung m und y-Achsenabschnitt c verwendet wird sprich (m = 0.083333333333333 und c= 1)
pitch-speed-3.jpg
y=mx+c ist die Formel für lineare Funktionen und meine Rechnung ändert einfach alle 12 Pitchwerte x (für x<=0) die Steigung m und den y-Achsen-Abschnitt c, sodass immer eine Oktave lineare Werte ausspuckt.
Denke besser kann ichs nicht erklären, fließt dank mathemathischer Unkentnisse auch viel Trial and Error mit ein.. :wink:

Cheers

Re: Speedfaktor zu Pitchwert

Verfasst: 20. April 2014, 18:18
von herw
PrinzThomas hat geschrieben:Du begehst einen Denkfehler!
Ich möchte ja Pitchwert zu Faktor! und nicht Pitchwert zur ständigen Verdoppelung.
Dass sich bei den ersten 2 Werten quasi erstmal Verdoppelungen oder Halbierungen einstellen ist ja klar, aber die Reihenfolge geht natürlich nicht so weiter. ^^
sorry falsch
[...]
Nach deiner Theorie müsste ja dann z.B. + 36 = das 8fache einer Oktave sein usw...
korrekt, wenn du hier den Begriff „Oktave” mit der entsprechenden Frequenz gleichsetzt.
[...]
Es wird z.B. ein Audiofile mit dem bestimmten Faktor abgespielt.
Folglich entspricht z.B. eine Dreifache Abspielgeschwindigkeit einem Pitchwert von + 24 ganzen Noten.
Nimm einen Sinus auf C3, speichere ihne als Audiofile und spiele das Audiomateriel 3 mal schneller ab.
Dann erhältst du gehört einen Ton C5 - ergo + 24 ganze Noten.[...]
sorry, nochmals falsch:
C3 entspricht 130,813Hz
C4 entspricht 2·130,813Hz=261,626Hz
C5 entspricht 4·130,813Hz=523,251Hz
C6 entspricht 8·130,813Hz=1046,50Hz
siehe hier: Frequenzen der gleichstufigen Stimmung
wenn man eine Audodatei um eine Oktave nach oben transponieren möchte, dann muss man jeweils mit doppelter Geschwindigkeit abspielen. Diesen Zusammenhang beschreibt meine angegebene Exponentialfunktion. Sie gilt selbstverständlich auch für alle Transponierungen auf Zwischentonhöhen und auch bei höheren Oktavtransponierungen.

@Pavel
Wie man leicht erkennen kann, handelt es sich bei der Funktion h(x) um eine Exponentialfunktion. Allerdings lineare ansteigende Werte innerhalb einer Oktave auszugeben ist eine sehr grobe Näherung. Wie man dem Handbuch von GeoGebra entnehmen kann, untersucht man mit dem Befehl TrendExp2 eine Regressionskurve der Form a·b^x, also einer Exponentialfunktion. Die Basis 1,059... entspricht dem Wert 2^(1/12): Quantitative Aspekte der gleichstufigen Stimmung.

ciao herw

PS: Bei digitalen Aufnahmen bewirken übrigens andere Abspielgeschwindigkeiten keine Tonhöhenänderungen; siehe zum Beispiel das Abspielen einer Audiodatei in Logic Pro X. Hier wird jeweils die Audiodatei in zeitliche Schnipsel eingeteilt und zum Beispiel bei doppelter Geschwindigkeit nur jeder zweite Schnipsel abgespielt. Dadurch bleibt die eingespielte Tonhöhe erhalten.

Re: Speedfaktor zu Pitchwert

Verfasst: 20. April 2014, 20:39
von PrinzThomas
@herw
genau deshalb habe ich geschrieben FAZIT: "Zumindest wenn man man von der Frequenz absieht."
Du musst schon alles lesen, was ich schreibe. ;)
Mathematisch bzw. das was man am Regler sieht ist absolut korrekt wie ich es beschrieben habe.
Da ist gar nix falsch.^^
Dass die Frequenzen hier natürlich anders verlaufen bzw. Verdoppelungen darstellen ist ein völlig anderes Thema.
Mir ging es hier um folgendes:
Faktor 1 = original Abspielgeschwindigkeit = Pitch 0 = kein Pitching
Faktor 2 = doppelte Abspielgeschwindigkeit = Pitch 12 = +1 Oktave
Faktor 3 = dreifache Abspielgeschwindigkeit = Pitch 24 = +2 Oktaven
Faktor 4 = vierfache Abspielgeschwindigkeit = Pitch 36 = +3 Oktaven
usw...
Ich rede auch hier nur von dem was man hört und nicht von dem was die Frequenzen in Wirklichkeit "tun".
Wie gesagt von Frequenzen war hier gar nicht die Rede und spielt auch in der eigentlichen Problemlösung gar keine Rolle, weil zwischendurch keine Frequenzwerte gebraucht werden.
Hier ging es immer nur um Faktoren und ohne Pitchkorrektur gehörte Pitchvergleiche.
Und da ist es nun mal so, dass ein Sinus bei C3 aufgenommen und mit Faktor 3 abgespielt ein Sinus rauskommt, der dem von C5 entspricht! Punkt.
Natürlich ist er dann als Sample betrachtet 3 mal kürzer - aber darum gings hier auch nicht.
C3 wäre in dem Beispiel mein Ausgangswert 0.
Frequenztechnisch gesehen ist C3 aber natürlich nicht 0 - das ist schon klar.
Hier kommt dann sogar Einstein mit in den Ring.
Frequenzen sind ja fest definiert - also absolut - ergo ist die Ausgangsbasis 0 Hertz!
Wir behandeln hier aber ein relatives Thema - da Nullpunkte irgendwo gesetzt werden und von da aus weiter gerechnet werden.
So kann mein Pitch 0 (also Ausgangspunkt) = C3 sein oder C26 oder C7 - je nach dem wo man das "Original" ansetzt.
Ergo muss man relativ rechnen und eine im Hintergrund ablaufende absolute Zuordnung nicht mit einbeziehen.
Ich glaube du hast vielleicht ähnlich wie pavel zum Anfang das Problem nicht verstanden!
Was hinten mit Frequenzen und den tatsächlichen Verdopplungen passiert ist völlig irrelevant - da es wie gesagt hier ein relatives Umrechnen ist und keine absolut bezogene Berechnung.
Und das mit C3 und C5 bzw. den Oktavsprüngen war nur ein Beispiel, um es verständlich zu machen, was ich dann am Knopf ablese und die Ohren am Schluss auch hören.

@pavel
Super!
Macro ist eingebaut und funktioniert sofort korrekt!
Danke nochmal.
Deine Ausführung werde ich mir mal in Ruhe durchdenken - das ist mir jetzt auf die Schnelle etwas zu heavy. ;)

Pitchwert -> Speedfaktor

Verfasst: 21. April 2014, 05:21
von herw
PrinzThomas hat geschrieben:@herw
genau deshalb habe ich geschrieben FAZIT: "Zumindest wenn man man von der Frequenz absieht."
Du musst schon alles lesen, was ich schreibe. ;)
das tue ich,darum hat die Funktion 2^(x/12) auch keinen Vorfaktor. Du musst schon die Mathematik richtig interpretieren.
Mathematisch bzw. das was man am Regler sieht ist absolut korrekt wie ich es beschrieben habe.
Da ist gar nix falsch.^^
auch wenn du es immer wieder wiederholst, du wirst die Physik (hier Akustik) nicht revolutionieren.
Dass die Frequenzen hier natürlich anders verlaufen bzw. Verdoppelungen darstellen ist ein völlig anderes Thema.
Mir ging es hier um folgendes:
Faktor 1 = original Abspielgeschwindigkeit = Pitch 0 = kein Pitching
Faktor 2 = doppelte Abspielgeschwindigkeit = Pitch 12 = +1 Oktave
Faktor 3 = dreifache Abspielgeschwindigkeit = Pitch 24 = +2 Oktaven
Faktor 4 = vierfache Abspielgeschwindigkeit = Pitch 36 = +3 Oktaven

usw...
Ich rede auch hier nur von dem was man hört und nicht von dem was die Frequenzen in Wirklichkeit "tun".
Wie gesagt von Frequenzen war hier gar nicht die Rede und spielt auch in der eigentlichen Problemlösung gar keine Rolle, weil zwischendurch keine Frequenzwerte gebraucht werden.
Hier ging es immer nur um Faktoren und ohne Pitchkorrektur gehörte Pitchvergleiche.
Und da ist es nun mal so, dass ein Sinus bei C3 aufgenommen und mit Faktor 3 abgespielt ein Sinus rauskommt, der dem von C5 entspricht! Punkt.
Diese Basta-Rethorik macht die Sache nicht korrekt. Einer dreifachen Abspielgeschwindigkeit entspricht nicht einem Anheben der Tonhöhe um zwei Oktaven, sondern im Beispiel von C3 einem Anheben der Tonhöhe auf G4, was in unserem Gehör ein angenehmes Intervall ist, aber eben nicht zwei Oktaven entspricht.
Natürlich ist er dann als Sample betrachtet 3 mal kürzer - aber darum gings hier auch nicht.
C3 wäre in dem Beispiel mein Ausgangswert 0.
Frequenztechnisch gesehen ist C3 aber natürlich nicht 0 - das ist schon klar.
Hier kommt dann sogar Einstein mit in den Ring.
abgesehen vom Wort „relativ", das du hier meinst, hat der nun gar nichts damit zu tun; siehe mein Kommentar oben.
Frequenzen sind ja fest definiert - also absolut - ergo ist die Ausgangsbasis 0 Hertz!
wieder falsch. Auch wenn du 0 Hz verdoppelst, bleibt es bei 0 Hz. Eine Exponentialfunktion nimmt niemals den Wert 0 an. Was du meinst ist der Pitchwert 0, dieser entspricht einer Frequenz von ca. 8,1795Hz. s.u.
Wir behandeln hier aber ein relatives Thema - da Nullpunkte irgendwo gesetzt werden und von da aus weiter gerechnet werden.
So kann mein Pitch 0 (also Ausgangspunkt) = C3 sein oder C26 oder C7 - je nach dem wo man das "Original" ansetzt.
Ergo muss man relativ rechnen und eine im Hintergrund ablaufende absolute Zuordnung nicht mit einbeziehen.
Ich glaube du hast vielleicht ähnlich wie pavel zum Anfang das Problem nicht verstanden!
doch habe ich; nebenbei bemerkt ist der gegebene Thread-Titel falsch: du schreibst „Speedfaktor zu Pitchwert”, redest aber nur von der Berechnung des Speedfaktors aus dem Pitchwert, also der Umrechnung vom „Pitchwert zum Speedfaktor”!
Was hinten mit Frequenzen und den tatsächlichen Verdopplungen passiert ist völlig irrelevant - da es wie gesagt hier ein relatives Umrechnen ist und keine absolut bezogene Berechnung.
habe ich schon mehrfach erwähnt.
Und das mit C3 und C5 bzw. den Oktavsprüngen war nur ein Beispiel, um es verständlich zu machen, was ich dann am Knopf ablese und die Ohren am Schluss auch hören.
Deine Ohren täuschen Dich, da das Tonhöhenintervall bei einem Abspielfaktor drei einer Anhebung auf den zweiten Oberton (reine Quinte) entspricht und daher in unseren klassisch geprägten Ohren angenehm klingt. Dies entspricht aber eben nicht zwei Oktaven. Pavels Näherungsrechnung ist gerade im Intervall von 24 bis 36 falsch.
Es wäre gut, wenn du dein Ensemble mal in kleiner Version hier hochladen würdest, dann müsste man nicht immer theoretisch darüber reden.

Re: Speedfaktor zu Pitchwert

Verfasst: 21. April 2014, 07:34
von PrinzThomas
Ausgangswert ist z.B.: +12
Ein Faktor 3 müsste also nach meiner Meinung nach 2 Oktaven höher ergeben.
Da 3 x 12 immer noch 36 ergibt!

FAKTOR 1:
1 x 12 = 12 = einfacher Faktor = keine Veränderung... 1x12 bleibt eben 12
-------------
FAKTOR 2:
2 x 12 = 24 = Verdoppelung / zweifacher Faktor... 2x12 ist und bleibt 24
-------------
FAKTOR 3:
3 x 12 = 36 = Verdreifachung / dreifacher Faktor... auch 3x12 wird immer 36 bleiben
-------------
Ergo:
Unterschied Ausgangswert +12 zu Endwert +36 = Differenz 24 Halbtöne sprich 2 Oktaven

Nichts anderes wollte ich - weder was von Frequenzen (das habe ich wie gesagt sofort oben in meinem Posting ausgeschlossen) sonst noch was von Pitchkorrekturen oder von was hier alles noch die Rede war.
Vielleicht hatte ich mich ja etwas falsch ausgedrückt.
Das Problem ergibt sich eben, dass sich Minusbereiche Halbieren mussten - jedoch positive Werte Multipliziert.
Das Macro von pavel ist genau der richtige Lösungsweg, den ich gesucht habe.
Und da pavel - genau das auch so umgesetzt hat - hat er ja auch anscheinend verstanden, was ich meinte - nur du vermutlich nicht.
Sonst gebe es auch das Macro nicht.^^

Im Übrigen ist eine Erklärung, dass eine Quinte angenehm für das Ohr ist - z.B. +7 Halbtonschritte ect. - glaube ich nach 9 Jahren Klavierunterricht nicht nötig.
Aber trotzdem danke für die nachträgliche Auffrischung in Sachen Harmonielehre. ^^

Re: Speedfaktor zu Pitchwert

Verfasst: 21. April 2014, 13:10
von herw
PrinzThomas hat geschrieben:Ausgangswert ist z.B.: +12
Ein Faktor 3 müsste also nach meiner Meinung nach 2 Oktaven höher ergeben.
ich geb's auf; mach es, wie du willst. Ohne ein konkretes Beispiel-Ensemble drehen wir uns nur im Kreis.
Du kannst zur Kontrolle ja mal deinen Sinus mit Speed 3 aufnehmen - nach deiner Meinung 2 Oktaven höher. Dann spiele dieses neue Audiofile mit dem Faktor 0,25 - nach deinen (richtigen) Ausführungen zwei Oktaven tiefer - und vergleiche!

Re: Speedfaktor zu Pitchwert

Verfasst: 21. April 2014, 21:33
von PrinzThomas
Das Timewarp Macro erwartet eben genau diese Art und Weise der Multiplikation.
Das kann ich auch nicht ändern. ^^
Dass es bei Samples, die man nahc Faktoren abspielt so ist wie du sagst - ist 1. jeden bekannt - war aber 2. gar nicht gefragt.
Und weil ich von Anfang an wußte, dass es hier nicht um die Frequenzverdopplung gehen soll hatte ich das ganz oben auch sofort ausgeschlossen.
Ich kann nix dafür, wenn man sich einfach über solche Sätze hinwegsetzt.
Ich wollte einen Lösungsweg die Pitchwerte in Faktoren bzw. Multiplikatoren umzurechnen.
Und du siehst ja anhand von pavels Lösung, dass das nicht gerade einfach war.
Ergo einen gewissen Anspruch hat.
Aber wir reden aneinander vorbei: du redest von Frequenzverdopplung durch Doppeltes Abspielen eines Samples - also dessen Frequenzen und ich rede von einem optischen Umrechnen von Pitchwerten zu Oktav-Multiplikationen bzw. Faktoren.
Komisch nur dass pavel es sehr schnell verstanden hatte, was ich wollte und auch einen Lösungsweg fand.
Aber wie gesagt ich gebe gerne zu mich nicht richtig ausgedrückt zu haben.
Vielleicht kommt auch noch der Wortdreher des Titels hinzu, dessen Fehler man sich aber in der nachfolgenden Beschreibung sofort denken kann.
Es gibt so ein Phänomen, wenn es um Expertenwissen geht.
Viele, die wie du sehr tief in so eine Materie wie die von Reaktor usw. eintauchen sind evtl. manchmal "blind" für die einfachen Dinge.
Es war hier nicht nach irgendwelchen Frequenzgesetzmäßigkeiten gefragt sondern nach einem optischen Feedback für den Benutzer, dem es völlig egal ist was da im Hintergrund abläuft solange es so funktioniert wie er es auch erwartet.
Deshalb sind eben viele GUIs von den Reaktor-Experten aufgrund dass sie eben exakt und richtig bezeichnet und angeordnet sind absolut schlecht zu bedienen.
Super, dass alles mathematisch korrekt ist, aber das Bedienen macht null Spaß.
Da gibt es z.B. eine Menge Beispiele wie bei Synthieknöpfen und was dann im Hintergrund abläuft getrickst wird.
Am Ende hat der Knopf technisch gesehen eine völlig falsche Bezeichnung, aber macht genau das, was der Benutzer erwartet und auch so hört.
So ist zum Beispiel heutzutage kaum noch von Resonanz die Rede sondern vielmehr von Boost - total falsche Bezeichnung.
Ebenso - und da kommen wir auch mal an unser Thema ran werden so oft optische Regelbereiche angeben wie z.B. Cutoff von 0-100, was nun völlig falsch ist.
Richtig wäre bei dem Cutoff die Frequnz anzugeben.
Lässt sich nur scheisse ablesen und führt meist zu Verwirrung des Benutzers - da viel zu kompliziert und technisch.
Ebenso werden Flankensteilheiten von Filtern, die früher streng technisch korrekt nach db angegeben wurden und die man in Stufen umschalten musste (6db / 12db / 18db / 24db) heutzutage überhaupt nicht mehr so angegeben.
Da befinden sich einfach ein "Slope" Regler, der alle db Filter einfach nacheinander mitttels Crossfade stufenlos durchzieht.
Technisch absolut unhaltbar, denn dann hätte man sich ja immer auch alle Zwischenstufen sparen können, wenn man das so einfach stufenlose durchfahren kann.
So bekommt man z.B. heutzutage auch locker einen LP mit was weiß ich 13,6 db - ist aber technisch völlig falsch, ABER er klingt trotzdem tatsächlich wie ein 13,6db Filter.
Ständig wird getrickst und falsch bezeichnet, um ein einfaches Bedienen zu ermöglichen.
Wenn alles so korrekt wäre wie du es dir vielleichst wünscht würde kein Benutzer mehr durchsehen, weil alles nur noch wilde spießige technische Bezeichnungen hätte.
Dass im Inneren es dann natürlich trotzdem korrekt ablaufen muss ist ja klar, war aber hier auch nie ausgeschlossen wurden.
Es ging die ganze Zeit immer nur um eine optische Anzeige und nicht, ob diese auch dem technischen Hintergrund entspricht.
Das tun die meisten Regler bei Software-Synthies nämlich nicht, was auch ein Punkt ihres Erfolges ausmachen dürfte.