der MODULAR

Hier soll es ausschließlich um Arbeiten zu neuen und alten Ensembles gehen.

Moderator: herw

Antworten
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von herw »

Die Überarbeitung des Panels erweist sich als äußerst fruchtbar. Ich verfolge den gesamten Signalwegs der Adressenzuweisung und Panelpositionen an die Kabelgrafik. Da die einzelnen Busse eine festgelegte Reihenfolge in ihrer Werteübertragung haben, muss ich nur darauf achten, dass ein entsprechender Trigger dies über den gesamten Signalweg synchronisiert.
Durch konsquentes Umstellen auf Core-Makros konnte ich dabei viele in Prim-Level erforderliche Order-Val-Elemente ersetzen bzw. ganz wegfallen lassen.
Die Umstellung von relativen Panel-Koordinaten (Grobrasterung) auf Pixelkoordinaten des Multidisplays schafft ebenfalls viel einfachere Operationen. Interessant dabei ist, wie unterschiedlich man durch den Begriff Gleichzeitigkeit (im Core-Level) denken muss (besser: kann).
Ein Beispiel: Ich habe auf dem Panel ein Wire gelöscht. Das ist grafisch nichts anderes als die Transparenz des Wires auf 100% zu setzen. Die Adresse der zuletzt benutzten Ausgangsbuchse ist immer noch aktuell.
Rechtsklicke ich auf irgendeine Eingangsbuchse, dann wird diese Adresse korrekterweise benutzt (wenn ich nicht einen anderen Ausgang benutzen möchte).
Beim Neustart merkte ich nun, dass (nur beim erstenmal) diese Ausgangskoordinaten aber auf 0 initialisiert waren, somit ein Wire in der oberen linken Ecke startet;
Bild 1.gif
In der alten Version mit Primary Level ist mir das gar nicht aufgefallen.
Kein Beinbruch, da man dies ja durch nochmalige Ausgangsauswahl sofort korrigieren kann. Aber das interessante war, die Ursache herauszufinden: es lag nur an einer Intialisierungsreihenfolge beim Starten des Progamms.
Bild 2.gif
Das Vertauschen der Reihenfolge der Ausgänge E, X1, Y1, X2, Y2 zu X1, Y1, X2, Y2, E schafft hier teilweise Abhilfe; zusätzlich musste ich allerdings im weiteren Verlauf snap-Module für X1 und Y1 einbauen, damit die Initialisierung korrekt erfolgt. CoreCells leiten gleichzeitige Events ins primary level über die Ausgänge von oben nach unten ab.
Letztendlich habe ich aber die Lösung nochmals geändert, so dass ich den 1-Event (gelber Rahmen) des Rechtsklick-Gates als Trigger (hier X2,Y2) und den 0-Event (grüner Rahmen) des Rechtsklick-Gates für die Eingangsadresse E benutze:
Bild 3.gif
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von herw am 21. Januar 2007, 18:02, insgesamt 1-mal geändert.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von herw »

Heute war ein sehr produktiver Tag. Ich habe auch die Signalumschaltung für die virtuellen Kabel umgestellt - nur eine kleine Änderung aber doch sehr vertrackt. Es hat hat mich sicherlich fünf Stunden gekostet, aber auch viel neue Erkenntnisse gebracht; und das finde ich immer wieder erstaunlich: Geduld und Ehrgeiz zahlen sich bei REAKTOR sofort aus.
Heute ging es um die IC-Send - Receive Umschaltung. Obwohl ich schon alles verstanden glaubte, musste ich nochmals alles neu ausprobieren, obwohl die Änderung nur minimal war. Ich werde es in das Workshop über interne Connections aufnehmen.

ciao herw
helmsklamm
synth gott
Beiträge: 1011
Registriert: 10. Mai 2006, 16:21
Wohnort: 030

Re: Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von helmsklamm »

herw hat geschrieben: Heute ging es um die IC-Send - Receive Umschaltung. Obwohl ich schon alles verstanden glaubte, musste ich nochmals alles neu ausprobieren, obwohl die Änderung nur minimal war. Ich werde es in das Workshop über interne Connections aufnehmen.

ciao herw
also irgendwie sind die teile auch unnötig ver-fallstrickt, für die eigentlcih simplen aufgaben die sie übernehmen, oder?
bitte vor jeder frage erstmal überprüfen, ob das kapitel "mein erster synth" S. 76 im hnadbuch, schon gelesen wurde.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von herw »

