monome norns (Stand-alone Audiohardware mit Supercollider & Lua)

serge

serge

*****
Aufgrund dieser kleinen Schachtel…

Ansehen: https://player.vimeo.com/video/266741634?color=ffffff&title=0&byline=0&portrait=0

…interessiere ich mich für die Sprachen Supercollider und Lua, allerdings beherrsche ich weder diese beiden Sprachen noch bin ich Programmierer.

Trotzdem macht mich diese akkubetriebende Kiste namens norns an: Stereo-Ein- und Ausgänge plus Kopfhörerausgang sowie vier USB-Anschlüsse, an die nahezu beliebige USB-Controller angeschlossen werden können, vor allem das ebenfalls im Video zu sehende monome grid. Über einen kleinen WiFi-USB-Stecker kann das Teil bei Bedarf mittels einen Web-Browsers angesprochen und programmiert werden. Programme und Daten (z.B. Samples) werden nichtflüchtig gespeichert.

Für die Klangerzeugung werden Supercollider-Programme genutzt,
es werden mehrere Programme mitgeliefert,
und es entwickelt sich gerade eine Community, die weitere schreiben.

Die in Echtzeit steuerbaren Parameter eines Supercollider-Programms werden über die Script-Sprache Lua mit den eingebauten und per USB angeschlossenen Bedienelementen verbunden.

In einem Lua-Script kann man aber nicht nur Bedienelemente mit Parametern verbinden, sondern auch
mit einem Bedienelement die Funktion eines anderen Bedienelementes umschalten,
Zufallswerte für Parameter erzeugen,
einen Sequencer bauen
und dergleichen Schabernack mehr.

Supercollider ist hier kostenlos erhältlich,
ersten Schritte gibt es hier:

Ansehen: https://www.youtube.com/watch?v=ntL8QDOhhL8


Hier gibt es Lua kostenlos,
und hier ein Tutorial.

Nein, ich habe noch kein norns.
 
Ich habe schon seit etwa zwei Wochen ein Norns und bin bisher sehr glücklich mit dem Workflow. Maiden (der webbasierte Editor) funktioniert sehr gut und da Norns im Grunde ein Linuxrechner ist, kommt man sowieso per ssh an alles nötige ran. An Audioengines herumzuschrauben ist noch ein wenig mühsam, weil a) SC-engines nicht in Maiden auftauchen und b) Änderungen nicht sofort übernommen werden (was auch verständlich ist, wenn man SCs Server/Client-Prinzip kennt... die Synth-Definitionen werden nur beim Start der Audioengine geladen, die muss man eben dann nach Austausch des Skripts neu starten). Bisher ist mein Workflow bzgl. SuperCollider daher, Code entweder (wenn hinreichend kompliziert) auf meinem Rechner zu testen und dann erst im fertigen Zustand rüberzukopieren oder (wenn simple Änderung) per ssh/vim direkt auf norns zu ändern und dann die AudioEngine neu zu starten.

Wenn man aber erstmal nichts an SC machen möchte, sondern nur an der UI / Ansteuerungslogik herumspielen möchte, genügt der LUA-Anteil ja schon und das läuft mit Maiden wirklich sehr schön. Die Integration mit Grid ist auch sehr einfach gehalten (über globale Variable g und ein paar callbacks), sodass man verhältnismäßig schnell auch komplexe Interaktionen hinbekommt. Jedenfalls liegt mir das sehr viel mehr, als Interaktionen mit dem Grid in Max zu definieren. Ein einfacher Step-Sequencer mit drei unterschiedlichen "Pages" fürs Grid, der eine eigene FM-Engine ansteuert, hatte ich jedenfalls am ersten Tag nach ein paar Stunden Erkundungsphase hinbekommen, was meiner Meinung nach eindeutig für Norns spricht (wohlgemerkt: SuperCollider und Lua kannte ich schon, wenn man ganz von 0 anfängt, wird es bestimmt etwas länger dauern). Der Bildschirm ist auch angenehm leicht anzusprechen und Parameter für die Soundengine lassen sich auch mit verhältnismäßig geringem Aufwand einbauen.

Alles in allem gefällt mir Norns bisher sehr gut.
 
Es gibt ja auch schon Bemühungen Norns auf anderen Plattformen laufen zu lassen und z.b. Push 2 zu unterstützen.
Ich hab seit vielen Jahren zwei 40h, aber seit den varilight Monome ein bisschen die Freude daran verloren.

