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

Dieses Thema im Forum "Web & Algorhythmics" wurde erstellt von serge, 13. Juni 2018.

  1. 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.
     
    x2mirko gefällt das.
  2. x2mirko

    x2mirko :D

    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.
     
    serge gefällt das.
  3. 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?
     
  4. fanwander

    fanwander ||||||||

    @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: 18. Juni 2018 um 17:25 Uhr
  5. x2mirko

    x2mirko :D

    ~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 :)
     
    serge gefällt das.
  6. x2mirko

    x2mirko :D

    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.
     
  7. fanwander

    fanwander ||||||||

    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.
     
    weinglas, serge und x2mirko gefällt das.
  8. 2bit

    2bit |

    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: 18. Juni 2018 um 19:31 Uhr
  9. x2mirko

    x2mirko :D

    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.
     
    serge gefällt das.
  10. 2bit

    2bit |

    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.
     
  11. serge

    serge ||||||||

    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.
     
  12. x2mirko

    x2mirko :D

    Den Eindruck hatte ich nicht.