dalinnen

i primarily use pluggo for my own plugins. i rebuilt all of my plugins with max 4.6.2, each with a .vst extension. i have always put my plugins in a subfolder of the pluggo directory (in /Library/Audio/Plug-Ins/VST/Pluggo/minus+/ if that helps). the au scanner has always found them, and i have never had trouble updating a plugin (even with a name change) and getting my logic sessions to find the correct plugin.

while it is very nice that 3.6 puts plugins such as mine in their own sublist, my "old" sessions (created before 3.6) do not find my plugins that were being used. for example...

CoreAudio: Plug-In "jumble.012" not available!

(names are truncated to 10 characters, but that has always been the case in logic, i believe.)

the plugins do exist in the new "minus+" category beside "Pluggo", and i can reselect my plugins easily (if not quickly). but by reselecting a plugin, i lose all of its parameter data that was saved in the session. this is the big problem.

regular pluggo plugs work fine in old sessions. i tried moving my plugins straight into the pluggo folder (and rescanning), but that didn't help. losing the .vst extensions doesn't help either, but i assume it has nothing to do with the filename anyway. i would guess that whatever au scan was telling logic previously via the pluggo.component isn't jiving with 3.6.

if someone with cycling could clarify whether there might be a work-around or not i would greatly appreciate it. for now i am on hold, hoping all my programming can be salvaged since it is still in those session files.

also any user experiences of opening sessions with 3.6 (and particularly if you have plugins in a subfolder of /Pluggo) would be very helpful.

i primarily use pluggo for my own plugins.  i rebuilt all of my plugins with max 4.6.2, each with a .vst extension.  i have always put my plugins in a subfolder of the pluggo directory (in /Library/Audio/Plug-Ins/VST/Pluggo/minus+/ if that helps).  the au scanner has always found them, and i have never had trouble updating a plugin (even with a name change) and getting my logic sessions to find the correct plugin.

while it is very nice that 3.6 puts plugins such as mine in their own sublist, my "old" sessions (created before 3.6) do not find my plugins that were being used.  for example...

the plugins do exist in the new "minus+" category beside "Pluggo", and i can reselect my plugins easily (if not quickly).  but by reselecting a plugin, i lose all of its parameter data that was saved in the session.  this is the big problem.

regular pluggo plugs work fine in old sessions.  i tried moving my plugins straight into the pluggo folder (and rescanning), but that didn't help.  losing the .vst extensions doesn't help either, but i assume it has nothing to do with the filename anyway.  i would guess that whatever au scan was telling logic previously via the pluggo.component isn't jiving with 3.6.

if someone with cycling could clarify whether there might be a work-around or not i would greatly appreciate it.  for now i am on hold, hoping all my programming can be salvaged since it is still in those session files.

old-sessions-big-problem-pluggo-3-6

If you're using the VST versions of the plugins, then (at least in 

Live), if you move them to your VST folder root (not in an enclosing 

sub-folder), they will appear not in an enclosing folder within the 

On the other hand, if you're using the AU versions, then I do think 

that even if you move your plugins to the VST folder root, they 

appear in a "VST" subfolder within the AU section (again, in Live, 

>if someone with cycling could clarify whether there might be a 

>work-around or not i would greatly appreciate it. for now i am on 

>hold, hoping all my programming can be salvaged since it is still in 

>also any user experiences of opening sessions with 3.6 (and 

>particularly if you have plugins in a subfolder of /Pluggo) would be 

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

If you're using the VST versions of the plugins, then (at least in 
Live), if you move them to your VST folder root (not in an enclosing 
sub-folder), they will appear not in an enclosing folder within the 
app.

