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.

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.

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

Sorry, I meant "Date Created."

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!

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

yeah, plugin management is more than just knowing what new plugs are recently installed, it's the whole "organising" or "management" of the plugins, a much bigger scope

the op was that the pim "needs refining to make it scan faster and the GUI needs some thought as well" - the other stuff came out through discussion in the thread


i think most of us realise that there are ways and means to accomplish various things, but without suggestions for different or new ways of accomplishing those things nothing would ever change, except when marketing needed a new gimmick
 
i would like to see some pim functionality exposed via the browser ui (custom menu organisation maybe? enable/disable plugins? assign icons or colour coding?)
i would like to able to add my own meta data for plugin sorting/grouping/searching rather than relying on that included by the dev
i expect that the pim is used more often by most users than a theme editor might be
i'd like to do all this within the sonar gui, not messing about in windows exporer
 
for example

Both please!

dantarbill

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

 
Just because you've installed a plug-in...it doesn't mean that you've also taken the time to go into the PIM and decide where it goes (even if that would have only been to put it in "uncategorized").

 
Well...I take the time to do it, so problem solved   The main "after the fact" thing I do with the PIM is place plug-ins I use all the time in a "Favorites" folder. 
 

what's in the "Favorites" folder please? :-)

Anderton

dantarbill
I'll come and work on your machine.

 
LOL!! I guess the issue is I make part of my living from what I create with SONAR, so I better have an organized system.
 
Probably I just accept the "busy work" that's needed with DAWs, having grown up with the constant maintenance that tape machines required. Maintaining DAWs and computers, despite their occasional hissy fits, is a lot less enervating.

Craig, busywork is one thing, and in most cases, keeping up with new plugins isn't that hard. The real problem comes when you have a suite of plugins that you've organized already, and an update to the plugins causes them to disappear from your carefully crafted custom menu layout. Now, one must determine which plugins need to be added back to the menu because they are no longer there, but not add any that one didn't want to include previously, but not exclude them, because one never knows when it might be useful and can be loaded from the full, non-custom menu anytime to find it.
 
I understand the Browser is where it's at going forward, but as long as the custom menu layouts are supported, it should be easier to know which ones are in the menu and which ones are not. It really is the only major new thing most are asking for.
 
Regards,
Dan

Anderton

dcumpian
The real problem comes when you have a suite of plugins that you've organized already, and an update to the plugins causes them to disappear from your carefully crafted custom menu layout. Now, one must determine which plugins need to be added back to the menu because they are no longer there, but not add any that one didn't want to include previously, but not exclude them, because one never knows when it might be useful and can be loaded from the full, non-custom menu anytime to find it.

 
Okay, I didn't realize that plug-ins changing their CLSID with an update was that common a problem. Generally when I update a plug-in, it stays where I put it; and because the ones I don't use are in an Uncategorized folder, they always have a home too.
 
I know this isn't what you want, but you might want to know that you can open a .PGL file in a text editor. At first it's just a daunting collection of text, but if you find/replace Name= with a return, then you get a list of all plug-ins in the layout, with the custom name listed first and the original name listed next. You can also replace other text strings with nothing, which cleans it up further. Probably the main value of this is you can see all the VST CLSIDs easily.

Good to know. The suite issue doesn't happen everyday, but it certainly happens once a year or so. Just enough to be depressed about it when it happens, lol. Waves is most guilty of this, though I've had it happen with a few others.
 
Regards,
Dan
 

Elffin
just a little tip - if you are unsue that you want to remove a plugin for future projects... you may want to consider just zipping the dll. Yeah, I know you can exclude the plugin. - but ... its another option... rescan removes the plugin from the list.

A bonus "Friday's Tip of the Week"...nice.