PG8X (inspired by the JX8P): new beta version uploaded

[AdmiralQuality]

Strange method... Hmmm... Why not... I guess that it would mean that even a single patch is in fact saved encapsulated in a "one record bank" and that the extension "fxp" is there... just for the fun.

Other than some header that says how many programs there are in it, I believe that's the only difference between .fxp and .fxb, yes. A bank is just a serial bunch of programs. (This is Steinberg's invention. Not any of us VST plugin authors'. We just use it according to their spec. In fact, we're not even supposed to use it at the plug-in level. .fxp and .fxb saving and recalling is normally just a host function.)

At the origin, yes. But when Steinberg introduced the version 2 with the ability to compile also as standalone, it was needed to have full internal access to the procedures in order to let a standalone version have the ability to manage the patches/banks itself without changing anything fundamental in the structure of the synth.

If i recall correctly

There's no support for stand-alone in VST 2.x. Developers are on their own, there. VST is a plug-in format, and a plug-in format only.

[AdmiralQuality]

Thanks for the patronizing lecture. I can assure you that I'm very well aware of the fundamental difference between patch and bank, and fxp and fxb.

The problem is, I never get an option to select one or the other in Mac OS 10.9.3 (the very latest OS). I assume you're on Windows? When I hit the Save button in PG8X AU, the file name in the System file dialog is by default suffixed by ".fxp" – you know, "one line in a spreadsheet".

There is no option to change the format of the save and consequently no option to save. or Load, for that matter, a bank. Dixi.

/Joachim

That's because the AU format isn't suppose to even use FXP/FXB format of patches, but AUPRESET. And I don't recall any AU synth that uses this format to save banks - just patches. FXP/FXP are formats created bt Steinberg for VST - which is a different format. I know this is silly, but it's as it is in the Mac world, and that's why many vendors opt to create their own format - to avoid this format chaos.

Your AU host should still offer to save in AUPRESET format. Again, this is not functionality plug-ins of either type are required or even expected to have. But it does make sense to provide a way to get program/banks from the AU version to the VST version, and vice versa.

[BlackWinny]

But it does make sense to provide a way to get program/banks from the AU version to the VST version, and vice versa.

Absolutely.

[martin_l]

Normally that would be the case, but another non-standard thing Martin has done here is make the filename extension you choose determine the type of thing you're saving vs. the other way around, as it should be. (There should be separate save program and save bank buttons.)

I'd just use the host for that, if I were you. (Except for the AU version. .fxp and .fxb are purely a VST thing.)

You are pointing out a couple of non-standard things, I seem to be doing. It seems I am missing something here. Is there somewhere a standard I can read up to see what exactly is and is not expected of a plugin?

There are many plugins which have their own preset handling system, often with their own file format. Is that "ok"? If so, what is wrong about doing the same, but uding the fxb/fxp format as the standard format?

The thing about deciding what to save based on the file extension also is used by reaper, when exporting fxp/fxb. That's why I did not consider it non-standard. But I agree that it might be confusing, and will implement a popup menu when clicking WRITE, which will ask what to write, rather than using the extension.

Thanks again for all the texting and many useful comments.

Cheers,
Martin

[AdmiralQuality]

Normally that would be the case, but another non-standard thing Martin has done here is make the filename extension you choose determine the type of thing you're saving vs. the other way around, as it should be. (There should be separate save program and save bank buttons.)

I'd just use the host for that, if I were you. (Except for the AU version. .fxp and .fxb are purely a VST thing.)

You are pointing out a couple of non-standard things, I seem to be doing. It seems I am missing something here. Is there somewhere a standard I can read up to see what exactly is and is not expected of a plugin?

No. As I'm sure you've noticed, VST is incredibly poorly documented in that way. But any experienced user of VSTs knows these things. Do you actually use plug-ins and DAWs when not working on your own product? If not, that might be a source of confusion there. You should do a survey of other products, and if you find yourself doing things that they don't do, ask yourself if and why you feel it's necessary.

There are many plugins which have their own preset handling system, often with their own file format. Is that "ok"? If so, what is wrong about doing the same, but uding the fxb/fxp format as the standard format?

As does my Poly-Ana. (But I made its program and bank formats proprietary, so as to not cause any confusion with the "native" formats of VST and AU hosts. In fact, my format is the exact C code I need to put the patch into my code as a preset.)

Anyway, that's not where your major disconnect is. I'm just pointing out that it's redundant (except for portability between the AU and VST) as it's a feature all hosts offer. The big issue however seems to be with this separate Write function, which frankly I don't even understand what it's supposed to be for. (If it's for writing into the preset bank then that makes sense. But it's certainly not working as such.)

And again, you seem to be doing more work than you need to. You already have a setProgram() function implemented somewhere. When you choose a new program number either from the menu or the + and - buttons, that's the only thing you should need to call. The rest is already there, as the host also can ask for a program change. But you seem to have two overlapping implementations for this same function. Just for one example that's fairly obvious from the quick bit of testing I've done.

[PAK]

Anyway, that's not where your major disconnect is. I'm just pointing out that it's redundant (except for portability between the AU and VST) as it's a feature all hosts offer.

