Frequenz- & Phasenmodulation

[herw]

[...]
sag ich ja

Hast ja recht… aber: Man muss ja doch irgendwie ersma drauf kommen und das auch umsetzen

ja

[KlangRaum]

Ich hab zugegeben nicht viel Erfahrung mit Core, mit Primary krieg ich jedoch jedes Ding hin. Wenn man nur Einzelheiten mit Core umsetzt, steigt die CPU-Last ziemlich an, macht man sich jedoch nen Kopp und baut alles in Core, kann man sehr effizient arbeiten. Aber genau da liegt mein Problem, ich verstehe nicht so ganz wie zB Events funktionieren: Mal gehts...mal nicht. Ich könnt fast verzweifeln. Wem gehts änlich?

[herw]

[...] ich verstehe nicht so ganz wie zB Events funktionieren: Mal gehts...mal nicht. Ich könnt fast verzweifeln. [...]

ein Beispiel wäre nützlich - BTW nicht verzweifeln (core ist super)

[KlangRaum]

Bin da grade etwas am erforschen: Zb habe ich eine Reihe Knobs die in eine EventCoreCell geführt werden und eine weitere Verarbeitung anstossen sollen. Solande ich momentan die Regler „Einzeln bediene“ klappt alles wunderbar, die Umschaltung via Snapshot tut jedoch noch garnichts. Vielleicht ist das nur ein Verständnisfehler meinerseits, die Schaltung ist auch noch nicht fertig. Aber gibts da evtl ein generelles Problem mit der „Gleichzeitigkeit von Events“ ?

Ich bastel da nochmal bisserl weiter und werde dann mal einen Schaltungsentwurf posten....

[herw]

Gleichzeitigkeit bedeutet: alle Werte, die von ein und demselben Eingangsevent (oder einem Clocktrigger) abhängig sind, werden in core cells (auch audiocells) so behandelt, als ob sie gleichzeitig bearbeitet würden.

Interessant ist die sehr heftige und intensive Darstellung der (Nicht)-Gleicheitigkeit von unserem Core-Spezialisten Gerald (krümelmonster). Die teilweise privaten Bemerkungen musst du überlesen; krümelmonster haut mir sein Konzept so richtig um die Ohren, ich hab's aber überlebt.
Wir diskutieren immer wieder mal darüber und es gibt tatsächlich immer noch in REAKTOR etwas zu entdecken: zum Beispiel wird nur der Audio-Eingang einer AudioCoreCell durch die SampleRateClock getaktet, jedoch nicht der Ausgang (!!!). D.h. da gibt's noch was zwischen den SampleRateTicks; ist aber nur beschränkt auszunutzen.

ciao herw

Ich habe übrigens die Überschrift des Teil-Threads geändert; dies erschien mir passender.

[KlangRaum]

Hmmmm....

Die Gleichzeitigkeit in Core ist eine solche per declarationem: ' Alle Events, deren Ursprung ein und derselbe ist, sind gleichzeitg'. Gut.
Hier geht es um den Umkehrschluss:
"Alle Events, deren Ursprung nicht ein und derselbe ist, sind nicht-gleichzeitig." Auch nicht-gleichzeitig mit der Sample-Clock.

...dann kommen noch diverse Effekte mit der Abarbeitungsreihenfolge -also der Reihenfolge wie die Schaltung verdrahtet wurde hinzu.

Ich konnte schon einen kleinen Teil des Problem beheben, indem ich die gesamte Schaltung originalgetreu mal in einer bestimmten Reihenfolge neu aufgebaut habe. Bei dieser Schaltung geht es um meinen Systembus, bei dem die Signale in einer genau festgelegten Reihenfolge generiert und abgearbeitet werden müssen. Ich hab wohl bisher an der Eventbearbeitung unter Core einiges nicht richtig eingeschätzt..



Ist sowas wie kontrollierter Anbau.... Bio-Öko ist für den Landwirt nichts anderes

[herw]

Hmmmm....

Die Gleichzeitigkeit in Core ist eine solche per declarationem: ' Alle Events, deren Ursprung ein und derselbe ist, sind gleichzeitg'. Gut.
Hier geht es um den Umkehrschluss:
"Alle Events, deren Ursprung nicht ein und derselbe ist, sind nicht-gleichzeitig." Auch nicht-gleichzeitig mit der Sample-Clock.