Bin gespannt, wie sich norns noch entwickelt.

Was hast du für norns bezahlt, wenn ich fragen darf?
 
@serge : Hat Dich die Optik angemacht, oder irgendwelche technische Fähigkeiten? Es gibt ja zB auch das Critter Guitari Organelle (das man in Pure Data programmiert). Kostet halt nur die Hälfte.
 
Zuletzt bearbeitet:
~800 Euro für Norns + Versand und dann nochmal ~170 Euro Zoll + Mwst dazu, also etwa 970 Euro alles in allem.

Der Raspberry Pi Port läuft schon ziemlich gut, auch wenn man sich derzeit noch etwas Mühe geben muss, um es selbst zum Laufen zu bringen. Ich nehme mal an, in ein paar Monaten gibt es bestimmt auch ein Image für einfache Installation. Ist natürlich eine deutlich günstigere Lösung. Der Preis hat nicht geschmerzt und ich bin generell sehr begeistert von Brians Arbeit und unterstütze das auch gern, insofern kein Problem.

Es sind weniger Optik oder spezielle technische Aspekte als die Gesamtlösung. Mit der Organelle muss man soweit ich weiß noch ziemlich viele Klimmzüge machen, um mal eben z.B. ein Grid, einen Arc und noch nen anderen Midicontroller anzuschließen, das alles zu mappen und damit ne eigene Audioengine anzusprechen. Dank ein paar Communitymitgliedern (TechnoBear z.B. der ja auch den Raspberry Pi - Port + Push2 support vorwärts treibt gerade) geht das wohl durchaus, aber die mühelosere Integration in Kombination mit der Community (ich bin sehr viel auf Lines unterwegs) macht für mich den Unterschied aus. Außerdem schreibe ich etwa 100 mal lieber Code in Supercollider als in Pure Data. Ich benutze zwar auch ab und zu PD und Max, aber ich fühle mich mit textbasierten Programmiersprachen deutlich wohler.

Das geht alles sicher deutlich günstiger und wäre im Grunde auch gar nicht nötig, aber so ist das ja oft. Es inspiriert eben, zumindest mich :)
 
Ach so, noch eine Sache: Ich würde zumindest derzeit als nicht-Entwickler noch eher die Finger davon lassen. Die Apps sind zwar teils sehr nett und kunstvoll, aber größtenteils wenig musikalisch nützlich (bzw. nur für sehr minimalistische Performances). Wenn man dem Gedanken von einem hypermobilen mlr was abgewinnen kann, könnte man das schon als Kaufgrund sehen - das funktioniert nämlich bereits sehr gut - ansonsten sind die mitgelieferten Apps aber meiner Meinung nach eher mau (was auch vollkommen okay ist meiner Meinung nach, Norns ist ja wie auch das Grid oder Arc als offene Hardware gedacht, für die die Software dann eben mit der Zeit aus der Community kommt). Es wird schon fleißig entwickelt, aber derzeit ist alles noch etwas chaotisch. Wenn ich nicht selbst dafür entwickeln wollte, würde ich eher noch ein paar Monate abwarten, bis sich die erste Aufregung gelegt hat, gewisse Standards entwickelt worden sind und mehr Patches zur Verfügung stehen.
 
Und vielleicht noch insgesamt zum Topic "Einstieg ins Programmieren für Medienerzeugung". Dies vor allem @serge :

Ich hab das gerade erst gemacht, mit der Critter&Guitari ETC. Die/das ETC ist zu programmieren in Python. Meine Vorkenntnisse: vor laaangen Jahren ein bisschen Basic, heute leidlich Shell-Scripting, ein bisschen Perl, und beruflich bedingt kann ich Java-Code lese (aber nicht wirklich schreiben). Mein Resultat: die allerersten Schritte sind ungemein befriedigend. Im Gegensatz zur Hardware-Bastelei, kommt beim Anfänger zunächst ziemlich sicher was raus, während das Lötanfänger-Ergebnis oft nur von partiellem Erfolg geprägt ist.
Aber dann kommt die Sache mit der Lernkurve... man bekommt eine Vorstellung davon, was im Prinzip möglich ist, aber wird immer öfter daran scheitern Vorstellungen in realen Code umzusetzen.

