Question for any VST / AU developers out there...

[JonHodgson]

Disagree, VST 2.4's patch handling is perfect. 2 modes: 1. make everything float and leave all interpretation to code in the plug-in. 2. do the exact same thing but you can also arbitrarily have your own BLOB of whatever opaque data you want (chunk mode).

If VST's patch handing was perfect we wouldn't all be rolling our own. For a start it doesn't distinguish between saving the complete state of the plugin, and an actual patch.

Plugins shouldn't need their own patch browsers, because the plugin standard should have all of that sussed.. I can forgive VST 2, because the VST standard was the first to arrive and noone had any experience to draw on, but every format after that has no excuse.

Lost chunks? We've all had "poison projects". This is why you should never use "Save" and always use "Save As...". Never overwrite good data with new data!

What are you on about? I said lost chunks of my life, not of my work. Dealing with idiosynchracies of various hosts because they operated in an odd manner in an area of the plugin spec which isn't clearly defined (which is most of the VST spec) has cost me a lot of time.

As or my work, I just use save... I have version control.

[AdmiralQuality]

Disagree, VST 2.4's patch handling is perfect. 2 modes: 1. make everything float and leave all interpretation to code in the plug-in. 2. do the exact same thing but you can also arbitrarily have your own BLOB of whatever opaque data you want (chunk mode).

If VST's patch handing was perfect we wouldn't all be rolling our own. For a start it doesn't distinguish between saving the complete state of the plugin, and an actual patch.

Sure it does. Patch vs. bank. .fxp vs .fxb.

Plugins shouldn't need their own patch browsers, because the plugin standard should have all of that sussed.. I can forgive VST 2, because the VST standard was the first to arrive and noone had any experience to draw on, but every format after that has no excuse.

Well that's just substandard hosts that cause that problem. Even then, I can't think of any offhand that don't let you save your patches and/or banks.

Lost chunks? We've all had "poison projects". This is why you should never use "Save" and always use "Save As...". Never overwrite good data with new data!

What are you on about? I said lost chunks of my life, not of my work. Dealing with idiosynchracies of various hosts because they operated in an odd manner in an area of the plugin spec which isn't clearly defined (which is most of the VST spec) has cost me a lot of time.

As or my work, I just use save... I have version control.

Oh, ha ha! I thought you were referring to chunk mode.

[TYSONIK]

Thanks guys for some useful replies!

[JonHodgson]

Disagree, VST 2.4's patch handling is perfect. 2 modes: 1. make everything float and leave all interpretation to code in the plug-in. 2. do the exact same thing but you can also arbitrarily have your own BLOB of whatever opaque data you want (chunk mode).

If VST's patch handing was perfect we wouldn't all be rolling our own. For a start it doesn't distinguish between saving the complete state of the plugin, and an actual patch.

Sure it does. Patch vs. bank. .fxp vs .fxb.

Not what I'm talking about, a bank (which is not actually a very useful concept in a single file IMHO, file system folders are a better way, or a file which simply references patches if you want more versatility) is a plugin's worth of patches, not a state save.

I've been doing this a while, the VST 2 patch system is sadly lacking, if you've found it adequate for your purposes, then lucky you, I haven't.

[AdmiralQuality]

The file system is the file system. Save your .fxp and .fxb files in it.

[arakula]

Not what I'm talking about, a bank (which is not actually a very useful concept in a single file IMHO, file system folders are a better way, or a file which simply references patches if you want more versatility) is a plugin's worth of patches, not a state save.

But you can save the current state into a bank, if you need that, together with the patches. The problem only arises if you insist that it has to be a separately stored entity.

[JonHodgson]

The file system is the file system. Save your .fxp and .fxb files in it.

Which is what I do.

The very concept of a fixed bank of "n" patches, which is what the VST patch system works on, is a poor one, carried over from hardware and an unnecessary limitation in software.

Also, regarding saving the state of the plugin, there is no way for the host and plugin to differentiate a state save (which means all the setting of the plugin) from a patch, or indeed a bank, save (where you'd ideally store ONLY the parameters which define that sound). The only distinction is between patch, and bank. There's also no real support for multitimbral plugins in the patch handling, you can't say "load patch x into slot y"

And that's before we get into stuff that a really good patch system would have, like tags allowing searching for patches and other funky stuff.

The original impOSCar just did things the VST way, and for imp 2 I jumped through hoops to try to give the user better functionality but still comply with the VST way as much as possible, so really I think I know a little about how it works and the issues I've encountered. If you've been happy with the way it works, then that's good for you, I don't consider it good enough, it doesn't provide or really allow for the sort of functionality I want to provide, eventually you're better off deciding to completely ignore it (which you'll notice is a fairly normal approach, I'm not alone in this conclusion, though I suspect I have far less company in how far I've gone to try to play ball with the various formats)... but then the other formats don't seem to have learned any lessons from it.

[JonHodgson]

Not what I'm talking about, a bank (which is not actually a very useful concept in a single file IMHO, file system folders are a better way, or a file which simply references patches if you want more versatility) is a plugin's worth of patches, not a state save.

But you can save the current state into a bank, if you need that, together with the patches. The problem only arises if you insist that it has to be a separately stored entity.

When I load and save patches, or banks, then I just want the sounds to change, not any other settings in the plugin.

When I load and save a project, I want the whole state of the plugin saved and restored.

In the VST standard there is no distinction between those two scenarios, the host cannot say "give me your complete state" versus "give me a bank".

It's just one of the things it's missing, but in my opinion a very fundamental one (but the other formats aren't any better in that respect, except perhaps Rack Extensions).

[Big Tick]

And that's before we get into stuff that a really good patch system would have, like tags allowing searching for patches and other funky stuff.

All of these can be built on top of fxp.

[JonHodgson]

And that's before we get into stuff that a really good patch system would have, like tags allowing searching for patches and other funky stuff.

All of these can be built on top of fxp.

Yes, you can use an fxp as your core file type, or tfx, or aupreset, but to implement such functionality you'll have to bypass the patch system and read the patch files directly. So you'll be rolling your own, but trying to get it to also work with the standard patch system, something which I've actually done.

But the fundamental structure of how patches and banks are conceived is flawed.

simple example, fixed number of patches per bank, that's not down to the files patches are stored in, it's down to the fact that the VST standard makes you define how many programs the plugin has in a bank. So if you in fact have variable bank sizes (because your bank is simply a folder on the drive) but you also want to give the user access through the standard host drop down menu of patches, then you have to do a bit of a bodge, because whatever number you choose is almost always going to be too big for some banks, or too small.

I've been through all this myself, and looked at what others have done, and really if you want a decent patch system you have to roll your own and then decide whether you want to try to make it as compatible as possible with one or more plugin standards (so the user can browse and select patches using the host's user interface as well as the one in the plugin itself), or whether you basically ignore it.

I chose the former route, and lost months of my life to it, it would have been easier if I'd chosen just one plugin patch standard to comply with rather than three.

Let me put it another way, if you had a clean sheet of paper and were designing a plugin standard, would you handle patches and state the VST way? I suspect you wouldn't, your core file type might not be dissimilar to an fxp, but other things would probably differ.