On the other hand, if you're using the AU versions, then I do think 
that even if you move your plugins to the VST folder root, they 
appear in a "VST" subfolder within the AU section (again, in Live, 
haven't looked at other hosts).

>if someone with cycling could clarify whether there might be a 
>work-around or not i would greatly appreciate it.  for now i am on 
>hold, hoping all my programming can be salvaged since it is still in 
>those session files.
>
>also any user experiences of opening sessions with 3.6 (and 
>particularly if you have plugins in a subfolder of /Pluggo) would be 
>very helpful.
>
>thanks, everyone.
>
>--dave linnenbank

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


Because you mention that all of Cycling's plugs are fine, I have only 

Then rebuild your plug-in and see if it works. If it doesn't could you 

1. open Terminal.app (in the /Applications/Utilities folder)

3. paste the results into a text file, and save the text file

4. uninstall Pluggo 3.6 (run the Cleaner that is on the 3.6 DMG, and 

then also trash the CFMAdaptor files in the /Library/CFMSupport folder)

7. paste the results onto the end of the text file you created before

8. email the text file to support@cycling74.com

Hopefully the first strategy will work and you can avoid all this! 

> i primarily use pluggo for my own plugins. i rebuilt all of my plugins with max 4.6.2, each with a .vst extension. i have always put my plugins in a subfolder of the pluggo directory (in /Library/Audio/Plug-Ins/VST/Pluggo/minus+/ if that helps). the au scanner has always found them, and i have never had trouble updating a plugin (even with a name change) and getting my logic sessions to find the correct plugin.

> while it is very nice that 3.6 puts plugins such as mine in their own sublist, my "old" sessions (created before 3.6) do not find my plugins that were being used. for example...

> CoreAudio: Plug-In "jumble.012" not available!

> (names are truncated to 10 characters, but that has always been the case in logic, i believe.)

> the plugins do exist in the new "minus+" category beside "Pluggo", and i can reselect my plugins easily (if not quickly). but by reselected a plugin, i lose all of its parameter data that was saved in the session. this is the big problem.

> regular pluggo plugs work fine in old sessions. i tried moving my plugins straight into the pluggo folder (and rescanning), but that didn't help. losing the .vst extensions doesn't help either, but i assume it has nothing to do with the filename anyway. i would guess that whatever au scan was telling logic previously via the pluggo.component isn't jiving with 3.6.

> if someone with cycling could clarify whether there might be a work-around or not i would greatly appreciate it. for now i am on hold, hoping all my programming can be salvaged since it is still in those session files.

> also any user experiences of opening sessions with 3.6 (and particularly if you have plugins in a subfolder of /Pluggo) would be very helpful.

Because you mention that all of Cycling's plugs are fine, I have only 
one theory.

Try adding this line to your plugconfig:
#C package PiMa;

Then rebuild your plug-in and see if it works.  If it doesn't could you 
please do the following?

1. open Terminal.app (in the /Applications/Utilities folder)
2. type this and hit enter:
	auval -a
3. paste the results into a text file, and save the text file
4. uninstall Pluggo 3.6 (run the Cleaner that is on the 3.6 DMG, and 
then also trash the CFMAdaptor files in the /Library/CFMSupport folder)
5. install Pluggo 3.5.4
6. type this and hit enter:
	auval -a
7. paste the results onto the end of the text file you created before
8. email the text file to support@cycling74.com

Hopefully the first strategy will work and you can avoid all this! 
Please let us know how this goes...
   Tim

dave linnenbank wrote:
> i primarily use pluggo for my own plugins.  i rebuilt all of my plugins with max 4.6.2, each with a .vst extension.  i have always put my plugins in a subfolder of the pluggo directory (in /Library/Audio/Plug-Ins/VST/Pluggo/minus+/ if that helps).  the au scanner has always found them, and i have never had trouble updating a plugin (even with a name change) and getting my logic sessions to find the correct plugin.
>
> while it is very nice that 3.6 puts plugins such as mine in their own sublist, my "old" sessions (created before 3.6) do not find my plugins that were being used.  for example...
>
> CoreAudio: Plug-In "jumble.012" not available!
>
> (names are truncated to 10 characters, but that has always been the case in logic, i believe.)
>
> the plugins do exist in the new "minus+" category beside "Pluggo", and i can reselect my plugins easily (if not quickly).  but by reselected a plugin, i lose all of its parameter data that was saved in the session.  this is the big problem.
>
> regular pluggo plugs work fine in old sessions.  i tried moving my plugins straight into the pluggo folder (and rescanning), but that didn't help.  losing the .vst extensions doesn't help either, but i assume it has nothing to do with the filename anyway.  i would guess that whatever au scan was telling logic previously via the pluggo.component isn't jiving with 3.6.
>
> if someone with cycling could clarify whether there might be a work-around or not i would greatly appreciate it.  for now i am on hold, hoping all my programming can be salvaged since it is still in those session files.
>
> also any user experiences of opening sessions with 3.6 (and particularly if you have plugins in a subfolder of /Pluggo) would be very helpful.
>
> thanks, everyone.
>
> --dave linnenbank


tim, you are a beautiful man. adding the PiMa package line does the trick.

i would note that an instantiated plugconfig has this line by default...

... as do all of my patches containing plugconfig. (perhaps the default value could be changed.) simply adding the PiMa line up top does no good because the old line takes precedence.

thanks again, tim (and fellow cyclers), for the always excellent work and brilliant reply.

Quote: Timothy Place wrote on Wed, 27 September 2006 12:26

> Try adding this line to your plugconfig:

tim, you are a beautiful man.  adding the PiMa package line does the trick.

... as do all of my patches containing plugconfig.  (perhaps the default value could be changed.)  simply adding the PiMa line up top does no good because the old line takes precedence.

> Try adding this line to your plugconfig:
> #C package PiMa;


Tim, sorry I misunderstood your problem with my previous reply (I 

read your note too fast) - and glad Tim set you straight!

At 1:12 PM -0400 9/27/06, dave linnenbank wrote:

>tim, you are a beautiful man. adding the PiMa package line does the trick.

Tim, sorry I misunderstood your problem with my previous reply (I 
read your note too fast) - and glad Tim set you straight!

At 1:12 PM -0400 9/27/06, dave linnenbank wrote:
>tim, you are a beautiful man.  adding the PiMa package line does the trick.

Of course I meant to say Dave - can't get anything straight today...

At 1:19 PM -0400 9/27/06, Dan Nigrin wrote:

>Tim, sorry I misunderstood your problem with my previous reply (I 

>read your note too fast) - and glad Tim set you straight!

At 1:19 PM -0400 9/27/06, Dan Nigrin wrote:
>Tim, sorry I misunderstood your problem with my previous reply (I 
>read your note too fast) - and glad Tim set you straight!
>

> tim, you are a beautiful man. adding the PiMa package line does the trick.

Be careful - beauty is a fleeting thing ;-). I'm glad it worked.

