VST preset change for AU

Is there nobody who uses vst as an audio unit plug in who could say why I do not get a preset change sending a number from a message box?
I use an OrangeVocoder which has 60 presets. In the prvious version all presets got listed in an ubu menu. This is now been changed, but I can not change presets anymore. Please tell me what is wrong.

Hey Hans,

Does it work if the plugin editing window is open? I've been struggling with preset recall for two specific VSTis recently, and one peculiarity of both of them is that they won't respond to programme change messages unless their interface windows are open (they don't need to be front-most though).

Hi David,

I am glad there is someone!!

Under Max5 there was a ubu menu which loaded all the presets. after they had been loaded you coud just use a message box with a number inside, press it and the preset would change! When I load the Orange Vocoder under the Max help for VST, I can set a number box and connect it to the first input on the left, but nothing changes when I send the number. There is no other indication on what else to do to change presets. How does it work now? We have to ask Timothy!

I think you may be right there.

I mentioned this problem to the plugin developer and he told me that their plugins use 2 different methods of recalling presets depending on whether the edit window is open or not (I can't say more than that as this is now totally out of my area of expertise. I'll paste his reply below in case it's in any way enlightening). Which is why I suggested you try recalling presets with the interface open. But if that still doesn't work, then I'm afraid I'm flummoxed. However, recalling presets with the edit window closed did work for me in max5, so _something_ has changed.

I wish the vst~ object worked just like a vst loaded into a sequencer channel (ie it stored and managed the various states of the plugin). Maybe it does, but it doesn't do as much, as easily. Maybe there's a reason...

Here's that reply.

About the program change not taking place, well I need to become technically here, can be if the host does not supply an "idle" call, that is, when nothing else is to do the plugin gets time to update itself (e.g. in responce to a program change request). However, I never heard of any host not doing so. If the GUI is open we have an alternative way of processing the program change. However, if we neither have our GUI being active, not getting any time to process ... we're lost (as I said, never had that case so far).

Here's partial solution in the patch below. Couple of problems- the plugins menu does not update to reflect the new patch selected from the Max window, although you can see the parameters change in the plugin window. Secondly not all the presets in the plugin menu respond to patch change or show up in the presetnames dump, such as the Jingle preset.

Hi Rick,
this is a work around which unfortunately does not help me, because I want to use an OHM64, as a controller. The OHM has plenty of buttons, which I want to assign to presets. I tried to send a number with a message box to the object, but it does not change anything. As you said the plug in does not write the new preset in the window. Thanks for the patch. We might have to ring the bell at Timothy's door.....

Cheers

You know you can sent a number to the umenu right?

Thanks Rick!! It would do the job for a start. I wonder if we get some feedback from cycling on this issue.
Cheers Rick, great.

Hi Rick,
I trying to control a parameter which is chosen by the umenu, but I do not know what to do to address it? Any idea how to control a parameter?