genau - hmmmm !!! mach dir da aber jetzt noch keinen Kopf drüber; das ist erst bei ganz anderen Problemen interessant und echte Core-Forschung

...dann kommen noch diverse Effekte mit der Abarbeitungsreihenfolge -also der Reihenfolge wie die Schaltung verdrahtet wurde hinzu.

jaaaa - ein Problem der Nichtkohärenz von primary und core. Das greife ich schon seit langem an und ist eigentlich unzumutbar: eine Schaltung kann davon abhängen, in welcher Reihenfolge die Drähte in primary geknüpft wurden; ein unhaltbarer Zustand, der in Core nicht existiert!
Da sind noch einige Überlegungen zu nötig.

Ich konnte schon einen kleinen Teil des Problem beheben, indem ich die gesamte Schaltung originalgetreu mal in einer bestimmten Reihenfolge neu aufgebaut habe. Bei dieser Schaltung geht es um meinen Systembus, bei dem die Signale in einer genau festgelegten Reihenfolge generiert und abgearbeitet werden müssen. Ich hab wohl bisher an der Eventbearbeitung unter Core einiges nicht richtig eingeschätzt..

Ist sowas wie kontrollierter Anbau.... Bio-Öko ist für den Landwirt nichts anderes

bei einer genau festgelegte Reihenfolge ist man schnell im Intialisierungsprozess, der in einer ganz bestimmten Reihenfolge beim Einschalten zum Beispiel Konstante und andere Eventquellen abfeuert. Beim Snapshot ebenfalls und leider wohl auch teilweise in einer anderen Reihenfolge.
Aber du musst hier konkret werden, sonst bleibt diese Diskussion vage.

Als eine erste Absicherung klemm hinter alle Controller (Knob, Fader, Button) in jedem Fall ein event-order und schließe nur den zweiten Anschluss an:

Sicherheit.jpg

ciao herw

[KlangRaum]

genau - hmmmm !!! mach dir da aber jetzt noch keinen Kopf drüber; das ist erst bei ganz anderen Problemen interessant und echte Core-Forschung

Nö, das ist genau jetzt schon mein Problem: Ich möchte ja bei meiner FM-Schaltung die gesamte Klangerzeugung möglichst CPU-schonend in in einem einzigen Audio-Core umsetzen, von daher müssen solche Effekte berücksichtigt werden und nicht später durch irgendwelche Hilfskonstruktionen an anderer Stelle mühsam überverbastelt werden, die dann wieder unnötige CPU-Last bringen. Es kann aauch nicht sein an einer bestimmten Stelle aus Core rauszugehen nur um auf Primary ein bestimmtes Laufzeitverhalten zu erzwingen.
In kleinen Schaltungen mag das egal sein, aber in grösseren Projekten ist das imho nicht akzeptabel, besonders wenn man in unzähligen Testläufen immer neue Haken in der Signalverarbeitung entdeckt und eine bestimmte Schaltung zum Xten mal neu aufbaut weil die Reihenfolge nur von Signalverbindungen und Macrokapselung zu Seiteneffekten führen. Andererseits kann ich jetzt schon behaupten: wenn man diese Effekte kennt und gezielt einsetzt, kann man auch sehr effizient arbeiten. Dazu muss man aber auch entsprechend „eingarbeitet“ sein…

jaaaa - ein Problem der Nichtkohärenz von primary und core. Das greife ich schon seit langem an und ist eigentlich unzumutbar: eine Schaltung kann davon abhängen, in welcher Reihenfolge die Drähte in primary geknüpft wurden; ein unhaltbarer Zustand, der in Core nicht existiert!
Da sind noch einige Überlegungen zu nötig.

Das existiert in ähnlicher Form aber auch in Core -auch wenn solche Effekte in den meisten Fällen vielleicht nicht auffallen oder keine Rolle spielen die sogenannte Gleichzeitigkeit ist für mich mittlerweile eine sehr abstrakte „Feststellung“: Besonders wenn man eine Schaltung später modifiziert…

Da muss vorallem auch im „Core-Debug-Modus“ eine Anzeige (ähnlich wie Primary Sorting/Initialisierung) möglich sein, damit später auch noch nachvollziehbar ist wie die Schaltungsstruktur durchlaufen wird, wenn sie von mehreren unterschiedlichen Eingängen zu mehreren unterschiedlichen Ausgängen berechnet wird...

