3 ms·

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

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 9mo ago
There's a lot of soft-realtime (=audio/video, gaming etc) apps using interpreted languages. Besides Python and Lua, also Erlang.
- fulafel 9mo ago
  Oh and of course SuperCollider.
  - fp64 9mo 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 9mo ago
  They don't use python or similar languages in their realtime threads, I would wager.
dist-epoch 9mo ago
Generating audio is far from being an "intensive" operation these days.
- PaulDavisThe1st 9mo 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 9mo 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 9mo 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 ...

fulafel 9mo ago

There's a lot of soft-realtime (=audio/video, gaming etc) apps using interpreted languages. Besides Python and Lua, also Erlang.

fulafel 9mo ago
Oh and of course SuperCollider.
- fp64 9mo 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 9mo ago
They don't use python or similar languages in their realtime threads, I would wager.

dist-epoch 9mo ago

Generating audio is far from being an "intensive" operation these days.

PaulDavisThe1st 9mo 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 9mo 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 9mo 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 ...