[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: josh
Subject: Re: [fluid-dev] Tickets, project status, and 1.1.0
Date: Tue, 07 Jul 2009 12:08:38 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]