@ thelittlebug: Also die handelsüblichen Kompressoren arbeiten nach dem Threshold, Ratio, Attack und Release - Prinzip, wie es hier beschrieben wird. Beim SOX-Kompressor reagieren Attack und Decay (= Release) genau entgegengesetzt, wie erwartet. Eine Ratio gibt es nicht. Über "in-dB1,out-dB1" ist nicht nur eine Veringerung, sondern auch eine Verstärkung des Ausgangs-Signals möglich. Der Befehl heißt "Compander". Ein Kompanderist aber was ganz Anderes Noisegate oder Downwardexpander sind mit dem SOX-Kompressor ebenfalls möglich. Der SOX-Kompressor arbeitet eher wie ein Hüllkurvengenerator. Probiers einfach aus. Es lassen sich damit durchaus kompressorartige Effekte herstellen, man muß nur ein wenig umdenken.
FFT geht auch recht fix mit tkSnack, inkl. grafischer Darstellung.
@BackJack: So isses (fast). Keine gleichmäßige Pegelabsenkung. Der Verstärkungseffekt tritt durch das Output-Gain auf, was aber nichts anderes als ein nachgeschalteter Aufholverstärker und auch nicht immer vorhanden ist.
Ansonsten gibt es hier eine weitere Version, wo jeder Effekt sein eigenes Klassen-Objekt hat.
Gruss, Seven
GUI für SOX
-
- User
- Beiträge: 408
- Registriert: Freitag 7. Oktober 2005, 14:37
- Wohnort: Berlin
- Kontaktdaten:
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Jetzt musst du dir noch abgewöhnen Module mit *-Importen reinzuziehen, siehe [wiki]Import[/wiki].snakeseven hat geschrieben:Ansonsten gibt es hier eine weitere Version, wo jeder Effekt sein eigenes Klassen-Objekt hat.
Achja und,
Code: Alles auswählen
# ---------------------------------------------------------------------------- GLOBALS ------------------------------------------------------------------------------------
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 408
- Registriert: Freitag 7. Oktober 2005, 14:37
- Wohnort: Berlin
- Kontaktdaten:
Hi Leonidas,
das hört sich nach einer sinnvollen Beschäftigung für ein verregnetes Himmelfahrt an Danke für die Verbesserungsvorschläge !
Gruss, Seven
das hört sich nach einer sinnvollen Beschäftigung für ein verregnetes Himmelfahrt an Danke für die Verbesserungsvorschläge !
Gruss, Seven
-
- User
- Beiträge: 408
- Registriert: Freitag 7. Oktober 2005, 14:37
- Wohnort: Berlin
- Kontaktdaten:
Das Problem das ich dabei habe ist, daß man dem 'command=' Befehl der Buttons anscheinend keine Parameter übergeben kann, z.B. command = Play('Volume'). Wie können die einzelnen Aufrufe dann voneinander unterschieden werden ?Leonidas hat geschrieben: Auch die ``call_volume()`` Funktionen sind allesammt kopiert und somit redundant. Man braucht nur eine generische Funktion, die alle Klassen abdeckt.
Hat bei mir nicht geklappt. Wenn ich den __init__() Aufruf in den call_effect() Funktionen weglasse, werden die Variablen nicht gesetzt ?Zuletzt ist es unnötig ``__init__()`` jemals explizit aufzurufen - das passiert automatisch wenn ein Objekt instanziiert wird.
Gruss, Seven
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Mit ``lambda``:snakeseven hat geschrieben:Das Problem das ich dabei habe ist, daß man dem 'command=' Befehl der Buttons anscheinend keine Parameter übergeben kann, z.B. command = Play('Volume'). Wie können die einzelnen Aufrufe dann voneinander unterschieden werden ?
Code: Alles auswählen
command = lambda: Play('Volume')
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Wobei ich da jetzt schon wieder in `Play()` eine ``if``/``else``-Kaskade sehe. Wenn man sich die ganzen `call_*()`-Funktionen ansieht, dann ändert sich ja nur das Effekt-Objekt. Kann man also so verallgemeinern:
Und bei den Lambdafunktionen gibt man dann das Effekt-Objekt an:
Wobei man bei der Namensgebung vielleicht die Klasse besser `Volume` und das Objekt `VOLUME` nennen sollte. Insgesamt ist die "Globalität" und Verflechtung in dem Programm immer noch extrem hoch.
Zu `__init__()` da gehört alles rein was bei der *Erzeugung* des Objekts passiert. Wenn mehrere Objekte in der `__init__()` dieselbe globale Variable setzen und Du die Objekte alle auf einen Schlag nacheinander erzeugst, dann "gewinnt" natürlich das zuletzt erzeugte Objekt.
Code: Alles auswählen
def call_effect(effect):
effect.__init__() # Dubios!
effect.build_frame()
effect.set_values()
Code: Alles auswählen
lambda: call_effect(VOL)
Zu `__init__()` da gehört alles rein was bei der *Erzeugung* des Objekts passiert. Wenn mehrere Objekte in der `__init__()` dieselbe globale Variable setzen und Du die Objekte alle auf einen Schlag nacheinander erzeugst, dann "gewinnt" natürlich das zuletzt erzeugte Objekt.
-
- User
- Beiträge: 408
- Registriert: Freitag 7. Oktober 2005, 14:37
- Wohnort: Berlin
- Kontaktdaten:
Hi,
Lambda kannte ich noch nicht. Geht gut damit !
__init__ wird nur bei Programmstart ausgeführt, wenn ich die Objekte bilde (Effect = EFFECT()). Wenn ich die Effekte über call_effect(effect) wechsel, werden der Konstruktoren nicht aufgerufen und somit die globalen Variablen nicht gesetzt.
Ganz ohne globale Variablen kann ich es mir schwer vorstellen. Play() muß 'wissen', welcher Effekt gerade aktiv ist und den entsprechenden Kommando-String an SOX schicken.
Gruss, Seven
Lambda kannte ich noch nicht. Geht gut damit !
__init__ wird nur bei Programmstart ausgeführt, wenn ich die Objekte bilde (Effect = EFFECT()). Wenn ich die Effekte über call_effect(effect) wechsel, werden der Konstruktoren nicht aufgerufen und somit die globalen Variablen nicht gesetzt.
Ganz ohne globale Variablen kann ich es mir schwer vorstellen. Play() muß 'wissen', welcher Effekt gerade aktiv ist und den entsprechenden Kommando-String an SOX schicken.
Gruss, Seven
Alles was `play()` wissen muss, sollte als Argument übergeben werden. Ein Effekt-Objekt kennt alle seine Werte und sollte auch ein paar von den "globalen" Werten kennen, also könnte ein Effektobjekt auch eine `play()`-Methode bekommen. Von der Möglichkeit Argumente zu übergeben und Rückgabwerte zurückzugeben wird fast gar kein Gebrauch gemacht. Deswegen war die erste Variante selbst für ein rein prozedurales Programm stilistisch nicht besonders gut.
Du könntest den Effekten ein Namensattribut verpassen und die Objekte in eine Liste stecken. Dann kann man das Programm so umschreiben, dass der Name nur einmal im Programm stehen muss und die Buttons in einer Schleife erzeugt werden können.
In den `build_frame()`-Methoden ist viel sich wiederholender Quelltext, sowohl auf die Methode bezogen als auch in einzelnen Aufrufen in den Methoden. Da kann man sicher einiges herausziehen.
Du könntest den Effekten ein Namensattribut verpassen und die Objekte in eine Liste stecken. Dann kann man das Programm so umschreiben, dass der Name nur einmal im Programm stehen muss und die Buttons in einer Schleife erzeugt werden können.
In den `build_frame()`-Methoden ist viel sich wiederholender Quelltext, sowohl auf die Methode bezogen als auch in einzelnen Aufrufen in den Methoden. Da kann man sicher einiges herausziehen.
-
- User
- Beiträge: 408
- Registriert: Freitag 7. Oktober 2005, 14:37
- Wohnort: Berlin
- Kontaktdaten:
aktuelle Version.
Mit den Objekten in der Liste war eine gute Idee. Neue Effekte lassen sich so recht schnell dazu programmieren.
Gruss, Seven
Mit den Objekten in der Liste war eine gute Idee. Neue Effekte lassen sich so recht schnell dazu programmieren.
Gruss, Seven