Aber du musst hier konkret werden, sonst bleibt diese Diskussion vage.

Zuerst muss ich die Grundstruktur mal endgültig hinkriegen. Da steht wieder eine Änderung an - also alles nochmal neu zusammenklicken....

Aber wie sagte schon mein ehemaliger Informatik-Dozent (seines Zeichen überzeugter Vollbart-Träger mit Hippi-Locken) mal:
“E D V steht für Experimentelle Daten Verwurstelung.“
Und das Beste daran: Der wusste das schon als es Reaktor noch garnicht gab



PS2:

Ich habe übrigens die Überschrift des Threads geändert; dies erschien mir passender.

Kannst Du das mal an meinen FM-Thread anhängen?
schon geschehen - herw

[KlangRaum]

Der SBus-Sender -derzeitige fast-Fertig-Beta.... Hab bis jetzt ca 1 Dutzent zum Teil sehr unterschiedliche Varianten probiert, das hier eist eine der Einfachsten, die noch am besten funktioniert

I0-I15: Eingänge für 16 Reagler oä.
V0-V15: Entspechende Ausgänge (Monitor...etc)
Adresse: 8bit Integer (High: 4 bit Gruppen-Id - Low: 4 bit Nummer des Eingang)
Value: 0…127 Float um mit Midi Kompatibel zu sein, kann aber auch problemlos andere Werte verarbeiten

Jeder doppelte Value-Block (Value und Latch sind ja im Prinzip identisch) muss von oben herab in dieser Reihenfolge angeschlossen werden :
1 (erzeugt und triggert Adresse)
… (Constant)
3 (triggert Datenwert)
2 (erzeugt Datenwert)

...Danach alle A(x) zum Adr-Merger
...Danach alle V(x) zum Val-Merger
...Danach die durchgeschleiften Verbindungen V(x) zu den Ausgängen O(x)

Werden die Leitungen in anderer Reihenfolge angelegt, ergibt sich kein korrektes Timing für dem Systembus.
Es ist wichtig das zuerst Adr komplett codiert ist und nur einen einzigen Event erzeugt bevor Val einen Event erzeugen kann.

Ich habe grad den Parameter ID hinzugefügt, der an dieser Stelle noch eine Gruppenadresse in die 8bit Adresse einfügt. Hier ergibt sich uU. noch ein falscher Event beim SnapShotwechsel, die Sache wird grade bearbeitet. Über ID werden momentan mit einem Knob mehrere unabängige „Bänke simuliert“
Um festzustellen, ob die Reihenfolge der Wertepaare korrekt übertragen wird, habe ich 16 Knobs und eine Anzahl Muster-Snapshots
Mit Adr und Value gehe ich dann zur Kontrolle in eine Event-Table. Wenn ich von der oben angegebenen Verdahtungsreihenfolge abweiche, kommt nicht nur in der Event-Table Mist an.... Dann kriegen auch die FM-Operatoren keine vernünftigen Parameter mitgeteilt. Hätte nicht gedacht, das mir so eine einfache Schaltung derart Kopfzerbrechen bereiten würde…

[herw]

genau - hmmmm !!! mach dir da aber jetzt noch keinen Kopf drüber; das ist erst bei ganz anderen Problemen interessant und echte Core-Forschung

Nö, das ist genau jetzt schon mein Problem: Ich möchte ja bei meiner FM-Schaltung die gesamte Klangerzeugung möglichst CPU-schonend in in einem einzigen Audio-Core umsetzen, von daher müssen solche Effekte berücksichtigt werden und nicht später durch irgendwelche Hilfskonstruktionen an anderer Stelle mühsam überverbastelt werden, die dann wieder unnötige CPU-Last bringen. Es kann aauch nicht sein an einer bestimmten Stelle aus Core rauszugehen nur um auf Primary ein bestimmtes Laufzeitverhalten zu erzwingen.

Mein Kommenar bezog sich auf asynchrone SampleRateClocks. Das dürfte nicht dein Ziel sein
Asynchrone SampleRateClocks kann man erzeugen, indem man die SampleRateClock über A->E (perm) in Events umwandelt, diese in eine EventCoreCell führt und über mehrere Eventausgänge zu einer zur AudioClock asynchronem Ablauf zwingt. Damit wieder in eine AudioCoreCell über Eventeingänge hinein. So hat man die Möglichkeit während eines SampleRateClocks innerhalb einer AudioCoreCell mehrfach dasselbe Macro zu verwenden.
(alles klar??)

