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.

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.

It's a matter of event priorities, explained in this article

https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue/

Thanks --- that's very helpful.

So, I seem to have pretty dependable solution now, using deferlow. However, in the context of the scheduling article above, I still don't quite understand what's going on.

First of all, I'm not using overdrive at this time so (according to the article, there should only be one thread). So that doesn't explain how a call to pcontrol could return immediately unless the pcontrol call is using 'post' rather than 'send' to the OS in which case it's not obvious why deferlow will always work as one doesn't know when new Max events will be inserted into the Max thread as a consequence of the pcontrol call.

It also doesn't explain why opening a patcher with a vst through pcontrol requires the ezdac to be restarted in the first place.

Any more insights? I realize I seem to have a working solution (at least on this particular computer) but it's still unclear to me how much of this is timing dependent and could break once other people try to use it on computers with different speeds.

"It also doesn't explain why opening a patcher with a vst through pcontrol requires the ezdac to be restarted in the first place."

This looks like a bug. Maybe you can isolate and demonstrate the issue with a small patch.

Yep --- I hacked a quick small test, and it fails precisely as described. Attached is an archive with the two patchers.

To reproduce the problem:

(I'm assuming that anyone trying this will edit the audio output and MIDI devices and VSTs in these patchers to match their own environments)

1) Open the StandaloneAudioOutputDevice and leave it open. Note the "load StandaloneVSTTest" piece on the bottom left but don't touch it yet.

2) Open the StandaloneVSTTest directly from the finder. If you play keys on your keyboard, you should hear basic sound. If you close this and open it a few times, it should work perfectly well each time.

3) Close the StandaloneVSTTest patcher. Now, click on the "load StandaloneVSTTest" message in the other patcher. The StandaloneVSTTest will open but you won't hear anything when you play keys. Now turn the DSP processing off and on again (either from the DSP Status object or just by clicking the "Manual restart" [bang] and everything will work fine.

I'd be very interested to know if anyone else can reproduce this issue

Did anyone try to reproduce this issue?

I can verify. This should be fixed in the next release.

Thank you.