Schuld daran sind mehrere Umstände
Da ist eine gewisse Ungeduld, sprich: man nimmt sich schnell zu Kompliziertes vor, weil man denkt, man habe es ja grundsätzlich verstanden.

Dann ist die Sache mit dem Lehrmaterial. Diese Tutorials bewegen sich alle auf einem sehr sehr einfachen Niveau. Die hören einfach auf einem sehr niedrigen Niveau auf; manbräuchte aber auf diesem Niveau lange noch eine Unterstützung durch einen Lehrer.
Und wenn es länger laufende Tutorials gibt, dann sind sie allesamt von Programmierern gemacht worden, die schon laaange programmieren. Das bedeutet, ihnen ist einfach nicht klar, dass die Anfängerfehler, die in Tutorial 3 und 4 eigentlich erklärt wurden, von mir nach zwei Monaten im Tutorial 27 einfach immer noch gemacht werden, und dass man gottverdammich in Tutorial 27 bitte immer noch langsam machen soll, und nicht husch-husch-das-hab-ich-ja-schon-in-Ausgabe-3-gesagt... drüber hinweggehen soll.

Und damit ich nicht dauernd alles auf die anderen schiebe merke ich auch schnell, dass mir einfach die grundlegende Programmiererfahrung fehlt. Da wäre dann relevant, in welcher Reihenfolge man Schleifen in einander verschachtelt, wo man welche Variablen definiert, wie man Code performant hält, und so weiter. Das bringt einem keiner wirklich bei. Das kommt wirklich nur per Erfahrung. Und jetzt bin ich hier sogar durch mein Vorwissen etwas gewarnt - wie mag es jemandem gehen, der einfach in diese Erfahrung reinrauscht. Das muss sehr frustrierend sein.
 
Wer nicht weiß, was eine Klasse, ein Objekt oder eine Methode ist oder was es mit dem Konzept der Vererbung auf sich hat, der sollte von SuperCollider wirklich besser erstmal die Finger lassen. Objektorientierte Sprachen sind ne ziemlich komplexe Angelegenheit, die ein enormes Vorwissen erfordern.

