Re: [fluid-dev] FS2.0 proposal

[Bernat Arlandis i Mañó]

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.


Pedro:
> 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ñó