Max, VSTs, and multi-threading
I’ve written a Max program that hosts four VSTs. It eats about 50% of the CPU on my year-old Macbook Pro. I own Native Instruments’ Kore, which can host VSTs, but never use it. Should I? Specifically, is it the case that a Max patcher cannot use both processors at the same time, whereas Kore can?
On the Reaktor forum I just learned that Kore doesn’t muiltithread either.
Anybody know about CPU-friendly multi-threaded VST host for Mac OS? Bidule claims to be, but according to a Bidule forum thread I read it’s not really there. I found a few others, but they’re only for Windows (Cantabile and Console).
Firstly let’s assume your VSTs are running in parallel, not in series (otherwise you can’t multithread them).
Secondly, I’m assuming you are running max 5 (some people out there are not).
Create a poly~ that contains the vst~ object with 4 instances – sort the correct I/O. Turn parallel on (see the poly~ help file). You may need to restart audio to see the effect of this. Load each VST in a different instance of the poly~. That should do you.
my experience is that if you want to take advantage of multithreading poly’s, you should put as much as you can into 1 single poly with multiple voices.
it is possible to make a poly~ where all the voices are routed in serie with sends and receives (I got it to work) so that you can improve the performance of vsts running in series. However this routing might be unstable, I’m not sure yet (we first need to sort out other more general poly problems)
>it is possible to make a poly~ where all the voices are routed in serie with sends and receives (I got it to work) so that you can improve the performance of vsts running in series. However this routing might be unstable, I’m not sure yet (we first need to sort out other more general poly problems)
i think using send~ and receive~ or send and receive for audio in and out of a poly voice (or between voices) is not to be recommended, especially with multithreading. JKC told me recently that even without multithreading, you can incur a delay of up to 16384 samples. I think send~ and receive~ within a poly~ voice are OK though
@Timo Rozendal- That may well work, but if so it WILL incur latency. Whether or not that is an issue for you or not is another matter. I would also be worried about using that technique in a multi-threading situation – but that is because without knowing more it’s hard to know whether or not this is reliable – the necessary info however, would require either seeing the source code, or the advice of someone on the c74 team who can look at the source.
Sorry to bump an old thread like this, but trying to wrap my head around this.
The wording in the help/reference for poly/parallel is not super clear.
So is it beneficial to run vst instruments inside a poly with parallel turned on? In my patch I have a vst with kontakt loaded with a large sample library. At the moment this is just sitting in my patch willy nilly. I notice kontakt tends to choke with higher voice counts (more than it does in logic for example). Will running this vst in its own thread (parallel mode turned on) alleviate that? Since the vst is running as an instrument, no audio is going into it, so if my understanding is correct that should remove the potential latency from audio talking between threads.
The help/reference files don’t mention anything about latency and are not clear about any overhead that comes from doing this.
Is parallel useful for single heavy vsts? Is it useful for signal processing vsts (series)? Is it useful for multi-intance polys that don’t use a ton of cpu on their own (ie 16 instances of a 10 object synth).
Gonna test this out, but not exactly sure what I should be looking for as I’m guessing max/activity monitor will register the exact amount of activity.
Is there a more objective way to test the effectiveness of a single heavy vst wrapped in a threaded poly than by "feel"?