.glo, .ksd, .h2p - why use your own format ?

[Big Tick]

Devs,

Is there any good reason for not using the fxp format, which allows you to embed any kind of binary data inside a chunk ?

'Tick

[ZenPunkHippy]

Mostly for cross-platform / plug-in format compatibility. Audio Units on OS X cannot read FXP / FXB files, and VST plug-ins cannot read Audio Unit preset files. This prevents users from easily sharing presets between Mac + Windows, or between some hosts on OS X e.g. Logic + Cubase.

Peace,
Andy.

[Big Tick]

I'm still baffled, since any proprietary format won't be recognized by hosts on either platform. And still, you need to implement support for (99% of) the fxp format since the host requires you to provide a getChunk() method.

[Music Engineer]

i like my preset files to be human readable - that's why i use xml. moreover, xml makes it easy to extend the format later when the plugin gets new features. sure, i could use the "chunk" mechanism in fxp an define my own datastructure and make that extensible too - but with xml, i get all that out-of-the-box.

[Urs]

I use a text-based preset format because

a) it's human readable

b) it can contain scripts (Randomizers etc. but also programmatically generated presets by 3rd party tools)

c) Host interfaces commonly suck anyway, my internal preset browsing and organisation stuff outperforms that of most of them, and users of multiple daws have a familiar way to browse preset libraries for my stuff

Another issue is, while I manage to parse .fxp on any platform, I could not comprehend to parse .aupreset on Windows. Hence back in the days when people saved in native format (.aupreset or .fxp), there were loads of support issues where I had to convert presets from one format to the other. E.g. a certain film composer had a sound designer who worked on Mac, and they couldn't get the .aupresets to show up on the Windows machine. So I had to go through hundreds of presets and convert them to .fxp

Urs

[Ben [Camel Audio]]

Devs,

Is there any good reason for not using the fxp format, which allows you to embed any kind of binary data inside a chunk ?

'Tick

We primarily chose to have our own format (.acp) for the same reason as Robin says - because we wanted to have human readable preset files you can open up and edit in a text editor. This has proved to be a really wise decision, as its saved us huge amounts of time - debugging problems, fixing issues with broken presets, if you eg. want to change the name of an author in loads of presets you can just do search/replace in multiple files...

Ben

[arakula]

One good reason seems to be that quite some hosts are epsilon minus semi-morons when it comes to big .fxp / .fxb files. Some die, some fail. Bridges seem to be especially vulnerable. In this case, saving the file separately and providing only a reference in the chunk helps tremendously.

[very angry mobster]

c) Host interfaces commonly suck anyway, my internal preset browsing and organisation stuff outperforms that of most of them [...]

+1. It was one of the reasons I bought Zebra.

[Zaphod (giancarlo)]

One good reason seems to be that quite some hosts are epsilon minus semi-morons when it comes to big .fxp / .fxb files. Some die, some fail. Bridges seem to be especially vulnerable. In this case, saving the file separately and providing only a reference in the chunk helps tremendously.

+1

[Big Tick]

Allright guys, I understand your motives. However, your solutions basically prevent the host from dealing with presets at all, thus making it impossible to make a better host interface.

If you must use your own proprietary format, then I think it would be a good practice to at least, allow the host to send you (via setChunk) the contents of one of your own files.

'Tick

[Urs]

If you must use your own proprietary format, then I think it would be a good practice to at least, allow the host to send you (via setChunk) the contents of one of your own files.

Just make sure you crop the name of preset file to char[24] and write it into the fxp header

[Shabdahbriah]

Allright guys, I understand your motives. However, your solutions basically prevent the host from dealing with presets at all, thus making it impossible to make a better host interface.

If you must use your own proprietary format, then I think it would be a good practice to at least, allow the host to send you (via setChunk) the contents of one of your own files.

'Tick

Though I do understand the devs perspective in having their own format, and won't rant about it being Emagic's/Steinberg's own "proprietary" faults... (sigh-grrrr-sigh)

I'd ask that if you do go this route, could you please be the hero and write a nice simple "bank-editor/maker"???

TBTH, the only "text" I want to see or deal with is in a three-windowed "explorer" interface, which is a 'list' of the presets in "bank-a", in a browser-menu on the left... and another 'list' of the presets in "bank-b" on the far right, with a 'blank-window' (pre-numbered/.init bank) in between, into-which you can (select/control-click) copy/paste, or drag-and-drop anything from either "bank" to make and save your own "custom" bank(s).

Including multiples of the same preset, which could be renamed/numbered-consecutively (if needs be) so as to fine-tune/modify (radically, or subtly) and then be able to load them sequentially (in real-time/while playing).

Loading more than two banks to mix-n-match would be even cooler, as would the "blank" (.init) bank, which should come with every Vst (IMO).

This can't be 'rocket-science' (is it???), and would be a god-send for people who CREATE presets/banks, and those who do not use multiple "instances" with different presets/iterations loaded in each one, and/or mind-numbingly complex "automation" schemes in their "productions"... etc., etc.

My personal form of "automation" is "next" and "previous". Aside from the above, it would allow ALL users to get rid of all the stuff they do not want or use, and make their own "favorites" banks of the things which they DO want and use. The advantages of that "feature" alone should be obvious.

[2c]

Thank you.

~S~


.

[Big Tick]

You can guess, from my original question, that I am indeed working on something involving banks and presets

[jupiter8]

You can guess, from my original question, that I am indeed working on something involving banks and presets

I'm guessing something with a non static number of parameters.......

[Shabdahbriah]

You can guess, from my original question, that I am indeed working on something involving banks and presets

I "guessed" (sensed) only a mild frustration...

I will send you much chocolate-chip cookies if you make a bank/preset thingy.

(I'll gladly beta-test it as well)