Deutsches Reaktor Forum

Oki leutz,

grüss gott, tach, straswutje, bonjourno...ich stell mich mal gleich mit einem meiner projekte hier, anstatt im smalltalk, vor - ich komm halt gern umwegfrei* zur sache;)

Phrasendrescher ist (wird) ein Midi-FX der Sonderklasse. er besteht aus 3 kernelementen - einem pfiffigen Akkord-Player, einem seqeunzierbaren Harmonizer und einem
"Arpeggiator", genauergesagt dem Namenspaten, eben einem Phrasendrescher. Letzterer kreiert, ähnlich wie Catanya (schau Youtube), aus eingehenden Akkorden Melodie-Fragmente
oder Chordrhytmen, jenseits von up/dwn/rnd....

Ergänzt wird das Ganze mit einem Scale-korrektor und CC-Seqeunzern. Kurz ein Tool, das aus eeinzelnen Noten echte Musik generieren kann. Verwendbar in jedem Host der Midi-Daten routen kann,
also meines Wissens nahezu alle, oder direkt, Reaktor-intern zum Instrument deiner Wahl.

*wie oben erwähnt - ich bin son Typ, der bei Ineffizenz/ergonomie seine stoische Ruhe und gute Laune verliert. Bei tausenden VSTs, Hosts, Apps... ist leider die Haptik, das Interface, die Gui, der Komfort... deutlich auf
der Strecke geblieben. Hausptsache Features reinpumpen, aber keinen Gedanken an Mauskilometer, Klickorgien, Intuitivitätstöten... verschwenden.

Phrasendrescher soll vor allem auch in puncto Bedienkomfort Massstäbe setzen. Ich denke, dieses Versprechen kann ich einlösen, das ist meine Paradedisziplin.

Bei der Arbeit tief unter der Haube siehts allerdings ganz anders aus. Hier brauche ich wohl hin und wieder eure Hilfe. Core ist für mich völliges Fremdland und Voice-Managment, womit ich mich aktuell
rumschlage, belegt auch keinen vorderen Platz auf meiner Skill-Hitparade.
Meine Arbeitsweise ist meist folgende: Bei technisch anspruchsvollen Sachen durchwilder ich die Lib und jage Macros die ich vglw. einfach adaptieren kann. Manchmal mehr, manchmal weniger
Try und Error bis es passt. Das technische Verständniss-Wachstum tangiert dabei natürlich nicht die Optimal-Grenze, aber es ist auch nicht mein Ziel, mit technischen Innovationen aufzuwarten.
Mich interessieren Konzepte, Anwendungsnutzen und Ergonomie - Technik ist nur (hassgeliebtes) Zweckmittel.

Jetzt habt ihr ein ungefähres Bild von mir/meinem Projekt und ich hoffe, trotz dieses Offenbahrungseides hier willkommen zu sein;)

Edit: hier kommen seltsame Zeilenumbrüche zustande, die im Edit-fenster so nicht sichtbar sind????

klingt sehr spannend. Freu mich darauf. Wenn ich kann helfe ich da gerne.

Am einfachsten ist die Hilfe immer, wenn man beispielensembles hochläd, die die Fragestellung oder das Problem soweit wie möglich eingrenzt. Also so klein und sauber wie möglich.

Phrasendrescher klingt gut!

gruss

he, danke.

schamlos wie ich bin, nehme ich auch gleich dein Angebot wahr;) denn idT habe ich aktuell
ein altes Martin Brinkmann "Makro" (ein dreifaches Hoch an dieser Stelle auf diesen Mann!) bei welchem es (bei mir) grad aussetzt.

es ist ein (4 stimmen) polyfoner voice-splitter, der noten oder akkorde monophon aufsplitten und dynamisch auf einzelne ausgänge routen soll. das tut er auch, sogar hervorragend, allerdings haben hier bei der dynamischen Port-Zuweisung die höheren Noten Priorität vor den Tieferen.
Das heisst, es ist gewährleistet das die höchste Note stets den gleichen Port belegt, die anderen aber schwanken, je nach Anzahl aktuell anliegender Noten.
Das Schwanken liegt in der Natur des Konzeptes, denn es sollen ja unterschiedliche Akkorde mit differierenden Tonhöhen/Anzahl Noten (auch komplett und teilweise überlappend) verarbeitet werden.
Es ist also nicht gewünscht, das ein Fis stets zu out 3 zugewiesen ist, sondern relativ zum Pitch der aktuell mitklingenden Notenkollegen dynamisch jeden Port belegen kann, sogar soll.
Ich wiederhole mich: es muss "nur" gewährleistet sein das unser Beispiel-fis als dritttiefste (hier sind 3T richtig, arnt they?) Note out 3 erreicht, als tiefste out 1, als höchste nummero 4 (beim 4er Akkord, beim dreiklang port 3, im duo port 2).

