Re: [Linuxsampler-devel] libakai what's next

[Josh G. <jg...@us...>]

On Sun, 2003-06-29 at 19:25, Marek Peteraj wrote:
> Hi Josh,
> 
> Yeah i know, but i've got a few concerns regarding libinstpatch, first
> of all i'd like to refer to some of your previous mails:
> 
> <snip>
> <1>
> 
> Of course it might make sense to use this
> library directly instead of implementing it in libInstPatch, depending
> on how flexible its API is. Then again it might be more convenient if
> the code was part of libInstPatch.
> 
> <2>
> ...because I'm thinking that filesystem and lowlevel device
> access code really does not belong in libInstPatch. It seems somewhat
> like a portability nightmare and I wan't to try and keep libInstPatch as
> portable as possible.
> 
> <snip>
> 

I seemed to recall writing emails later, retracting some of those
statements. I'm actually not opposed to writing that sort of code into
libInstPatch, but I'd prefer to try and use file images rather than
accessing low level hardware.

> The thing is that there's a majority of diskbased formats out there
> (at least those we need, there's halion and exs24 format as well)
> 
> http://www.pleasewipeyourfeet.com/webtest/linuxsampler/samplerformat.html
> 
> Second thing is that libinstpatch is really C, while C++ is more
> desirable for this project(i'm not really C++ myself right now, but
> there's lots of people here who are C++, there's Benno, Juan, Christian,
> Marc, and there's a few more lad members in lurk mode all of which are
> c++ afaik :)
> 

Nothing stopping libInstPatch++.

> Third thing is that it might be more desirable to design an API/lib
> around formats which are most widely used and popular in the pro audio
> world, such as akaiS1000/3000, Gig.
> 

libInstPatch isn't designed around any particular format. Thats the nice
thing about it. I don't think you want to design any instrument library
around a particular format if its going to support multiple formats. I
think some formats make more sense to write import loaders for rather
than full on object manipulation/save support, though.

> Finally i'd like to say that i'd rather see this project go the "from
> scratch" way for everything(format lib, engine, GUI), 

I'd rather see linuxsampler go the way of interoperability, so that
other projects can easily integrate and co-operate with linuxsampler.
What you a describing might then become something of a collection of
programs working together, which is the way I see Linux audio going.
Creating one large project is just too un-manageable in my opinion, I
think the goals of Swami are almost too much to manage.

> although it might
> seem that it's just reinventing the wheel again.   
> 

Yes, it does. But thats how the open source world works at times so go
ahead. I'll be working on Swami/libInstPatch, which I would love to see
work with linuxsampler in the future. And yes, I think I would be a
little disappointed if another project was started with similar goals,
but thats unfortunately also how the open source/free software world
goes. I think there is quite a lot of man hours put into the API design
of libInstPatch though, hell I re-wrote it like 3 times now.

> 
> Marek

Cheers.
	Josh Green