TranscendingMusic wrote:ALSO, sorry if I missed it but java which Sonar edition are you running?
Running the latest... Sonar Platinum x64. However, I don't have any of the extras installed. No Cakewalk instruments, no plugins from Cakewalk except the couple of Engineering FX I use for utility. So it's just Sonar and the Engineerig FX Suite. Nothing else Cakewalk is installed.
cool thanks...I haven't updated yet, but always curious as to others' experience with it.
Noel @ Cakewalk seems to have said pretty much the same as I posted above... that plugin manufacturers implementing their own control of multi-threading would quickly turn into a mess. The DAW should be handling the multi-threading. He seems to have thought about and discussed the issue with Aleksy @ Voxengo in the past, though. Although he doesn't recall being involved with this issue by anyone from Acustica. He seems willing to talk with someone at Acustica, but doesn't know who the person to contact regarding the issue of plugin multi-threading would be.
See above link to Sonar thread.
no there is not a rule. All hosts are different You can disable multithreading in nebula, threads to zero
I have this server version of 1.3.903 working pretty well (knock wood) with Sonar now.
However, it was through experimentation, and is running rather unconventionally... as in I think differently than intended. So any change in how Acustica implements this Server edition, and how the OS changes from Win7 X64 to Win8 and Win10 may break it.
1.3.903 definitely hardly worked at all just running the server version locally, as intended.
However, I've played around with Win7 x64 processor affinity and priority settings with another application, and wondered if it wouldn't help in this situation.
So what I ended up doing is... I run the standalone server locally. I start it up with a shortcut that runs it with Admin rights, and sets processor affinity and priority.
What you do is enter the shortcut's Properties|Target field with the line...
What this does is set a switch for the Standalone Nebula server to only run on the last 4 cores (or 8 threads) of my 6 core X99 processor via the affinity switch set to the hex number FF0. This appears to leave the first 4 threads free from processing Nebula, and let Sonar do its thing. In case you're not familiar, the hex number is derived from the binary switches set to "on" for each of the 12 threads. In this case, the binary to only run on the last 8 threads is 1111 1111 0000... converts to hex FF0. Then the switch line AboveNormal sets the priority just above Normal and just below High.
Then enter the lines for port 6000 (default) in your Nebula plugin's XML, with the address as just default "." (a period). This tells your Nebula plugin to run via the local Standalone server.
This works like a charm so far. I can do more with this than I can with the 1.3.846 Pro version.
It hasn't, however, allowed me to run any lower DSP Buffer. I still have to set the Nebula plugin's DSP Buffer to 2048, which is twice that of my FF800 interface latency. But that's what I was doing before, so it works fine for me.
I'm able to run, like, 14 or 15 fairly intense Nebula plugins in a project, including one VNXT reverb and one TankVerb, each with a full 7 or 8 second tail, along with tons of algo plugs.
I don't know if this is as good as it should run or not. I do know it's running rather smoothly, and a little higher headroom than I was getting with the 1.3.846 Pro version before. And definitely makes 1.3.903 run fairly well with Sonar now, where before, 1.3.903 wouldn't play a third of the way through a 6 minute project without dropping Sonar's audio engine (if it played at all).
I'm rather happy with this right now, if it keeps working.
If Acustica wasn't aware of running the standalone Server version locally in this way before, perhaps you might look into optimizing the Server version to run in this manner.
I'm fully aware, however, that if this unintended method of running the local Server is not acknowledged... it very well may be broken with the next update.
yes because sonar cannot handle nebula threads now, because nebula is completely apart I think there is something wrong in sonar, though. There should be an option for not changing affinity threads for a specific plugin
giancarlo wrote:yes because sonar cannot handle nebula threads now, because nebula is completely apart I think there is something wrong in sonar, though. There should be an option for not changing affinity threads for a specific plugin
G has communication with Noel from Cakewalk started yet?