helmsklamm hat geschrieben:...also irgendwie sind die teile auch unnötig ver-fallstrickt, für die eigentlcih simplen aufgaben die sie übernehmen, oder?
ach es geht eigentlich; die Verwaltung der Einträge von Receive- oder auch Schalter-Modulen sind nur nicht so, wie man es sich intuitiv denkt.
helmsklamm
synth gott
Beiträge: 1011
Registriert: 10. Mai 2006, 16:21
Wohnort: 030

Re: Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von helmsklamm »

herw hat geschrieben:
helmsklamm hat geschrieben:...also irgendwie sind die teile auch unnötig ver-fallstrickt, für die eigentlcih simplen aufgaben die sie übernehmen, oder?
ach es geht eigentlich;
stimmt, deshalb reicht auch ein workshop dazu :wink:
bitte vor jeder frage erstmal überprüfen, ob das kapitel "mein erster synth" S. 76 im hnadbuch, schon gelesen wurde.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von herw »

helmsklamm hat geschrieben:
herw hat geschrieben:
helmsklamm hat geschrieben:...also irgendwie sind die teile auch unnötig ver-fallstrickt, für die eigentlcih simplen aufgaben die sie übernehmen, oder?
ach es geht eigentlich;
stimmt, deshalb reicht auch ein workshop dazu :wink:
ja, dass man dafür extra ein workshop braucht, ist schon schlimm; andererseits ist es gut, wenn man sich damit mal gründlich beschäftigt. Alle Möglichkeiten eines Moduls erschöpfend in einem Handbuch zu betrachten, ist ja wohl sehr übertrieben.
An das Schalten über IC-Verbindungen trauen sich offenbar nur wenige, weil es mit viel Experimetieren verbunden ist. Daher auch das Workshop. Ich werde dann darauf verweisen.
Zuletzt geändert von herw am 18. Januar 2007, 13:39, insgesamt 1-mal geändert.
helmsklamm
synth gott
Beiträge: 1011
Registriert: 10. Mai 2006, 16:21
Wohnort: 030

Re: Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von helmsklamm »

herw hat geschrieben: An das Schalten über IC-Verbidungen trauen sich offenbar nur wenige, weil es mit viel Experimetieren verbunden ist.
ich finds aber auch in der jetztigen entwicklungsstufe unübersichtlich, tlw. auch unhandlich: die "verdrahtung" zu erkennen, is manchmal echte detektivarbeit und das copy/pasetn von macros ist zumnindest bei der version ohne IC ne strafarbeit, da master/slave ständig neu gesetzt werden muss (als kabelloser port-ersatz sind die teile deshalb nur bedingt zu gebrauchen).
bitte vor jeder frage erstmal überprüfen, ob das kapitel "mein erster synth" S. 76 im hnadbuch, schon gelesen wurde.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von herw »

helmsklamm hat geschrieben:...ich finds aber auch in der jetztigen entwicklungsstufe unübersichtlich, tlw. auch unhandlich: die "verdrahtung" zu erkennen, is manchmal echte detektivarbeit und das copy/pasetn von macros ist zumnindest bei der version ohne IC ne strafarbeit, da master/slave ständig neu gesetzt werden muss (als kabelloser port-ersatz sind die teile deshalb nur bedingt zu gebrauchen).
das ist richtig, deshalb liegen im MODULAR das schaltende IC-Send direkt neben dem zugeordneten Schalter. Dann wird man fragen, ob man nicht gleich nur einen Schalter benutzen kann? Nun das würde eine Schaltungsmatrix wie zum Beispiel in Ernest Meyers Marx-Modular erfordern, was dann wesentlich unübersichtlicher wäre. Abgesehen davon haben Receive-Send-Verbindungen, die von IC-Sends geschaltet werden, den Vorteil, dass sie hybrid sind, d.h. sowohl Event- wie auch Audio-verbindungen anstandslos akzeptieren und - das Wesentliche - nicht auf 40 Eingänge beschränkt sind. Schaut man sich mal nur die Anzahl der Eingänge beim MM1 und MM2 an, dann wäre man dort schon auf eine zweite Matrix angewiesen.
Ich habe aber vor, große MODULAR-Ensembles mit einigen hundert Ein- und Ausgängen zu entwickeln.
helmsklamm
synth gott
Beiträge: 1011
Registriert: 10. Mai 2006, 16:21
Wohnort: 030

Re: Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von helmsklamm »

