Studio One v3: Still can't organize effects and instruments in the browser?
-
- KVRAF
- 10176 posts since 16 Dec, 2002
I've never had problems moving VST dlls around on windows
-
- KVRian
- Topic Starter
- 1063 posts since 28 Dec, 2012 from Boston area
Did you ever run an updater or uninstaller for anything whose pieces you moved around manually? Wouldn't expect that to go well.VariKusBrainZ wrote:I've never had problems moving VST dlls around on windows
-
- Beware the Quoth
- 35527 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
I do. Very frequently.dwozzle wrote:Did you ever run an updater or uninstaller for anything whose pieces you moved around manually?VariKusBrainZ wrote:I've never had problems moving VST dlls around on windows
It goes fine, ta. Used to do that completely manually too, which was trivial except for 3 or 4 specific companies with bundled installers (eg Melda).Wouldn't expect that to go well.
Now, though I manage it all with two perl scripts, one to write a simple text file containing the locations of all .dll files in my VST folder, the other one to check that file and move any out-of-place .dll files back where they should be. Takes seconds.
edit: followup on this...
I actually know how common it is; 'not very'. And actually, its not a problem if the code needs to locate other resources relative to its location; relative is relative, that's the point of relative filepaths. Cakewalk's plugins, for example, manage this without any issues.dwozzle wrote:The DLL files are the actual code guts of each plugin. In most cases, they're put where they are by the plugin's installer, and shouldn't be moved, both so the plugin's uninstall script knows where they are, and in case the code itself needs to locate other resources relative to its location (no idea how common that is).
What's a problem is if the code needs to locate other resources relative to a hardcoded location (for, example stored in a registry entry). Which also occurs, though its less common. (eg Rob Papen, NI).
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
-
- KVRian
- Topic Starter
- 1063 posts since 28 Dec, 2012 from Boston area
Interesting. Did you come to that approach pre v3.1, before you could organize things directly in the S1 browser? I've written some things that come at this from a different angle, but they were always hacks that took more effort than the benefit they delivered. I've completely abandoned them since 3.1, and wouldn't go back just because I have this one bent folder.
-
- Beware the Quoth
- 35527 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
Not for Studio 1; my original main host was Sonar which has the most flexible plugin menu organisation around. However other hosts I use didnt have that flexibility, so I worked out a system for organising my plugin folders and their contents to reflect the way I wanted things. Since I still use multiple hosts (also including things like Bidule, and also Metaplugin to bridge VST into ProTools) having as consistent menu layouts as possible across all of them is preferable to me, and moving the plugins is the only way to achieve that.dwozzle wrote:Interesting. Did you come to that approach pre v3.1, before you could organize things directly in the S1 browser? I've written some things that come at this from a different angle, but they were always hacks that took more effort than the benefit they delivered. I've completely abandoned them since 3.1, and wouldn't go back just because I have this one bent folder.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
-
- KVRian
- Topic Starter
- 1063 posts since 28 Dec, 2012 from Boston area
I'm a web dev myself these days, and I've been thinking about a possible open source web app for this, kind of like the (massively redundant as long as I'm using new Studio One only) spreadsheet I've only recently stopped updating for this.
Basic idea was that you could enter all your plugins, rename them, categorize them how you wanted, and view them by category, search, etc.. Ideally, it'd be able to export this in the format required for various hosts, but even my raw spreadsheet without that was useful to get a reliable idea (as opposed to memory) of what my choices were for a category, or what plugins I had from a certain dev. (I also kept track of when I bought each one and for how much, on separate tabs by year, just to keep myself honest with myself about what I've spent. Could be part of such an app too.)
Obviously, the big hang is exporting in different DAW formats. Without that, it's a reference tool only, doesn't actually affect your DAW at all. Not without value, but I'm not at all sure anyone would think it was worth the bother.
Your strategy of capturing the original DLL locations, doing a make-it-so in the file system to organize them how you like, then putting them all back for updates etc, is a cool way of handling it. To integrate that into a web app would require some kind of downloadable, zero-install (ideally) platform independent capture tool whose results you could upload. I'm not sure I'd want to deal with the oddball cases though, Waves for instance.
Super pie-in-the-sky thought: Ideally DAW makers would come together on a common format for describing plugin metadata, include categorization, renaming, aliases, tags, etc., so one file could server a bunch of common apps. Department of Not Gonna Happen In Our Lifetime.
Basic idea was that you could enter all your plugins, rename them, categorize them how you wanted, and view them by category, search, etc.. Ideally, it'd be able to export this in the format required for various hosts, but even my raw spreadsheet without that was useful to get a reliable idea (as opposed to memory) of what my choices were for a category, or what plugins I had from a certain dev. (I also kept track of when I bought each one and for how much, on separate tabs by year, just to keep myself honest with myself about what I've spent. Could be part of such an app too.)
Obviously, the big hang is exporting in different DAW formats. Without that, it's a reference tool only, doesn't actually affect your DAW at all. Not without value, but I'm not at all sure anyone would think it was worth the bother.
Your strategy of capturing the original DLL locations, doing a make-it-so in the file system to organize them how you like, then putting them all back for updates etc, is a cool way of handling it. To integrate that into a web app would require some kind of downloadable, zero-install (ideally) platform independent capture tool whose results you could upload. I'm not sure I'd want to deal with the oddball cases though, Waves for instance.
Super pie-in-the-sky thought: Ideally DAW makers would come together on a common format for describing plugin metadata, include categorization, renaming, aliases, tags, etc., so one file could server a bunch of common apps. Department of Not Gonna Happen In Our Lifetime.
-
- Beware the Quoth
- 35527 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair
I dont actually put them back for updates. Most installers will try and put the .dll where it originally did. As long as that's in my custom VST folder, the second script will move it to where -I- want it, from where the installer wants it.dwozzle wrote: Your strategy of capturing the original DLL locations, doing a make-it-so in the file system to organize them how you like, then putting them all back for updates etc, is a cool way of handling it.
I use the xlutop VST2Shell to separate that out into individual .dll files that go in the folders I want. Only one or two ('indie') hosts have any issues with that (Tracktion for example, barfs on a random few of them per plugin scan, but there's only one IO configuration of one plugin it that it will never work with. Usine didnt play well with it though, but Ive stopped using that.)I'm not sure I'd want to deal with the oddball cases though, Waves for instance.
That'd be like, sensible or something. Cant have that.Super pie-in-the-sky thought: Ideally DAW makers would come together on a common format for describing plugin metadata, include categorization, renaming, aliases, tags, etc., so one file could server a bunch of common apps. Department of Not Gonna Happen In Our Lifetime.
An idiot on Set Theory:
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
"In some cases there is an object called red that contains everything that is red. In much the same way a pot is a plate."
-
- KVRian
- Topic Starter
- 1063 posts since 28 Dec, 2012 from Boston area
Ah, I get it, simple and clean. I like it!whyterabbyt wrote:I dont actually put them back for updates. Most installers will try and put the .dll where it originally did. As long as that's in my custom VST folder, the second script will move it to where -I- want it, from where the installer wants it.
Don't know about this, almost no search hits. Wazzat?whyterabbyt wrote:I use the xlutop VST2Shell to separate that out into individual .dll files that go in the folders I want.
-
- KVRAF
- 6159 posts since 4 Dec, 2004
No comment on the topic... I just wanted to express how much I like that phrase.Department Of: Not Gonna Happen In Our Lifetime
"Yes sir, I understand. Take the elevator to the 8th floor, make a left and then a right at the bathroom and talk to the people in the "Department of Not Gonna Happen in our Lifetime". They'll sort you out."
