Trond Lossius

I have a small request concerning the vst~ object: If the user change 

preset program from the editing window, would it be possible to get a 

notification from an outlet that the program was changed as well as the 

I have just made a Jamoam module for hosting vsts. One of the features 

is that it builds a menu of plug-ins based on the content of the vst 

folder, and when a plug-in is loaded it builds another menu for 

programs. This way the plug and program used can be stored as part of 

the general mechanisms for maintaining states in Jamoma (pattrstorage or 

OSC-based cue scripts). This works fine as long as I change the program 

of the plug-in from the built menu of the Jamoma module itself, but if I 

change program in the editing window the module menu gets out of sync.

More info on the module and a screenshot here:

http://www.bek.no/Members/lossius/lostblog/862

I have a small request concerning the vst~ object: If the user change 
preset program from the editing window, would it be possible to get a 
notification from an outlet that the program was changed as well as the 
number of the new program selected?

I have just made a Jamoam module for hosting vsts. One of the features 
is that it builds a menu of plug-ins based on the content of the vst 
folder, and when a plug-in is loaded it builds another menu for 
programs. This way the plug and program used can be stored as part of 
the general mechanisms for maintaining states in Jamoma (pattrstorage or 
OSC-based cue scripts). This works fine as long as I change the program 
of the plug-in from the built menu of the Jamoma module itself, but if I 
change program in the editing window the module menu gets out of sync.

request-concerning-vst

thing to try: hook up print to every non-audio outlet and see if anything comes out when you send a program change [int]... i'm not in front of my max machine right now so i can't test this.

thing to try:  hook up print to every non-audio outlet and see if anything comes out when you send a program change [int]... i'm not in front of my max machine right now so i can't test this.


Thanks for the suggestion, but changes to parameters are not output in 

response to program changes. This is not a problem when I change program 

from Jamoma as I can afterwards poll to get current values for all 

parameters. But when it is changed in the edit interface the module have 

> thing to try: hook up print to every non-audio outlet and see if anything comes out when you send a program change [int]... i'm not in front of my max machine right now so i can't test this.

Thanks for the suggestion, but changes to parameters are not output in 
response to program changes. This is not a problem when I change program 
from Jamoma as I can afterwards poll to get current values for all 
parameters. But when it is changed in the edit interface the module have 
no clue that it happened.

> thing to try:  hook up print to every non-audio outlet and see if anything comes out when you send a program change [int]... i'm not in front of my max machine right now so i can't test this.


Trond, I faced this myself in my VSTi Host app - I never found a way around it.

At 10:40 AM +0200 7/16/07, Trond Lossius wrote:

>I have a small request concerning the vst~ object: If the user 

>change preset program from the editing window, would it be possible 

>to get a notification from an outlet that the program was changed as 

>well as the number of the new program selected?

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 

At 10:40 AM +0200 7/16/07, Trond Lossius wrote:
>Hi,
>
>I have a small request concerning the vst~ object: If the user 
>change preset program from the editing window, would it be possible 
>to get a notification from an outlet that the program was changed as 
>well as the number of the new program selected?

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


i guess the only thing you can currently do is

to ask vst~ to send out the parameters of presets.

when it stops returning anything, there is no 

it should be possible to find the number of built-in 

presets quickly by starting with preset #32 - if #32 

has parameters try #48, if #48 does not have 

parameters request preset #40 next and so on.

when preset #43 returns parameters and #44 not,

i guess the only thing you can currently do is
to ask vst~ to send out the parameters of presets.

when it stops returning anything, there is no 
preset anymore.

it should be possible to find the number of built-in 
presets quickly by starting with preset #32 - if #32 
has parameters try #48, if #48 does not have 
parameters request preset #40 next and so on.

when preset #43 returns parameters and #44 not,
you know the plug-in has 43 presets.

I'm not quite sure how this relates to the original request. Getting the 

number of presets is not a problem, the problem is that if preset is 

changed form the plug-in editor, vst~ gives no notification to the Max 

I guess one could make a hack by getting all parameters at regular 

intervals, compare to the values Max have stored from beforehand, and if 

they differ, compare the set of new values to sets of values for all 

presets retrieved earlier on the way you suggest, but an extra outlet 

> i guess the only thing you can currently do is

> to ask vst~ to send out the parameters of presets.

> when it stops returning anything, there is no 

> it should be possible to find the number of built-in 

> presets quickly by starting with preset #32 - if #32 

> has parameters try #48, if #48 does not have 

> parameters request preset #40 next and so on.

> when preset #43 returns parameters and #44 not,

I'm not quite sure how this relates to the original request. Getting the 
number of presets is not a problem, the problem is that if preset is 
changed form the plug-in editor, vst~ gives no notification to the Max 
patch that something changes.

I guess one could make a hack by getting all parameters at regular 
intervals, compare to the values Max have stored from beforehand, and if 
they differ, compare the set of new values to sets of values for all 
presets retrieved earlier on the way you suggest, but an extra outlet 
sounds a lot simpler, doesn't it?  ;-)

Roman Thilenius wrote:
>
> i guess the only thing you can currently do is
> to ask vst~ to send out the parameters of presets.
>
> when it stops returning anything, there is no 
> preset anymore.
>
> it should be possible to find the number of built-in 
> presets quickly by starting with preset #32 - if #32 
> has parameters try #48, if #48 does not have 
> parameters request preset #40 next and so on.
>
> when preset #43 returns parameters and #44 not,
> you know the plug-in has 43 presets.


> I guess one could make a hack by getting all parameters at regular 

> intervals, compare to the values Max have stored from beforehand, and if 

> they differ, compare the set of new values to sets of values for all 

> presets retrieved earlier on the way you suggest, but an extra outlet 

But this is solely the responsibility of the plug-in creator. There are 

plug-ins which notify and others don't. I came across the same problem, 

and its just a fact that some (including pluggos from cycling) just 

don't send this information out. Polling is bad, but it seems the only 

Trond Lossius schrieb:
> I guess one could make a hack by getting all parameters at regular 
> intervals, compare to the values Max have stored from beforehand, and if 
> they differ, compare the set of new values to sets of values for all 
> presets retrieved earlier on the way you suggest, but an extra outlet 
> sounds a lot simpler, doesn't it?  ;-)

But this is solely the responsibility of the plug-in creator. There are 
plug-ins which notify and others don't. I came across the same problem, 
and its just a fact that some (including pluggos from cycling) just 
don't send this information out. Polling is bad, but it seems the only 
solution....

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


sorry trond i completely misunderstood what you wanted.

stefan is right, changing a preset from a custom GUI is not changing a preset from the host.

you know that you cannot recall a preset in a pluggo from plugconfig? - see, its the same with C++ VST plug-ins, because

you know that you cannot recall a preset in a pluggo from plugconfig? - see, its the same with C++ VST plug-ins, because
"preset" is host slang. ;)

of course that wuld be a request about vst~ object:

that the window has preset selection included, just

of course that wuld be a request about vst~ object:
that the window has preset selection included, just
like cubase or logic have.


Request concerning vst~