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

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

On Mon, 2003-06-30 at 16:33, Christian Schoenebeck wrote: 
> >
> > 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.


I wrote "Once again I'm not opposed to this", which I thought would have
conveyed that I don't have a problem with it.


> 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...

Understandable. I had thought of C++ at the time when I was trying to
decide what to re-write Swami with. As to how good my decision was with
using GObject, that remains to be seen. Essentially I wanted to try to
program something that could be used by everyone, and so C seemed the
most logical choice. I like the relation that GTK+/GObject/glib has,
although I didn't really compare that with C++ toolkits. I don't think
GTKmm for GTK2 was anywhere near where it is now, so thats why I choose
GObject. If I had more knowledge of C++ and what can and can't be done,
perhaps I would have chosen otherwise, but for now I think to start
re-writing everything in C++ would be a mistake. Perhaps I may undertake
this in the future, but things are already object oriented, so I just
have to live with some of the excess C object fluff, and hope that if I
do recode it in C++ it won't be too much of an architecture change.

> > > 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.

>From the view of linuxsampler, yes, for FluidSynth, not a problem, but a
design decision. Many patch formats do fit well within the SoundFont
model, at least DLS2 and other simple formats like GUS. I'm not
completely familiar with gigasampler yet, but from what I've seen
probably a good portion of its synthesis model could fit into SoundFont
as well.

> > 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,...

Swami is becoming pluggable in regards to the GUI. I don't want to go
into it too much yet, since its not at a stage where one can actually
use it. Getting very very close though. Never underestimate how long
things can take, is what I try and remind myself of.

> 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.
> 

I've been thinking about this a bit more. For right now I'm going to
keep concentrating on Swami/libInstPatch development. This is the best
use of my time, I think. Once the new development code is usuable as a
program then I'd feel more comfortable returning to the subject as to
whether linuxsampler should make use of it or not. I definitely think
Swami has many similar goals as linuxsampler, mainly in creating a
generic instrument patch editing and composition environment. I have no
intentions of doing synthesis though, and thought that was going to be
linuxsampler's main focus. That is why I saw it as potentially 2
projects that could work happily together. It may end up being that my
choice of using C was a bad one in regards to interfacing with other
people and projects, but I still haven't come to this conclusion yet.

BTW I did look into Gtkmm to try and get an idea of what a C++ binding
would entail. The process of creating a binding for GObjects for C++
looks similar to the procedure for Python bindings, even uses some of
the same tools. So perhaps it may be quite easy to create a C++ binding.

> 
> Best regards,
> Christian
> 

Cheers.
	Josh