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

[josh]

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


Let me put a little more work into the current changes, so it builds  
and works for the most part.  Then I'll send it your way.  I'll try  
and do this in the next few days.


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


Sounds good.


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


Indeed!  It reminds me of how little effort I've put into making money  
on free software.  For some reason it has always been more difficult  
for me to justify getting paid to work on free software, versus "real  
work".  Seems like an ideal situation though!


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


Sure, that sounds like a good deadline.


> > > - 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 I didn't understand that half of it then.  So this is related  
to not flushing all the audio from the audio driver's perspective.   
Should this be done in the close() method?


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


Done.  I now have 2 tickets :)  I'm planning on working on some of the  
other ones, but since I'm not currently doing so, they are open for  
someone to grab.


> // David

Cheers!

Josh