Zynewave.
roninSounds reasonable. Does it solve the problem I had with the initial scan? Maybe there is an easy way to trace the plugins that had already been scanned and omit them in subsequent scans (in case of a crash).
thcilnnahojHmm, what about people who work with multiple templates… maybe the “import database” button could become a sort of dropdown menu to select a template.
Sure, you can use the ‘old’ way to create a project from a template, but it’d be nice to have them all available like this.
No other suggestions at this time, but some questions:
– How does it work for plug-ins that have since been removed – does the “update database” function clean them out automatically?
– Does the update function go by filename only, or will it create additional mappings for plug-ins that are already present, but the user may have created custom mappings for?
– If the option for importing surround mappings is removed, you’ll have to delete them from the very first plug-in database yourself, no? I hope they won’t reappear, should you use the “update database” function.
Though I guess there’s no need for concern since this change in 2.27: “Using any of the import plugin commands will only create surround mappings for the plugin if there already are other surround mappings in the project.”?
– Is this going to change anything concerning audio and MIDI device setups, or will the database somehow only story plug-in (and external instrument/effect) mappings?
Zynewave@ronin wrote:
Sounds reasonable. Does it solve the problem I had with the initial scan? Maybe there is an easy way to trace the plugins that had already been scanned and omit them in subsequent scans (in case of a crash).
Scanning of each plugin produces the various device mapping, device definition, preset and parameter objects. To be able to skip rescanning plugins in case of a crash, then it’s necessary to save the project template file after each scanned plugin. I’m afraid that is going to slow down the scanning process noticeably.
I’m curious: How many crashing plugins do you encounter during a scan of your complete plugin collection?
Once a plugin has crashed, Podium will put it on the quarantine list. Future complete scans will then skip these crashing plugins. So the problem should only exist the first time you scan all your plugins, unless you manually remove the crashing plugins from the quarantine list.
ronin@Zynewave wrote:
I’m curious: How many crashing plugins do you encounter during a scan of your complete plugin collection?
Too much 😆 The strange thing is that the plugin collection worked back on Windows XP (with crashes too but after a few tryouts and and few quarantined plugins later the scan was successfull). The last time on Win7 I gave up. I’ve tried it two hours and everytime a different plugin crashed. Sometimes even a plugin that had been already scanned. So quarantining the “faulty” plugin does not solve the problem in every case. I’ve tried to explain that in the first post.
I don’t blame Podium for the crashes! It is definately the fault of the plugins but I think Podium should somehow handle this case. I guess I’m not the only one with this problem.
Zynewave@thcilnnahoj wrote:
Hmm, what about people who work with multiple templates… maybe the “import database” button could become a sort of dropdown menu to select a template.
Sure, you can use the ‘old’ way to create a project from a template, but it’d be nice to have them all available like this.
If you have saved your own project templates, then there will be a dropdown menu button. I think most users will never use the project template feature, so I’m trying to figure out a transparent way to handle a global plugin database, without worrying the user about templates.
– How does it work for plug-ins that have since been removed – does the “update database” function clean them out automatically?
Yes, I think they should be cleaned out.
– Does the update function go by filename only, or will it create additional mappings for plug-ins that are already present, but the user may have created custom mappings for?
No, it will skip any plugin whose dll is already referenced in a mapping in the database. Otherwise it would need to rescan all plugins anyway, and then there won’t be much time saved with the update option.
– If the option for importing surround mappings is removed, you’ll have to delete them from the very first plug-in database yourself, no? I hope they won’t reappear, should you use the “update database” function.
Though I guess there’s no need for concern since this change in 2.27: “Using any of the import plugin commands will only create surround mappings for the plugin if there already are other surround mappings in the project.”?
I’m considering moving the stereo and surround options up on the page as general options, and not just plugin related. The options also decide if surround mappings should be created for audio ins/outs and busses.
– Is this going to change anything concerning audio and MIDI device setups, or will the database somehow only story plug-in (and external instrument/effect) mappings?
No, the project template menu will work as always. It’s only the auto-generated “plugin database” template which will be used to extract VST plugin definitions only.
Malcolm JacobsonHi Frits,
@Zynewave wrote:
Scanning of each plugin produces the various device mapping, device definition, preset and parameter objects. To be able to skip rescanning plugins in case of a crash, then it’s necessary to save the project template file after each scanned plugin.
Why does the plugin database need to be part of the POD file, and therefore part of the template?
Reaper scans for new plugins each time you start it up (by default, but it can be configured to only scan on command) and writes the list of plugins to an ini file in an Application Data folder. You can then create as many Project files (equivalent to Podium projects) as you want without having to rescan the plugin database.
Is there some architectural reason the database can’t be separated from the POD file?
Cheers,
Malcolm.
pavouk100@Malcolm Jacobson wrote:
Reaper scans for new plugins …. You can then create as many Project files (equivalent to Podium projects) as you want without having to rescan the plugin database.
I think that the main difference is that emphasized part is not completely true. I’d say that reaper’s project is more like podium’s arrangement, while podium’s project is something like reaper’s ‘group of projects + some global settings, like VST’s db’. While I like the way podium handles this, from the feedback on the forum I’d say that most people would rather go with more traditional reaper/cubendo/other-hosts project/settings management.
Zynewave@Malcolm Jacobson wrote:
Hi Frits,
@Zynewave wrote:
Scanning of each plugin produces the various device mapping, device definition, preset and parameter objects. To be able to skip rescanning plugins in case of a crash, then it’s necessary to save the project template file after each scanned plugin.
Why does the plugin database need to be part of the POD file, and therefore part of the template?
Reaper scans for new plugins each time you start it up (by default, but it can be configured to only scan on command) and writes the list of plugins to an ini file in an Application Data folder. You can then create as many Project files (equivalent to Podium projects) as you want without having to rescan the plugin database.
Is there some architectural reason the database can’t be separated from the POD file?
The main reason that the plugin definitions (or database) are included in the project file, is to allow customization of the plugin setups for different projects. You may have different plugin setups that you have organized for mastering, mixing, surround, classical, rock, and so on. Another use could be to have one setup that is organized into folders for plugin vendors, and another into folders for plugin type. You save these different setups in project templates. With the use of the “Load device setup” from the project template menu you can even switch between the plugin setups while working on the project.
I agree that the vast majority of users won’t bother with organizing different plugin setups, and will only ever need one setup. That’s why I’m currently making some changes for 2.28 that will support a global plugin database. The plugin setup is still included in the project, but the management of the plugin setup is now much easier. I hope to have a preview ready later this week.
ZynewaveI’ve posted a preview topic for Podium 2.28, which features a new plugin database system. Please comment in that topic: