Hey folks, I’m looking at making a stand alone audio app, as opposed to plugin, and am thinking of Juce as the main framework. I’m not sure what to do about audio output though, can anyone who has used multiple options comment? I’m weighing the alternatives of
Juce all the way
Juce with RtAudio
Juce with Portaudio
I plan to mostly use it with Jack, and clocking will be very important. I’m probably also going to use some kind of signal library as I did a lot of csound so am comfortable with that style of dsp coding. Probably I’ll use either the Perry Cook Synthesis Toolkit, or the Create Signal Library, or maybe even embed Csound5.
Any comments on platform choices and audio layer choices would be appreciated!
thanks
Iain
I can’t really think why anyone would use juce with another i/o library… I’m sure the juce classes cover all the same devices and have equally good performance, so why give yourself the headache of trying to mix the two things together?
Mostly I was thinking of it because of the examples and tutorials I’ve found for both, and I don’t really know enough about the audio layers to know whether they will all be the same for my purposes. Sounds like CSL moved to a pure Juce setup though so I guess it’s a strong possibility I’ll do the same.
One huge problem with Juce audio for consumer apps is that it only supports when samplerate match on input and output…
Portaudio does not have that limitation.
[quote=“iainduncan”]Can anyone comment on hotplugged device detection? And does JUCE support multiple-API at once for audio?
thanks
iain[/quote]
The newest versions provide a callback when the device list changes. And yes, of course you can use whatever device types you like simultaneously, as long as the drivers support that.
[quote=“OBO”]One huge problem with Juce audio for consumer apps is that it only supports when samplerate match on input and output…
Portaudio does not have that limitation.[/quote]
Not true.
If you ask juce to open a single device with both input and output channels, it’ll attempt to do that, and yes, the device would have to have matching rates for that to work, because it gives you one callback containing both input and output data.
But if you don’t mind having separate input and output devices, then you could just open an AudioIODevice for input-only, and another one for output-only, and obviously they could each run at different rates. You’d have two different callbacks of course, but that’s inevitable since they’re not synced together.
