[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: Mon, 06 Jul 2009 14:24:02 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

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.

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

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


reply via email to

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