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

[Christian S. <chr...@ep...>]

Es geschah am Montag, 30. Juni 2003 15:05 als Josh Green schrieb:
> On Mon, 2003-06-30 at 16:37, Marek Peteraj wrote:
> > Hi Josh,

Hi everybody!

> > AFAIK it makes no difference under linux, you can open a /dev/hd- or a
> > /dev/scdx just like a file.
>
> Sure, but not portable and some strange formats might require low level
> hardware control. Once again I'm not opposed to this.

I don't see your problem with the low level hw acess josh. That's just a 
matter of encapsulation. Define a stream class, put the low level code in 
there and let the rest of the lib just use the methods of this stream class. 
At the moment the whole thing will be used under Linux only anyway and if 
some day somebody want to use it under OSwhatever just add the low level code 
into your stream class.

You could even decide one day to completely drop the low level approach at all 
for POSIX systems and do a simple

	f = fopen(/dev/cdrom);

That way, no matter what you do, it won't affect the code of your lib at all 
except the few lines in your stream class.

> > But instead of rewriting it as C++, woudln't it be better to write a new
> > one in collaboration with others here(Christian, Paul, Marc, me ...) and
> > design it with respect to other popular formats? The main benefit would
> > be the experience other people have with them.
>
> No no.. Not re-writing it, having a binding for it. This is what a lot
> of the GObject based C libraries have that are related to GTK+ and such.
> Thats the plus I think with C, its the least common denominator.

Maybe that's the best for the moment to leave libinstpatch as is and just 
writing a C++ frontend.

But I will never understand why people still stick with C...

> > JACK :)
>
> Of course. But I also like the abstraction that FluidSynth has, although
> SoundFont 2 centric, you can load arbitrary patch formats as long as
> they somewhat conform to the SF2 model.

And that's the problem.

> I realize that there is no reason for me to push libInstPatch/Swami
> stuff here if no one wants it, I'd rather be doing some actual work.

libinstpatch with a C++ frontend sounds good and should IMO be used in 
LinuxSampler, but I think it would be better to write a GUI from scratch. I 
would propose an observer model encapsulating the logic of the gui (e.g. 
network connection to LinuxSampler host, sample editing) and then using 
simple plugins for the actual visual part, so you can choose between gtk, 
qt,...

> What linuxsampler I think needs most right now is cooperation and
> activity. Go extend libakai if you want, I know that my time would be
> more efficiently used by working on libInstPatch. Once you have
> something, we can all decide what makes the most sense for inclusion in
> linuxsampler.

No one talked about extending libakai. That's the least problem, because these 
couple of lines can easyily incorpareted anywhere. I just thought a general 
API for the various formats would be nice, but without your support Josh it 
doesn't make sense, so just using your C++ bindings for libinstpatch might be 
the best.

Best regards,
Christian