Wer arbeitet mit Python?

[einseinsnull]

von pyseq haben wir ja hier schon einiges dazu gelesen. es geht also.

es ist sicherlich sehr elegant - und ideal für leute, die es schon können (das gleiche gilt für ruby oder commonlisp) - aber irgendwie dünkt mir trotzdem, dass supercollider naheliegender wäre - auch wenn standalone building sicherlich nicht dein wichtigstes anliegen dabei ist.

 

[2bit]

Bei Python-Code in Postings findet sich dagegen immer jemand, dem man erst die Sache mit den Einrückungen erklären muß.

Whitespaces als Syntaxstrukturelement ist die Seuche...

 

[Max]

Stimmt, bei Midi kommt es auf das Timing an, da wäre schneller C-Code natürlich besser.

die Programmiersprache sollte bei so gut wie jeder MIDI-Anwendung ziemlich egal sein

das größte Bottleneck ist hier so gut wie immer die langsame serielle Übertragung (~ 1ms pro Nachricht - in der Zeit kann selbst ein uralter Prozessor seeeeehr viel berechnen)

das zweitgrößte Problem (auf einem Desktop-PC) ist wohl Multi-Threading, d.h. die Zeit die deine MIDI-Anwendung warten muss, bis sie an die Reihe kommt (heutzutage mit den Multicore-Rechnern aber auch eher vernachlässigar)

und selbst für Berechnungen, bei denen man in C theoretisch noch was rausholen könnte z.B. gegenüber einer Skriptsprache gilt meistens auch: wenn man die Zeit, die man brauchen würde ein super optimiertes C-Programm zu schreiben in "strukturelle" Optimierungen steckt hat man am Ende in den meisten Fällen wohl ein deutlich schnelleres Programm in der eigentlich langsameren Sprache

 

[einseinsnull]

die Programmiersprache sollte bei so gut wie jeder MIDI-Anwendung ziemlich egal sein

das größte Bottleneck ist hier so gut wie immer die langsame serielle Übertragung (~ 1ms pro Nachricht - in der Zeit kann selbst ein uralter Prozessor seeeeehr viel berechnen)

du übersiehst glaube ich, dass die mehrheit der MIDI empfänger heute andere anwedungen auf den gleichen host computer sind. dort haben nachrichten immer die genauigkeit, die das erzeugende programm und die midi umgebung des betriebsystems hergeben.

hat ein programm einen so beschissenen scheduler, dass der zwischendurch auch mal 10 sekunden aussetzt o.ä., ist es nicht mehr verwendbar.

 

[PySeq]

die Programmiersprache sollte bei so gut wie jeder MIDI-Anwendung ziemlich egal sein

Also, mein Sequencer-Programm verwendet einen Main-Loop, in dem auf einkommende Noten von seq24 geprüft wird, auf Events auf dem PC-Keyboard (mit den Modulen "termios", "select" und "tty") und auf dem Midi-Keyboard, dann müssen die Berechnungen durchgeführt werden, und zur passenden Zeit müssen Midi-Events an alsa-jack gegeben werden, wobei auf Note-On und Note-Off geprüft werden muß. Während auf dem PC gleichzeitig noch zig andere Prozesse ablaufen.
Da wäre es schon gut, wenn dieser Loop wirklich schnell und damit häufiger ablaufen könnte.
Sonst kann es halt passieren, daß es zu leichten Verzögerungen bei den Noten kommt.
Diese Verzögerungen gibt es auch, aber für meine Hobby-Zwecke ist es ausreichend.
Zur Not kann man die Midi-Events, die das Skript ausgibt, auch aufzeichnen und ggf. nachquantisieren.
Aber es wäre halt schön, wenn es auch in Echtzeit verläßlich ohne Verzögerungen ablaufen würde. Na, man kann nicht alles haben.
Ich mein', man würde ja auch nicht aufwendige, moderne Spiele in einer Skriptsprache schreiben. Die bequemen Datentypen mit automatischer Speicherverwaltung kosten halt Zeit während der Programmausführung. Und wenn sich der Code in irgendwelchen Modulen verfängt, die man eingebunden hat, kostet das auch Zeit. Is' nunmal so.
Trotzdem: Wenn man C64-Basic oder in meinem Fall ZX Spectrum-Basic gewohnt ist, ist Python auf einem modernen Rechner im Vergleich sauschnell. Damit kann man schon eine Menge machen.

 