herw hat geschrieben:
helmsklamm hat geschrieben:...ich finds aber auch in der jetztigen entwicklungsstufe unübersichtlich, tlw. auch unhandlich: die "verdrahtung" zu erkennen, is manchmal echte detektivarbeit und das copy/pasetn von macros ist zumnindest bei der version ohne IC ne strafarbeit, da master/slave ständig neu gesetzt werden muss (als kabelloser port-ersatz sind die teile deshalb nur bedingt zu gebrauchen).
das ist richtig, deshalb liegen im MODULAR das schaltende IC-Send direkt neben dem zugeordneten Schalter. Dann wird man fragen, ob man nicht gleich nur einen Schalter benutzen kann? Nun das würde eine Schaltungsmatrix wie zum Beispiel in Ernest Meyers Marx-Modular erfordern....
hm, auf den gedanken das zu "vermatrixen" bin ich noch garnich gekommen, muss ich mir mal gleich anschauen, klingt gut, obwohl man dann schon mit den standard-list-einträgen-design leben muss ... aber, wenn man wie bei dir unten erwähnt einige sources/dest mehr anbietet is das villeicht ne alternative. guter tip, mein kopf sagt ja, aber ich schätze mein auge wird das induskutabel finden;-)
bitte vor jeder frage erstmal überprüfen, ob das kapitel "mein erster synth" S. 76 im hnadbuch, schon gelesen wurde.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Gleichzeitigkeit und Reihenfolge in CORE

Beitrag von herw »

arrgh, ich habe gerade hier ein lange Seite geschrieben und durch einen falschen Tastendruck völlig gelöscht, just in dem Augenblick als ich eine Sicherheitskopie anfertigen wollte. Nun ist es zu spät. Also morgen nochmals.

ciao herw
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Verwaltung A/E (1)

Beitrag von herw »

Die Verwaltung der Ein- und Ausgänge ist nun in Core umgesetzt, hier am Beispiel des ADSR-Moduls:
Verwaltung A-E.gif
Wir erkennen drei große Bereiche:
  • gelb: Die relativen Modulkoordinaten (linke obere Ecke werden um die Breite des Moduls erhöht)
  • orange: wir erkennen zwei Ausgänge. In dem kleinen Makro A iGate wird aus den Modulkoordinaten XM+ und YM+ die absolute Position der Ausgangsbuchse berechnet. Mit Hilfe des Rechtsklicks (hier A1R) werden diese an die Daten-Busse >x1> und >y1> übergeben. Der zweite Ausgang out ist entsprechend aufgebaut.
  • grün: Der Eingang ist ähnlich strukturiert, doch muss durch die Wahl des Eingangs ja auch die wirkliche Datenbahn geschaltet werden; insofern brauche ich noch den Ausgang SW (switch), der an die IC-Send-Verbindung die Schaltposition des zugeordneten Receive-Elements übergibt.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Verwaltung A/E (2)

Beitrag von herw »

Schauen wir mal in den orangenen Bereich hinein:
A igate.gif
das Makro A igate erhöht die Zählvariable A um 1; wir erinnern uns, dass die Anzahl aller Ausgänge automatisch bestimmt wird, die absoluten X,Y-Koordinaten der Panelposition werden aus den Eingangswerten XM+ und YM+ berechnet. Alle Daten werden mir Rechtsklick BR übergeben.
Das Makro Ausgang1 ist nur geringfügig interessanter:
Ausgang1.gif
Die berechneten Werte werden an die entsprechenden Busse übergeben.

Zusammenfassend: ein Rechtsklick auf die Ausgangsbuchse im Panel übermittelt die Ausgangsadresse und die zugehörigen Koordinaten auf dem Panel.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Verwaltung A/E (3)

Beitrag von herw »

Das Eingangsmakro ist dagegen viel spannender:
Eingang.gif
  • gelb:
    vom Panelelement Eingang werden Rechtsklick BR und Doppelklick DB ausgewertet. Der Rechtsklick ist ein Gate-Event und wird mit dem Router in zwei 1-Trigger BR1 und BR0 umgewandelt.
  • orange:
    Der GateOn-Befehl BR1 übergibt wie beim Ausgang die x-y-Koordinaten der Eingangsbuchse an die entsprechenden Busse >x2> und >y2>.
  • türkis:
    nachdem die beiden Koordinaten übertragen wurden, schließt der GateOff-Trigger BR0 mit der Übergabe der Eingangsadresse E+ ab. Zusammen mit den Koordinaten des gewählten Ausgangs werden diese Daten zur Speicherung an ein Snap-Array übergeben und dann zum Zeichnen der Kabels an das Grafikdisplay weitergeleitet. Der GateOff-Trigger stellt als letzter Event sicher, dass alle Informationen in der richtigen Reihenfolge an diese Makro gelangen.
    Das Löschen der Verbindung ist sehr einfach durch Doppelklick Db (ein Trigger) geregelt. Er versendet einfach die negative Adresse. Sie bewirkt auf dem Grafik-Display ein Heraufsetzen der Transparenz, d.h. das Kabel verschwindet nur optisch.
  • grün:
    Hier wird die Verschaltung des virtuellen Kabels gesteuert. Es sind zwei Situationen zu betrachten:
    (1) Der Rechtstrigger GateOff BR1 übergibt die Nummer des gewählten Ausgangs. Diese wurde ja vom Ausgangs-Makro über den Bus >A> an den Bus A>E übergeben und wird nun hier abgegriffen.
    (2) Der Doppelklick dagegen übergibt die Gesamtzahl A# aller Ausgänge