Das Brinkmann-Makro tut dergleichen schon, aber wie gesagt, mit Hoch-vor-Tief-Priorität. Die Port-Schwankungshäufigkeit ist also bei tieferen Noten höher als bei Hohen.
Das ist sowohl für das musikalische Ergebniss durch den nachgeschalteten Arp, als auch für die diametral entgegengesetzte intuitive Erwartungserhaltung des (wahrscheinlich anfangs ohnehin verwirrten) Bedien-Menschens, ungünstiger als andersrum.

Kurz ich hätte gerne das die Pitch-Port-"Statik" zugunsten der tieferen Noten, denn der Höheren ausfällt. Also einen invertierten Jetzt-Zustand.
Klingt trivial zu bewerkstelligen, aber ich verzweifel grad dran. Da tummeln sich soviele "kleiner, grösser, gleich" Module, das ist das reinste Dschungelcamp für Bedingungsabhängigkeiten.

Ich hab das Makro soweit wie irgend möglich reduziert und sauber aufgeräumt, trotzdem muss ich derzeit kapitulieren:-(

Also wenn du mal nen Blick drauf werfen würdest, oder vielleicht hast du sogar ein besseres Makro, das der Aufgabenstellung noch besser gewachsen ist (dieses ist nicht 100% bugfrei, es verschluckt sich zwar äusserst selten, aber es kann vorkommen), ich danke dir in jedem Fall.

("Makro" meint Mini-Instrument).

hmm, bei mir gibt es da relativ oft Fehler wenn ich das richtig sehe. Weiss nicht ob es an qwertz liegt, aber oft werden Noten verschluckt. Auch glaube ich, dass das mit Core weitaus besser zu lösen ist. Lustigerweise hab ich so eine Lösung schon mal gemacht auf core basis. Diese wollte ich bald in meinem Projekt Thread "monokl" vorstellen. also falls du noch etwas Gedult hast dann kommt da bald was, vielleicht auch ein guter Einstieg in Event core. Dein Projekt wird nicht ganz unkompliziert. Deswegen ist mein Tip dich langsam an Core heranzutasten. Für komplexe Sachen geht es ohne meiner Meinung nach nicht.

Also wenn du mal nen Blick drauf werfen würdest, oder vielleicht hast du sogar ein besseres Makro, das der Aufgabenstellung noch besser gewachsen ist (dieses ist nicht 100% bugfrei, es verschluckt sich zwar äusserst selten, aber es kann vorkommen),
("Makro" meint Mini-Instrument).

Das Verschlucken von Midi-Informationen der QWERTZ-Eingabe liegt in der Natur der Abfrage des Computerkeyboards. Bedient man zum Beispiel zwei Tasten, die einer Oktave entsprechen (z.B. „n” und „z”) dann läuft bei der dritten und vierten Note gar nichts mehr.
Eine QWERTZ-Tastatur ist also nur ein rudimentäres MIDI-Instrument, um mal eben ein paar Töne auszuprobieren.
Du solltest gerade bei einem solchen Projekt wenigstens einige wenige Euros für eine einfachste MIDI-Tastatur investieren. Dann diskutiert man auf einer gemeinsamen Basis.

Ich habe nur einen kurzen Blick in die Struktur geworfen; alles, was sich mit der Logik befasst, lässt sich sofort gut in Core umsetzen, vor allem vermeidet man dann doppelt auftretende Events (bedingt durch die Nicht-Gleichzeitigkeit von Events auf der primary-Ebene).
Wahrscheinlich kann man sogar fast alles in Core ausführen mit Ausnahme des Übergangs von polyphonen Quellen zur monophonen Ausgabe. In Core kann man leider from-voice nur polyphon emulieren, d.h. man kann eine Voice herausfiltern und die anderen auf 0 setzen. Durch einen Voice-Combiner könnte man aber außerhalb sofort einen monophonen Übergang schaffen. Ein to-Voice ist in Core nicht möglich.

Das Problem ist sehr reizvoll, um sich in die Event-Logik von Core einzuarbeiten.
Ich würde, wenn du in Logik firm bist, zunächst schrittweise die Brinkmann-Struktur in Core umsetzen. Das kann man in diesem Fall sehr gut machen: erst ganz kleinschrittig, dann immer mehr zu ganz wenigen Corecells zusammenfassen. Dann hast Du die Logik der Corecell wahrscheinlich etwas verstanden. Erst dann würde ich daran gehen, das Ergebnis der Struktur zu deinen Wünschen umzuwandeln. Meiner Ansicht nach läuft das auf ein Umkehren der logik-Abfrage hinaus (gute Übung).
Interessantes begrenztes Problem, das Ergebnis interessiert mich auch!

ciao herw

@herw:
mit qwertz ist ja interessant, aber das problem tritt bei proprietärer midi-eingabe auch auf. es ist jedoch kein bug, wie ursprünglich angenommen, es ist ganz ordinärer stimmen-klau und falsch erwarteter retrigger (oder hold), der aktuell gehaltenen (aber eben nicht erneut angeschlagenen) keys. ich hatte da nur einen gedankenknoten und qwertz hatte ich nur erwähnt, weil ich nicht weiss, wie IHR mit HW bestückt seid;-)
ich hab die voice-reduction mal auf auf "oldest" gesetzt, aber auch hier hat neu-trigger Priorität vor gehaltenen Noten. Aber dieses Verhalten ist ja eigentlich gewünscht und war jetzt nur als akademische Frage interessant. Für die Projekt-Praxis dürfte das irrelevant sein.
Ja, Core ist sicher eine ganz feine Angelegenheit, aber ich will das Ding schnellstmöglich "ab-agendern". Ein eintauchen in Core heb ich mir für lange Winterabende auf und für die V2 auf.

