Re: [fluid-dev] Re: The 1.1.0 milestone

[Bernat Arlandis i Mañó]

jimmy escrigué:
> It seems we are all looking forward to 2.0, while 1.0 is agreed as legacy code 
> base.
>
> I don't know how far along the code refactoring (FS 2.0) is.  Can we get a 
> status update, or current functions available.  What's missing compare to 1.0.9?
>
>   
I still haven't worked a lot on it, and at least one change has been 
already merged for 1.0.9. I've fixed dependencies for the shell 
component and was working on doing the same for the synth and soundfont 
loader by uncoupling them so we could later link to any soundfont 
library. I had already planned the changes in the audio drivers that 
would fix the synth rate mismatch and would simplify timing, but I 
didn't get to implement them still.
> It may be better if we put more efforts to work toward the new 2.0 code and get 
> it to a somewhat fully functional equivalence of 1.0.9.  It would be a waste of 
> time to make changes to 1.0 code, only to have to redesign everything because 
> 2.0 won't be compatible at all.
>
>   
Right now it's fully functional and equivalent to 1.0.9, I didn't want 
to loose any functionality and it hasn't, but it has broken API 
compatibility.
> Sure, the 2.0 code could be using libInstPatch and any other libraries, or 
> features that makes sense.  Let's get a way so folks can checkout the 2.0-dev 
> code first, new patches can be posted here before checked in to the code 
> repository by a couple of main contributors for now.  This way, folks can try, 
> or test out the new patches without checking out half-broken daily updates.
>   
I decided to go by myself since there wasn't any active contributors 
interested and it was a bit hard for me to explain in detail what I was 
going to do in advance. I think is still hard to work together in the 
direction I've taken without talking a lot, but there's many things that 
can be done still in the stable branch in parallel.

Having a new branch with a similar aim to 2.0 is meaningless and not 
that useful because when the two branches differ more and more it'll be 
harder to merge some changes from one to the other. There's also some 
areas where the solution taken for 1.1.0 might not work for 2.0, so 
unless it's something critical we could rather fix issues in other areas.

On Tue, 2009-04-14 at 18:06 +0200, David Henningsson wrote:

> > Being one of the people "jumping in", I don't know much about Miguel's
> > fork/branch or the 2.0 branch. That's why I asked for some pointers, so
> > I don't have to read an entire year of messages. What I'm looking for
> > the answer to is why all of you decided to branch instead of doing code
> > cleanup one piece at a time, into the stable branch. I'm sure you had
> > good reasons for doing so, I just don't see them.
>   
The main problem was breaking API compatibility and other quality/stability 
issues that might be important for a stable branch.

I'll give my oppinion on proposals for 1.1.0 or whatever the new version is.

> Proposals for tickets for 1.1.0:
>
> - Replace some of the more ugly portability code with glib.
This might be hard to merge in 2.0 unless it's done before more changes 
land.
> - Timing related issues and faster than realtime audio rendering (#1,
> #24, #15)
This will have a different approach in 2.0, although ideas on this area 
and test cases for known issues would be useful.
> - Support dynamic change of sample rate (#6), causes improper tuning if
> audio driver rate does not match FluidSynth's rate!
This would be fixed in 2.0 by changing the audio driver API.
> - Improve voice stealing algorithm (#27)
OK.
> - Audio rendering to .wav or other audio file formats using libsndfile
> or libaudiofile (ticket #30)
This might be easy to merge, not sure, but I wonder how important is now.
> I also have some test code for doing timing metrics on FluidSynth.  It
> would be nice to have a test suite, which could do timing and synthesis
> tests.  This will be made much easier when we have improved sample based
> MIDI to audio rendering and would help to spot regressions or
> improvements in synthesis or performance.
This would be very good, although I would forget about audio rendering 
for now, this is another area for change. I think I fixed profiling for 
AMD64 systems in the 2.0 branch, but need more testing.

I would add:

- Improving the reverb function, now it's hard-tuned for a 44Khz 
sampling rate and it hasn't great quality, plus it would be great to 
have some way to know when the reverb function is idle (doesn't produce 
any sound) so we could know when rendering has really stopped. Besides, 
this would help us avoid some calculations when not needed.

- Implementing configurable LADSPA plugins for chorus and reverb effect 
as an option.

These don't require API changes and I think are interesting and easily 
portable to the 2.0 branch at any time. I bet there are more things that 
can be done without breaking API compatibility nor clashing with the 2.0 
branch. It would be good having everything as tickets on the tracker and 
labeling them for 1.1.0 or 2.0.

I don't mean to be an obstacle for new development, so if this sound too 
restrictive for the new programming forces we should decide whether we 
hold to the old 2.0 plan or refrain from it and start another one. You 
should understand that doing long-term work on a project that might 
shift direction anytime isn't pleasant.

--
Bernat Arlandis i Mañó