Python für komplexes Projekt die richtige Wahl?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,
    ich arbeite gerade an einem Projekt (Musikinstrument als elektronische Variante) bei dem mehrere GIPOs zusammen spielen und es auf das Timing (wenn möglich nahe realtime) ankommt. Es müssen z.B. 5 - 6 Klänge gleichzeitig abgespielt werden, und das ganze wird noch durch einen Hall-Sensor (zur Erfassung einer Drehgeschwindigkeit) beeinflußt.
    Zu beginn, als es "nur" Midi NoteON / Off war, war es ganz OK. Leider gibt es da Verzögerungen in der Wiedergabe, was evtl. an der Trägheit vom Senden der Midi-Messages zum Timidity Server lag. Ich habe nun kleine Soundsamples vom original Instrument in WAV Format und wollte diese per pygame/sound/channel abspielen. Teilweise in einer eigenen Klasse, die von einem Thread ableitet (langlaufend, d.h. einmal anstoßen und von aussen dann Flag setzen). Das haut aber alles nicht ganz so hin. Reaktionszeit etc.
    Jetzt Frage ich mich, ob Python dafür die richtige Sprache ist, und ob ich nicht nach C++ wechseln sollte. Python läßt sich einfacher schreiben, und mein C/C++ ist schon etwas eingerostet.
    Was meint Ihr?

  • Wenn du bereits "Trägheit" festgestellt hast, kann das entweder an deinem Code liegen denn es führen immer mehrere Wege nach Rom, oder deine Frage könntest du selber beantworten... Wobei du auch mit C++ einen langsameren Weg wählen und dann auch solch eine "Trägheit" haben könntest...
    Natürlich geht es immer irgendwie schneller, aber auch langsamer. C++ ist nicht die schnellste, Python ist nicht die langsamste.... Aber wie gesagt kann man auch eine eigentlich super schnelle Programmiersprache ausbremsen.

    Deshalb: Bitte Code zeigen!

  • Anbei mein Code mit dem ich derzeit experimentiere. Als Ergebnis soll eine elektrische Drehleier entstehen, die man per Kopfhörer verwenden kann:
    Drehleier Beispiel

    Die Idee hinter dem Code ist, dass ein Rad gedreht wird, auf dem 16 Magnete aufgebracht sind und per HallSensor Switch überwacht wird. Erst wenn das Rad gedreht wird, sollen 2 Grundtöne abgespielt werden. Wird das Rad schneller gedreht (trumpetOffset) soll ein zusätzlicher Ton abgespielt werden. Und nur so lange, wie der Offset unterschritten wird. Dies ist mein aktuelles Problem. Die Ermittlung des Offsets schwankt. Die Drehgeschwindigkeit liegt über dem Offset, aber es wird ein falscher Wert ermittelt (stick_elapse_time()) und der 3 Ton springt an, obwohl er es nicht soll.
    Ziel ist es auch, dass der dritte Ton schon nach der Drehdistanz von einem Magneten auf den anderen anspringen sollte, also ab dem zweiten Magnet. Der Ton wird aber erst nach einer viertel Umdrehung abgespielt, was 4 Magnete entspricht.
    Daher meine Überlegung, ob Python einfach zu träge ist. Oder ist wie meigrafd angedeutet hat, der code unglücklich geschrieben?

    Einmal editiert, zuletzt von NeuHier (14. August 2017 um 06:25)

  • Hallo,

    in der Klasse DronePlayer stimmt definitiv was nicht, was du 2x die Methode `play` definiert ist, womit die zweite Definition von der ersten überschrieben wird. Was wahrscheinlich nicht gewünscht ist.

    In der Datei `playAsWAVE.py` sind die Einrückungen ganz komisch - keine Ahnung, ob das so überhaupt läuft.

    Der massive Gebrauch von `global` macht das Programm schlecht bis nicht nachvollziehbar. Abgesehen davon ist die Verwendung von `global` in 99,9% der Fälle falsch, weil nicht nötig. Hier solltest du dringend mal nachbessern...

    Variablennamen schreibt man in Python übrigens per Konvention klein_mit_unterstrich.

    Gruß, noisefloor

  • Hi noisefloor,
    vielen Dank für's ansehen. Ja, mit Python hatte ich bis vor eine Woche nichts am Hut. Im Moment überlege ich noch, mit welcher Sprache ich das Projekt machen soll. Wenn es Python wird, nehme ich den Wink auf, und werde mir erst einmal die Grundprinzipien reinziehen. Das mit den globals habe ich Aufgrund der Runtime Errors so gemacht. Trial and Error ;)
    Das zweite def play ist durch das Ausprobieren mehrerer Varianten rein gekommen. Aber, jep - no excuses...
    Prinzipiell läuft aber alles, nur eben mit Verzögerungen.

    Einmal editiert, zuletzt von NeuHier (13. August 2017 um 18:46)

  • Du hast ein schwerwiegenden Designfehler, den ich mir schon fast gedacht hab - abgesehen von dem was noisefloor schrieb: Du blockiert die Interrupt-Callback Funktion sobald ein Flankenwechsel stattfindet. Dh derweil kann kein weiterer Flankenwechsel verarbeitet werden, und somit bremst du dein Programm künstlich aus. Auf die Art und Weise kriegst du mit jeder Programmiersprache Probleme.

    Bessere Vorgehensweise: FAQ => Nützliche Links / Linksammlung => Interrupt => #8

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!