Wer wirklich programmieren lernen will, dem kann ich empfehlen, sich grundsätzlich erst einmal mit ANSI-C vertraut zu machen. Das ist erstens noch eine prozedurale Sprache, die den ganzen Ballast der Objektorientierung erst mal außen vor lässt, aber grundsätzlich schon vermittelt, worauf es beim Programmieren ankommt und wie Computer "unter der Haube" mit den Befehlen, die sie so bekommen, umgehen. Außerdem lernt man mit ANSI-C eine der wichtigsten Syntaxkonstruktionen überhaupt kennen, die einen Haufen wichtiger Sprachen (z.B. C++, PHP, Java, JavaScript, C# und in weiterem eben auch LUA und SuperCollider) wesentlich beeinflusst hat.

Essenziell:
Ansehen: https://www.amazon.de/Kompaktreferenz-Programmers-Choice-Helmut-Herold/dp/3827322863


Nötiges Arbeitspensum für die absolut unverzichtbaren Basics: Ein halbes Jahr lang pro Woche 6 Zeitstunden.
90 Minuten davon theoretisches Grundwissen aus der Referenz oben erarbeiten, die restlichen viereinhalb Stunden gehen dann für das Zeichnen von Struktogrammen und die praktische Umsetzung ebendieser Diagramme in wirklich funktionierende Programme drauf. Das ist ne ganz harte Nummer, aber machbar.
 
Zuletzt bearbeitet:
Das halte ich persönlich für den vollkommen falschen Weg. Ich würde ja eher mit ner Sprache wie Python anfangen, die einem Abstraktionen an die Hand gibt, sodass man sich nicht gleich von Anfang an mit jeder Menge Konzepten herumplagen muss, mit denen man direkt mal total überfordert ist und auch Ergebnisse sehen kann. Es gibt schon so genug zu lernen. Es ist ja richtig, dass all diese Sprachen von C beeinflußt wurden, aber das heißt nicht, dass der beste Weg, Programmieren zu lernen, ist, ganz vorn in der Geschichte anzufangen. Sonst könnte man ja auch gleich noch Assembler vorschieben. Ist alles sehr lehrreich, aber nicht unbedingt der beste Weg, um zu beginnen. Unter Umständen wäre sogar noch sowas wie Processing vorzuziehen - je nachdem, was das Ziel ist und wie man am besten lernt.

Ist vielleicht aber nicht der richtige Thread, um sowas zu diskutieren.
 
x2mirko schrieb:
Das halte ich persönlich für den vollkommen falschen Weg. Ich würde ja eher mit ner Sprache wie Python anfangen, die einem Abstraktionen an die Hand gibt, sodass man sich nicht gleich von Anfang an mit jeder Menge Konzepten herumplagen muss, mit denen man direkt mal total überfordert ist und auch Ergebnisse sehen kann. Es gibt schon so genug zu lernen.
Zum Vergrößern anklicken....

Das Entwickeln von knallharten, schnellen und effizienten Algorithmen sowie die Fehlerbeseitigung lernt man durch die Benutzung von abstrakten Python-APIs jedenfalls nicht. Und genau darum geht es doch hier, oder nicht?

Fallbeispiel:
Ich kann ne Methode für einen Dateidialog aufrufen. Funktioniert prima. Unendlich kompliziert wird es aber, wenn ich mit einem winzigen Detail an dieser Methode unzufrieden bin. Dann lerne ich nämlich nicht mehr das Programmieren an sich, sondern ich fummle stattdessen an der abstrakten API (und der unter Umständen hochkomplexen gekapselten Lösung eines Anderen) herum. Und spätestens dann MUSS man Objektorientierung verstanden haben, sonst wird das einfach nix.

Das selbe gilt selbstredend auch für Methoden, die bestimmte Töne auf ganz spezifische Art und Weise generieren, manipulieren und an den Audio-Buffer schicken sollen. Man kann fertige Lösungen von anderen benutzen, die regelmäßig nicht das liefern, was man haben will. Oder man weiß halt, was man tut, weil man "vorn in der Geschichte" angefangen hat und imstande ist, diese Sachen selbst zu machen, was ja das Ziel hier ist.

Schnell "irgendwelche" Ergebnisse zu produzieren kann ein Weg sein. Die "richtigen" Ergebnisse zu produzieren, wird auch mit Python ganz genau so schwer werden, wie mit ANSI-C. Am Ende hat man durch eine bestimmte Sprache null Vorteile, wenn man nie gelernt hat, was man eben braucht.
 
2bit schrieb:
Das Entwickeln von knallharten, schnellen und effizienten Algorithmen sowie die Fehlerbeseitigung lernt man durch die Benutzung von abstrakten Python-APIs jedenfalls nicht. Und genau darum geht es doch hier, oder nicht?
Zum Vergrößern anklicken....
Das ist ein Missverständnis, dass es sich hier um das "Entwickeln von knallharten, schnellen und effizienten Algorithmen" drehen würde. Das ist – im Kontext von norns, wohlgemerkt! – nicht das Ziel des Erlernens von Lua und Supercollider.
 
2bit schrieb:
Das Entwickeln von knallharten, schnellen und effizienten Algorithmen sowie die Fehlerbeseitigung lernt man durch die Benutzung von abstrakten Python-APIs jedenfalls nicht. Und genau darum geht es doch hier, oder nicht?
Zum Vergrößern anklicken....

Den Eindruck hatte ich nicht.
 
Ich hab zur Zeit vor allem Spaß mit Norns + Linnstrument (dem kleinen 128er). Total portabel und macht MPE ohne Probleme mit. Bin immer noch begeistert von dem kleinen Ding.
 
Mein norns habe ich am Samstag ausgepackt und habe mich bisher vom "awake"-Skript einfach nicht losreissen können.
 
Moin .-)

OT: Um auf das Video oben einzusteigen: Bring das Ding mit zur EA-Party... Ich mach was mit dem Vibe und Du verwurstest es dann damit... ;-)

Jenzz
 
Gerne, falls ich bis dahin auf dem norns soweit sein sollte, dass ich zum Script "mlr" vorgedrungen sein und dies hinreichend gut beherrschen sollte – anderenfalls kann ich Dein Vibe auch mit meinem Octatrack auf mannigfaltige Art in Echtzeit verwursten.
 
serge schrieb:
Welches Script nutzt Du dafür?
Zum Vergrößern anklicken....