Die Übergabe dieser beiden Informationen wird in dem Makro Schalterstellung verarbeitet. Dazu muss ich etwas länger ausholen (siehe nächste Post).
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Verwaltung A/E (4)

Beitrag von herw »

Neben der Adressverwaltung für die Ein- und Ausgänge ist in jedem Modul natürlich die eigentliche Signalverarbeitung das Wichtigste:
Sends.gif
Über die Send-Receive-Verbindung erhält sie Daten (SW1) und über die eigenen Send-Module (gelber Rahmen) werden die verarbeiteten Daten wieder abgegeben. Am Beispiel des ADSR-Moduls sehen wir zwei Ausgänge:
A iGate: Das Modul stellt ein interenes Midi-Gate Signal zur Verfügung.
out: Der Ausgang des ADSR-Generators.

Sobald man die Send-Module einfügt und bezeichnet, werden sie jedem Receive-Modul in seinen Properties als Quelle angeboten
D.h. ich muss nicht eine eigene Verknüpfungsmatrix, wie in vielen semi-Modularen Ensembles erstellen, sondern bekomme sie automatisch angeboten. Man stelle sich einmal die Arbeit vor, wenn man 200 Quellen über eine selbst erstellte Matrix mit 200 Eingängen verknüpfen wollt. Nicht die 40000 (!) Verbindungen schrecken ab (man kann ja geschickt duplizieren), aber die Übersicht ist schrecklich, da man ständig an die Grenzen von switsches stößt (nur 40 Schalterstellungen).
Auch wenn man interne Verknüpfungen benutzt und diese über Menüs schaltet, stößt man ergonomisch schnell an Grenzen: wer möchte schon ein PullDown-Menu bedienen, in dem sich 200 Einträge befinden?
Ich habe ich diesem Ensemble bisher zwei ADSR-Module eingefügt. Bei einem solch umfangreichen System, ist meiner Ansicht nach die grafische Verknüpfung das Einfachste. Nun man wird am Ende dieses Projektes sehen, ob sehr große Systeme auf einem scrollenden Bildschirm noch Spaß machen. Aber ich denke, dann kann man sich auch mehrere Bildschirme zulegen; das ist dann immer noch wesentlich preiswerter als ein entsprechendes Hardware-System. Aber ich schweife ab.
ADSR-Panel.gif
Das Einfügen ergänzt in den Properties der Receive-Module also die angebotenen Quellen:
Receive als Switch.gif
Wir erkennen die vier Quellen der beiden ADSR-Module (ich habe keine weiteren Ausgänge eingefügt). Da ich grundsätzlich mit Audio-Quellen arbeite, sind auch alle Quellen direkt aktiviert. D.h. ich muss mich beim Erstellen eines großen MODULAR-Systems gar nicht darum kümmern.
Entscheidend ist die Reihenfolge, in der die Send-Module eingefügt werden. Dies geschieht am besten, wenn man alle MODULAR-Module zuzammengestellt hat und anschließend alle sends ergänzt. Das ist zwar der letzte mühsame Schritt, ist aber in ein, zwei Stunden geschehen und belohnt durch sofortigen Gebrauch. :-)
Ich habe hier die beiden ADSR-Module ohne Sends hineinkopiert und dann die entsprechenden Sends erstellt. Sie erscheinen jetzt in der richtigen Reihenfolge, d.h. die Reihenfolge der Quellen entspricht deren Adressierung.
Wichtig ist bei dieser Adressierung, dass die Enable Switch Off-Option akitiviert ist, sonst benötigt man noch eine Schein-Quelle, die die Konstante 0 sendet, was allerdings dann die MODULAR-Module nicht wirklich ausschaltet, also CPU-Leistung verbraucht. Das habe ich im Gegensatz zu den bisherigen MODULAR-Versionen geändert, indem ich die interne Off-Quelle benutze. Sie deaktiviert tasächlich "angehängte" Strukturen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von herw am 22. Januar 2007, 08:34, insgesamt 1-mal geändert.
Benutzeravatar
herw
moderator
Beiträge: 3122
Registriert: 13. März 2006, 18:28
Wohnort: Dortmund

