Rack v1 builds with improvements

oh, for sure it makes sense to try it. I didn’t mean to imply you should rush out and buy a new computer. :wink:

God, I would if I could. This thing is holding me back!

1 Like

Interesting. I asked because, at least for me, the realtime option on Linux is dangerously broken and has caused whole system lockups and data corruption of some vcv project files.

I hate spending money on computers. I usually get one every 10 years. last year was my lucky year.

Just tried. All is really snappier. The module browser. Wow. Thanks so much.

@fstop - you may try to lower the sampling rate of the engine by hand (as via menu you can only go down to 44100) in the settings-v1.json file to 32000 or 22050 - this lowers the cpu usage quite a bit and makes more modules possible on low end hardware if you do not have any other option

good luck and best wishes - hexdump

2 Likes

This was the thought once Rack v1 first came out. I don’t doubt it’s true, as I have done things like place my laptop on a fan cooled stand and they have helped. This build seems to help an order of magnitude more to me though, but I probably should not use precise language as I have zero data to back that up.

Thanks for the info! Sounds very interesting, I will try it soon… but currently I’m not maintaining the arm test build, because of the low response…

1 Like

I would love to try your ARM test build, if you have a compiled version?

FWIW i think the low response might be cause there is no straight forward methode yet for trying the build, and it involves some steps going through hoops to set it up, is that correct?

1 Like

I believe it.on current MacBooks they say that powering it through the left side heat up worse than the right side! Don’t know if it’s true, but I use the right side at work (I don’t have a Mac at home).

You’re right, there are some drawbacks compared to a translated Rosetta version of Rack; first of all you have to recompile all plugins and bundle it with the binary and the other big problem is, that on macOS app’s have to be singed in order to run, else you get a message that the application is corrupted and you have to reset some gatekeeper flag by hacking commands on the terminal, which is a nogo for the most user. Anybody know how to sign an app? Didn’t figure it out and the Apple support pages are not clear to me… :wink:

1 Like

Yeah, it’s a pretty huge pain, I just went through that process with some of my plugins. The main blocker is that you need an “Apple Developer Account” which costs money. I’d be happy to donate my developer account credentials to this cause, but that’s probably something we should discuss in a private message.

From there, I was able to make signed builds by changing some settings in my CMake configuration. If you’re using the standard Rack Makefile setup I think you would just have to run an extra command or two after building. I have some decent guesses as to what those commands would be.

Anyway, feel free to ping me if you’d like to chat about it more.

2 Likes

T hat sounds about right. also, aren’t apps signed with a developer account “different” that ones signed “for real”? I’m not sure about this, but maybe the mac security settings need to be different to all running dev signed? Or I could be totally wrong about this…

Have you spoken to Andrew Belt about these changes?

I didn’t know you could lower it in the json. Thanks.

this version is performing great on my machine. my eGPU fan is barely noticeable and the eGPU itself (which i bought due to heat issues) isnt even warm. with the official build the eGPU would get pretty hot and the fan would immediately kick on when opening the module browser. kind of miss the port lights but the macOS problems seem to have been vastly improved with this. thanks so much for the effort.

3 Likes

Nice work! I’m typing this message, and browsing the internet, while Rack is playing in the background. I wouldn’t have been able to do this without audio hiccups before.

3 Likes

Here is bugreport on GitHub about macOS fix.

2 Likes

Thanks Dmitry

For reference, here’s Andrew’s answer:

Rack v2 doesn’t use an engine thread at all. All engine processing is done on the audio thread which is realtime by default. It works better because no thread communication is needed between the audio drivers and graph processing of modules.

I hope it can be interpreted as “in V2 there will be better engine performance and realtime is default”. I’m not knowledgable enough, but I wonder if this means that processing a patch will abandon the multithreaded approach (like Apache webserver) and instead operate on a tight loop in one thread (like Nginx webserver, node.js) at max. speed and priority. Someone with knowledge of the Rack engine help me out here…

I don’t have insights in Rack v2 but this is my interpretation:
In Rack v1 there is a engine thread which “drives” the whole thing, coordinating all dsp-threads for processing the dsp of the modules. There is also a thread in the audio module which handles the audio driver for the selected output and input device. Obviously the engine thread and the audio module thread must work tightly together because of the block size and buffering. This is also the reason why multiple audio modules do not work in Rack v1.
In Rack v2 one of the audio modules is selected as “master module” which takes the role of the engine thread driving the dsp-processing. The dsp should be done by multiple threads like in v1.

2 Likes