Archive: Default Preset Location


3rd January 2010 15:00 UTC

Default Preset Location
i've recently been thinking about the structure winamp uses to save its plugins and presets (for milkdrop and avs). being also the developer of pimpbot, there's one thing about the default preset location i don't like: the user has to be admin to install new presets. i don't consider the installation of presets a harmful thing and knowing winamp for more than 13 years, i take it the reason for this lies in the history of winamp and the windows operating system.

with windows vista and windows 7 finally using a more secure user access model, i would love to see the winamp developers to overthink their outdated model. there is no reason why somebody who wants to watch visualizations needs to be an admin to get a look at them. i'm aware that it's already possible to change the default path for all visualizations plugins using the VISDir section of Winamp.ini. but maybe that's not good enough or ideal for other scenarios than avs or milkdrop.

hence i would suggest this to be changed in future versions of avs (or winamp). i guess the user folder (e.g. %APPDATA%) makes a more appropriate place for presets to be stored.


3rd January 2010 15:11 UTC

its been considered (*) for all aspects like skins, language packs and other files requiring write ability but nothing firm has been decided on from what i understand or has been done yet (as files would need to be prompted to be migrated, etc).

(*) which either meant going into the %appdata%\winamp or using %programdata%\winamp (has been a while since it was discussed so the second may not be correctly remembered).

-daz


3rd January 2010 15:33 UTC

thanks for the quick reply. i got my fingers crossed! :)


31st March 2010 19:08 UTC

did this for fun, migrates plugins, skins and user-settings to APPDATA


1st April 2010 00:17 UTC

better use this version instead

BUT

in any case be careful, this is an early alpha version. you might want to back up your data first!


20th May 2010 16:19 UTC

finally gotten around to looking at the script and moving plug-ins just wouldn't work as they need to be within the system search path so LoadLibrary(..) will work correctly so there's no real chance of that changing (and i know there's a means to override the search path with an alternate LoadLibrary-like function but that causes issues with AV apps and other 3rd party plug-ins).

the main issue really is the handling of the vis presets as i know there's the issue with Milkdrop preset ratings not being correctly applied (as skin and language pack moving can be done by changing the set path in the preferences for the next client release) but i think of the shipped plugins, Milkdrop will pretty much cope with a change in the default location but AVS i think may involve some work (and considering the issues getting the thing to build i don't know what'd happen with that).

it's definitely something that needs to be decided upon (hence the client support to move things which has been added for skins / lang packs) but it's how much it may affect other plug-ins and features that still really needs to be checked out (and agreed on by higher up) before anything substantial is done - something ideal for a full version increment possibly.

-daz


24th May 2010 00:00 UTC

Originally posted by DrO
finally gotten around to looking at the script and moving plug-ins just wouldn't work as they need to be within the system search path so LoadLibrary(..) will work correctly so there's no real chance of that changing (and i know there's a means to override the search path with an alternate LoadLibrary-like function but that causes issues with AV apps and other 3rd party plug-ins).
i only tried that for vis-plugins (and skins), but as i'm only using AVS i didn't come across any problems apart from old installers not supporting alternate vis-dirs. i guess all of this would only make sense for a new major version of winamp - if there are even plans for that.

all of visbot's installers support alternate vis-dir locations, just in case.