Re: [fluid-dev] Tickets, project status, and 1.1.0

[David Henningsson]

address@hidden skrev:
> Good questions!  I converted a lot of functions over in fluid_synth.c to
> use the thread safe lock free event queue if not called by the synthesis
> thread, as we discussed.  Its not currently buildable though, and there
> is still a bit of work to do (it has started to feel a little bit like
> an overhaul).  I tested things with basic note-on/note-off messages
> through the queue, which worked fine.  I think we should try and make
> FluidSynth 1.1.0 completely thread safe (as far as crashes and potential
> synthesis anomalies).

Okay. I agree that it would be dumb to leave the thread safety
half-implemented for 1.1.0. But if you feel that you don't have the time
to work with it, perhaps we can work on it together. Let me know if you
would like that.

> One user who is building FluidSynth on the iPhone, mentioned that glib
> is not supported currently on that platform.  I started to think that we
> might want to make glib optional for certain platforms.  The iPhone
> seems like a case where building FluidSynth single threaded would be OK,
> which would mean less boiler plate as far as needing to implement the
> thread related functions.  Perhaps Windows might also be a candidate for
> optional glib, though that might be a bit more of a pain to maintain. 
> I'm leaving all glib specific code out of most FluidSynth source files
> and providing simple macro #defines or implementations in fluid_sys.c. 
> I changed g_return_if_fail to fluid_return_if_fail for example.

This means glib is something we should try to avoid rather than try to
use, when we write new code? What about the data structures (lists etc),
should we copy glib code for that, like we did before glib was introduced?

> It
> would be great to be able to just work on free software projects and
> make money at it too ;)

I read somewhere that the Daniel Langlois Foundation sponsored
FluidSynth a while ago. Perhaps you could see if they're willing to do
that again.

> I don't think we should rush the release of 1.1.0 at this point though,
> since there aren't a huge amount of features that are being held back. 
> I'd much rather get things right and have a more well rounded FluidSynth
> worthy of the 1.1.0 version bump.

On the whole I agree with you here, but I also have a personal interest
in getting it into Ubuntu. I've made sure we have 1.0.9 in the upcoming
Karmic (release in October), but I'm less sure that 1.1.0 will make it
into that version now.

> As far as I am aware there aren't a whole lot of tasks in progress at
> the moment.  While there may be many tickets assigned to myself, only
> the FluidSynth config file and thread safe event queue tasks are
> currently being worked on by me.  I'm not aware of any other tasks in
> progress.
> 
> Others on the list: Please speak up if you are currently working on one
> or more FluidSynth tasks.

As for myself, I'm not working on anything at the moment. Things I'm
thinking of fixing is one or some of these:

- Compatibility with GM/GS/XG/GM2 etc. Problems: Need do buy
documentation, unless anybody has it? In particular, fix correct default
values. This will of course be a change of behaviour, perhaps we need a
"legacy" mode as well to keep backwards compatibility?

- The player, mainly ticket #35. I was thinking that maybe Pedro would
fix this one himself, but I can do it if he doesn't want to.

- Half of ticket #24, will require some kind of "soft-stop" feature in
the audio drivers. Problems: I can fix alsa and probably also jack
drivers, but I don't have a clue about how to fix the rest of them.

Any thoughts?

> The number of developers right now is low enough to where we can
> probably simply communicate about what we are working on.  

That is, you and me? :-) And Pedro, although he doesn't seem to have
touched much of the code lately - although he should have much credit
for fixing documentation, making test cases etc!

> Anything else
> should be considered up for grabs, but it never hurts to ask and make
> sure someone else isn't already working on it.  I wish Trac had the
> ability to set the ticket back to "unassigned".  

There is a trick here: If you reassign it to yourself, trac will change
the status from "assigned" to "new".

> Perhaps adding a
> special user, as you suggested, is the best option.  

Can you do that? Call it "N/A" and let it be the default user when
someone is creating a ticket.

Enjoy the summer!

// David