Eigenbau - MIDI ist ja angenehmerweise kein Hexenwerk. Eine Minimalversion (lua + sc-script, 8 Kanäle mit simplen Sinus-Wellen) gibts hier:
Ansehen: https://gist.github.com/x2mirko/8e35b6825d04e3d925817f288aab16c4

Ich bastele noch an der Soundengine rum, weshalb ich mich noch nicht drum gekümmert habe, das ins dust-repo zu schieben. Außerdem will ich zumindest die wichtigsten Sachen noch konfigurierbar machen (z.b. pitchbend range ist aktuell hardcoded auf 24 usw.). Hatte das nur schon mal online gestellt, falls jemand einen Einstiegspunkt braucht (gerade der Supercollider-Anteil ist ja bisher fast gar nicht dokumentiert)

edit: Wow, das Forum macht aus dem Link eingebetteten Code? Das war so eigentlich nicht gedacht :D
 
Ich fürchte, ich werde da bei Dir in die Lehre gehen müssen, um schon dieses Nichthexenwerkige zu verstehen!
 
@haesslich Das Buch hab ich und kann es sehr empfehlen. Wobei auch schon die Dokumentation in der SuperCollider-IDE oft sehr gut weiterhilt. Ich meinte mit fehlender Dokumentation mehr die CroneEngine, die ja Norns-spezifisch ist. Ist auch nicht weiter kompliziert, aber es gibt eben keine Doku außer den wenigen bereits existierenden Implementationen.

@serge : Ich gebe zu, das man nicht mit Bits und Bytes auf dem Kriegsfuß stehen sollte. Im Grunde hab ich aber nur das hier gelesen und umgesetzt.

Kurzer Spaziergang durch den Code: Wenn eine Midi-Nachricht ankommt, wird sie an die Funktion midi_event weitergeleitet. Der Parameter "data" ist ein Array, das 3 Bytes enthält, die den empfangenen MIDI-Daten entsprechen. Im ersten Byte steht in der ersten Hälfte der Typ der Nachricht (z.b. 1001 = note on) und in der zweiten Hälfte der MIDI-Kanal (z.B. 0001 = Kanal 1 - zusammen dann etwa 10010001 = Note on event auf Kanal 1).

Um die beiden Werte getrennt auslesen zu können, setze ich die jeweils anderen Bits per bit32.band auf 0, was zugegebenermaßen etwas unleserlich wirkt: bit32.band nimmt zwei Zahlen und wendet ein bitweises Und an: Beim Ergebnis steht genau dann an n-ter Stelle eine 1, wenn an n-ter Stelle in beiden eingegebenen Zahlen eine 1 stand: bit32.band(11110011, 11111100) liefert z.B. 11110000, weil bei beiden Eingaben die ersten vier Stellen den Wert 1 haben, während bei den letzten vier Stellen jeweils eine der beiden Eingaben eine 0 enthält.

Um also z.B. den Event-Typ auszulesen (der ja in den ersten vier Stellen steht), kann man bit32.band(11110000, data) auswerten - dadurch werden die hinteren Bits, die den Kanal enthalten, auf 0 gesetzt und so ignoriert. 11110000 ist in dezimalschreibweise gerade 240, daher kommt diese Zahl in der getEventType-funktion (und 00001111 ist 15, daher der Wert in der Funktion getChannel).

Sobald der Eventtyp bekannt ist, kann man das zweite und dritte Byte interpretieren, da diese für unterschiedliche Events unterschiedliche Daten enthalten. Beim Note-On steht z.B. im zweiten Byte die Notennummer und im dritten Byte die Velocity, während bei Pitchbend-Nachrichten beide Bytes für die Übertragung des Pitchbends genutzt werden (um mehr Genauigkeit zu ermöglichen - 16384 Schritte statt 255). Pitchbend beginnt in der Mitte des Wertebereichs (damit man auch abwärts benden kann), also bei 8192 statt bei 0, weshalb man da noch etwas herumrechnen muss, um den richtigen Wert in Halbtönen zu bestimmen.

Nachdem man die ganzen interessanten Daten aus dem Midi-Protokoll herausgepopelt hat, kann man sie an die Audioengine (also supercollider) weiterleiten. Dazu muss man auf SuperCollider-Seite der engine commands hinzufügen. Der Anteil this.addCommand("noteOn", "if", {...}); im SuperCollider-Code führt z.B. dazu, dass ich danach aus dem lua-Skript heraus engine.noteOn(channel, freq) aufrufen kann, um eine neue Note zu spielen. Das "if" auf SuperCollider-Seite sagt dabei, dass die Funktion zwei Parameter erwartet, der erste ein integer (also eine ganze zahl) der zweite ein float (also eine fließkommazahl). Die übergebenen Parameterwerte werden dann auf den Synth für den übergebenen Kanal angewendet.

