okay, so in my pluggo compilation script I have the line...

include "E:/maxmsp/4Front Piano Module.dll"

and, I have "4Front Piano Module.dll" as the argument in a vst~ of the plugin I am trying to build. However, when in loads up, it says, of course...

vst~: can't find plug-in 4Front Piano Module.dll

so, instead, I put the include filepath as the argument and then recompile, and, it works!! but, now I'm stuck keeping the plugin in the same directory for all of time. I want to be able to supply a local filepath instead of an absolute.

Any reason why this is? I know including a .dll works in some cases [like with taptools]... Any thoughts?

include "E:/maxmsp/4Front Piano Module.dll" 

and, I have "4Front Piano Module.dll" as the argument in a vst~ of the plugin I am trying to build.  However, when in loads up, it says, of course...

so, instead, I put the include filepath as the argument and then recompile, and, it works!! but, now I'm stuck keeping the plugin in the same directory for all of time.  I want to be able to supply a local filepath instead of an absolute.

Any reason why this is? I know including a .dll works in some cases [like with taptools]...  Any thoughts?


including-a-plugin-for-vst-from-within-a-pluggo-via-script

> okay, so in my pluggo compilation script I have the line...

> include "E:/maxmsp/4Front Piano Module.dll"

> and, I have "4Front Piano Module.dll" as the argument in a vst~ of 

> the plugin I am trying to build. However, when in loads up, it 

> vst~: can't find plug-in 4Front Piano Module.dll

> so, instead, I put the include filepath as the argument and then 

> recompile, and, it works!! but, now I'm stuck keeping the plugin in 

> the same directory for all of time. I want to be able to supply a 

> Any reason why this is? I know including a .dll works in some cases 

It's not allowed to use the vst~ object inside a plugin. TapTools is 

> okay, so in my pluggo compilation script I have the line...
>
> include "E:/maxmsp/4Front Piano Module.dll"
>
> and, I have "4Front Piano Module.dll" as the argument in a vst~ of  
> the plugin I am trying to build.  However, when in loads up, it  
> says, of course...
>
> vst~: can't find plug-in 4Front Piano Module.dll
>
> so, instead, I put the include filepath as the argument and then  
> recompile, and, it works!! but, now I'm stuck keeping the plugin in  
> the same directory for all of time.  I want to be able to supply a  
> local filepath instead of an absolute.
>
> Any reason why this is? I know including a .dll works in some cases  
> [like with taptools]...  Any thoughts?

It's not allowed to use the vst~ object inside a plugin. TapTools is  
not a plugin, it's a shared library.

EJ, your syntax is kind of confusing. I can use vst~ within a plugin, I just have to supply absolute filepaths. I have successfully loaded the plugin 4front piano module from within the pluggo I had created. So, I think you are mistaken about that.

EJ, your syntax is kind of confusing.  I can use vst~ within a plugin, I just have to supply absolute filepaths.  I have successfully loaded the plugin 4front piano module from within the pluggo I had created.  So, I think you are mistaken about that.


> EJ, your syntax is kind of confusing. I can use vst~ within a 

> plugin, I just have to supply absolute filepaths. I have 

> successfully loaded the plugin 4front piano module from within the 

> pluggo I had created. So, I think you are mistaken about that.

t=msg&goto=97046&rid=0&S=fd7f93021165589099bf9998d9da53ee&srch=vst 

using a vst~ object in a plugin is not allowed. It might work if you 

use the plugin in Max though, but just because Max is not a simple host.

On the absolute path question, can you post the part of the patch 

which does that? This might help to figure out what is (not) going on.

> EJ, your syntax is kind of confusing.  I can use vst~ within a  
> plugin, I just have to supply absolute filepaths.  I have  
> successfully loaded the plugin 4front piano module from within the  
> pluggo I had created.  So, I think you are mistaken about that.

https://cycling74.com/forums/index.php? 
t=msg&goto=97046&rid=0&S=fd7f93021165589099bf9998d9da53ee&srch=vst 
+inside+plugin#msg_97046

using a vst~ object in a plugin is not allowed. It might work if you  
use the plugin in Max though, but just because Max is not a simple host.

On the absolute path question, can you post the part of the patch  
which does that? This might help to figure out what is (not) going on.

dude, i have a plugin loaded inside of a pluggo residing within Cubase right now, as we speak, and it works fine. If you mean accessing the GUI, then yeah, you can't do that. But you can defintely use plugins within plugins.

dude, i have a plugin loaded inside of a pluggo residing within Cubase right now, as we speak, and it works fine. If you mean accessing the GUI, then yeah, you can't do that.  But you can defintely use plugins within plugins.


> dude, i have a plugin loaded inside of a pluggo residing within 

> Cubase right now, as we speak, and it works fine. If you mean 

> accessing the GUI, then yeah, you can't do that. But you can 

You're a lucky man ;-) Anyway, do you still have a problem with 

> dude, i have a plugin loaded inside of a pluggo residing within  
> Cubase right now, as we speak, and it works fine. If you mean  
> accessing the GUI, then yeah, you can't do that.  But you can  
> defintely use plugins within plugins.

You're a lucky man ;-) Anyway, do you still have a problem with  
absolute path?

absoulte path isn't the problem at all from inside a plugin.

