Forums > MaxMSP

vst~ voodoo

November 7, 2006 | 7:51 am

Hi,

I’m having some problems with vst~ which I thought I had solved a
while ago simply by rebuilding the patch and, thereby changing the
order of the code within the Max file in question. Unfortunately, it
doesn’t do the trick anymore.

Here’s what’s causing my headache:
For a patch of mine I had to build a wrapper around vst~ named
"plugin". I use 6 instances of it in a subpatch named "plugins". Now,
when I create a single instance of the wrapper, I can send out
parameter values out of the 4th outlet just by moving GUI elements in
the vst~ window, but when the instance is inside the plugins patcher,
there is no output until I manually re-instantiate the wrapper. This
behavior seems a bit odd to me.

Any help is appreciated.

Georg



jml
November 8, 2006 | 6:20 am

hi georg,

i can’t reproduce this behavior– what system/vers. are you on?
you’re just wanting to have the output from your plugs w/out having to re-instantiate, correct?

FWIW, you can query the number of params (get -4, and then route -4) and get them with the get (param#) message.

if you’re having load-time issues, maybe throw in the message from outside the patcher so that it gets there after the patcher loads.

hope i’m not regurgitating stuff you already know…
i’ve also included my test

#P window setfont Geneva 9.;
#P window linecount 1;
#P newex 109 62 45 11337737 loadbang;
#P newex 138 207 50 11337737 print vals;
#P message 103 256 37 11337737 get $1;
#P button 73 209 15 0;
#P newex 73 227 40 11337737 uzi;
#P number 36 208 35 9 0 0 0 173 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 103 179 45 11337737 route -4;
#P window setfont Geneva 14.;
#P message 109 96 51 11337742 get -4;
#P window setfont Geneva 9.;
#P message 55 96 25 11337737 plug;
#N vst~ loaduniqueid 0 Chamberverb;
#P newobj 55 141 92 11337737 vst~ Chamberverb;
#P connect 9 0 2 0;
#P fasten 3 0 4 0 108 203 41 203;
#P fasten 3 0 6 0 108 203 78 203;
#P connect 3 0 5 1;
#P connect 3 1 8 0;
#P fasten 7 0 0 0 108 299 21 299 21 130 60 130;
#P connect 5 2 7 0;
#P connect 6 0 5 0;
#P connect 0 3 3 0;
#P connect 2 0 0 0;
#P connect 1 0 0 0;
#P window clipboard copycount 10;

jl


November 8, 2006 | 8:05 am

Hi JL,

Thanks for your help. Unfortunately, I still can’t get vst~ to send
out the parameter values (only the first instance in uber_plug works;
the rest is mute). I use Max 4.6 on a Powerbook 1.25 GHz with Mac OS
X 10.4.8.

Georg

On Nov 8, 2006, at 7:20 AM, jLubow wrote:

> hi georg,
>
> i can’t reproduce this behavior– what system/vers. are you on?
> you’re just wanting to have the output from your plugs w/out having
> to re-instantiate, correct?
>
> FWIW, you can query the number of params (get -4, and then route
> -4) and get them with the get (param#) message.
>
> if you’re having load-time issues, maybe throw in the message from
> outside the patcher so that it gets there after the patcher loads.
>
> hope i’m not regurgitating stuff you already know…
> i’ve also included my test
>
> #P window setfont Geneva 9.;
> #P window linecount 1;
> #P newex 109 62 45 11337737 loadbang;
> #P newex 138 207 50 11337737 print vals;
> #P message 103 256 37 11337737 get $1;
> #P button 73 209 15 0;
> #P newex 73 227 40 11337737 uzi;
> #P number 36 208 35 9 0 0 0 173 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 103 179 45 11337737 route -4;
> #P window setfont Geneva 14.;
> #P message 109 96 51 11337742 get -4;
> #P window setfont Geneva 9.;
> #P message 55 96 25 11337737 plug;
> #N vst~ loaduniqueid 0 Chamberverb;
> #P newobj 55 141 92 11337737 vst~ Chamberverb;
> #P connect 9 0 2 0;
> #P fasten 3 0 4 0 108 203 41 203;
> #P fasten 3 0 6 0 108 203 78 203;
> #P connect 3 0 5 1;
> #P connect 3 1 8 0;
> #P fasten 7 0 0 0 108 299 21 299 21 130 60 130;
> #P connect 5 2 7 0;
> #P connect 6 0 5 0;
> #P connect 0 3 3 0;
> #P connect 2 0 0 0;
> #P connect 1 0 0 0;
> #P window clipboard copycount 10;
>
> jl
>


November 8, 2006 | 9:44 am

I am confused by what you mean….. could you elaborate? I am very "pro" with the vst~ object. I’ve spent months revolving around it.


November 8, 2006 | 11:25 am

Hello,

I had sent some screen dumps before.
Basically, sending parameter values from within the plugin out of the
4th oulet of vst~ stops on my machine after loading several instances
of vst~ at once, either wrapped in an abstraction or not.

After re-instantiating the object(s) by scripting everything is OK
again. I’m resorting to e-instantiating vs~ each time the object
receives a plug message. But that should only be a temporary work
around, don’t you think?

Georg

On Nov 8, 2006, at 10:44 AM, DrSbaitso wrote:

>
> I am confused by what you mean….. could you elaborate? I am very
> "pro" with the vst~ object. I’ve spent months revolving around it.


November 8, 2006 | 11:53 am

sounds like a bug to me, why would you think otherwise?


November 8, 2006 | 6:33 pm

georg, do you have a plug-in name as default in them?

(or do you load fresh plug-in and there is still no
output from parameters.)

i remember similar issues with loading more than 5,6
vst~ AND doing stuff to them (like plug-in preloading)


November 8, 2006 | 6:59 pm

Example patch?


November 8, 2006 | 8:25 pm

Hi Andrew,

Just use the patch that J. Lubow provided today. Try the last
abstraction inside uber_plug on the right: Double-click on test_plug
and load a plugin (it makes no difference whether the vst~ object has
an argument or not). You’ll probably notice that moving a GUI element
will not lead to the expected result. I’m trying this now a MacBook
Pro and I’m having the same problem as on a Powerbook G4.

Best,

Georg

On Nov 8, 2006, at 7:59 PM, Andrew Pask wrote:

>
>
>
> Example patch?


November 8, 2006 | 9:18 pm

huh – ok – it does look like there is some kind of weird issue.

Looks like the get -4 workaround is fine though. Don’t expect this one to get fixed for a *long* time.

Thanks for the report – it has been noted.

-A


November 9, 2006 | 7:36 am

-4 sends out initial values. That’s it. The values won’t be updated
by the GUI elements though.
Does this mean I won’t be able to use my patches for a long time? Or
do I really have to create a new vst~ object each time it receives a
plug message? That would be "vraiment dommage", as the French would say.

Georg

On Nov 8, 2006, at 10:18 PM, Andrew Pask wrote:

>
>
>
> huh – ok – it does look like there is some kind of weird issue.
>
> Looks like the get -4 workaround is fine though. Don’t expect this
> one to get fixed for a *long* time.
>
> Thanks for the report – it has been noted.
>
> -A


November 9, 2006 | 12:58 pm

08/11/06, kl. 21:25 +0100 , skrev Georg Hajdu:

>Just use the patch that J. Lubow provided today. Try the last
>abstraction inside uber_plug on the right: Double-click on test_plug
>and load a plugin (it makes no difference whether the vst~ object has
>an argument or not). You’ll probably notice that moving a GUI element
>will not lead to the expected result. I’m trying this now a MacBook
>Pro and I’m having the same problem as on a Powerbook G4.

I experienced a simular issue about vst~ not sending parameter values
out of the 4th outlet, in patches with a large number of vst~ objects.
One thing I found out was that it only happens if the vst~ objects
doesn’t have an argument (load a plug automatically). So my workaround
was to create a ‘dummy’ pluggo, that does nothing, but contains some
parameters. And load it instantly when the patcher opens [vst~ dummy].
So are you sure it doesn’t make a difference if the vst~ object has an
argument or not. My guess is that if the argument is the name of a
pluggo vst~ that’s in your system, it will also send parameter values
out of the 4th outlet just fine.

Another issue I also had to deal with. Parameter values are not reportet
to the 4th outlet of vst~, if you call a program by a message into the
vst~ inlet, and the vst~ window is not open. If the window is open
values are reportet. More about this issue here: http://
http://www.cycling74.com/forums/index.php?t=
msg&th=21476&start=0&rid=0&S=5f441c1c46322acfac95f9216990b539

/J


November 10, 2006 | 9:54 pm

Hello Jakob,

I just tried that again, but to no avail.

Best,

Georg

On Nov 9, 2006, at 1:58 PM, Jakob Riis wrote:

> My guess is that if the argument is the name of a
> pluggo vst~ that’s in your system, it will also send parameter values
> out of the 4th outlet just fine.


November 11, 2006 | 12:59 am

Hello Georg. Sorry to hear that. My optimism was based on experiences
with four different systems. All of them Powerbooks, Max 4.5.7, OS X 10.4.?
/Jakob

>
>I just tried that again, but to no avail.

>> My guess is that if the argument is the name of a
>> pluggo vst~ that’s in your system, it will also send parameter values
>> out of the 4th outlet just fine.
>


November 13, 2006 | 12:05 am

I tried to bypass my problem by creating a new instance of vst~ each
time a new plugin is chosen. Unfortunately, Max quits on me after
loading a plugin the second time with following crash report:

Thread 0 Crashed:
0 com.cycling74.VstPlugLib 0x372af904 vstplug_outputparam
(_vstplug*, _param*) + 16
1 com.cycling74.VstPlugLib 0x372afa22
vstplug_dopendingparams_mt(_vstplug*) + 48
2 com.cycling74.MaxMSP46 0x00058da1 sched_dequeue + 129
(sched.c:351)
3 com.cycling74.MaxMSP46 0x000262ab plug_preevent + 47
(main.c:926)
4 com.cycling74.MaxAPI 0x0181521a plug_preevent + 30
5 com.apple.HIToolbox 0x91c19c41 TimerVector + 31
6 com.apple.CoreFoundation 0x902a6822 CFRunLoopRunSpecific +
3341
7 com.apple.CoreFoundation 0x902a5b0e CFRunLoopRunInMode + 61
8 com.apple.HIToolbox 0x91be1bef
RunCurrentEventLoopInMode + 285
9 com.apple.HIToolbox 0x91be12fd ReceiveNextEventCommon
+ 385
10 com.apple.HIToolbox 0x91c29c8f _AcquireNextEvent + 58
11 com.apple.HIToolbox 0x91c29ad0
RunApplicationEventLoop + 150
12 com.cycling74.MaxMSP46 0x00026e8a app_run + 52 (main.c:
1458)
13 com.cycling74.MaxMSP46 0×00027134 main + 680 (main.c:415)
14 com.cycling74.MaxMSP46 0×00002436 _start + 228 (crt.c:272)
15 com.cycling74.MaxMSP46 0×00002351 start + 41

Georg

On Nov 11, 2006, at 1:59 AM, Jakob Riis wrote:

> Hello Georg. Sorry to hear that. My optimism was based on experiences
> with four different systems. All of them Powerbooks, Max 4.5.7, OS
> X 10.4.?
> /Jakob
>
>>
>> I just tried that again, but to no avail.
>
>>> My guess is that if the argument is the name of a
>>> pluggo vst~ that’s in your system, it will also send parameter
>>> values
>>> out of the 4th outlet just fine.
>>
>
>


November 13, 2006 | 12:23 am

I case someone wants to reproduce my crash:

max v2;
#N vpatcher 165 382 539 554;
#P button 78 49 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 78 73 56 196617 opendialog;
#P newex 78 97 66 196617 prepend plug;
#N vpatcher 10 59 610 459;
#P window setfont "Sans Serif" 9.;
#P window linecount 0;
#P newex 170 69 59 196617 my-change;
#P objectname prepend[1];
#P outlet 144 205 15 0;
#P objectname outlet5;
#P outlet 131 205 15 0;
#P objectname outlet4;
#P outlet 118 205 15 0;
#P objectname outlet3;
#P outlet 105 205 15 0;
#P objectname outlet2;
#P outlet 92 205 15 0;
#P objectname outlet1;
#P inlet 170 31 15 0;
#P outlet 79 205 15 0;
#P objectname outlet0;
#P newex 170 49 55 196617 route plug;
#P objectname route;
#P newex 79 121 66 196617 prepend plug;
#P objectname prepend;
#P message 200 119 91 196617 script delete vst~;
#P newex 170 91 40 196617 t l b b;
#N thispatcher;
#Q end;
#P newobj 185 235 61 196617 thispatcher;
#P window linecount 4;
#P message 185 155 370 196617 script new vst~ newex 72 137 79 196617
vst~ , script connect prepend 0 vst~ 0 , script connect vst~ 0
outlet0 0 , script connect vst~ 1 outlet1 0 , script connect vst~ 2
outlet2 0 , script connect vst~ 3 outlet3 0 , script connect vst~ 4
outlet4 0 , script connect vst~ 5 outlet5 0 , script connect route
1 vst~ 0;
#P window linecount 1;
#N vst~ loaduniqueid 0;
#P newobj 79 144 79 196617 vst~;
#P objectname vst~;
#P fasten 3 0 5 0 175 114 84 114;
#P connect 5 0 0 0;
#P connect 0 0 7 0;
#P connect 0 1 9 0;
#P connect 0 2 10 0;
#P connect 0 3 11 0;
#P connect 0 4 12 0;
#P connect 0 5 13 0;
#P connect 8 0 6 0;
#P connect 6 0 14 0;
#P connect 14 0 3 0;
#P connect 3 1 1 0;
#P connect 4 0 2 0;
#P connect 1 0 2 0;
#P connect 3 2 4 0;
#P pop;
#P newobj 78 121 79 196617 p my-vst~;
#P comment 97 50 219 196617 Choose 2 different vst plugins. Watch Max
go down.;
#P connect 4 0 3 0;
#P connect 3 0 2 0;
#P connect 2 0 1 0;
#P pop;

Georg

P.S. With this option not working I’m pretty much out of luck what
the querying of parameter values of several vst~s is concerned.

On Nov 11, 2006, at 1:59 AM, Jakob Riis wrote:

> Hello Georg. Sorry to hear that. My optimism was based on experiences
> with four different systems. All of them Powerbooks, Max 4.5.7, OS
> X 10.4.?
> /Jakob
>
>>
>> I just tried that again, but to no avail.
>
>>> My guess is that if the argument is the name of a
>>> pluggo vst~ that’s in your system, it will also send parameter
>>> values
>>> out of the 4th outlet just fine.
>>
>
>


November 13, 2006 | 10:15 am

It also crashes here. MaxMSP 4.5.7, OS X 10.4.8, 1.33 GHz PowerBook G4.

/J

13/11/06, kl. 1:23 +0100 , skrev Georg Hajdu:

>I case someone wants to reproduce my crash:
>
>max v2;
>#N vpatcher 165 382 539 554;
>#P button 78 49 15 0;
>#P window setfont "Sans Serif" 9.;
>#P window linecount 1;
>#P newex 78 73 56 196617 opendialog;
>#P newex 78 97 66 196617 prepend plug;
>#N vpatcher 10 59 610 459;
>#P window setfont "Sans Serif" 9.;
>#P window linecount 0;
>#P newex 170 69 59 196617 my-change;
>#P objectname prepend[1];
>#P outlet 144 205 15 0;
>#P objectname outlet5;
>#P outlet 131 205 15 0;
>#P objectname outlet4;
>#P outlet 118 205 15 0;
>#P objectname outlet3;
>#P outlet 105 205 15 0;
>#P objectname outlet2;
>#P outlet 92 205 15 0;
>#P objectname outlet1;
>#P inlet 170 31 15 0;
>#P outlet 79 205 15 0;
>#P objectname outlet0;
>#P newex 170 49 55 196617 route plug;
>#P objectname route;
>#P newex 79 121 66 196617 prepend plug;
>#P objectname prepend;
>#P message 200 119 91 196617 script delete vst~;
>#P newex 170 91 40 196617 t l b b;
>#N thispatcher;
>#Q end;
>#P newobj 185 235 61 196617 thispatcher;
>#P window linecount 4;
>#P message 185 155 370 196617 script new vst~ newex 72 137 79 196617
>vst~ , script connect prepend 0 vst~ 0 , script connect vst~ 0
>outlet0 0 , script connect vst~ 1 outlet1 0 , script connect vst~ 2
>outlet2 0 , script connect vst~ 3 outlet3 0 , script connect vst~ 4
>outlet4 0 , script connect vst~ 5 outlet5 0 , script connect route
>1 vst~ 0;
>#P window linecount 1;
>#N vst~ loaduniqueid 0;
>#P newobj 79 144 79 196617 vst~;
>#P objectname vst~;
>#P fasten 3 0 5 0 175 114 84 114;
>#P connect 5 0 0 0;
>#P connect 0 0 7 0;
>#P connect 0 1 9 0;
>#P connect 0 2 10 0;
>#P connect 0 3 11 0;
>#P connect 0 4 12 0;
>#P connect 0 5 13 0;
>#P connect 8 0 6 0;
>#P connect 6 0 14 0;
>#P connect 14 0 3 0;
>#P connect 3 1 1 0;
>#P connect 4 0 2 0;
>#P connect 1 0 2 0;
>#P connect 3 2 4 0;
>#P pop;
>#P newobj 78 121 79 196617 p my-vst~;
>#P comment 97 50 219 196617 Choose 2 different vst plugins. Watch Max
>go down.;
>#P connect 4 0 3 0;
>#P connect 3 0 2 0;
>#P connect 2 0 1 0;
>#P pop;
>
>Georg
>
>P.S. With this option not working I’m pretty much out of luck what
>the querying of parameter values of several vst~s is concerned.
>


November 13, 2006 | 3:20 pm

FWIW, I’ve been struggle with a patch with 8 instances of vst~ in today – crashes on loading, loud whines as soon as you turn dac~ on or add new objects, feedback noises where no feedback path should exist, sub-patches behaving strangely – which all seem to have miraculously dissapeared now that I’ve succesfully managed to get the patch loading with a dummy plug to initialise the vst~’s.
I experienced similar problems a while ago, and someone suggested that vst~ can behave strangely if not initialised in this way. Since updating the patch for Intel Mac, I’d forgotten to recompile the dummy plug for UB, so it wasn’t loading.
When this happened before, I spent a long time trying to isolate things so that I could make a proper bug report, but it was so random, I gave up.
Nevertheless, seeing all this weird behaviour again makes me think that all is not well with vst~, particularly in patches that contain several instances. I wish I could be more precise, but initialising by loading a plug definitely seems to work some magic,
cheers
Roger


November 14, 2006 | 10:43 am

Hi Roger,

Thank you for your detailed report. I had already tried various
things (including initializing the object with a plugin name such as
the Pluggo plugin Degrader). Unfortunately, the bug seems to depend
on the patcher architecture; so some patches work, others won’t. Very
disturbing.

Georg

On Nov 13, 2006, at 3:20 PM, roger.carruthers wrote:

>
> FWIW, I’ve been struggle with a patch with 8 instances of vst~ in
> today – crashes on loading, loud whines as soon as you turn dac~ on
> or add new objects, feedback noises where no feedback path should
> exist, sub-patches behaving strangely – which all seem to have
> miraculously dissapeared now that I’ve succesfully managed to get
> the patch loading with a dummy plug to initialise the vst~’s.
> I experienced similar problems a while ago, and someone suggested
> that vst~ can behave strangely if not initialised in this way.
> Since updating the patch for Intel Mac, I’d forgotten to recompile
> the dummy plug for UB, so it wasn’t loading.
> When this happened before, I spent a long time trying to isolate
> things so that I could make a proper bug report, but it was so
> random, I gave up.
> Nevertheless, seeing all this weird behaviour again makes me think
> that all is not well with vst~, particularly in patches that
> contain several instances. I wish I could be more precise, but
> initialising by loading a plug definitely seems to work some magic,
> cheers
> Roger


November 16, 2006 | 7:10 am

Georg Hajdu wrote:
> I had already tried various things (including initializing the
> object with a plugin name such as the Pluggo plugin Degrader).
> Unfortunately, the bug seems to depend on the patcher architecture;
> so some patches work, others won’t. Very disturbing.

I had the same issue some time ago (I reported it, but it didn’t seem to
create too much interest in the debugging department…), loading one of
my self-made pluggos seemed to do the trick. I had also issues with
getting parameters out, I think I finally just recalled them all with
messages (can’t remember the details, would have to dig into it again…)

Stefan


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


Viewing 20 posts - 1 through 20 (of 20 total)