Zynewave.
roninHi Frits,
I’ve tried to test 2.27beta6. Unfortunately I have a quite huge plugin collection and not all of the seem to be properly and carefully programmed. I usually have no problems using them but there are lots crashes during the scan of the plugins folder.
This is one of the reasons why I have just one or two projects with several arrangements. Once scanned I can reuse the plugin mappings in different songs.
This has been bugging me for a long time although I have to admit that the described workaround worked for me so far. I just had to use the project system in a differnt way than I think it is intended.
While testing the new beta I’ve spent two hours and did more than 20 attempts to scan the plugins folder. Everytime another plugin crashed/got blacklisted. Sometimes even plugins that had been successfully scanned in previous runs. Currently this is an iterative process because the complete plugin folder is scanned on every attempt.
I’m not aware of the scan algorithm but I’m sure that every scanned plugin can lead to a stack corruption or other difficult-to-debug problems. These corruptions can manifest later and therefore quarantining the last scanned plugin may not always lead to satisfying results (as in my case).
What I would like to suggest is a plugin cache or plugin database. Every successfully scanned plugin is stored there. This would speed up future project creation and would solve problems with scanning large databases. Already scanned plugins can be omitted in future scans if a previous scan has failed or led to crash. If a plugin crashes during runtime (while using) the user may have the option to blacklist them.
Another approach to this problem may be another process. This dedicated process could scan the plugin (and crash) without affecting Podium. I don’t know how difficult this is to implement but maybe this is an option to consider.
druidThe way I do it is to have a template “blank” project, that I use when I start a new project, that has all the plugins loaded into it. And I had issues importing a lot of plugins as well. It seems to me it depends how many you import at once. I have mine organised in folders, so what I ended up doing was to import just one folder at once, instead of the whole VST folder. That way, I was able to import them all.
Not ideal; my ideal is the way XT1 (and 2?) does it, which is to have a submenu and then list folders, then .dll files. When it opens that submenu of that folder, it loads that folder at the time. This is bad for people who don’t like having subfolders, or even if they use folders to organise their VSTs, have lots of plugins.
roninI used templates too but from time to time I have to redo the template, so I end up with the same problem.
The folder trick should work too but it might be a bit cumbersome depending on how many folder there actually are.
UncleAge@druid wrote:
Not ideal; my ideal is the way XT1 (and 2?) does it, which is to have a submenu and then list folders, then .dll files. When it opens that submenu of that folder, it loads that folder at the time.
I don’t think XT1/2 verifies plugins upon startup at all. My understanding is that it verifies them when you load them on a track. And I could be wrong but I’m pretty sure it is the only host that does this.
The two programs that handle this pretty well (IMO) are Tracktion and Studio One. They both do a full scan but they don’t crash on bad .dll’s. They just blacklist them and let you know which plugins failed.
With that said, I like the idea suggested. A plugin mapping/cache that is its own thing that can be managed separately. This would also allow different plugin templates to be managed separately from the project templates. So for instance you could have a mixing template or a mastering template and yet another template for doing voice-overs or podcasts. I have used project templates to handle this process in the past because I don’t like to see the very long list of vst’s that popup in the context menus.
Malcolm Jacobson+10 to separating the plugin database from the Project/Arrangement management.
I would use the Project function a lot more if I didn’t have to do a full VST scan each time I create a new Project. At the moment I have lots of Arrangements, but only one Project per Podium release.
Cheers,
Malcolm.
pavouk100@Malcolm Jacobson wrote:
+10 to separating the plugin database from the Project/Arrangement management.
I would use the Project function a lot more if I didn’t have to do a full VST scan each time I create a new Project. At the moment I have lots of Arrangements, but only one Project per Podium release.
Hmm, the same with me, although I don’t have project per Podium release, but only 3-4 global projects, with many arrangements. I like it this way, I don’t see what’s wrong with it. I’d guess that this is the intended usage…
EDIT: I think that ‘project’ is a bit of misnomer. I think that more proper names would be something like ‘Studio’ or ‘Virtual Studio Setup’ or some such.
Pavel
LiquidProj3ctI agree with this too. I cannot see any advantage into have a plugin list for each project.
druid@UncleAge wrote:
I don’t think XT1/2 verifies plugins upon startup at all. My understanding is that it verifies them when you load them on a track. And I could be wrong but I’m pretty sure it is the only host that does this.
No it doesn’t, you’re right. What I was trying to get at was that it lists .dll files (I think that’s how it does it) when you actually load that submenu that lists them. So no loading at startup, AND no searching a massive folder with tons of plugins. Rather, just read files, then try to load that plugin when you actually use it in a project. I think that’s how it works.
I always liked it, personally. It was dynamic. I didn’t need to update a plugin list, either central or per project. Still a problem for people with lots of plugins in one folder, but then I’d say it would be hard to scroll through that many plugins in a menu anyway.
ZynewaveCould you guys explain why you don’t use the “load device setup” submenu in the project templates?
The way I see it, project templates are plugin databases, with the possibility to also include default arrangements etc. Granted, the database is included in your project file, but with the “load device setup” it’s easy to substitute the plugin database in your existing projects.
Maybe what is needed is making the project template available on the create new project page through a combobox. When a template is selected, the plugin scan options would then only import plugins that are not already found in the project template.
I’m open for suggestions.
UncleAge@druid wrote:
I always liked it, personally.
I agree. Its one of those things that once you see it, you wonder, “Why doesn’t every app do it like this?”
ronin@Zynewave wrote:
Could you guys explain why you don’t use the “load device setup” submenu in the project templates?
My problem is the creation of the device setup and not the usage of such setups. In my case this is a really cumbersome procedure which takes a lot of time and patience. Please keep in mind that this holds true for a lot of hosts and not just Podium.
I don’t really know EnergyXT but its seems like it solves the problem fairly easy.
druid@Zynewave wrote:
Could you guys explain why you don’t use the “load device setup” submenu in the project templates?
I understand how you see it, but personally, I just don’t quite work that way. For me, I look at plugin lists, and then add them, almost like browsing a list of files. I don’t need it “mapped” until I choose to use it in the software.
I also find that having to remember to keep my “blank.pod” updated is a nuisance. If I even update a plugin, sometimes updates have new or changed parameters, and therefore I need to re-import. Or if I’m adding new plugins. I have to first handle the installation of the plugins, then I have to open the blank.pod file, then import the particular plugins (and I also do a bit of renaming and shifting of the device definitions and stuff – on that note, you can still move, if you copy it, paste it, then delete the old one 🙂 ), to make sure Podium doesn’t try to use outdated sets of parameters.
When just the files are listed right in the project arrangement view like in XT, I can choose which I want and as long as I’ve maintained the VST folders, and load it. If I’ve recently updated it, or added more, they are just listed automatically after the file is there, I don’t need to maintain any database within the host as well.
It’s just more intuitive to me.
Zynewave@druid wrote:
When just the files are listed right in the project arrangement view like in XT, I can choose which I want and as long as I’ve maintained the VST folders, and load it. If I’ve recently updated it, or added more, they are just listed automatically after the file is there, I don’t need to maintain any database within the host as well.
If the plugin dlls are not scanned, then it won’t be possible for the host to know whether a plugin is an instrument or an effect. That wouldn’t work well in Podium where the list of plugins are filtered depending on whether you click on an effect or a source selector.
druidThat’s indeed true; I hadn’t thought of that because I don’t work that way usually. 🙂
ZynewaveHere’s how I’m planning to change the Create New Project page:
These options will be removed:
“Scan and import mono/stereo VST plugins”
“Scan and import surround VST plugins”
“Save the created project as a project template”
Instead, for the first project you create you will see this option:
“Create plugin database”
When you create the project with this option enabled, it will scan for plugins as in previous versions, but once scanning is complete Podium will automatically save a project template named “Plugin database” without prompting the user for a template name.
The following projects you create will then show these options:
“Import plugin database (updated: xx-xx-2010)”
“Recreate plugin database”
“Update plugin database”
If you only check the “import plugin database” option, Podium will import the plugin definitions from the “Plugin database” template file, and there will be no scanning.
The “update plugin database” option will import the plugin database, but scan for any new installed plugins that are not already in the database.
Any suggestions for ways to make this easier?