3 ms·

This seems to conflate different things. Interpreted is not a problem from the predictable behaviour point of view. You may get less absolute performance. Thou

by fulafel 8mo ago

This seems to conflate different things. Interpreted is not a problem from the predictable behaviour point of view. You may get less absolute performance. Though with Python you can do the heavy lifting in numpy etc which are in native code. And this is what is done here, see eg https://github.com/gpasquero/voog/blob/main/synth/dsp/envelope.py https://github.com/gpasquero/voog/blob/main/synth/dsp/envelo... Languages that have garbage collection: not going to rehash the standard back-and-forth here, suffice it to say that the devil is in the details.

PaulDavisThe1st 8mo ago
I was speaking in broad generalities (and did mention Lua as a counter-example). If you want realtime safe behavior, your first port of call is rarely going to be an interpreted language, even though, sure, it is true that some of them are or can be made safe.
- fulafel 8mo ago
  There's a lot of soft-realtime (=audio/video, gaming etc) apps using interpreted languages. Besides Python and Lua, also Erlang.
  - fulafel 8mo ago
    Oh and of course SuperCollider.
    - fp64 8mo ago
      It compiles and sends bytecode to the server, no? I'm quite sure the server at least does not run a plain interpreter, and I know for sure you build a graph there. That's why you can also use it with other languages (Saw a clojure example I think I wanted to give a try)
  - PaulDavisThe1st 8mo ago
    They don't use python or similar languages in their realtime threads, I would wager.
- dist-epoch 8mo ago
  Generating audio is far from being an "intensive" operation these days.
  - PaulDavisThe1st 8mo ago
    It has nothing to do with cpu cycles, and everything to do with realtime safety. You must be able to guarantee that nothing will block the realtime audio thread(s), and that's hard to do in a variety of "modern" languages (because they are not designed for this).
    - dist-epoch 8mo ago
      I know you are an audio guy, I also wrote low-latency audio software. I was just saying that setting HIGH_PRIORITY on the audio running thread and it's feeding threads is enough, you don't need QNX. Python has the GIL problem, but that is another story. For a simple audio app like this synth on a modern CPU it's kind of trivial to do it in any language if the buffer is >40 ms. I'm talking about managing the buffers. Running the synth/filter math in pure Python is still probably not doable.
      - PaulDavisThe1st 8mo ago
        Sure, but 40ms for a synth intended to be played is generally the kiss of death these days, unless you target audience are all pipe organ players ...

by fulafel 8mo ago

PaulDavisThe1st 8mo ago

I was speaking in broad generalities (and did mention Lua as a counter-example). If you want realtime safe behavior, your first port of call is rarely going to be an interpreted language, even though, sure, it is true that some of them are or can be made safe.

fulafel 8mo ago
There's a lot of soft-realtime (=audio/video, gaming etc) apps using interpreted languages. Besides Python and Lua, also Erlang.
- fulafel 8mo ago
  Oh and of course SuperCollider.
  - fp64 8mo ago
    It compiles and sends bytecode to the server, no? I'm quite sure the server at least does not run a plain interpreter, and I know for sure you build a graph there. That's why you can also use it with other languages (Saw a clojure example I think I wanted to give a try)
- PaulDavisThe1st 8mo ago
  They don't use python or similar languages in their realtime threads, I would wager.
dist-epoch 8mo ago
Generating audio is far from being an "intensive" operation these days.
- PaulDavisThe1st 8mo ago
  It has nothing to do with cpu cycles, and everything to do with realtime safety. You must be able to guarantee that nothing will block the realtime audio thread(s), and that's hard to do in a variety of "modern" languages (because they are not designed for this).
  - dist-epoch 8mo ago
    I know you are an audio guy, I also wrote low-latency audio software. I was just saying that setting HIGH_PRIORITY on the audio running thread and it's feeding threads is enough, you don't need QNX. Python has the GIL problem, but that is another story. For a simple audio app like this synth on a modern CPU it's kind of trivial to do it in any language if the buffer is >40 ms. I'm talking about managing the buffers. Running the synth/filter math in pure Python is still probably not doable.
    - PaulDavisThe1st 8mo ago
      Sure, but 40ms for a synth intended to be played is generally the kiss of death these days, unless you target audience are all pipe organ players ...