das brauchst du für dein Projekt sicherlich nicht und ist eher von theoretischem Wert.

ciao herw

[KlangRaum]

(alles klar??)

Bevor ich asynchron synchronisiere, muss ersma das synchrone synchronisieren funzen.
Sonst wird bei mir schnell assi & chronisch ...

*gggg*

Ja Neee.... alles Klar...
Hab ja auch schon mal überlegt, ob Core-Events nur an die Eventrate fest gebunden sind, ob da evtl mehr geht und ich das nutzen soll. Weiss jemand, ob das das eine von NI garantierte Eigenschaft ist oder fliegt das bei R6 evtl raus?
Ich bin schon am überlegen, on ich statt einzelnen Events komplette Datenbereiche (zb für Tabellen) über einen „2-Draht-Bus“ schicken soll....

[herw]

(alles klar??)

Bevor ich asynchron synchronisiere, muss ersma das synchrone synchronisieren funzen.
Sonst wird bei mir schnell assi & chronisch ...

*gggg*

Ja Neee.... alles Klar...
Hab ja auch schon mal überlegt, ob Core-Events nur an die Eventrate fest gebunden sind, ob da evtl mehr geht und ich das nutzen soll. Weiss jemand, ob das das eine von NI garantierte Eigenschaft ist oder fliegt das bei R6 evtl raus?
Ich bin schon am überlegen, on ich statt einzelnen Events komplette Datenbereiche (zb für Tabellen) über einen „2-Draht-Bus“ schicken soll....

ach herje, über R6 würde ich mir erstmal keine Gedanken machen; laut NI-Forum arbeiten sie zunächst erstmal an R5.5.2 und bringen es hoffentlich bald auf 64-bit-Tauglichkeit.
Mir ist es lieber es kommt öfters etwas in kleinen Schritten als dass ich Jahre auf ein Major-Update warten muss.

Nun zu den Events: es gibt drei Eventarten: innerhalb von Core werden diese nicht unterschieden, nur an Schnittstellen von Core zu primary (und umgekehrt) und auf primary gibt es Unterschiede:
Am einfachsten zu verstehen sind Audio-Events. Sie werden durch die sampleRateClock getaktet und werden in der Regel mit 44100Hz gesendet. An der Schnittstelle von primary zu core erfolgt dies bei den audio-Eingängen der AudioCoreCells. Auf primary-Ebene eben auch an den Audio-Eingängen und -Ausgängen.
Dann gibt es die Events, die durch eine Teiltaktung dieser AudioClock mit EventRate erfolgen, meistens mit 200Hz oder 400Hz je nach Bedarf. Sie sind also synchron zu den AudioEvents, passieren nur eben seltener: LFOs, ADSRs, A2E-modul zum Beispiel senden solche synchronisierten Daten. Dann gibt es als drittes noch GUI-Events, die völlig frei erfolgen: Konstante beim Intialisieren, Regler, Schalter etc.. Sie passieren spontan unabhängig jeglicher Synchronisation. Auch ein Iterator-Modul gehört dazu.
Ein interessanter Sonderfall sind die Audioausgänge der AudioCoreCells. Sie sind entgegen der allgemeinen Meinung nicht durch die SampleRate getaktet sondern lassen auch zusätzlich noch dazwischen gelegte Events durch. Man staunt manchmal, was REAKTOR so alles kann. Gerald List (krümelmonster) hat das mal eindrucksvoll mit seiner AudioCoreSonde und seinem AudioCoreCellEventOutput bewiesen. Hier ist noch einiges an Entwicklungspotential möglich. Insofern darf das in keinem Fall bei irgendeinmal vielleicht möglicherweise erscheinenden R6 herausfallen.
Eher sollte man was neueres noch erfinden, zum Beispiel verschiedene Samplerates. Kann man sich aber auch selbst durch Heruntertakten (durch Teilung beispielsweise) selbst herstellen.
Problematisch ist tatsächlich die unterschiedliche Handhabung der Events auf primary- und core-Ebene. Das ist historisch bedingt, da ja die Core-Ebene erst 2005 mit aufgenommen wurde.