> i would note that an instantiated plugconfig has this line by default...

> ... as do all of my patches containing plugconfig. (perhaps the default value could be changed.)

We won't be changing the default because we would like to discourage 

people from using PiMa for any new plug-in development. PiMa is really 

intended to designate the official Pluggo plug-ins. However, until 

Pluggo 3.6 this value was hard-coded and you were not able to change it. 

So all old plug-ins were marked as Pima (or Mode or HpNo in special 

So for old plug-in maintainence (such as what you are doing) it makes 

sense to have it be "PiMa" but for any new plug-in development it should 

The 'package' feature as well as the new 'category' and 'nonrealtime' 

features of plugconfig are both documented in the MSP 4.6.2 Reference 

dave linnenbank wrote:
> tim, you are a beautiful man.  adding the PiMa package line does the trick.

Be careful - beauty is a fleeting thing ;-).  I'm glad it worked.

> i would note that an instantiated plugconfig has this line by default...
>
> #C package ????;
>
> ... as do all of my patches containing plugconfig.  (perhaps the default value could be changed.)

We won't be changing the default because we would like to discourage 
people from using PiMa for any new plug-in development.  PiMa is really 
intended to designate the official Pluggo plug-ins.  However, until 
Pluggo 3.6 this value was hard-coded and you were not able to change it. 
  So all old plug-ins were marked as Pima (or Mode or HpNo in special 
cases).

So for old plug-in maintainence (such as what you are doing) it makes 
sense to have it be "PiMa" but for any new plug-in development it should 
not be "PiMa" but something else.

The 'package' feature as well as the new 'category' and 'nonrealtime' 
features of plugconfig are both documented in the MSP 4.6.2 Reference 
manual, for what it's worth.

Quote: Dan Nigrin wrote on Wed, 27 September 2006 11:30

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

> Of course I meant to say Dave - can't get anything straight today...

Quote: Dan Nigrin wrote on Wed, 27 September 2006 11:30
----------------------------------------------------
> Of course I meant to say Dave - can't get anything straight today...
>
> Dan

old sessions, big problem (pluggo 3.6)