It seems Steinberg is not very willing to improve on the aging FXP/FXB format. I wanted to suggest that you guys got together and establish a new more flexible standard.

There are many limitations in the current format, you should know them better, and me as a musician, I would like additional functionality.

In general, I would like a format that would allow the inclusion of additional information such as:

- Patch description: short text, author, copyright, date etc...

- Patch classification: like with mp3s you can classify a song from a pre-defined list of music types (e.g. pop, rock), you can have the same for synth/FX patches. Predefined types like: pad, lead, bass, percussion etc.

- Each file holds information on the plug-in it was made on, version of the plug etc.

Overall, you could have the potential benefits from this new format:

- You could search a patch library for certain types of sounds

- You could sort a library by parameters: e.g. show all pads, show all leads etc.

- You could find all patches that are made for a particular plug-in, instead of having endless FXB/FXP files not knowing for which plug they were supposed to work for.

Finally, a patch management software can be created to create new libraries from existing ones so that you can easily sort, share and organize your favourite sounds. And so on... I am sure you guys can elaborate on this idea much more than I possibly could.

I really hope this works out. It doesn't have to be complicated to develop, a format based on XML or similar would work just fine I suppose. Let's do this real, and let's make it a standard.

Thanks for listening!

you know, this is actually a decent idea.

If I can throw in a couple of suggestions.

Ability to save a couple of bars of midi with a patch and...
A FL/Kontakt style patch browser on the synth. So together you could step through synth patches like samples.

And a one button save to a patchname like yymmddhhmmss. When I'm making patches it breaks my flow to think up names. I'd rather do that later.

Nice idea Evan.

nuffink wrote:

And a one button save to a patchname like yymmddhhmmss.

better to be like "user_1", then the next would be "user_2". Have it look for the next available number so if you have 1 and 2 already, and decided to go back to patch one and work on it, it would save to "user_3" instead of rewriting 2.

A million times over: please consider XML.

- m

Markleford wrote:

A million times over: please consider XML.

Why XML? what's that good about XML? Why not to have binary chunk with title fields defined (name/author/date/etc), and then the same thing as fxp?

Actually, it even can be done with fxp. Just plugin developers should handle fxp save/load and store/retrieve the meta data.

I believe, that some of the companies (like NI) would not want their patches to be text-editable. So they'll rather stick with some binary format. While there is nothing bad in putting title/etc in a patch

gyohng wrote:

Why XML? what's that good about XML?

Well I'm not sure of its suitability in this case, but in general, it allows third party programmers easy access to file content from practically any programming language on any platform without having to program a file streaming routine from the ground up.

I think all the things mentioned are already possible, it is just a matter of standardisation between patches/instruments/developers.

Also, consider that file sizes (banks, song files etc.) will grow if you're saving midi clips and your family biography with every patch.

gyohng wrote:

Why XML? what's that good about XML?

For all the reasons cold c mentions!

Use of XML also allows for easy manipulation and reporting via style sheets and other XSLT fun, which means more easily-created third-party tools with be out there (librarians, patch morphers, etc)

Personally, one of my side-projects is to standardize a RIFF chunk for audio files that's bassed upon XML, rather than the hodge-podge of vendor-specific chunks that are out there. That's one reason for my XML bias.

- m

The actual implementation method of this concept is of the least importance at the moment. What needs to happen first, is to establishe the commitment of a few talented plug-in developers that lurk around in these forums at nights.

Perhaps K-v-R can help by dedicating a forum on this issue (assuming there is enough interest).

I suggested XML because it is already with us, and it would be very easy to work with. But it doesn't matter what method is used.

The format would also be platform independent. It won't matter if the version of your plug-in is DX or VST, if you are working on a PC or MAC or whatever.

Once there is an agreement, and an SDK is made, it should be promoted as freeware for all developers out there.

I really hope this catches on! So many times I wanted a specific type of sound and I had to go through tons of presets to actually find it. The benefits are many really...

PS. Just got another idea... you could rank your presets, say, in a scale from 1 to 5. So, you could then find out your most favourite ones in a single list and so on.

How about automatic/encapsulated filehandling... so I can modify a preset (or make a new one), and not have to bother saving it, it's automatically saved... and when I open a new instance, all my presets are already there for me, I don't have to trawl my hard drive trying to remember where I saved that damn file... and not having to load a file everytime I want non-default presets, or having to save a file blah blah blah.

That's why Synth1 is so cool. Check out Synth1's bank/patch management system. It rules. I wish all plugins managed patches like that.

Forever,




Kim.

Kim,

You just need to tell your host's developers to (make your host) remember the last used patch directories for the open/save dialogue for each plugin. (Or use the plugin's own save/load buttons). No need to overwrite the existing presets.

Yet another cool idea (will this ever stop?)...

Hybrid patch creation! You could use this patch management concept to create entirely new sounds based on parameters from existing ones. Here's an example... you can create a new strings patch, using the oscillator settings from a specified lead, the envelope settings from another strings patch, and the filter settings from say a pad. Instant mix'n match without touching a knob!

Back to reality again.

Evan wrote:

Yet another cool idea (will this ever stop?)... Hybrid patch creation! You could use this patch management concept to create entirely new sounds based on parameters from existing ones. Here's an example... you can create a new strings patch, using the oscillator settings from a specified lead, the envelope settings from another strings patch, and the filter settings from say a pad. Instant mix'n match without touching a knob! Back to reality again.

Orion Platinum has Patch Genetics, which does similar magic what you just described.

Anyway, I'd go for XML too (btw, I'm software developer). What'd do first is to define the XML Schema which would have proper definitions to allow conversion of existing FXB/FXP files into the new XML formatted files, and otherway around to preserve "backwards" compatibility.

One more suggesstion: I only want to see synthx Fx, banks when browsing form inside synthx, and only want to see synthy files when browsing from inside synthy.