To find out which plug-ins have been added or modified lately, you can open your VST plug-ins folder and sort by "Date Modified." This is most effective if your plug-in strategy is to consolidate all of them into a single folder.

Anderton
To find out which plug-ins have been added or modified lately, you can open your VST plug-ins folder and sort by "Date Modified." This is most effective if your plug-in strategy is to consolidate all of them into a single folder.

and if you have subfolders, search for ".dll" and then sort by date modified


 
still, it would be nice to do this within the pim

pwalpwal

Anderton
To find out which plug-ins have been added or modified lately, you can open your VST plug-ins folder and sort by "Date Modified." This is most effective if your plug-in strategy is to consolidate all of them into a single folder.

and if you have subfolders, search for ".dll" and then sort by date modified


 
still, it would be nice to do this within the pim

Well, that's the issue...lots of things would be "nice." I think Cakewalk is currently concerned with bigger-picture items. For example I think a lot more users would rather see Cakewalk spend its time on a theme editor than overhauling the PIM.

fair enough, though i expect the pim would get more frequent use than a theme editor...
and while i understand noel's clarification (post #2) of why the images and colours are still embedded in a dll, if they were just files in a folder it wouldn't be such a big dev task, as i can imagine the dynamic recompiling of that dll while sonar is running is not a simple task, but maybe simpler than rewriting that area of code to use files/folders instead of dll
swings and roundabouts, eh?

Anderton

pwalpwal

Anderton
To find out which plug-ins have been added or modified lately, you can open your VST plug-ins folder and sort by "Date Modified." This is most effective if your plug-in strategy is to consolidate all of them into a single folder.

and if you have subfolders, search for ".dll" and then sort by date modified


 
still, it would be nice to do this within the pim

Well, that's the issue...lots of things would be "nice." I think Cakewalk is currently concerned with bigger-picture items. For example I think a lot more users would rather see Cakewalk spend its time on a theme editor than overhauling the PIM.

Listing dll's by modified date doesn't really show you the most recently installed plugs.  (If you decided to buy PSP Vintage Warmer...it would immediately sink to the bottom.)  It also doesn't show the ones that aren't in the current layout.  This also misses those plugs that you installed a year or two ago and never had a clear understanding of what they did...so you didn't know how to categorize and place them in the layout.  Thus, that insane mangler that you need for that serial killer film project will never be found when you need it.
 
I don't think this is a WIBNI (wouldn't it be nice if).  Even if you never installed a non-Cake supplied plug-in...there are still an alarming number number of plugins to deal with.  A good tool to manage this pile is mandatory.

See Week #78 in Friday's Tip of the Week. By following this strategy I know which plug-ins I have, they're organized, and new plug-ins are added properly. Basically, the PIM is something I use once to do the giant sort that's described, and then open it up as needed after installing a new plug-in so I can add it to the appropriate category.
 
The tip is also followed by some comments of how other people use the PIM. 
 
 

dantarbill
 
Listing dll's by modified date doesn't really show you the most recently installed plugs. 

Sorry, I meant "Date Created."

Anderton
See Week #78 in Friday's Tip of the Week. By following this strategy I know which plug-ins I have, they're organized, and new plug-ins are added properly. Basically, the PIM is something I use once to do the giant sort that's described, and then open it up as needed after installing a new plug-in so I can add it to the appropriate category.
 
The tip is also followed by some comments of how other people use the PIM. 
 
 

 
Thanks for the tip on the tip.  I'll have to read it more carefully to see if there's something there that I haven't already done.
 
One thing jumped out at me though...the idea of a Legacy folder (or a Legacy folder that contains the same sub-folder structure as your "main" view) so all that $#!+ that you'll never use in a new project can be saved "out of the way".

Anderton

dantarbill
 
Listing dll's by modified date doesn't really show you the most recently installed plugs. 

Sorry, I meant "Date Created."

i'm not sure it's as simple as that:
date created shows the timestamp from the local file system when it was first created...
date modified shows the date the dll was last changed...
so initially date modified would be taken from the dll distributed by the developer, timestamp from the dev's file system...
when first installing a new vst dll, the created date (when you first installed it) is more recent than the modified date (the build released by the dev)...
the twist being that if the dll is then updated (ie, a newer version copied over the existing one) then the modified date becomes more recent than the created date...


wahey!

I think you're losing sight of the goal of plug-in management. The original request was to be able to know what new plug-ins were installed most recently. Presumably if you have a plug-in already installed, then you've decided where it should live in terms of organization. So when it gets overwritten with an update and given a modified date that's more recent than the installation date, it really doesn't matter in terms of affecting organization. The plug-in was already organized.
 
If you follow the advice in Week 78 referenced above, when you install a plug-in, put it in the appropriate folder...or in the uncategorized "pool" of plug-ins, and sort later. I just don't why that's such a problem.