Der Synth selbst ist ja maximal simpel, einfach eine Sinuswelle mit einem Envelope, der ein ganz wenig Attack und Release beigibt, damit es nicht knackst, wenn man die Taste loslässt. Wichtig für den MPE-Anteil ist, dass man für jeden MIDI-Kanal einen eigenen Synth erstellt und sich eine Referenz auf diesen hält, damit man später Nachrichten wie Pitchbend oder Aftertouch an den zugehörigen Synth weiterleiten kann. Dafür hab ich mir das Array synths definiert. Bevor ich auf einen Synth zugreife, prüfe ich sicherheitshalber noch, dass für diesen Kanal auch gerade ein Synth existiert, damit ich keine Probleme bekomme, falls mal eine Pitchbend-Nachricht für einen Kanal reinkommt, auf dem ich gerade keine Note abspiele.
 
Ganz herzlichen Dank – zwar stehe ich mit Bits und Bytes nicht auf Kriegsfuß, aber ich teile auch nicht unbedingt mein Kopfkissen mit ihnen, daher hilft mir Deine Erklärung sehr!
 
Basiert das Gerät eigentlich auf dem Raspberry pi 3?
Sieht eigentlich total interessant aus, der Preis ist (für mich) allerdings etwas zu hoch.
 
x2mirko schrieb:
~800 Euro für Norns + Versand und dann nochmal ~170 Euro Zoll + Mwst dazu, also etwa 970 Euro alles in allem.

Der Raspberry Pi Port läuft schon ziemlich gut, auch wenn man sich derzeit noch etwas Mühe geben muss, um es selbst zum Laufen zu bringen. Ich nehme mal an, in ein paar Monaten gibt es bestimmt auch ein Image für einfache Installation. Ist natürlich eine deutlich günstigere Lösung. Der Preis hat nicht geschmerzt und ich bin generell sehr begeistert von Brians Arbeit und unterstütze das auch gern, insofern kein Problem.

Es sind weniger Optik oder spezielle technische Aspekte als die Gesamtlösung. Mit der Organelle muss man soweit ich weiß noch ziemlich viele Klimmzüge machen, um mal eben z.B. ein Grid, einen Arc und noch nen anderen Midicontroller anzuschließen, das alles zu mappen und damit ne eigene Audioengine anzusprechen. Dank ein paar Communitymitgliedern (TechnoBear z.B. der ja auch den Raspberry Pi - Port + Push2 support vorwärts treibt gerade) geht das wohl durchaus, aber die mühelosere Integration in Kombination mit der Community (ich bin sehr viel auf Lines unterwegs) macht für mich den Unterschied aus. Außerdem schreibe ich etwa 100 mal lieber Code in Supercollider als in Pure Data. Ich benutze zwar auch ab und zu PD und Max, aber ich fühle mich mit textbasierten Programmiersprachen deutlich wohler.

Das geht alles sicher deutlich günstiger und wäre im Grunde auch gar nicht nötig, aber so ist das ja oft. Es inspiriert eben, zumindest mich :)
Zum Vergrößern anklicken....
Tip: Für Musikinstrumente zahlt man aus den USA nur die Mehrwertsteuer.
Kein Zoll.
So war es bei meinem Ansible
 
Tip: Für Musikinstrumente zahlt man aus den USA nur die Mehrwertsteuer.
Kein Zoll.
So war es bei meinem Ansible
 
Meines Wissens & meiner Erfahrung nach werden auch bei Musikinstrumente aus den USA Zollabgaben fällig (siehe u.a. auch hier).

@tom3d : Es wäre toll, wenn Du die Abrechnung mit der Auflistung der Einfuhrabgaben hier anonymisiert posten könntest, dann könnte man sehen, wie diese Rechnung zustande gekommen ist und welche Zollcodes zum Einsatz gekommen sind.

Unabhängig davon: Glückwunsch zum neuen Ansible!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.


Neueste Beiträge

News

Zurück
Oben