Re: Verwaltung A/E (5)

Beitrag von herw »

Ich habe hier die beiden ADSR-Module ohne Sends hineinkopiert und dann die entsprechenden Sends erstellt. Sie erscheinen jetzt in der richtigen Reihenfolge, d.h. die Reihenfolge der Quellen entspricht deren Adressierung.
Leider ist genau diese Aussage falsch. Deshalb benutzen wohl so wenige REAKTOR-Benutzer diese Option. Aber keine Panik, alles ist wohl geordnet, nur eben nicht so, wie man es sich denkt (ein Manko ist, dass die NI-Entwickler manchmal etwas anders denken als der Laie ;-) ). Hat man allerdings einige weiter gehende Programmierkenntnisse, dann erscheint die Verwaltung wieder logisch.
Zunächst das Prinzip:
Receive-Module sind nichts anderes als Mehrfachschalter: Sie können beliebig viele (ich habe noch keine Grenze bestimmen können, zumindest erfassen sie Hunderte von Eingängen) Signalquellen, die über die Send-Module angeboten werden, empfangen. Man kann die "Schalterstellung" manuell wählen, wie sie die meisten Semi-modularen-Ensembles benutzen; vergleiche zum Beispiel die Ensembles 3X v1.8 von James Walker-Hall oder auch Marx Modular v3.2 oder das sehr moderne Lenin v5.1 von Ernest Meyer.
Solange die Anzahl der Quellen sich im Rahmen von etwa 30 hält, ist dies sicherlich eine praktikable Alternative, ganz sicherlich aber nicht bei größeren Dimensionen.
Wir schauen nochmals kurz in die Eingangsverwaltung hinein:
Schalterstellung1.gif
Der Rechts-Trigger BR1 und der Doppelklick DB bestimmen die Schalterstellung des zugehörigen Receive-Moduls. BR1 sendet die aktuelle Eingangsadresse minus 1, der Doppelklick die Zahl aller Eingänge.
Für unser Mini-Ensemble also sende ich die Eingangsnummern 0 bis 3, für den Doppelklick die 4. Es gibt also insgesamt 5 Receive-Schalter-Stellungen, wobei in den Properties nur die vier echten Signalquellen aufgelistet sind und die fünfte (OFF) durch das aktivierte "Enable Switch Off" intern erzeugt wird.
Das geht folgendermaßen:
IC-send to Receive.gif
Man klickt in den Properties des IC-Send den Sende-Button
Sende-Button.gif
und beim Receive-Modul auf den Empfänger-Button
Empfänger-Button.gif
. In den jeweiligen Properties erscheinen nun die interne Quelle und das Ziel. Das Modul IC-Send steuert nun das Verhalten des Receive-Moduls, also seine Schalterstellung. Wohl bemerkt, nur die Funktionalität des Receive--Moduls nicht die Daten, die es sendet. Die Ausgabedaten des Receive-Mduls hängen davon ab, welche Quelldaten im Struktur-Menü angeboten werden.
Damit das ganze richtig funktioniert, müssen die Wertebereiche von IC-Send und Receive übereinstimmen. Also sollte man annehmen, dass die Einstellung 0 .. 4 korrekt ist und dann alles klappt.
Korrekt? - FALSCH!!
REAKTOR zeigt zwar die Datenequellen in dem Properties-Menü in der richtigen Reihenfolge an, aber mit umgekehrter Zählung (arrgggh :evil: ). Diesen "geistreichen Trick" kann ich mir so erklären: Jeder neu hinzugekommen wird in einem so genannten Stack (für programmiertechnische Laien: ein Beamten-Ablage-Fach im Sinne von: neuer Arbeitsauftrag? zuerst mal ins abgelegte Fach, schon wieder ein neuer Auftrag? wieder ins Ablagefach usw. Die Abarbeitung erfolgt genau rückwärts: wer zu spät kommt wird als erster bearbeitet: FIRST IN - LAST OUT).
Schalterstellungen.gif
Das heißt: der oberste Eintrag F01-1 iGate ist zwar in meinem Ensemble der Ausgang 1, wird aber im Receive-Modul mit der Schalterstellung 4 ausgewählt. Der zweite Eintrag F01-1 out mit der Schalterstellung 3 usw. und Off mit der Schalterstellung 0, also in genau umgekehrter Reihenfolge (Stack: FirstIn-LastOut).
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von herw am 22. Januar 2007, 10:29, insgesamt 2-mal geändert.
Antworten