what i want todo is include a .dll in the build script so I can invoke the plugin via a local path. essentially, i want to include the plugin in the build of the pluggo and invoke it with just the argument "4front piano module" in vst~....

what i want todo is include a .dll in the build script so I can invoke the plugin via a local path.  essentially, i want to include the plugin in the build of the pluggo and invoke it with just the argument "4front piano module" in vst~....

If I include TEST.txt in the build script, and have a coll with an argument TEST.txt, it'll read it without any further filepath requirements. "coll TEST.txt" will function correctly.

now, if I include TEST.dll, and put that as the argument for vst~, it'll say vst is not found.

All I'm asking for here is some consistent behavior. The only way, that I know of to get the plugin TEST.dll to load is to put the fullpath, in quotes if necessary, as the argument to vst~. then that vst will load correctly inside the pluggo.

All I'm asking for here is some consistent behavior.  The only way, that I know of to get the plugin TEST.dll to load is to put the fullpath, in quotes if necessary, as the argument to vst~.  then that vst will load correctly inside the pluggo.

do i make sense yet? =)
thanks for your help/interest,
jamez


> now, if I include TEST.dll, and put that as the argument for vst~,

> All I'm asking for here is some consistent behavior. The only way,

> that I know of to get the plugin TEST.dll to load is to put the

> fullpath, in quotes if necessary, as the argument to vst~. then that

> vst will load correctly inside the pluggo.

You might be able to construct the full path out of a local one:

send the path message to thispatcher and then add the part where you 

placed the dll. That's what I would try. Don't know if this will create 

problems on Windows, as I am a notorious mac user...

jamez schrieb:
> now, if I include TEST.dll, and put that as the argument for vst~,
> it'll say vst is not found.
>
> All I'm asking for here is some consistent behavior.  The only way,
> that I know of to get the plugin TEST.dll to load is to put the
> fullpath, in quotes if necessary, as the argument to vst~.  then that
> vst will load correctly inside the pluggo.

You might be able to construct the full path out of a local one:
send the path message to thispatcher and then add the part where you 
placed the dll. That's what I would try. Don't know if this will create 
problems on Windows, as I am a notorious mac user...

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


Quote: jamez wrote on Tue, 27 March 2007 03:16

----------------------------------------------------

> dude, i have a plugin loaded inside of a pluggo residing within Cubase right now, as we speak, and it works fine. If you mean accessing the GUI, then yeah, you can't do that. But you can defintely use plugins within plugins. 

first of all, he is not your dude, he is my dude.

that some freaks (like you or me) abuse vst~ to sucessfully 

host VSTs inside pluggos inside cubase does not mean that 

this is legal accoring to the zicarelli law.

tip: try to host 4 northpoles inside 4 vst~s inside poly~s

in a pluggo in cubase and see how nicely it can chrash your system.

with onle one VST it mostly works (but shhht about its illegal)

Quote: jamez wrote on Tue, 27 March 2007 03:16
----------------------------------------------------
> dude, i have a plugin loaded inside of a pluggo residing within Cubase right now, as we speak, and it works fine. If you mean accessing the GUI, then yeah, you can't do that.  But you can defintely use plugins within plugins. 
----------------------------------------------------

that some freaks (like you or me) abuse vst~ to sucessfully 
host VSTs inside pluggos inside cubase does not mean that 
this is legal accoring to the zicarelli law.

tip: try to host 4 northpoles inside 4 vst~s inside poly~s
in a pluggo in cubase and see how nicely it can chrash your system.

path to thispatcher doesn't work inside pluggos...,nothing comes out the right outlet =( shucks. it'd be so leet if this worked.

"first of all, he is not your dude, he is my dude."

I guess my southern californian-ness is showing =(

path to thispatcher doesn't work inside pluggos...,nothing comes out the right outlet =( shucks.  it'd be so leet if this worked.

"first of all, he is not your dude, he is my dude."
-Roman

I guess my southern californian-ness is showing =(


Quote: jamez wrote on Fri, 30 March 2007 21:00

> path to thispatcher doesn't work inside pluggos...,nothing comes out the right outlet =( shucks. it'd be so leet if this worked.

> "first of all, he is not your dude, he is my dude."

> I guess my southern californian-ness is showing =(

thats true about thispatcher and has its reaon in the nature 

of plug-ins. but i am not able to explain it or i would lie.

have you tried to show your plug-in only the path to the 

folder where ALL VSTs are (and it builds the rest of the 

full path including the filename on its own?)

maybe by drag and drop or so (drag one VST one time into

your patch, after that the pluggo knows the path to the folder

where another VST is also waiting for beeing loaded?)

Quote: jamez wrote on Fri, 30 March 2007 21:00
----------------------------------------------------
> path to thispatcher doesn't work inside pluggos...,nothing comes out the right outlet =( shucks.  it'd be so leet if this worked.
>
> "first of all, he is not your dude, he is my dude."
> -Roman
>
> I guess my southern californian-ness is showing =(
----------------------------------------------------

thats true about thispatcher and has its reaon in the nature 
of plug-ins. but i am not able to explain it or i would lie.

have you tried to show your plug-in only the path to the 
folder where ALL VSTs are (and it builds the rest of the 
full path including the filename on its own?)

maybe by drag and drop or so (drag one VST one time into
your patch, after that the pluggo knows the path to the folder
where another VST is also waiting for beeing loaded?)

including a plugin for vst~ from within a pluggo via script