[Max]

Den Punkt mit dem (Betriebssystem-) Scheduler hab ich doch bereits geschrieben - das ist aber heute auch minimalst und außerdem völlig unabhängig von der Programmiersprache. Dem Betriebssystem ist es beim Scheduling völlig egal, ob das Programm jetzt in C oder Python ist. Und auch die MIDI-Umgebung ist die selbe für jedes Programm. Wenn eine Programmierumgebung sowas wie einen Garbage-Collector hat, ok - aber solange man da nicht massenweise ständig Daten erzeugt und wegwirft ist das auch kein spürbares Problem mehr (und wenn, sollte man sich eher überlegen, was in dem Programm falsch läuft als auf C zu setzen).

Gegenüber der 1ms seriellen Übertragung kann die Berechnung auch noch so langsam ablaufen, das wird so gut wie immer um mehrere Größenordnungen kürzer dauern als die Übertragung (ich schätze mal grob Faktor 1000 - 100.000).

-> am allerbesten in der Theorie ist natürlich ein in C/C++/Assembler programmierter Mikroprozessor (ohne Betriebssystem), auf dem außer der Anwendung nichts anderes läuft...

Ich denke aber wirklich, man sollte sich da nicht zu viele Gedanken machen und MIDI Sachen einfach in der Sprache programmieren, die einem am Besten gefällt - selbst wenn es theoretische Unterschiede gibt, wird man die nicht hören. (bei Audio sieht das natürlich etwas anders aus, aber selbst da werden heute Skriptsprachen verwendet...)

 

[khz]

• The Scientist and Engineer's Guide to Digital Signal Processing By Steven W. Smith, Ph.D. - http://www.dspguide.com/pdfbook.htm
• Julius Orion Smith III - https://ccrma.stanford.edu/~jos/
• The Theory and Technique of Electronic Music - http://msp.ucsd.edu/techniques.htm
• Advanced Digital Signal Processing and Noise Reduction, Second Edition. -
  • http://dsp-book.narod.ru/293.pdf
  • http://dsp-book.narod.ru/294.pdf
  • http://dsp-book.narod.ru/295.pdf
  • ...
• Kadenze search - https://www.kadenze.com/search?q=audio
• openAudioProgrammingTutorials - https://github.com/harryhaaren/openAudioProgrammingTutorials
• LV2 wiki - https://github.com/drobilla/lv2/wiki

 

[einseinsnull]

Den Punkt mit dem (Betriebssystem-) Scheduler hab ich doch bereits geschrieben - das ist aber heute auch minimalst und außerdem völlig unabhängig von der Programmiersprache. Dem Betriebssystem ist es beim Scheduling völlig egal, ob das Programm jetzt in C oder Python ist.

ich kenne ja python nicht, aber ich könnte mir vorstellen, dass es durchaus einen unterschied macht, ob eine umgebung z.b. überhaupt einen scheduler hat und wenn ja, mit welchem takt der läuft.
in einer umgebung mit nur einem thread würde jede mausbewegung und jedes blinkende lichtchen im interface die midi ausgabe verzögern.
man vergleiche mal die MTC ausgabe von cubase unter volllast mit der einer MPC...

python würde mich grundsätzlich auch mal interessieren, aber ich bin leider zu faul dafür das mal auszuprobieren.

 

[aliced25]

der Vorteil/Nachteil (je nach Blickwinkel) von Systemnahen Sprachen ist , dass man nicht verführt wird, Container zu benutzen, dass erleichtert die Umsetzung, wenn es Richtung Hardware gehen soll...

ich arbeite zurzeit auch an einem kleinen MidiProjekt, allerdings in C, da die es in der aktuellen Version auf einem esp32 MikroController läuft...
die ersten Skizzen habe ich aber mit der windowsAPI (c++) gemacht und einen mini Sequencer auf Konsolenbasis programmiert.

sequencer.de/synthesizer/threads/miditrac

 

[noir]

Wenn man will, kann man Python auch auf nem Chip (STM32F405RG) haben: https://micropython.org

 

[OutOfTune]

Whitespaces als Syntaxstrukturelement ist die Seuche...

