[Top][All Lists]

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

Re: [fluid-dev] FS2.0 proposal

From: Bernat Arlandis i Mañó
Subject: Re: [fluid-dev] FS2.0 proposal
Date: Sat, 07 Mar 2009 19:31:58 +0100
User-agent: Mozilla-Thunderbird (X11/20090103)

Josh Green escrigué:
How did you arrive at the conclusion that we aren't getting on very
well?  I'm really excited that you are interested in working on cleaning
up the FluidSynth API and modularizing it.  From this correspondence I
realize that I have a bit more desire to overhaul things, than simply
clean them up, which might not even be that realistic at this stage.  I
think your ideas and thoughts are well thought out and the last thing I
want to do is get in the way of your efforts.  Everything you mentioned
in your proposal sounded good to me, I was simply trying to add my own
thoughts on FluidSynth 2.0.  In reality, thoughts and ideas are much
easier spoken than coded and you seem to currently have more motivation
to work on FluidSynth than I do (due to my other projects).

It's just that I thought it would much easier to get along at this early state, but it seems a bit hard for me to explain and get you going. I'm a bit scared thinking on the future. :)

We both share that desire to overhaul things, the only difference might be that I want to go step by step, I would do it along the whole 2.x path (2.0,2.1, 2.2,...).

So by all means, the forked branch is yours to do with as you will and
as we go along, I can get a better idea of how I can help.

I think that might be the easiest way to go and the best one given the current circumstances.

Bernat Arlandis i Mañó wrote:

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

I think this is not the best moment to discuss it.
> 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?

Everything you've mentioned will be involved. I've been thinking about two issues that have been talked about frequently and which are important to what I want to do, timing and locking. If you have ideas for these issues we can talk about them here in the list or we might discuss them privately and then give feedback to the list.
> > [...]
> >>  - 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.
Yes, that's what I'm asking for, but I wouldn't focus on interfaces and functions but functionality. I mean, the interface might need to change and that's inevitable, but we should try to keep the current functionality to a logical extent.
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.
It might be hard not to get disappointed by your comments since keeping the changes at a minimum should be taken as saying "don't touch anything".

You may have had the impression that I'm overlooking the stable branch, but I'm not. In fact, it's important enough to open dedicated threats to talk about it and the new release. Working on new things doesn't make it irrelevant at all, the new branch is still in the early beginning, it will take some time to have something new that is usable, and even then it will have to live with the stable branch since not everyone might want to use the new developments. Also, the new branch will feed from improvements in the stable branch, so in all aspects the stable branch is important for me.

I would like to be able to give you more details but it would take me a lot of time planning everything and writing it down before starting. This would make more sense if there was going to be several developers working on this, but since I'm going to be pretty much alone, it would be a waste of time giving detailed plans, time is scarce. Nevertheless, I'll try to explain and discuss with you the major steps that might need from your feedback specially.

I know I can't make everyone happy, but I want to be sure I don't make anyone angry. I'll try to talk a bit more about those big issues, API, locking and timing. You can also expose your ideas on these topics, either privately or in the list.

Best regards.

Bernat Arlandis i Mañó

reply via email to

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