@mvkeinen
Das du bereits mit etwas Adäquatem aufwarten kannst, klingt süpi. Jo, freu mich auf dein Up, aber bloss kein Stress - hab im Rest-Ensemble noch genügend weitere Baustellen;-) mit dem Teil im Ist-Zustand kann ich erstmal als Dummy arbeiten und in Gimp bin ich auch nicht grad der Held, das frisst ebenfalls Unmengen Zeit. Wie gesagt kein Stress, aber ich hab auch kein Problem mit, wenn ich es schon morgen dl-en könnte;-)

PS. Ich hab mal in eure Projekte reingeschnuppert - boah ey, ich versteh kein Wort;-) Speziell Monokl klingt hochgradig interessant, hab gleich tausend Ideen wie man das nutzen könnte (namentlich alles Interfacige hat mich hart getriggert), aber ich befürchte, ich werd mir da keine Funktionsblöcke rippen/adaptieren können ohne die gesamte Struktur verstanden zu haben - und dieses Vertändniss ist wohl leider an ein höheres Core-Diplom in der Tasche gekoppelt:-(
Aber kjule Geschichten, auf was für Ideen ihr Nerds;-) kommt, Respekt!!!!!!
Ich werde einstweilen nicht in euren Strängen rumsenfen, aber seid versichert: ich lese fleissig.

Eventmanager hat geschrieben:@herw:[...]
Ja, Core ist sicher eine ganz feine Angelegenheit, aber ich will das Ding schnellstmöglich "ab-agendern". Ein eintauchen in Core heb ich mir für lange Winterabende auf und für die V2 auf.
[...]

Dies ist in der Tat eine in Core sehr viel eleganter zu lösende Aufgabe. Auch wenn die Ensemble von Martin Brinkmann zu Zeiten von R4 vorbildlich und elegant waren, trotzdem wage ich zu behaupten, dass die Lösung in Core wesentlich moderner und konsequenter ist.
Ich habe eine Lösung in einer halben Stunde gefunden und ich denke, dass sie wesentlich übersichtlicher als die primary Lösung ist. Insbesondere ist die Gleichzeitigkeit, wie du richtig bemerkst, das eigentliche Problem. Daher musste Martin so viele trigger-value-Makros einbauen. Ganz schrecklich empfinde ich die Verknüpfungsharfe am Ende der Struktur. Im Bild sieht man, wie die Pitchwerte in der richtigen Reihenfolge sortiert sind. Bei jedem Clock-Event findet die Sortierung statt. Das kann ich gut in meinem modular-projekt verwenden. Falls Interesse besteht und du nicht bis zu den Winterabenden warten möchtest, kann ich ja mal meine Lösung hochladen und erklären. Ansonsten warte ich ab, was du in primary findest.

