Menu
▾
▴
linuxsampler-devel
|
From: Levi B. <ld...@pu...> - 2003-12-22 00:20:20
|
Hello, I have not yet had a chance to try and use linuxsampler, but based on some of the mail trafic ive seen, i have a couple questions and comments. 1. Why use gig format? Isn't the gig format proprietary? Is reverse engineering a proprietary file format the best possible solution to represent sampler intstruments in a software synth that aims to be the be-all-end-all of linux software samplers? I don't. From a developer and maintenance point of view, this seems like it would be an absolute nightmare. How do you debug a commercial gig file? How do you track changes to the gig format? What about developing gig file editors? As I see it, the same problems arise here too. Which would be more beneficiary: a native linux sampler instrument format or the gig file format. Another problem: What if legal issues arise preventing linuxsampler from even using the gig file format? My suggestion is this: Design a native linuxsampler format, and build tools to convert gig files to it. Put the tools for converting into a library, which could then be extended to support conversion of other formats. The advantages would be a single point of maintenance for file format conversion, easing the burdern of developers supporting multiple file formats (they simply recompile their tools when the formats change and the conversion tools are updated). Levi -- Levi Burton http://www.puresimplicity.net/~ldb |
|
From: Mark K. <mar...@co...> - 2003-12-22 01:53:27
|
On Sun, 2003-12-21 at 16:20, Levi Burton wrote: > Hello, > > I have not yet had a chance to try and use linuxsampler, but based on some of the mail trafic ive seen, i have a couple questions and comments. > > 1. Why use gig format? Isn't the gig format proprietary? Is reverse engineering a proprietary file format the best possible solution to represent sampler intstruments in a software synth that aims to be the be-all-end-all of linux software samplers? I don't. > Hi, Because, from my point of view, we need to be able to load GigaSampler files. Simple as that. We need high quality sounds from day one. Supporting gig files is a requirement to get GSt users to try out LS. After that, possibly Halion, Kontakt, etc... It would be fine, and I think even planned, to create a new Linux format to store files in, but I don't think I'll use it to any great extent. I have LS and GSt on the same machine as dual boot. They share about 15GB of gig files. I wouldn't see much value in loading and storing all that data in two formats. There has been discussion here representing different thinking than mine, which is cool too. Cheers, Mark |
|
From: Mark C. <ma...@re...> - 2003-12-22 06:49:21
|
On Mon, 22 Dec 2003 11:52 am, Mark Knecht wrote: > > 1. Why use gig format? Isn't the gig format proprietary? Is reverse > > engineering a proprietary file format the best possible solution to > > represent sampler intstruments in a software synth that aims to be the > > be-all-end-all of linux software samplers? I don't. If you could convince some capable linux/ALSA audio engineers to spend the next couple of years working on an alternative then your point would be totally valid. > Because, from my point of view, we need to be able to load > GigaSampler files. Simple as that. We need high quality sounds from day > one. Supporting gig files is a requirement to get GSt users to try out > LS. After that, possibly Halion, Kontakt, etc... Yes, hopefully. Then eventually the itch that needs scratching to blend the best of breed from all formats into an advanced killer open audio format will become more obvious. > It would be fine, and I think even planned, to create a new Linux > format to store files in, but I don't think I'll use it to any great > extent. I have LS and GSt on the same machine as dual boot. They share > about 15GB of gig files. I wouldn't see much value in loading and > storing all that data in two formats. That depends... an open audio format would begat open gig-like samples and in this context it would make sense to use the newer open format. For me, your "15GB of gig files" would be totally useless if they were not openly sharable with other folks... it's not just a technological issue but cultural as well (for me anyway). --markc |
|
From: Mark K. <mar...@co...> - 2003-12-22 12:46:36
|
On Sun, 2003-12-21 at 22:49, Mark Constable wrote: > > It would be fine, and I think even planned, to create a new Linux > > format to store files in, but I don't think I'll use it to any great > > extent. I have LS and GSt on the same machine as dual boot. They share > > about 15GB of gig files. I wouldn't see much value in loading and > > storing all that data in two formats. > > That depends... an open audio format would begat open gig-like > samples and in this context it would make sense to use the newer > open format. For me, your "15GB of gig files" would be totally > useless if they were not openly sharable with other folks... it's > not just a technological issue but cultural as well (for me anyway). > > --markc To those of us just making music the file format doesn't really matter. I'm nat that political. The story today is that the best library developers do their work and charge money for the results. If I want to use their product, then $...$$...$$$. It's just the way it is.... That said, I use all the free gig files I can find also. - Mark |
|
From: Josh G. <jg...@us...> - 2003-12-22 08:12:54
|
On Sun, 2003-12-21 at 16:20, Levi Burton wrote: > Hello, > > I have not yet had a chance to try and use linuxsampler, but based on some of the mail trafic ive seen, i have a couple questions and comments. > > 1. Why use gig format? Isn't the gig format proprietary? Is reverse engineering a proprietary file format the best possible solution to represent sampler intstruments in a software synth that aims to be the be-all-end-all of linux software samplers? I don't. > > >From a developer and maintenance point of view, this seems like it would be an absolute nightmare. How do you debug a commercial gig file? How do you track changes to the gig format? > > What about developing gig file editors? As I see it, the same problems arise here too. > > Which would be more beneficiary: a native linux sampler instrument format or the gig file format. > > Another problem: What if legal issues arise preventing linuxsampler from even using the gig file format? > > My suggestion is this: Design a native linuxsampler format, and build tools to convert gig files to it. Put the tools for converting into a library, which could then be extended to support conversion of other formats. The advantages would be a single point of maintenance for file format conversion, easing the burdern of developers supporting multiple file formats (they simply recompile their tools when the formats change and the conversion tools are updated). > > > Levi > You may be interested in a project I'm working on called libInstPatch (part of the Swami project, http://swami.sourceforge.net), which aims to do some of the things you described. It is just starting to become generally useful, since its been in heavy development for a while now. Currently SoundFont files are the best supported, and DLS/GigaSampler loading has been added. The conversion interface is still code in progress though. Its got a Python binding at the moment which is fairly functional, although it needs more development as well. The biggest complaint I have heard, is that its not coded in C++, but it uses GObject, so like GTK+ it could have a C++ binding added to it. Personally, I think DLS is probably the best current format to support. Unfortunately the documentation for DLS2 isn't as open as SoundFont (still requires you to pay for it), but I believe the standard is "open". I'm also starting to like the idea of instrument data being stored in an XML file and each sample in its own individual file (something that has been mentioned on this list before). Cheers. Josh Green |
|
From: Mark C. <ma...@re...> - 2003-12-22 09:23:13
|
On Mon, 22 Dec 2003 06:08 pm, Josh Green wrote: > ... > Personally, I think DLS is probably the best current format to support. > Unfortunately the documentation for DLS2 isn't as open as SoundFont > (still requires you to pay for it), but I believe the standard is > "open". . IYO do you think it is feasible at this point in time to develop a high-end open instrument format ? . if paying for the DLS2 spec is a problem I'd be happy to do so if I am confident whoever gets the spec will translate it into C code. > I'm also starting to like the idea of instrument data being > stored in an XML file and each sample in its own individual file > (something that has been mentioned on this list before). Yes please. Individual binary files and meta info as plain text XML all in a directory would be very *nix friendly. --markc |
|
From: Christian S. <chr...@ep...> - 2003-12-22 12:19:41
|
Es geschah am Montag, 22. Dezember 2003 10:22 als Mark Constable schrieb: > On Mon, 22 Dec 2003 06:08 pm, Josh Green wrote: > > ... > > Personally, I think DLS is probably the best current format to support. > > Unfortunately the documentation for DLS2 isn't as open as SoundFont > > (still requires you to pay for it), but I believe the standard is > > "open". > > . IYO do you think it is feasible at this point in time to develop a > high-end open instrument format ? > > . if paying for the DLS2 spec is a problem I'd be happy to do so if > I am confident whoever gets the spec will translate it into C code. As already said, we will start to design our own format when all the basic features in the engine are done, so maybe mid of january. I have already written DLS1 and 2 loader classes (see DLS.cpp, DLS.h), but at the moment these are only used for the gig format (gig is based on DLS as you might know). Writing a custom engine for DLS won't be much effort. But at the moment I'm more tending for an XML based format for LinuxSampler's own patch format. Although DLS claims to be an "open" format, the specs are officially not, so that is IMO a big minus for DLS and I think that opinion reflects most of the ones here on the list, doesn't it? CU Christian |
|
From: Josh G. <jg...@us...> - 2003-12-23 08:30:30
|
On Mon, 2003-12-22 at 01:22, Mark Constable wrote: > On Mon, 22 Dec 2003 06:08 pm, Josh Green wrote: > > ... > > Personally, I think DLS is probably the best current format to support. > > Unfortunately the documentation for DLS2 isn't as open as SoundFont > > (still requires you to pay for it), but I believe the standard is > > "open". > > . IYO do you think it is feasible at this point in time to develop a > high-end open instrument format ? > Feasible, sure why not. I think for now I'm going to stick with DLS/SoundFont though, since they are open standards and DLS was adopted as part of MPEG4 and is supported by M$ Media player (although I don't know to what extent it is). The format is rather flexible in many regards, actually GigaSampler is based on it, if you didn't already know. > . if paying for the DLS2 spec is a problem I'd be happy to do so if > I am confident whoever gets the spec will translate it into C code. > I have a copy of the spec myself (and have already written code for it, so has the LinuxSampler project for that matter), its around $30 US dollars or something. Its from the MIDI Manufacturer's Association (http://www.midi.org). The version 1 DLS spec can be downloaded for free, but version 2 is unfortunately purchase only, which seems really stupid to me. > > I'm also starting to like the idea of instrument data being > > stored in an XML file and each sample in its own individual file > > (something that has been mentioned on this list before). > > Yes please. Individual binary files and meta info as plain text XML > all in a directory would be very *nix friendly. > It would be kind of cool :) > --markc > Cheers. Josh |
|
From: Christian S. <chr...@ep...> - 2003-12-22 12:07:53
|
Es geschah am Montag, 22. Dezember 2003 01:20 als Levi Burton schrieb: > Hello, Hi Levi! > > I have not yet had a chance to try and use linuxsampler, but based on some > of the mail trafic ive seen, i have a couple questions and comments. > > 1. Why use gig format? Isn't the gig format proprietary? Is reverse > engineering a proprietary file format the best possible solution to > represent sampler intstruments in a software synth that aims to be the > be-all-end-all of linux software samplers? I don't. The Gigasampler format is only a starting point for us. We chose it to be the first format supported by LinuxSampler because there already a lot of interesting, high quality instrument libraries which IMO beat most libraries in other formats, at least from my perspective demanding high quality natural sounds (piano, guitar, strings,...). I hope I didn't start a new thread with this proposition. ;) When we finished basic features in the sampler engine (which is hopefully done with the begin of january), supporting all articulation parameters the gig format offers, we will introduce other proprietary formats and definitely start to design our own format, which will be mandatory, because we will have to store informations that are not covered by any available patch format at the moment (e.g. think about the recompilation feature which is planned). If we get legal issues with one of the proprietary formats then we'll simply drop that format. But IMHO I don't expect that to happen. > > From a developer and maintenance point of view, this seems like it would be > an absolute nightmare. How do you debug a commercial gig file? How do you > track changes to the gig format? > > What about developing gig file editors? As I see it, the same problems > arise here too. Changes to the gig format occured very rarely in the past and new versions are usually backward compatible. But again: gig is only a starting point, when we have our own format there will be no need for an gig editor. If somebody wants to write one, fine, but we won't be dependant on that. Simply converting other formats to one and only one format was already discussed here a couple of times, but we decided to create custom engines for each format. Using OO technics the effort for this is much lower than writing an converter and an engine that supports all features for all kind of patch formats out there. That would be for me a nightmare! I hope that answered all your questions and took your fears! ;) CU Christian |
Thanks for helping keep SourceForge clean.
X