|
From: Marek P. <ma...@na...> - 2003-11-26 00:33:29
|
On Tue, 2003-11-25 at 03:43, Mark Knecht wrote: > On Mon, 2003-11-24 at 19:17, Marek Peteraj wrote: > > What i was talking about was - it has to sound like Gst if you want it > > to sound like Gst. But it can sound like anything else, or custom. My > > point was - flexibility. > > > > What we're aiming at AFAIK is to provide 100% .gig support, not Gst > > support. We just want to take full advantage of the .gig format, > > anything beyond that could be considered as reverse-engineering Gst(or > > any other app) which is forbidden. > > > > what i was trying to propose was to make the velocity system as flexible > > as possible from the start, so that it would handle virtually any kind > > of situation, custom settings, or that it could be used in conjunction > > with virtually any sampler velocity emulation, not just Gst. > > I have no problem with anything you wrote. > > > > > > > > > If LS doesn't play gig files so that they sound substantially the same > > > as GSt then $$$$$ of dollars of gig files are useless to people that use > > > GSt today. > > > > You forgot the akai users, the exs24 users, halion users, kontakt users, > > nnxt(not sure about that name, the reason sampler), and roland users(old > > hw samplers s-7xx). :) > > No, I didn't really. I just fundamentally don't want things to get > overly complicated supporting all this stuff before GSt support works > very well. 100% audio compatibility with GSt, then do whatever else you > want as we grab lots of new users. You'd grab a lot more users with akai support. What i don't like is to prefer one format over another and compromising designs in favor of one format if a general solution can be found or at least worked out in a reasonable way. I see linuxsampler as a project that aims to provide all features that another sampler would provide and more, a project that is innovative and unique, comfortable and userfriendly, efficient. *That's* what's going to get us tons of users. A fully fledged sampler, not a simple gig playback engine with a simple gui although 100% comatible and faithfully playing any .gig. I don't want LS end up being called as a Gst clone just because its name is similar to Gst and that it provides 100% compatibility, even if only for the beginning. So what i'm suggesting in general is - if .gig offers a certain model or system, can we extend upon that? how far can we go? is the model limited? is an unlimited model possible? If yes, let's implement that instead of the limited gig one, becasue the unlimited one will provide the same functionality. Will it take longer to develop? Certainly. But in the end we'll all have something better. And the development process could speed up considerably later on if the current code allows to easily implement other models/systems just because it was designed to be as flexible as possible, not just limited to one format. Marek |