There are VST hosts which can't save fxb/fxp. A small example being all of Steinberg's products, where it can import fxb/fxp but only exports in vstpreset format. So portability is required there too.

That's why I'm always happy to see programs which provide their own export functionality, which isn't reliant on the host. Avoiding a custom preset format is a bonus, since it means it's possible other tools (such as patch management type tools, or a hosts own management systems) could make use of the format. I wish more devs would do it..

[AdmiralQuality]

Anyway, that's not where your major disconnect is. I'm just pointing out that it's redundant (except for portability between the AU and VST) as it's a feature all hosts offer.

There are VST hosts which can't save fxb/fxp. A small example being all of Steinberg's products, where it can import fxb/fxp but only exports in vstpreset format. So portability is required there too.

That's why I'm always happy to see programs which provide their own export functionality, which isn't reliant on the host. Avoiding a custom preset format is a bonus, since it means it's possible other tools (such as patch management type tools, or a hosts own management systems) could make use of the format. I wish more devs would do it..

Yep, like I said, portability. (But using Steinberg's same format causes a bit of confusion.)

I didn't realize they had taken away .fxp and .fxb from their new hosts. Even for VST 2.4 plug-ins? Less is more!

[PAK]

They can only import for years now.. their way of trying to move everyone to the new format, I guess. AFAIK there's no way to save banks with the new system either. Steinberg's own internal dev tools use a vstsound container file for this purpose, but I've never seen anything which offers the ability to export in that format.

Most cross-platform plugins have moved to their own export formats, so it's not been the issue it could have been. But it's obvious when a dev didn't test vstpreset functionality, since their plugin can generate huge file sizes (sometimes 1MB+) for a single preset
3rd party tools, to convert to fxp/fxb, usually don't work well either.

[AdmiralQuality]

They can only import for years now.. their way of trying to move everyone to the new format, I guess. AFAIK there's no way to save banks with the new system either. Steinberg's own internal dev tools use a vstsound container file for this purpose, but I've never seen anything which offers the ability to export in that format.

Most cross-platform plugins have moved to their own export formats, so it's not been the issue it could have been. But it's obvious when a dev didn't test vstpreset functionality, since their plugin can generate huge file sizes (sometimes 1MB+) for a single preset
3rd party tools, to convert to fxp/fxb, usually don't work well either.

This is why I hate them.

[fmr]

The vast majority of users don't care about "banks" anymore. They only want/need a proper browser and patch management system that allows them to organize the patch coillections the way they feel better suits their needs. That said, I'm not sure if stick to the old FXP/FXB paradigm is a good thing. If Martin is going to create a "write" function, why not a browser/patch manager, and create his own format file, maybe XML based, or simply text based? I'm not against banks, but if we have a proper patch manager, I don't feel the need for them, and having his own patch format is the best guarantee that it will work no matter what host is in use.

[AdmiralQuality]

The vast majority of users don't care about "banks" anymore. They only want/need a proper bowser and patch management system that allows them to organize the patch coillections the way they feel better suits their needs.

A "bowser" like, the file system?

Do you write a lot of plug-ins, FMR? Work in market research for a plug-in developer, maybe?

[fmr]

The vast majority of users don't care about "banks" anymore. They only want/need a proper bowser and patch management system that allows them to organize the patch coillections the way they feel better suits their needs.

A "bowser" like, the file system?

Browser and yes, like a file system, or patch management system, if you prefer. I think that will be safer in the long term, and will cover also the problem of different format compatibility.

[BlackWinny]

The vast majority of users don't care about "banks" anymore. They only want/need a proper browser and patch management system that allows them to organize the patch coillections the way they feel better suits their needs. That said, I'm not sure if stick to the old FXP/FXB paradigm is a good thing. If Martin is going to create a "write" function, why not a browser/patch manager, and create his own format file, maybe XML based, or simply text based? I'm not against banks, but if we have a proper patch manager, I don't feel the need for them, and having his own patch format is the best guarantee that it will work no matter what host is in use.

I agree with you... but only when one can qualify oneself the patches, by tags for example, in order to be able to find easily one's patches within hundreds or thousands. Even the sorting by folders in not enough when we have to manage hundreds or thousands patches which are all accessible simultaneously.

[AdmiralQuality]

The vast majority of users don't care about "banks" anymore. They only want/need a proper bowser and patch management system that allows them to organize the patch coillections the way they feel better suits their needs.

A "bowser" like, the file system?

Browser and yes, like a file system, or patch management system, if you prefer. I think that will be safer in the long term, and will cover also the problem of different format compatibility.

Well then you're reinventing the wheel. What is a file load dialog if not a browser of the file system?

If you want to organize your patches, you can do it in folders and files on your storage volumes.

But yes, for portability, it absolutely makes sense for a plugin to have its *own* program and bank file formats. However, by using Steinberg's .fxp and .fxb, we get the confusion we're getting now. (Martin will also have to guarantee that .fxp and .fxb saved by his plug-in exactly match those as saved by VST hosts.) A proprietary format would have been the better choice here, IMHO. But as for browsing, that's what the file system is for. Organize away!

[AdmiralQuality]

Even the sorting by folders in not enough when we have to manage hundreds or thousands patches which are all accessible simultaneously.

21st century problems...