Mattijs

I load a pluggo plugin in a max patch with the vst~ object. This pluggo plugin uses an abstraction with the same name as an abstraction used in the max patch.

At the point where the plugin is loaded into the vst~, max changes the search path for this abstraction to the one that is saved -inside- the pluggo plugin! So now I have two different abstractions with the same name in my patch: the ones loaded before the vst~ and the ones loaded after the vst~.

I load a pluggo plugin in a max patch with the vst~ object. This pluggo plugin uses an abstraction with the same name as an abstraction used in the max patch. 

At the point where the plugin is loaded into the vst~, max changes the search path for this abstraction to the one that is saved -inside- the pluggo plugin! So now I have two different abstractions with the same name in my patch: the ones loaded before the vst~ and the ones loaded after the vst~.


pluggo-vst-and-maxmsp-patch-share-abstraction

is this not fixed in the dot 4 release, since pluggo no longer shares the Cycling74 folder ?

The vst uses my own abstractions, which are not in the cycling74 folder but in the same folder as the vst patch.

I still use 3.5.3 though, so I will get the update and try again.

On Apr 21, 2006, at 9:04 AM, Mattijs Kneppers wrote:

> The vst uses my own abstractions, which are not in the cycling74 

> folder but in the same folder as the vst patch.

> I still use 3.5.3 though, so I will get the update and try again.

If you update then you should make sure that you update Max to 4.5.7 

as well to avoid trouble. And updating is good :-).

Nevertheless, it won't change your particular situation. When you 

are working in Max, it is really doing a lot of stuff under the hood.

For example, when you load an external object for the first time, Max 

loads it into memory. Then every time you use the extern Max calls 

it from memory - not from the hard drive. So if an external gets 

loaded out of a collective first - then that is the version in Max's 

RAM and it will be used rather than some copy floating around in your 

It sounds like something similar is happening with your patch. It is 

different, but hopefully the above will paint enough of story that 

you can figure out that the problem is best resolved by renaming your 

patch, or keeping the versions in sync, or something...

> The vst uses my own abstractions, which are not in the cycling74  
> folder but in the same folder as the vst patch.
>
> I still use 3.5.3 though, so I will get the update and try again.

If you update then you should make sure that you update Max to 4.5.7  
as well to avoid trouble.  And updating is good :-).

Nevertheless, it won't change your particular situation.  When you  
are working in Max, it is really doing a lot of stuff under the hood.

For example, when you load an external object for the first time, Max  
loads it into memory.  Then every time you use the extern Max calls  
it from memory - not from the hard drive.  So if an external gets  
loaded out of a collective first - then that is the version in Max's  
RAM and it will be used rather than some copy floating around in your  
searchpath, until you restart Max.

It sounds like something similar is happening with your patch.  It is  
different, but hopefully the above will paint enough of story that  
you can figure out that the problem is best resolved by renaming your  
patch, or keeping the versions in sync, or something...

So now I know this behaviour is on purpose.

Actually, there should be some huge bunch of documents available (constructed by cycling74) that cover these topics. Something like 'now that you mastered the manual and you believed you could rely on a black-box approach..' or 'stuff you gotta know when your patch exceeds 10,000 lines..' or 'before you start as a full-time max-programmer..' (which is currently my case, which is why I prefer reading a bunch of documents instead of spending another few hours on stuff like 'wtf, I got two different similar abstractions!!'. :)

So now I know this behaviour is on purpose. 

Quote: mattijs@samplemadness.nl wrote on Fri, 21 April 2006 08:04

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

> The vst uses my own abstractions, which are not in the cycling74 folder but in the same folder as the vst patch.

if you have one abstraction in the externals folder,

and another one or a copy with the same name

the externals folder but still inside the search path,

different patches might load different copies.

Quote: mattijs@samplemadness.nl wrote on Fri, 21 April 2006 08:04
----------------------------------------------------
> The vst uses my own abstractions, which are not in the cycling74 folder but in the same folder as the vst patch.
>
> I still use 3.5.3 though, so I will get the update and try again.
----------------------------------------------------

if  you have one abstraction in  the externals folder,
and another one or a copy with the same name
outside
the externals folder but still inside the search path,
different patches might load different copies.


That is no problem. I like every patch to have its own abstractions, I don't use the max search path at all for this. I prefer storing the abstractions in the same folder as the main patch to avoid version conflicts.

I would be very happy with an upgrade that adds not only a the main patch folder but also its subfolders to the max search path. Now the abstractions (currently at a count of 65) are all in the same folder as the main patch.

But the problem was that I had two different copies of one abstraction in one patch :)

Pluggo vst and max/msp patch share abstraction!