Hacker News Reader

Comment by PaulDavisThe1st | Hacker News Reader

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.

View on HN

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

Oh and of course SuperCollider.

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)

They don't use python or similar languages in their realtime threads, I would wager.

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

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

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.

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

Reply on news.ycombinator.com