Any particular reason why the entire juce_linux_Audio.cpp files’ content is wrapped in #if JUCE_BUILD_GUI_CLASSES ? I couldn’t see any GUI related stuff there…?
It probably uses some event-based classes like changelisteners or timers…
Couldn’t find any of those…?
But the other platforms might do…
aaagghhh… those stylish winblows device drivers that doesn’t compile without a static const reference to a HWND 
How would that affect the linux specific platform? :?
Well it wouldn’t affect linux directly, but the main purpose of that #ifdef is to chop out all the stuff you don’t generally need in a command line app.
Seems a bit odd to write a command line app that plays audio though - what’s it for?
well, i’ve thought of it too.
lately i’ve changed my mini mac to behave like a standalone synth, and it have only a command line, no gui or something, but still, you can switch it on, wait for it to boot a minimal gentoo installation, then connect it and let it play sounds through the soundcard via network or via keyboard.
things like receptor or plugzilla are mainly stripped linux versions that runs command line only with audio in a rack based hardware synth.
this is definately i would like to see possible with the linux version of the juce framework. Jost for example, is built with this option in mind, so i’ve separated the gui from the low level audio stuff, and i will put it in my mini mac and use it like a hardware synth when i will go out on stage…
i don’t see why not permit in linux to built sound support without gui stuff, if the other platforms can’t…
[quote=“jules”]Well it wouldn’t affect linux directly, but the main purpose of that #ifdef is to chop out all the stuff you don’t generally need in a command line app.
Seems a bit odd to write a command line app that plays audio though - what’s it for?[/quote]
It’s more like an application where audio is needed, but juce can’t support the GUI. Well, without that #ifdef it seems to work anyway…