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

[josh]

Hi David,

Quoting David Henningsson <address@hidden>:
> 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.


Sure, if you would like to work on it too, that would be great.  I was  
a bit apprehensive about checking things in in a broken state.  How do  
you want to go about collaborating on things?  Do you think we should  
create a separate "work" branch or just assume that subversion trunk  
will be broken sometimes?  Once we decide this, I can check my changes  
in and describe what I'm doing.


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


Yeah..  It will make things more difficult for us.  glib is nice and  
convenient for many of these data structures.  We could make a little  
standalone glib compatibility library which gets statically linked in,  
in which we borrow code directly from glib.  The license is  
compatible, so there shouldn't be any problem with that.  It seems  
like one of the main things going for FluidSynth in certain  
environments is the minimal amount of dependencies that it has.


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


Sponsorship would be an interesting thing to look into.  Setting up  
paypal donations could also be good or having a bounty system (users  
pledge an amount for a certain task).  I have not yet seriously  
attempted making money at working on free software, though it has  
consumed much of my time in the past 10 years.  The need to make an  
income definitely affects how much time I have available for free  
software projects though, so receiving money for working on FluidSynth  
would definitely give me more time to work on it.


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

What particular features are you trying to get into the next version  
of Ubuntu?  Perhaps we could release another 1.0.x version if need be,  
which include these changes.

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


Sounds great!  Let me know how I can help make things easier for you  
to work on tasks.


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


I imagine most of this information can be found online, though perhaps  
not the complete official standard.  I've definitely seen a bunch of  
info scattered around in various places.  Things like default values  
and program instrument maps should be relatively easy to find.   
Implementing this properly would involve a current MIDI mode  
parameter, which could get triggered by SYSEX (I think that is the  
type of message that can set GM/GS/XG etc) or overridden by the user.   
There was a thread a year or more ago about this and also the more  
recent thread.


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


It seems like if the player stops and all voices have stopped, that  
means nothing else will sound, except for remaining reverb/chorus  
effect.  I've been thinking it would be nice to have some API for  
checking the current number of active voices.  This could also be used  
for the logic which determines when a song has ended.  Perhaps some  
sort of callback could be triggered when the song ends?


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


Good to know.


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

How about "unassigned"?  I'll add that.

> Enjoy the summer!
>
> // David

Cheers!
Josh