Georg Hajdu

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 

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 

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.

vst-voodoo

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 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?

hope i'm not regurgitating stuff you already know...
i've also included my test

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 

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

> 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 

> 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...

> #P newex 138 207 50 11337737 print vals;

> #P number 36 208 35 9 0 0 0 173 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newobj 55 141 92 11337737 vst~ Chamberverb;

> #P fasten 7 0 0 0 108 299 21 299 21 130 60 130;

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.

> 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
>


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.

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 

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.

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?

>
> 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.


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

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

(or do you load fresh plug-in and there is still no

i remember similar issues with loading more than 5,6

vst~ AND doing stuff to them (like plug-in preloading)

(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)


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.

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

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.

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.

-4 sends out initial values. That's it. The values won't be updated 

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.

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 

> Thanks for the report - it has been noted.

-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.

>
>
>
> 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


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

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: 

msg&th=21476&start=0&rid=0&S=5f441c1c46322acfac95f9216990b539

>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://
www.cycling74.com/forums/index.php?t=
msg&th=21476&start=0&rid=0&S=5f441c1c46322acfac95f9216990b539

I just tried that again, but to no avail.

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

> 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.


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.?

>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

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.
>

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:

0 com.cycling74.VstPlugLib     0x372af904 vstplug_outputparam 

1 com.cycling74.VstPlugLib     0x372afa22 

vstplug_dopendingparams_mt(_vstplug*) + 48

2 com.cycling74.MaxMSP46     0x00058da1 sched_dequeue + 129 

3 com.cycling74.MaxMSP46     0x000262ab plug_preevent + 47 

4 com.cycling74.MaxAPI     0x0181521a plug_preevent + 30

5 com.apple.HIToolbox     0x91c19c41 TimerVector + 31

6 com.apple.CoreFoundation     0x902a6822 CFRunLoopRunSpecific + 

7 com.apple.CoreFoundation     0x902a5b0e CFRunLoopRunInMode + 61

8 com.apple.HIToolbox     0x91be1bef 

9 com.apple.HIToolbox     0x91be12fd ReceiveNextEventCommon 

10 com.apple.HIToolbox     0x91c29c8f _AcquireNextEvent + 58

11 com.apple.HIToolbox     0x91c29ad0 

12 com.cycling74.MaxMSP46     0x00026e8a app_run + 52 (main.c: 

13 com.cycling74.MaxMSP46     0x00027134 main + 680 (main.c:415)

14 com.cycling74.MaxMSP46     0x00002436 _start + 228 (crt.c:272)

15 com.cycling74.MaxMSP46     0x00002351 start + 41

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 

>> 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 

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         	0x00027134 main + 680 (main.c:415)
14  com.cycling74.MaxMSP46         	0x00002436 _start + 228 (crt.c:272)
15  com.cycling74.MaxMSP46         	0x00002351 start + 41

> 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.
>>
>
>


I case someone wants to reproduce my crash:

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.

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.

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

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

>I case someone wants to reproduce my crash:

>#P message 200 119 91 196617 script delete vst~;

>#P newobj 185 235 61 196617 thispatcher;

>#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 

>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.
>


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,

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


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 

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 

> 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,

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.

>
> 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


> 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...)

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


vst~ voodoo