Man fragt sicht echt was sich die dabei gedacht haben...
In Sprachen wo es das nicht gibt (Java, C# ,...) braucht man sich um die Formatierung gar nicht kümmern, das macht die Entwicklungsumgebung automatisch.

 

[einseinsnull]

am schönsten ist, wenn du sie dir selbst machen kannst.

 

[kris_]

Ich denke, man sollte zuerst das nehmen was man kann und wo man sich wohl fühlt, außer man hat gerade Bock, neben der eigentlich Problemlösung noch ein neues Werkzeug in seinen Werkzeugkasten zu nehmen.

Meiner Erfahrung nach gilt allerdings:

* Nutzt dynamisch typisierte oder untypisierte Skriptsprachen wie Python, Perl, JavaScipt, Lua ... für schnellen Erfolg und einen einfachen Start. Kleine Dinge lassen sich damit sehr schnell machen, und auch die Einstiegshürde ist geringer. Python is für viele Sachen nützlich: Das zu können, kann eigentlich nicht schaden.
* Nutzt statisch stark typisierte Sprachen wie C++, C, Java, ... für Systeme, die entweder die Chance haben, komplex zu werden oder lange zu leben (Jahre, Jahrzehnte). Auch der Hardware-Aspekt ist zu berücksichtigen, allerdings eher auf Arduino als auf Raspi-Level...

Man kann das aber auch wunderbar kombinieren, wenn man nur entschlossen genug ist

 

[noir]

Whitespaces als Syntaxstrukturelement ist die Seuche...

Ich versteh nicht was Du meinst, geht doch!

if foo: #{
    print "it's true"
#}
else: #{
    print "it's false!"
#}

 

[kris_]

Ich versteh nicht was Du meinst, geht doch!

if foo: #{
    print "it's true"
#}
else: #{
    print "it's false!"
#}

Ha! Cool, den kannte ich noch nicht. Untersützt PyCharm das?

 

[2bit]

Ich versteh nicht was Du meinst, geht doch!

Was genau?

Die geschweiften Klammern sind durch # auskommentiert und für den Interpreter komplett bedeutungslos.

 

[bohor]

Bitte!
Lasst uns in diesem Thread einfach darauf konzentrieren, wer welche Erfahrungen bei der MIDI- und Audioprogrammierung unter Python gemacht hat. Und welche Fragen dazu entstehen.

Das Thema Syntaxstruktur von Python ist hier einfach nicht zielführend und lenkt ab. Don't feed the Trolls.

Danke. : - )

 

[Max]

ok, einer muss noch OT, dann ist gut: man kann auch nur mit Whitespace programmieren: https://de.wikipedia.org/wiki/Whitespace_(Programmiersprache)

eine Programmiersprache nur mit Leerzeichen, Tabs und Zeilenumbrüchen

 

[2bit]

Das Thema Syntaxstruktur von Python ist hier einfach nicht zielführend und lenkt ab. Don't feed the Trolls.

Okay. Plonk.

 

[bohor]

So! Jetzt aber inhaltlich weiter! Ich denke, MIDI und auch Anbindung von Modulargeräten kriegt man irgendwie hin. Aber wie steht es mit Audio-Verarbeitung in real time unter Python? Hat jemand damit Erfahrung?

 

[aliced25]

https://www.youtube.com/watch?v=tgamhuQnOkM&t=496s


hier gibt es eine sehr interessante Serie zum Thema Audio Programming, als Sprache steht zwar c++ im Vordergrund, aber die Konzepte, die hier angewendet werden, sind ja übertragbar, von daher ein sehr guter Einstieg in die Materie...

 

[haebbmaster]

das möchte ich aber doch noch beantworten

Man fragt sicht echt was sich die dabei gedacht haben...

das macht die Entwicklungsumgebung automatisch.

Wir reden von Anfang der 90er. IDEs steckten noch in den textorientierten Kinderschuhen und sowas wie Visual Studio oder Eclipse schwebte vielleicht als diffuse Wolke am Himmel des Xerox PARCs. Quelltextformatierung konnte man machen, indem man der Text durch ein pretty-printer Programm jagte.
Deswegen hat man sich damals dafür entschieden, den Programmierer schon beim Coden zum sauberen Arbeiten zu zwingen, um ihm (und vor allem seinen Nachfolgern) die Arbeit bei Lesen und Debuggen zu erleichtern.

 