ciao herw

[herw]

Der SBus-Sender -derzeitige fast-Fertig-Beta.... Hab bis jetzt ca 1 Dutzent zum Teil sehr unterschiedliche Varianten probiert, das hier eist eine der Einfachsten, die noch am besten funktioniert

I0-I15: Eingänge für 16 Reagler oä.
V0-V15: Entspechende Ausgänge (Monitor...etc)
Adresse: 8bit Integer (High: 4 bit Gruppen-Id - Low: 4 bit Nummer des Eingang)
Value: 0…127 Float um mit Midi Kompatibel zu sein, kann aber auch problemlos andere Werte verarbeiten

Jeder doppelte Value-Block (Value und Latch sind ja im Prinzip identisch) muss von oben herab in dieser Reihenfolge angeschlossen werden :
1 (erzeugt und triggert Adresse)
… (Constant)
3 (triggert Datenwert)
2 (erzeugt Datenwert)

...Danach alle A(x) zum Adr-Merger
...Danach alle V(x) zum Val-Merger
...Danach die durchgeschleiften Verbindungen V(x) zu den Ausgängen O(x)

Werden die Leitungen in anderer Reihenfolge angelegt, ergibt sich kein korrektes Timing für dem Systembus.
Es ist wichtig das zuerst Adr komplett codiert ist und nur einen einzigen Event erzeugt bevor Val einen Event erzeugen kann.

die Reihenfolge, wie du diese Module eingefügt hast, ist in Core unerheblich.

Ich habe grad den Parameter ID hinzugefügt, der an dieser Stelle noch eine Gruppenadresse in die 8bit Adresse einfügt. Hier ergibt sich uU. noch ein falscher Event beim SnapShotwechsel, die Sache wird grade bearbeitet. Über ID werden momentan mit einem Knob mehrere unabängige „Bänke simuliert“
Um festzustellen, ob die Reihenfolge der Wertepaare korrekt übertragen wird, habe ich 16 Knobs und eine Anzahl Muster-Snapshots
Mit Adr und Value gehe ich dann zur Kontrolle in eine Event-Table. Wenn ich von der oben angegebenen Verdahtungsreihenfolge abweiche, kommt nicht nur in der Event-Table Mist an.... Dann kriegen auch die FM-Operatoren keine vernünftigen Parameter mitgeteilt. Hätte nicht gedacht, das mir so eine einfache Schaltung derart Kopfzerbrechen bereiten würde…

Ja, damit ist ein Eventbus erzeugt: Wenn man sich jetzt auf der linken Seite Regler, Fader etc. vorstellt, dann erzeugt ein Event jeweils eine Adresse und gibt seinen Wert weiter. Am Ausgang brauchst du nun nur noch die beiden Ausgänge Adr und Val. Sie stehen damit der primary Ebene aufeinander folgend zur Verfügung und können dort deiner AudioCoreCell zugeführt werden. Die Ausgänge V0-V15 sind nicht mehr nötig; sie dienten ja wohl ohnehin nur der Kontrolle.
Die Werte I0-I15 musst du nicht durch ein Latch oder Value-Modul schicken: Der I-Event erzeugt zeitgleich die Adresse. D.h. Adresserzeugung und eigentlicher Werte-Event gelten innerhalb der CoreCell als gleichzeitig (da sie derselben Eventquelle entspringen). Da sie aber getrennt nach außen abgeführt werden, entscheidet die Anordnung der Ausgänge von oben nach unten, welcher event zuerst an primary übergeben wird, in diesem Fall sinnvollerweise die Adresse. Nun kannst Du auf primary-Ebene entscheiden, ob du diese zwei Busse getrennt lässt, also einen Adressbus und einen Wertebus, wobei du durch deine Anordnung sicher sein kannst, dass die Adresse immer der erste Event ist (wie zum Beispiel im Ensemble GREYHOUND), oder ob sie durch ein Merge-Modul zu einem Bus zusammengeführt werden, um sie gemeinsam wieder in die CoreEbene zu schicken. Dies hat glaube ich mal vor einigen Jahren Chris List im englischen Forum vorgeschlagen; musst du bei Interesse mal die Suchfunktion einschalten. Auf diese Art und Weise kann man alle Paneldaten zum Beispiel über ein oder zwei Leitungen an die Core-Ebene übergeben und geht so den Beschränkungen (maximal 40 inputs) elegant aus dem Weg. Abgesehen davon wird das ganze Strukturbild viel überschaubarer.
Nun bleibt natürlich die Auswertung des Busses im Innern der Core-Ebene.

