vst~ plug-in loaded status
Hello!
Is there any way to trace, if a plug-in has been loaded into vst~ object?
I store all the plug's settings into external .xml, but when sending it to vst~, nothing happens, because plug hasn't been loaded...
Would be appreciate for any help.
proposed workaround: request preset number 1 from the plug-in every 500 ms. when you get an answer, it has finished loading.
p.s. in many situations "plug filename, read something.xml" should work just fine no matter how long the load time is, but it is not safe.
Yeah, that works! Thank you :)
p.s. Hope Max team will add this vst~ feature in one of future updates.
Roman has been round for so long he has forgotten.
This will always work.
I had forgotten this too --- does this work for the 'read' message so you can be informed when the plugin has finished reading (and processing) an fxp file?
in my experience this isnt 100% safe and i am tempted to bet against it works for reaktor, kontakt, or the wizoo players.
the forum software will win, because now there is only one browser (tenfourfox) which it works with. if support for firefox is dropped too now, you get rid of me.
then again, on my outdated hard and sofware there is at least a bug free vst~object to my hands. :)
This one comes up so often.
Here's what's going on.
The deferlow in my patcher example is to ensure that the loading of the plug state happens in the low priority thread in case you are running Max in overdrive. The RH bang from the trigger object initiates the plug load, and because this code is running at low priority the vst~ object only returns after the asynchronous plug loading operation has completed. So the vst~ object returns back to the trigger object, and at that point the trigger object may fire its next bang.
Theoretically this could fail if the plug performed some kind of subsequent state processing on its loaded content, but in my experience plug vendors avoid this sort of thing. I've never seen a problem with Kontakt, for example.If you have a counter example,we're all ears, but there is not much anyone can do about a plug which continues to initialise state after it has told the host it is all done.
If you wish to determine that loading a preset into a plug follows the same rules, you could use the final bang from the trigger object to play a note.
-A
So the vst~ object returns back to the trigger object, and at that point the trigger object may fire its next bang.
Hey Andrew, I'm trying to wrap my brain around that statement. Are you saying that the trigger object waits for each triggered function to complete before it triggers the next outlet? Or, is this a result of the fact that it's attached to a deferlow object? Thanks!
It's basic order of operations.
The deferlow is there to make sure you are not running in the high priority thread, in which case the trigger wouldn't "hang around" for the code to complete
Andrew, I thought I understood all this stuff quite deeply until your last remark about deferlow? I thought that deferlow just makes events get handled on a lower priority queue but all events in a deferlow are still handled in the same order they arrive in that queue.
if two events A and B are sent (A first) to the same queue (high or low priority), isn't it still the case that B will not execute until A has completed. In other words why would the [vst] plug command behave asynchronously in the high priority queue but synchronously not in the low priority queue? Even in overdrive, isn't the call tree still depth first with ordering preserved?
What did I miss?
----
The deferlow is there to make sure you are not running in the high priority thread, in which case the trigger wouldn't "hang around" for the code to complete
Here is a quote from this document.
"Sometimes during the course of a high priority event’s execution, there is a point at which the event attempts to execute a message that is not safe to be performed at high priority, or is a long operation that would affect the scheduler’s timing accuracy. Messages that cause drawing, file i/o, or launch a dialog box are typical examples of things which are not desirable at high priority. All (well-behaved) Max objects that receive messages for these operations at high priority will generate a new low priority event to execute at some time in the future. This is often referred to as deferring execution from the high priority thread (or scheduler), to the low priority thread (or queue)."
So as I understand it, using deferlow is required because messages to vst~ are not safe to be performed at high priority and vst~ is not a "well-behaved" Max object.
If I understand that extract correctly (which I've seen before but forgotten), then it sounds to me that vst IS in fact well-behaved, switching to low priority, and hence the need for deferlow to ensure you're already in low priority to maintain the trigger ordering.
Now I understand (again)
Yes, your explanation makes sense to me.
why would anyone load a vst plug-in in overdrive? :)
You got your [vst~], you got your 'plug' message, you're running in overdrive because that's the only way to get decent response, everything else works fine, it's not immediately obvious that you'll have a problem detecting that a plugin has finished loading.