ciao herw

Habe definitiv Interesse. Upload würde mich sehr freuen. Mit Erklärungen im Reisegepäck noch viel mehr.
Hätte schon Lust in Core einzusteigen, aber eher im VHS-Rhytmus, so 3x wöchentlich ein gemütliches Doppel-Stündchen.
Habe nur Bedenken das das so vergebene Liebesmüh ist - hatte ja schon bei Prim meine (mehr als leidlichen) Schwierigkeiten.

"Harfe" = Merge?

Eventmanager hat geschrieben:[...]
"Harfe" = Merge?

ja
ok upload sofort, am besten du versuchst dich „einzulesen” und zu fragen, möglichst der Struktur von links nach rechts folgend und von außen nach innen; ich habe noteoff (gate=0) in pitch=128 umgewandelt, um einfacher sortieren zu können. Bei der Ausgabe habe ich wieder in 0 zurücktransformiert. Vergiss nicht, die Clock zu starten. Core ist definitiv logischer und dann auch einfacher.

PS: VHS-Rhythmus ist gut; wenn es dich einmal packt, verlängerst du automatisch

Spassiba Maestro! Funzt hervorragend!!!

Oki, ich versuch mal zu rekapitulieren, was ich aus der Struktur des ersten Makros rauslese:
Erstmal indiziert GRAU wohl, das es noch tiefer geht, wohinggegen GRÜN die echten Atome darstellt. Schon mal gut zu wissen, das es etwas gibt, an das ich mich höchstwahrscheinlich bis zur nächsten Lektion erinnere;)

Gate wird vermittels GT-Modul einfach zum Value 1 konvertiert, sobald irgendwas > 0 anliegt.
Da am unteren IN eine Null anliegt, ist es also dass Logik-OR Modul, richtig?
Warum hast du unten noch explizit eine Null-Konstante rangehangen? Es ist zwar kein Atom, aber ist es in Core nicht adäuquat zu Prim, das unbestückte INs automatisch mit Null-Konstante "versehen" werden?

Das Teil dahinter ist kein normales Multiply, es multipliziert nur, wenn am oberen Eingang eine Änderung stattfindet. Änderungen unten bewirken garnichts, nicht mal einen Event-trigger. Aha!
Es ist aber kein Step-Filter verbaut, denn die Änderungen oben werden mehrfach ausgegeben, zufälligerweise genauso oft, wie das Instrument Stimmen hat. -> ich glaube, das werde ich auch behalten.

Das =Compair und der Router, dürften kaum anders die Prim-Entsprechungen sein, was ich nicht verstehe, warum hast du die auf Float statt Integer gesetzt? Wir operieren doch ausschliesslich mit Integer, dank dem "Logik (GT)"?

FP Präzission lässt du überall auf Default, weshalb man das wohl vernachlässigen darf.

In die "Makros" rein, trau ich mich noch nicht, ich möchte erstmal grundlegend wissen, ob ich es soweit begriffen habe, anstatt sich auf falschen Grundanahmen weiteres "Wissen" anzueignen.

Abermals Danke!

Eventmanager hat geschrieben:Spassiba Maestro! Funzt hervorragend!!!

Oki, ich versuch mal zu rekapitulieren, was ich aus der Struktur des ersten Makros rauslese:
Erstmal indiziert GRAU wohl, das es noch tiefer geht, wohinggegen GRÜN die echten Atome darstellt. Schon mal gut zu wissen, das es etwas gibt, an das ich mich höchstwahrscheinlich bis zur nächsten Lektion erinnere;)

Vergleich.jpg

Gate wird vermittels GT-Modul einfach zum Value 1 konvertiert, sobald irgendwas > 0 anliegt.
Da am unteren IN eine Null anliegt, ist es also dass Logik-OR Modul, richtig?

nein GT heißt greater-than also ein Logik-Vergleichsmakro.

