Korg Trinity - Saving user presets, why so cumbersome?

[rafa1981]

I agree that it's nice.

I think there are many plugins that have a self-hosting wrapper. Korg uses the Juce host, which is just adding a flag to the CMake build. A thin host (not a DAW) might achieve the same if it's Windows providing thst type of scheduling, so probably you can do what you do with any plugin. Worth looking.

I don't know about this Windows infrastructure you named, but are you saying that the audio thread (not the app, which also includes the UI thread) will get exclusive access to a core as in a realtime system?

Still, providing an exe, while nice doesn't contradict not having UI insanity points. Like you I own and like what Korg does, but the UI experience is still early 2000-2010's on many products.

[rafa1981]

Duplicate. Removed.

[IvyBirds]

I don't know about this Windows infrastructure you named, but are you saying that the audio thread (not the app, which also includes the UI thread) will get exclusive access to a core as in a realtime system?

If you run stand alone synth applications in Windows 11 they operate as independent processes (executables) managed by the Windows operating system scheduler, which determines how to distribute the load across available cores. It will almost always just assign them individually to unused cores unless you don't have any available unused cores then it will try to balance it. This also assumes you have an efficient system that is optimized without a lot of processes running.

This is in contrast to running them in a DAW where the DAW is trying to manage core allocation at the same time that Windows is which can cause overload on a single core and the resulting pops and clicks in the audio

So does Windows 11 lock down a core for the exclusive use of your synth no. However the system will pretty always just give each one its own core unless some other cute management scheme makes sense based on what you are running

In the real world this allows you to simply load up some stand alone plugins, and assign them to different MIDI channels. Windows will manage them efficiently by placing them on their own core

The end result is you can load up multiple Korg plugins in stand alone mode loaded with different sounds on different channels. Then just play and switch between them by changing the MIDI channels of your controller. Also handy for splits

[rafa1981]

...

I think that you have it wrong, at least partially. I'm no expert in the Windows scheduling algorithm but I will mark what seems wrong to me of your explanation.

The operative system scheduler doesn't schedule processes, but threads. The threads inherit the priorities from its parent process if the process doesn't configure them.

There is no way for a DAW to interfere with the scheduler in the way you describe. The DAW can only call APIs for setting thread priorities and possibly pin threads to cores. That's it. It will also do what you want of doing a distribution by core for each audio channel.

A bad DAW could probably make the OS scheduler take bad decisions, but then it would be a bad DAW. It will definitely not be calling OS functions during playback, as syscalls are expensive. A daw most likely will be setting up its audio threads at startup and that's it.

An OS scheduler doesn't automatically distribute 1 process per core, as CPU is not the only thing they try to optimize for. They also try to optimize for no cache misses, which means sometimes using less cores. Probably energy usage too, but that might be change by the power profile. All this also depends on the thread priority configuration.

I would argue that a good DAW will setup as many threads as cores there are and pin the audio threads to a CPU, so probably the behavior you are looking for is more likely to happen inside a DAW that outside.

To complicate things more, a DAW can also run plugins as processes. Single plugins can have multiple audio threads (that's why CLAP added APIs for thread pools, so thread-greedy are less likely to cause dropouts), etc.

With all that I'm not saying that if you have some empirical observations about what happens running inside DAW X or standalone wrong, only that the causes might not be what you think.

[IvyBirds]

...

I think that you have it wrong, at least partially. I'm no expert in the Windows scheduling algorithm but I will mark what seems wrong to me of your explanation.

The operative system scheduler doesn't schedule processes, but threads. The threads inherit the priorities from its parent process if the process doesn't configure them.

There is no way for a DAW to interfere with the scheduler in the way you describe. The DAW can only call APIs for setting thread priorities and possibly pin threads to cores. That's it. It will also do what you want of doing a distribution by core for each audio channel.

A bad DAW could probably make the OS scheduler take bad decisions, but then it would be a bad DAW. It will definitely not be calling OS functions during playback, as syscalls are expensive. A daw most likely will be setting up its audio threads at startup and that's it.

An OS scheduler doesn't automatically distribute 1 process per core, as CPU is not the only thing they try to optimize for. They also try to optimize for no cache misses, which means sometimes using less cores. Probably energy usage too, but that might be change by the power profile. All this also depends on the thread priority configuration.

I would argue that a good DAW will setup as many threads as cores there are and pin the audio threads to a CPU, so probably the behavior you are looking for is more likely to happen inside a DAW that outside.

To complicate things more, a DAW can also run plugins as processes. Single plugins can have multiple audio threads (that's why CLAP added APIs for thread pools, so thread-greedy are less likely to cause dropouts), etc.

With all that I'm not saying that if you have some empirical observations about what happens running inside DAW X or standalone wrong, only that the causes might not be what you think.

Awesome let's do KVR and argue the hypothetical and semantics instead of real world experience and observations

All I know is that when I load up a few stand alone software synths in the real world they can all share the same MIDI port now and Windows 11 will put each of them on it's own core, and my CPU doesn't have the overhead of a DAW who is also trying to manage CPU resource allocations

The end result is better performance of the Synths on my laptop, which means a better performance by me playing those Synths at the gig

As riveting as arguing about how the sausage is actual made might be, the fact is the sausage is being made and it's good sausage, don't believe me? Try it yourself, get a Windows 11 computer and use a utility that allows you to see which cores are being used, then load up a stand alone synth and see what happens to your cores, then load up another one, and another

[xx JPRacer xx]

He's not trying to be an ass, just to explain how things really work. I think this is clear:

With all that I'm not saying that if you have some empirical observations about what happens running inside DAW X or standalone wrong, only that the causes might not be what you think.