[PySeq]

Aber wie steht es mit Audio-Verarbeitung in real time unter Python?

Nicht schnell genug.

Höchstens für Nicht-Realtime-Aufgaben geeignet, wie z.B. PyMP3Cut, das wohl ganz beliebt sein soll.

 

[PySeq]

@noir: Semikolon am Zeilenende kann man auch noch haben.

 

[Klinke]

Aber wie steht es mit Audio-Verarbeitung in real time unter Python? Hat jemand damit Erfahrung?

Alles was mit einem Garbage Collector und/oder JIT compiler daher kommt, ist nur dann geeignet, wenn man mit sehr hohen Latenzen arbeiten will, oder mit Knacksern ab und zu leben kann. Die Erfahrung musste ich mit einem Looper machen, den ich mit protoplug (https://www.osar.fr/protoplug/) entwickelt habe, und LuaJIT ist sicherlich schon viel geeigneter für diese Aufgabe als Python. Ich sehe zur Zeit keine echte Alternative zu C++ als Programmiersprache (okay, es gibt das Dplug Projekt für D, aber ob die Vorteile von D gegenüber C++ tatsächlich gegenüber den Vorteilen des JUCE-Framework gegenüber dplug überwiegen, wage ich zu bezweifeln), wobei es ja Sprachen wie Faust (https://faust.grame.fr/) gibt, welche C/C++ Code generieren.

 

[Max]

ich bin auch eher der Meinung, dass für Audio eine hardware-nahe Sprache besser geeignet ist...

andererseits - wenn man sich anschaut was die Kiddies heutzutage alles mit JavaScript so machen kommt man da schon auch ins Zweifeln

ich hab mal mit C# und ASIO ein bißchen rumgespielt, das lief soweit ganz ordentlich und deutlich besser als erwartet - Performance war ok, Aussetzer gab es keine

die Garbage-Collectoren räumen ja heutzutage nicht mehr alles auf einmal auf und legen den ganzen Betrieb lahm und auch die Just-In-Time-Compiler sind mittlerweile doch auch sehr gut und produzieren ziemlich effizienten und schnellen Maschinencode - da muss man schon schauen dass man da noch mithalten kann wenn man selbst hardware-nah programmiert...

 

[ZH]

Ich habe das hier programmiert und moechte evtl demnaechst mal dran weitermachen (lag ein paar Jahre auf Eis - also nicht ich, sondern das Projekt):


https://www.youtube.com/watch?v=fy9ifaqeagk

Im Grunde ist es ein MIDI-Sequencer der wie ein Tracker bedient wird, allerdings mit dem zusaetzlichen Zwischenschritt dass aus kurzen "Phrasen", die immer nur fuer einzelne Instrumente gelten, ganze Songs gebaut werden (anders als beim klassischen Tracker, wo ein Pattern immer einen gesamten Song-Abschnitt darstellt in dem alle Instrumente drin rumdudeln).

Hier noch zwei Bilder davon:

 

[Klinke]

Es ist halt nur dumm, wenn der JIT Compiler für das kompilieren für irgendeinen Branch Deines Audiocodes 3 ms mehr braucht als üblich. Bei meiner Anwendung z.B., wenn ich zum ersten mal ein Loop aufnehmen will. Das GC-Problem habe ich halbwegs in den Griff bekommen (da ich von LuaJIT auch selbst im C-Style Memory Managment betrieben kann), den JIT-Compiler aber nicht.

 

[Max]

Kannst du das Kompilieren des kompletten Codes nicht irgendwie forcieren? Evtl. gibt es ja einen Befehl dafür?

Ansonsten könntest du vielleicht beim Programm-Start irgendwas hinhacken was den entsprechenden Branch benutzt? (z.B. irgendeinen Dummy-Loop aufnehmen und gleich wieder löschen)

 

[PySeq]

Kannst du das Kompilieren des kompletten Codes nicht irgendwie forcieren? Evtl. gibt es ja einen Befehl dafür?

Hmm, es werden ja diese ".pyc"-Dateien erzeugt, die den sog. "Bytecode" enthalten. Ich denke, die sind schon fertig kompiliert (wodurch es aber auch nicht viel schneller wird).