Warum hast du unten noch explizit eine Null-Konstante rangehangen? Es ist zwar kein Atom, aber ist es in Core nicht adäuquat zu Prim, das unbestückte INs automatisch mit Null-Konstante "versehen" werden?

Darauf verlasse ich mich niemals; da ich meine Strukturen unter Umständen auch nach Jahren wieder einsehe, möchte ich keine Überraschungen erleben.

Das Teil dahinter ist kein normales Multiply, es multipliziert nur, wenn am oberen Eingang eine Änderung stattfindet. Änderungen unten bewirken garnichts, nicht mal einen Event-trigger. Aha!
Es ist aber kein Step-Filter verbaut, denn die Änderungen oben werden mehrfach ausgegeben, zufälligerweise genauso oft, wie das Instrument Stimmen hat. -> ich glaube, das werde ich auch behalten.

klar es ist eine polyphone corecell.

Das =Compair und der Router, dürften kaum anders die Prim-Entsprechungen sein, was ich nicht verstehe, warum hast du die auf Float statt Integer gesetzt? Wir operieren doch ausschliesslich mit Integer, dank dem "Logik (GT)"?

nein, das Logik (GT) liefert zwar die integer-Werte 0 und 1, das nachfolgende Modulations Makro x-mul-a ist wieder mit float Eingängen versorgt. Falls Du nur integer-Werte für den Pitch-Eingang benutzt, dann kannst du auch das entsprechende integer-Makro benutzen. Aber vielleicht möchtest du ja den pitch noch geringfügig modulieren?

FP Präzission lässt du überall auf Default, weshalb man das wohl vernachlässigen darf.

Das hängt davon ab, was du später machen möchtest. Hängt man zum Beispiel FM-Oszillatoren wie im YAMAHA DX7 dran, dann müssen die Frequenzverhältnisse unter Umständen extrem exakt sein: Dann benutze ich höchste Rechengenauigkeit.

In die "Makros" rein, trau ich mich noch nicht, ich möchte erstmal grundlegend wissen, ob ich es soweit begriffen habe, anstatt sich auf falschen Grundanahmen weiteres "Wissen" anzueignen.

Abermals Danke!

Ja gut so; auf das Logik-Makro würde ich jetzt nicht eingehen, sondern nur erstmal akzeptieren, dass es Wahrheitswerte liefert.

kleiner Nachtrag zum Modulations-Makro x-mul-a: man stellt dadurch auch sicher, dass es bei einer Initialisierung auch höchstens einen Initialisierungsevent durch den Pitch-Event gibt. Das ist hier bestimmt nicht wichtig, aber in komplizierten Strukturen muss man Initialisierungswerte im Überblick behalten.

Das GT erfüllt also oberflächlich die gleichen Aufgaben wie das Prim-Compair. Aber die Arbeitsweise ist anscheinend anders, denn intern hast du ja ein schnödes Compair-Atom verbaut, anstatt dieses direkt zu nutzen.
Muss ich das schon wissen oder verwirrt es einstweilen? Ich denke ich werde mich wohl lieber vom "Großen" zum Kleinen vorarbeiten, wobei mir das Latch als äusserst wichtiges Modul erscheint.

Ganzzahl vs. Fliesskomma: PB will man natürlich nicht in Haltonschritten, dann hast du schon recht;-) Aber generell: Integer würde (bei relevanten Strukturen, hier wohl vernachlässigbar) weniger CPU benötigen? Und wie gestaltet sich das Runden in Core? Wie wird Komma-5 gehändelt? Nach oben, unten, oder gar Lust und Laune?

Also Default-Präzision ist bei Event-Strukturen wohl ausreichend. Nur mal interessehalber was bedeutet Default in diesem Zusammenhang, da man ja zudem noch zwischen 32&64 Bit wählen kann - 16Bit?

Das andere Makro sieht heftiger aus. Setz ich mich mal heute Abend oder Morgen ran. Immer kleine Schritte;-)

Eventmanager hat geschrieben:Das GT erfüllt also oberflächlich die gleichen Aufgaben wie das Prim-Compair. Aber die Arbeitsweise ist anscheinend anders, denn intern hast du ja ein schnödes Compair-Atom verbaut, anstatt dieses direkt zu nutzen.
Muss ich das schon wissen oder verwirrt es einstweilen? Ich denke ich werde mich wohl lieber vom "Großen" zum Kleinen vorarbeiten, wobei mir das Latch als äusserst wichtiges Modul erscheint.

