Multi wav fileformat?

[thockin]

Re: velocity mapping - I think it IS needed, or this would be wasted time. Velocity is 'special' in MIDI (don't get me started on how that is wrong, but it that is how it is).

1) I don't think any particular existing archive format is necessary, is it? Roll your own and make a utility to pack and unpack them (as well as convert from SF2, etc)

Open standards amigo, that was half the point. If it is simple zip, then I can use any zip editor to view, extract, or create these files.

2) Compression should be left to an external app, sort of the way sfpack and sfark do things.

Agreed, which is why I suggest tar format. It's *really* simple.

3) Are we keeping an eye towards platform-interop for the binary portions? Should samples be allowed in aiff, as well? mp3, ogg?

To stay cross platform you want to LIMIT choices, not offer them. MP3 has a host of issues. Ogg is great, but I think the right answer is wav.

We'd also need to somehow set convention for mono vs. stereo, encoding, sample rate and bit depth.

Something like "All the samples in an archive must have the same sample rate, channel count, and bit depth, or the behavior is undefined." and "Any wav encoding may be used, though non-PCM encodings may limit cross platform use of an archive. PCM encoding is reccomended."

4) As pointed out, where are sample lengths and loop points? Of course, these could be embedded in an internal .wav or .aif file, but how will the other formats cope?

See above. Sample length is intrinsic to a wav file, and loop points are embedded within the wav file.

5) Muting group? Hey, this ain't no stinkin' drum machine!

Possibly true - that CAN be done well at the plugin level. I'd vote to nix it.

6) More important than the file-format is perhaps the API for use in the synth's development! I'd naturally gravitate to providing a solid C++ class first of all, which could be ported later to other popular audio dev

If the specification is simple enough and clear enough, we don't NEED an SDK or anything beyond the DTD for the metadata. By all means write all the C++ code you want, but when it comes time to implement this format reader, it should take a few hours AT MOST.

That's the hallmark of simplicity, to me

[pljones]

If the specification is simple enough and clear enough, we don't NEED an SDK or anything beyond the DTD for the metadata. By all means write all the C++ code you want, but when it comes time to implement this format reader, it should take a few hours AT MOST.

Absolutely. The point of the XML format is you've a whole host of standard/widely-available libraries to choose from. You don't want to mandate a particular toolset. Same goes for handling the binary portions. Personally, I'd say anything is allowed but "here's the minimum a consumer of the file format must recognise" - i.e. wav, key-map, vel-map, done!

I would like to see the format extensible enough to support importing an SF2 instrument into the XML format and being able to recreate a SF2-format instrument without degradation. Ideally, the same for other existing sample formats -- BUT! These would be via extensions to the minimal schema which could be ignored by a consumer of the XML-format data.

[thockin]

pljones,

If someone extends Foo (for lack of a name) and still calls it Foo, you then have a case of their Foo files working better on their player than other players. Bad.

Foo is what it is. Anything that is not Foo should not be named Foo. They may be Foo compatible, or a superset of Foo, but they are not Foo

[Markleford]

Open standards amigo, that was half the point. If it is simple zip, then I can use any zip editor to view, extract, or create these files.

The standard could be open without using existing tools: all you have to do is publish what you come up with. While it's cool to blue-sky the fact that you could use a zip editor to construct these files, what good will it do you in common practice?

If I have a choice to use a special-purpose app to create these files versus WinRar, I'm going to use the special-purpose app. After all, what good is it to add or remove a .wav to your file if it doesn't update the XML config file automatically?

I suppose there's really no harm in using zip or tar if you want, but I think the return on that decision would be fairly minimal in reality. You're still going to have to write a special-purpose app for editing these files no matter what you choose.

Mind you, I have no compelling reason to go home-brew: I'm just telling the other side of the zip story!

- m

[Markleford]

If the specification is simple enough and clear enough, we don't NEED an SDK or anything beyond the DTD for the metadata. By all means write all the C++ code you want, but when it comes time to implement this format reader, it should take a few hours AT MOST.

However, if you want your format to be widely adopted, you *should* provide an SDK. If you can save a dev those "few hours", it makes them that much more productive on the meat of their app. (And they'll tell all their peers how easy it was to integrate support for your format!)

You certainly wouldn't expect everyone to write their own SynthEdit module for this format, right? That's why it's already been suggested that one be made available to the public near the beginning. I see it being the same way for native-code devs.

- m

[thockin]

While it's cool to blue-sky the fact that you could use a zip editor to construct these files, what good will it do you in common practice?

Well, if I want to extract a wave file from the format, it's simple. If I want to see how it works, it's simple. If I want to replace a wave file with another, it's simple.

That aside, why define something new that does teh exact same thing as something old? It's not like there are things about tar that make it BAD for this, and it's not like there are any licensing issues.

I mean, we could use a custom meta-data file format, too, but why bother?

[pljones]

You certainly wouldn't expect everyone to write their own SynthEdit module for this format, right?

If you mean a .SEP that turns MIDI note on into Audio based on a selected XML document, then... I can see the benefits in doing that much just once. The same .SEP source, of course, would be the kernel of any VST plugin, plus/minus Jeff's API vs VSTSDK. But if I implemented it, I might rely on libsndfile to do the wav/aiff handling, whereas another person might prefer to go direct to disk and do their own buffering etc. So I can see there being multiple implementations of the .SEP/VST kernel module for different purposes.

The schema is the what gives you the power to implement any solution using any toolset. If a provider wishes to provide a pre-built tool based on the schema, that's good. (Like I've said, I'm probably more interested in using the schema as a way of "decompiling" SF2 files into a format I can edit comfortably. I really do prefer handing text files and doing stuff manually, to having some automated tool built to someone else's idea of user-friendly.)

[Rock Hardbuns]

Wow, what activity
Great!

Velocity mapping stays. The plugin can always implement velocity curving to offset the ranges.

I prefer zip before tar. No 1 reson being that there are already a number of file formats out there that implement simmilar structures with zip such as the open office files and java jar files.
Also, there are freely available zip libs and dlls for basicly all languages and platforms. Tar may be easier to implement in it self, but there is not as much premade code to deal with it.

I agree with thockins restrictions on the wave file formats.

How about naming the format KMWAV (keyboard mapped wav). Theres no reason to stick with 3 char suffixes anymore, is there. Then there could also be KMAIFF and possibly even KMOGG. All distinct formats built on the same structure.
This avoids a great deal of confusion.

Im gonna rewrite the spec draft and start a new thread I think.. this ones becomming a bit cluttred

[Markleford]

It's not like there are things about tar that make it BAD for this, and it's not like there are any licensing issues.

True enough. Have at it!

- m