fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] FS2.0 proposal


From: Pedro Lopez-Cabanillas
Subject: Re: [fluid-dev] FS2.0 proposal
Date: Sun, 1 Mar 2009 16:36:33 +0100
User-agent: KMail/1.9.6 (enterprise 20070904.708012)

Bernat Arlandis i Mañó wrote:
> Pedro Lopez-Cabanillas escrigué:
> > Bernat Arlandis i Mañó wrote:
> >> I've been thinking a bit on what I'd like to do for FS2.0 and would be
> >> interesting to do. My goal is having a better code base to work on
> >> building new features and improving performance and compatibility
> >> without the problems we have right now.
> >
> > Please, can you elaborate what are those problems, and the goals that we
> > can't fullfill without the big overhaul you are proposing?
>
> My main complain is not being able to fix bugs and implement simple
> features without breaking API compatibility. FS is a program that is
> build as a library by exposing a lot of internals. Max has also pointed
> some of the flaws of FS as a library.

He pointed to some valid issues (i.e. const char*), and also spitted some 
bullshit. Starting by the general tone of disdain of his message.

For instance, it is true that some parts of the FluidSynth API are not well  
documented. And what would you say about this?

                http://www.musicpd.org/doc/api/html/

And when I answered that his complain about the midi player is not well 
argued, he replied that he don't care, because anyway it is not comfortable 
for him. Instead of politely asking for help in the mailing list, or 
contributing with code to fit his needs and enhance FluidSynth, he expects 
that we work for free, as a reward for his insults?

> Modularization is also a bit too rough and makes it difficult to work
> isolated in a module, or even replace modules. Timing is another thing
> that isn't well defined.

I would like to talk about the timing issues into another thread, if you don't 
mind. If you prefer to do so, privately in Spanish. Are you talking about the 
fluid_timer implementation for some platforms, or the API, or the usage of 
the timer in the midi player and the file output driver? Or about an 
implementation for the ticket #15?

> > [...]
> >>  - Helping applications developers upgrade to the new API.
> >>
> >> This is much work, and we're a just few developers with not much time. I

I would say that this is a very valid argument to keep the changes at a 
minimum, and always check that the applications using FluidSynth aren't going 
to lose needed API interfaces and functions. I mean: keep in touch with them.

Please, don't be disappointed because my comments. You asked for our opinions, 
and I've tried to be clear. My first interest, in the short term, is to 
release 1.0.9 and maintain a stable branch in order to fix bugs. Sorry if you 
feel that I am  not very supportive, because that is not my intention. I only 
would like to know more details. 

Regards,
Pedro




reply via email to

[Prev in Thread] Current Thread [Next in Thread]