das Makro GT ist aus der Reaktor Library und findest du hier: Spannend werden die Vergleiche und auch die Logikfunktionen auf Coreebene insbesondere dann, wenn man sie im Integer-Bereich bitweise benutzt (Einsatz von Masken). Da kann primary überhaupt nicht mithalten. Um die Vorteile von core zu sehen, muss man ganz bewusst auch die atomare Herangehensweise ausnutzen. Das ist keine höhere Mathematik sondern einfach nur binäres Denken.

Ganzzahl vs. Fliesskomma: PB will man natürlich nicht in Haltonschritten, dann hast du schon recht;-) Aber generell: Integer würde (bei relevanten Strukturen, hier wohl vernachlässigbar) weniger CPU benötigen?

das ist egal, ich kann jetzt natürlich keine Testumgebung angeben, ob die Addition von integer-Zahlen oder Fließkommazahle effektiver sind; das ist sicherlich auch Betriebssystem- und Rechner-abhängg. Entscheidend ist, dass die integer-Rechnung immer auf höchstem Niveau exakt bleibt (insbesondere 0=0) während, wie in allen Programmiersprachen üblich, Fießkommazahlen immer nur in einem bestimmten Rahmen genau sind, also kann zum Beispiel sich durchaus anstelle einer erwarteten 0 auch 1E-12 ergeben. D.h. ein Vergleich auf Null wäre hier präkär. Bei den Pitchwerten, ist dies hier kein Probem.

Und wie gestaltet sich das Runden in Core? Wie wird Komma-5 gehändelt? Nach oben, unten, oder gar Lust und Laune?

siehe hier: IEEE 754

Also Default-Präzision ist bei Event-Strukturen wohl ausreichend. Nur mal interessehalber was bedeutet Default in diesem Zusammenhang, da man ja zudem noch zwischen 32&64 Bit wählen kann - 16Bit?

je nachdem, wie REAKTOR läuft

Das andere Makro sieht heftiger aus. Setz ich mich mal heute Abend oder Morgen ran. Immer kleine Schritte;-)

jo - mach mal; ich antworte gerne, solange du wie bisher mitdenkst.
ciao herw

Ah, mit Privatleher macht das doch gleich viel mehr Spass;-) Danke!

Das Problem ist, das ich meine gedruckte Bibliothek in meiner alten Bude (Lagerhalle)
0,8 megameter von meinem jetzigen Standort habe und das Core-PDF nur auf englisch
(beim letzen Update gabs wohl nur das GetStart lokalisiert, oder ich hab beim PDF-Aufräumen fäslchlicherweise die Deutschen gelöscht?) verfügbar ist.
Und da Core und English simultan zuviel meine Synapsen ist, werde ich also wohl schon bald deine Geduldskapazität sprengen;-)

-----
Aber mal weg von Core. Zu meinem Projekt drängt sich mir grad ne Frage auf, die ich bislang nur testweise und äusserst unbefriedigend gelöst bekam:
Ich habe diverse monofone Seqeunzer-Einzelstränge die am Signalkettenende monofon Pitch und Gate ausgeben. Die Pitch/Gate Daten münden in ein Note-Out-Modul.
Ich habe also verschiedene "monofone" Sequenzer (defacto ist jeder 32ig-stimmig aber die Voices werden horizontal für Positions-Daten, etc. verwendet - es gibt also keine vertikale Gleichzeitigkeit sprich "Akkorde" pro Unit) wobei jeder sein eigenes Note-Out speist.
Im polyfonen Test-Synth kommen also gleichzeitig über die diversen Note-Outs unterschiedlcihe Pitches und Gates an. Das arbeitet natürlich so präzisse wie ein 6-mal geflicktes Midi-Kabel. Die Gates werden munter durchwürfelt, teilweise verschluckt, vergessen… In der Praxis also unbrauchbar.

Im Prinzip bräuchte ich einen soliden Stimmen-Vereiner, der die diversen monofonen Signal-Paare (Pitch+Gate) zusammenfasst und dann sauber polyfon (als zusammengehörige Paare) ausgibt, also ein invertiertes Event-All.

Ich hab jetzt 3 Stunden nachgedacht, der beste Gedanke war hier nachzufragen:-(