Die möglichst strikte Trennung von Paneldatenübergabe und der eigentlichen Datenverarbeitung (in Core) halte ich für absolut sinnvoll. Core ist allerdings nicht perfekt; ab und zu benötigt man die primary-Ebene zum Beispiel gibt es ja in Core kein Order-Modul, keine to-Voice-Verarbeitung, keine Iteration, etc..
D.h. so ganz kommt man nicht mit einem Wechsel zwischen beiden Ebenen aus, aber das kann man händeln.

ciao herw

[herw]

kleiner Tipp, wenn man viele Konstanten benötigt; das Kopieren von identischen Makro-Gruppen fällt leichter, wenn man so viel wie möglich der Struktur selbst überlässt, hier die Erzeugung der Konstanten 1 bis 15

DRF.jpg

Bei großen Projekten sind solche kleinen Helfer unerlässlich und für andere Aufgaben immer wieder verwendbar.
ciao herw

[KlangRaum]

Ich hab mal gestern und heute -quasi als Konzeptstudie- einen Pf-Hasenmodulator mit 4 Öperatören zusammengestellt, das meiste ist hier noch konventionel mit Primary umgesetzt, der eigentliche Operator ist jedoch schon Core. Der Systembus ist in diesem Release noch nicht implementiert, es kommt erstmal darauf an die eigentliche Struktur festzulegen, die dann nach und nach in Core umgesetzt wird. Man sieht auch sehr schön den Ansatz der leidigen Drahtharfen, obwohl hier nur 4 Operatoren zum Einsatz kommen (ich wünsche mir einen Quickbus für Primary…)

Wiegesagt: 4 Operatoren...... Ich hab das dann mal mit einem Ladder-Tiefpass ergänzt um abzuwägen wieviel Sinn ein Filter bei FM/PM überhaupt macht. Eigentlich wenig, ein Filter nimmt die Transparenz & Präsenz der meisten PM/FM-Sounds, momentan plane ich für den nächsten Schritt nachher nochmal einen LFO in den Filter einzusetzen, ansonsten bringen Filter recht herzlich wenig bei dieser Syntheseform. Ich hab mit nur 4 OP's einige Sounds gebastelt, darunter zahlreiche Percussion, Brass und Organs. Einige Organs (ich krieg da schon glasige Augen) haben einen typisch rauchigen Hammond-Overdrive Anschlag mit viel Druck, sowas hab ich mit einer gewöhnlicher Filter-Subtraktivsynthese noch nie hinbekommen. Auch die Percussions gehen bereits jetzt in den Charakter der alten E-Pianos.

Wichtiger als ein Filter ist vorallem eine gut durchdachte Steuerung mittels Velocity- und KeyScale-Curves, vorallem wenn es dabei um mehr als 4 OP's geht was ja mein Ziel ist. Da habe ich bereits den ersten Lösungsansatz in Arbeit.

Sinnvoll ist hingegen ein VCA mit eigenem Master-Envelope und LFO - dabei hab ich mal mit schneller AM experimentiert und baue nun grade für jeden OP einen Ringmodulator (4-Quadrant) ein. Dabei beeinflussen sich Phasen und Ringmodulation gegenseitig, jenachdem nach welcher Methode man die OP-Grundfrequenz steuert, ergibt sich entweder ein harmonisches oder nicht harmonisches Spectrum -man kann bei diesem Release auch schon gut abschätzen wie man ganz bestimmte Sounds konstruieren muss und stochert nicht blind im Nebel herum. Ein weiteres Feature wird eine Umschaltung der Operatoren Phasen- und Frequenzmodulation.

PP_GUI.jpg

PP_STRUCT.jpg

Hier der momentane 4-OPL

PP_OPL1.jpg

Man sieht sehr gut, das sich bei einer Ansteuerung mit einzelnen Signalen bei 4-5 OP's Schluss ist. Es gibt halt nicht endlos Signaleingänge......







Nur 3 Bilder pro Post? Prost!
Øøhm… Wørkfloh Ärrœr !
Fortsetzung Seite 3
*hehehe*