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

[David Henningsson]

address@hidden skrev:
> 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.

That's a difficult question and I don't mind other people speaking up on
this as well. It is important that the svn is not completely broken when
I want to work on things, but we should also make it as easy as
collaborate as possible.

Perhaps you could send me your code as a svn diff and we could work on
it that way until it is ready for checkin - which doesn't have to mean
that everything has to be completed, just that things aren't much more
broken than they are currently.

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

I'm personally neither for nor against glib, so I don't mind whether we
depend on it or not. But if we borrow code from glib I suggest we put it
in a separate directory. At the same time, we should review fluid_list /
fluid_hash and change it to newly updated glib code.

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

Seems like you just got your first $25 then :-)

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

I was thinking of the sample timers, the fast-render feature and
possibly the new default controller values (yet to be implemented).
Anyway, Ubuntu Karmic is already past DebianImportFreeze, so I think it
is better to make sure we get a good 1.1.0 into Karmic+1. This means a
deadline for 1.1.0 no later than november 2009. Does this seem okay to you?

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

You're talking about the other half of the ticket, I'm talking about
fixing the audio driver part. For ALSA the problem is that we never call
snd_pcm_drain.

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

Great! Could you also change the tickets that are assigned to you (i e
jgreen/assigned) to something else (e g unassigned/new) to indicate
you're not working on them?

// David