Problem getting VST to work (in certain cases)

Some more clues ---- I'm using an ezdac~ for audio output.

Although it continues to show as ON (as I said above),

if I toggle it manually with the DSP Status dialog or by manually sending a 'stop' and 'start' message), audio immediately starts to work again.

However, if I send the 'stop' and 'start' programatically, after sending the 'load' message, it still does not work.

However again, if I insert a [delay 1000] object in between, so that the 'stop' and 'start' get sent after a 1 second delay, they work fine.

So there's some funky asynchronous behavior with pcontrol and the ezdac (or audio processing in general) that requires a reset.

Still looking for insights --- I can certainly workaround this problem now with a [delay] but such things always make me nervous --- who knows how long the delay actually needs to be, etc....race conditions, blah blah blah.

D

I have to say I'm a little discouraged by the lack of responses. Is this really stuff that nobody knows the answer to? Hard to believe.

Can you show us a small example patch which demonstrates what you are trying to do?

-A

Well, here's a stripped down version with most stuff removed to avoid distraction....probably won't actually work but will give the idea of what I'm trying to do.

First I have a patcher called GenericVST that looks something like the following:

Then I can create a patcher that represents a VST with a specfic patch --- that becomes an "instrument". Here's one that would use the ACE vst with a "Strings" sound that is saved in a patcher called "Strings"

Then I can create a top level patch that would contain the patcher called "Strings" and some other patchers that represent inputs from my MIDI keyboards.

So for example, here is a real top level patcher that loads (ultimately) a vst that sounds like a harmonica and it is played from a Yamaha An1X controller.

So here's the problem. If I open the above patcher by double-clicking on the file name, everything works perfectly fine every time. However, if I open the above patch by sending a 'load filename' message to a [pcontrol] then I get no audio. If I subsequently send messages manually to 'stop' then 'start' the DSP processing, it works again. However, if I send those messages as part of a patch, for example, after it returns from the 'plug' message, it does not work unless I add significant delays before the 'stop/start' messages are sent and even then it doesn't always work.

Incidentally, at this point (after a load but with no sound) if I play a few notes on my keyboard and THEN restart the DSP processing, all those notes come out instantly in a burst and then everything works fine until the next time.

Note that there's a description of my overall design in a couple of my blog entries, including lots of pictures so you can get a better idea of what I'm doing.

http://deskew.com/blog/replacing-apple-mainstage-with-a-custom-maxmsp-implementation-part-1.html

Thanks in advance for any suggestions as to what is going wrong here.

David

There seem to be several issues

1) pcontrol seems asynchronous, that is, if I send a message through it, it returns immediately so messages intended to be sent after the patch is loaded are being sent too early

2) the loading of [vst~] seems asynchronous. Again, if I send a 'plug' message to it, it returns immediately.

Any way to detect that a vst has in fact finished loading?

This thread may be helpful

https://cycling74.com/forums/how-to-get-a-bang-when-vst-is-done-loading

Thanks --- I'll try those suggestions --- however, they're still stopgaps because I still don't understand the underlying problem, i.e., why does the DSP stuff have to be restarted when a vst is loaded via pcontrol?

"Any way to detect that a vst has in fact finished loading?"

no, i´d wish.

but what you can do is to call it every 250 ms and ask for the number of
parameters - when there is an answer, its there. ^^

btw, your delay solution is not perfect, you may know that. it is on the one
hand not sure that 1000 ms will always be enough, but on the other hand
you put the loadbang to high priority this way, which could stop working
in certain situations.

Yes, I've already discovered that the delay solution isn't reliable --- but I didn't really expect it to work well, as I indicated in my initial posting.

I am having better luck with the deferlow though I don't quite understand exactly why it helps.

I understand technically what it's supposed to do but since I don't understand why the regular Max "ordering" is not apparently being obeyed, it's a bit murky. Note: I understand things like blocking vs. non-blocking calls and it would seem that the pcontrol system is using "post" rather than "send" messages but I don't understand WHY it was done that way as it completely breaks the Max semantics of right-to-left depth first algorithm.