Radium

Haven't looked at mac. Probably easiest to switch from JackPilot to qjackctl if doing the same for OSX,.

Any news with Jack murder on osx?

Hi,

I still don't understand why you need this. I understand the argument that it's inconvenient to install jack, especially if you just want to try out the program really quick, and that's why I included an internal version of jack on Windows. However, it's quite a bit of work to include an internal version of jack, and it doesn't seem worth the time to do the same on OSX.

Also, it's not really a lot work to install jack. It probably takes more time to register on this forum and post messages here, so please let me know why you think this is important.

ffx wrote: ↑13 Dec 2017 11:40 Maybe with kind of jack->coreaudio wrapper?

Jack already is a coreaudio wrapper since it runs on top of coreaudio. Sorry for asking, but Is there a misconception that jack lowers the performance, or that you get higher CPU usage, or that jack will take up resources when it is not running?

No, using JackServer on macOS just is a workflow mess, that's all. CoreAudio is fine.

Thank you for the answer. So the only problem is that you manually have to start jack first? Personally I think that's a clean design since you set up the audio parameters in a separate process, although I see the inconvenience argument. But there's so much other things that seems more important to fix in Radium than this. It doesn't make sense prioritizing a task that hardly has any impact on usability, plus that it could make Radium less stable by moving parts of the audio code into the same process as the main program.

And there is no jack-to-coreaudio wrapper in c++? Why coreaudio can't run in a separate process, too? Or can't you fully integrate the jackosx server into your app, so it runs invisble for runtime and auto-quits?

ffx wrote: ↑28 Apr 2018 12:46 And there is no jack-to-coreaudio wrapper in c++? Why coreaudio can't run in a separate process, too? Or can't you fully integrate the jackosx server into your app, so it runs invisble for runtime and auto-quits?

It would probably make most sense to offer an alternative library to access coreaudio instead of jack. For instance Portaudio or Juce seems like good alternatives. This might not be so much work either. It might also be possible to integrate jack into a program, but that seems very messy and would probably lead to various problems. However, the problem doesn't seem important enough to spend a lot of time on, at least not right now. I'm not even sure if it can be counted as a problem as jack offers advantages that other libraries don't, for instance sample-accurate synchronization. If you run two instances of radium at the same time, they will both synchronize sample-accurately. Same thing with midi, and for timing in general.

An audio software without coreaudio support on macOS feels like a foreign object.

ffx wrote: ↑28 Apr 2018 13:09 An audio software without coreaudio support on macOS feels like a foreign object.

Most portable audio software probably use a third party library, such as juce or portaudio, to access coreaudio. The only reason you notice this with Radium is that you have to start the Jack server first. This is an implementation detail that the user shouldn't care about. It's also possible to let Radium start the jack server automatically in the background without the user noticing, it's actually the the default behavior of jack, but for various reasons, I think that's a bad solution. Edit: At least I know that automatically starting the jack server is a bad solution on Linux and Windows, but maybe it works better on OSX, which I don't know that well. I'll investigate that a little bit.