Re: MIDI Standard Specs WAS Re: [fluid-dev] Tickets, project status, and 1.1.0
On Monday, July 6, 2009, Graham Goode wrote: > For GM1 and GM2 specs see http://en.wikipedia.org/wiki/General_MIDI, > http://www.midi.org/techspecs/gm.php > For GS download a Roland Sound Canvas manual from > http://www.edirol.net/products/en/archives.html and see the appendix > lists > For XG try > http://web.archive.org/web/20060926124939/http://www.yamaha.co.uk/xg/readin >g/pdf/xg_spec.pdf Worth to mention: http://home.roadrunner.com/~jgglatt/ (includes a complete and free MIDI specification reference). There are printed books on bookstores containing the whole MIDI specification. I guess they may be a better investment than buying the overpriced spec from midi.org. For instance: MIDI Programmers Handbook http://books.google.com/books?id=cakdHQAACAAJ And more... http://books.google.com/books?q=MIDI+specification Regards, Pedro ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: minor FluidSynth sponsorship opportunity (Re: [fluid-dev] Tickets, project status, and 1.1.0)
Hello Kevin, Quoting Kevin Fishburne : j...@resonance.org wrote: Hello Kevin, I did some research on these parameters by also looking at the source code. The FluidSynth C API differs as far as the allowable ranges for some reverb/chorus parameters in comparison to the command interface. This seems like a bug to me. Thanks Josh, hopefully soon you'll all be able to check out my new app, to which I've found nothing comparable yet. QSynth gets the job done, but it has some bugs and SoundFont management isn't really present yet. I sent you the $25, so spend it wisely (on beer, for example). I'd like to see your app. It sounds like a useful program. Swami also has the goal of providing SoundFont management and library support, but after all these years in development, it still isn't complete. - rev_setlevel command takes -31.0 to 31.0 but the code clamps this value between 0.0 and 1.0, so that is the actual usable range. When you say "clamps" do you mean it scales the input values from the -31.0 to 31.0 range to the 0.0 to 1.0 range or that it clips input values that are outside the 0.0 to 1.0 range? For example, were the former the case it would do something like: realvalue = (inputvalue + 31) / 63 Were the latter the case then it would assume that a value less than 0.0 is equal to 0.0 and a value higher than 1.0 is equal to 1.0. I need to know if I should feed the command values between 0.0 and 1.0 or -31.0 to 31.0. The latter is the case. If any value less than 0.0 is received, 0.0 is assumed, above 1.0, 1.0 is assumed. - cho_set_nr is not Chorus delay from what I know. Its actually the number of Chorus "voices". I pulled that info from the Chorus section of the UserManual on the Documentation page. It describes the /cho_set_nr/ command as "Use n delay lines (default 3)". Is there such a command/parameter as "delay," or is cho_set_nr the only other available setting for chorus other that what we've already discussed? If so, should it better be described as "chorus voices" then? The Chorus code was adapted from some other existing code. From what I can tell there was originally a Delay parameter which was separate from the NR parameter. It likely controlled when the effect actually kicked in or something. It is not used in FluidSynth. It seems to me like number of chorus "delay lines" and number of chorus "voices" describe the same thing. I'm definitely not an expert on the Chorus effect, so perhaps my terminology is faulty also. At any rate, increasing NR causes the chorus effect to have more voices. Thanks for the excellent info and I'll post the source and executable of my app as soon as it's ready for use. It's programmed in GAMBAS, which although is an awesome language/app it doesn't seem to be as widely used as I'd like it to be. Luckily the GAMBAS runtime is in the Debian and Ubuntu repositories so my app should be immediately usable by newbies. Great. Glad you are finding FluidSynth useful and improving upon it. KEVIN FISHBURNE Eight Virtues www: e-mail: phone: http://sales.eightvirtues.com[1] sa...@eightvirtues.com[2] (770) 853-6271 Cheers! Josh Green ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Tickets, project status, and 1.1.0
Quoting David Henningsson : 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. Of course, if we're finished in september, that would be even better. FluidSynth are distributed to many more places than just Ubuntu. Yeah, I guess I should have said.. Sounds like a good worst case deadline. I'm all for getting a release out before then. Done. I now have 2 tickets :) Eases the burden somewhat, huh? :-) Well I didn't really consider all those tickets to be assigned to me in the first place ;) // David Cheers! Josh ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: minor FluidSynth sponsorship opportunity (Re: [fluid-dev] Tickets, project status, and 1.1.0)
j...@resonance.org wrote: Hello Kevin, I did some research on these parameters by also looking at the source code. The FluidSynth C API differs as far as the allowable ranges for some reverb/chorus parameters in comparison to the command interface. This seems like a bug to me. Thanks Josh, hopefully soon you'll all be able to check out my new app, to which I've found nothing comparable yet. QSynth gets the job done, but it has some bugs and SoundFont management isn't really present yet. I sent you the $25, so spend it wisely (on beer, for example). - rev_setlevel command takes -31.0 to 31.0 but the code clamps this value between 0.0 and 1.0, so that is the actual usable range. When you say "clamps" do you mean it scales the input values from the -31.0 to 31.0 range to the 0.0 to 1.0 range or that it clips input values that are outside the 0.0 to 1.0 range? For example, were the former the case it would do something like: realvalue = (inputvalue + 31) / 63 Were the latter the case then it would assume that a value less than 0.0 is equal to 0.0 and a value higher than 1.0 is equal to 1.0. I need to know if I should feed the command values between 0.0 and 1.0 or -31.0 to 31.0. - cho_set_nr is not Chorus delay from what I know. Its actually the number of Chorus "voices". I pulled that info from the Chorus section of the UserManual on the Documentation page. It describes the cho_set_nr command as "Use n delay lines (default 3)". Is there such a command/parameter as "delay," or is cho_set_nr the only other available setting for chorus other that what we've already discussed? If so, should it better be described as "chorus voices" then? Thanks for the excellent info and I'll post the source and executable of my app as soon as it's ready for use. It's programmed in GAMBAS, which although is an awesome language/app it doesn't seem to be as widely used as I'd like it to be. Luckily the GAMBAS runtime is in the Debian and Ubuntu repositories so my app should be immediately usable by newbies. Kevin Fishburne Eight Virtues www: e-mail: phone: http://sales.eightvirtues.com sa...@eightvirtues.com (770) 853-6271 ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Tickets, project status, and 1.1.0
j...@resonance.org skrev: > Quoting David Henningsson : >> j...@resonance.org skrev: >> 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. Works for me. Of course I'm not made of time either, but I think I can spare some every now and then :-) >> 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. Yep, until we're looking for volunteers and everybody looks down at the floor ;-) >>> 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. We also have Google Summer Of Code, but I'm not sure that FluidSynth is big enough to attract their attention. (And we need a student as well, btw.) >> 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! People make software for free because it warms the heart (giving back to the community that has given him/her good software), and for fun. But not everyone can work on the fun parts, or GNOME would have hundreds of 3D screensavers (oh wait, bad example ;-) ). But for the boring work that nobody wants to do for free, adding money as a compensation seems like a good idea to me. And, it does speed up the rate of which things are being done, which is also important. >> 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. Of course, if we're finished in september, that would be even better. FluidSynth are distributed to many more places than just Ubuntu. - 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? To not get too much off-topic I'll continue this part as a comment to ticket #24: http://fluidsynth.resonance.org/trac/ticket/24 >> 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 :) Eases the burden somewhat, huh? :-) // David ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Tickets, project status, and 1.1.0
Quoting David Henningsson : j...@resonance.org 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 ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Tickets, project status, and 1.1.0
j...@resonance.org skrev: > Hi David, > > Quoting David Henningsson : >> j...@resonance.org 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 e
Re: minor FluidSynth sponsorship opportunity (Re: [fluid-dev] Tickets, project status, and 1.1.0)
Hello Kevin, I did some research on these parameters by also looking at the source code. The FluidSynth C API differs as far as the allowable ranges for some reverb/chorus parameters in comparison to the command interface. This seems like a bug to me. Notes: - cho_set_nr is not Chorus delay from what I know. Its actually the number of Chorus "voices". - rev_setlevel command takes -31.0 to 31.0 but the code clamps this value between 0.0 and 1.0, so that is the actual usable range. - rev_setroomsize command takes 0.0 to <1.2. The actual value 1.2 seems to fail the test <1.2 for some reason (1.199 works for example, but 1.2 does not). - fluid_revmodel_setroomsize, fluid_revmodel_setdamp, fluid_revmodel_setwidth do not check or clamp the input value. Setting values outside of the allowed command range, could lead to unexpected behavior. - Max allowed chorus depth depends on sample rate of synth. 22050 = ~92.92, 44100 = ~46.46, 48000 = ~42.68, 96000 = ~21.34 default, min, max: Gain: 0.2, 0.0, 10.0 Reverb Level: 0.9, 0.0, 1.0 Reverb roomsize: 0.2, 0.0, <1.2 Reverb damping: 0.0, 0.0, 1.0 Reverb width: 0.5, 0.0, 100.0 Chorus nr: 3, 0, 99 Chorus level: 2.0, 0.0, 10.0 (reasonable level is < 1.0) Chorus speed: 0.3, >0.29, 5.0 Chorus depth: 8.0, 0.0, (depends on sample rate) Chorus mode: FLUID_CHORUS_MOD_SINE Seems like a bit of a mess to me. I think it would be nice to have individual FluidSynth settings parameters for these, then the valid range could be queried from the API. I added a ticket for this: http://fluidsynth.resonance.org/trac/ticket/49 $25 would be most appreciated and was definitely an incentive to research this! You could send it to my paypal email address: jgr...@users.sourceforge.net. Best regards, Josh Green Quoting Kevin Fishburne : j...@resonance.org wrote: 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. On that note if anyone can correct/verify and fill in this table I'll pay them $25 U.S. by whatever method they like. I pulled some additional tentative values by issuing commands with various numbers to a FluidSynth server daemon, which sometimes would reply with "Values should be between x and y". Also if anyone knows if these value ranges differ between the shell, server, and API interfaces that would be extremely useful. I perused the source code to the best of my ability and could only pull some possible value ranges for these settings. EFFECT MEASUREMENT TYPE DEFAULT MINIMUM MAXIMUM COMMAND Gain float 0.2 0.0 5.0 gain x Reverb Level float 3.0 0.0 < 31.0 rev_setlevel x Reverb Room Size float 0.84 0.0 1.0 rev_setroomsize x Reverb Damping float 0.2 0.0 1.0 rev_setdamp x Reverb Width float 1.0 0.0 100 rev_setwidth x Chorus Level float 0.0 30.0 cho_set_level x Chorus Delay Lines integer 3 0 100 cho_set_nr x Chorus Speed Hz float 0.295.0 cho_set_speed x Chorus Depth ms float 0.0 10.0 cho_set_depth x I need this in order to finish a FluidSynth GUI and SoundFont management app. It's already pretty much completed but I need to adjust the slider value ranges so they are consistent with each other and have sane defaults. KEVIN FISHBURNE Eight Virtues www: e-mail: phone: http://sales.eightvirtues.com[1] sa...@eightvirtues.com[2] (770) 853-6271 Links: -- [1] http://sales.eightvirtues.com [2] mailto:sa...@eightvirtues.com ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
minor FluidSynth sponsorship opportunity (Re: [fluid-dev] Tickets, project status, and 1.1.0)
j...@resonance.org wrote: 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. On that note if anyone can correct/verify and fill in this table I'll pay them $25 U.S. by whatever method they like. I pulled some additional tentative values by issuing commands with various numbers to a FluidSynth server daemon, which sometimes would reply with "Values should be between x and y". Also if anyone knows if these value ranges differ between the shell, server, and API interfaces that would be extremely useful. I perused the source code to the best of my ability and could only pull some possible value ranges for these settings. Effect Measurement Type Default Minimum Maximum Command Gain float 0.2 0.0 5.0 gain x Reverb Level float 3.0 0.0 < 31.0 rev_setlevel x Reverb Room Size float 0.84 0.0 1.0 rev_setroomsize x Reverb Damping float 0.2 0.0 1.0 rev_setdamp x Reverb Width float 1.0 0.0 100 rev_setwidth x Chorus Level float 0.0 30.0 cho_set_level x Chorus Delay Lines integer 3 0 100 cho_set_nr x Chorus Speed Hz float 0.29 5.0 cho_set_speed x Chorus Depth ms float 0.0 10.0 cho_set_depth x I need this in order to finish a FluidSynth GUI and SoundFont management app. It's already pretty much completed but I need to adjust the slider value ranges so they are consistent with each other and have sane defaults. Kevin Fishburne Eight Virtues www: e-mail: phone: http://sales.eightvirtues.com sa...@eightvirtues.com (770) 853-6271 ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Tickets, project status, and 1.1.0
Hi David, Quoting David Henningsson : j...@resonance.org 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,
MIDI Standard Specs WAS Re: [fluid-dev] Tickets, project status, and 1.1.0
Hi, For GM1 and GM2 specs see http://en.wikipedia.org/wiki/General_MIDI, http://www.midi.org/techspecs/gm.php For GS download a Roland Sound Canvas manual from http://www.edirol.net/products/en/archives.html and see the appendix lists For XG try http://web.archive.org/web/20060926124939/http://www.yamaha.co.uk/xg/reading/pdf/xg_spec.pdf Hope that helps... GrahamG ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Tickets, project status, and 1.1.0
j...@resonance.org 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. > 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? > 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. > 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. > 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: - 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? - 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? > 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". > 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. Enjoy the summer! // David ___ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
Re: [fluid-dev] Tickets, project status, and 1.1.0
Hello David, It is indeed a nice summer here too where I am, which is one of the reasons I've been on my computer less as of late :) Quoting David Henningsson : Hello Fluidsynth community, I hope that you are enjoying yourselves and have a great summer (or winter, or rain period, or whatever depending on where you live :-) ). At least it's quite warm in southern Sweden currently! Anyway, it has not been much activity in the fluid-dev and the code base lately. If I remember correctly, the 1.1.0 release was scheduled to be released in the end of July or in August, which is a month from now. So I think it would be nice if we could sum up how we're progressing. * A few weeks ago Josh and I discussed how we could improve the thread safety inside the synth engine, which Josh volunteered to do. It would be nice to know how this is progressing, and if it is scheduled for 1.1.0 or not? 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). 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. * We have a number of tickets that are assigned to the 1.1.0 milestone, but are yet to be implemented. I guess whether these are fixed before 1.1.0 are merely an indication that "it would be nice if this was fixed ASAP" rather than an absolute requirement, do you agree? I agree with the optional nature of the tickets for 1.1.0, it was more of a wish list. I've been spending very little time on programming outside of work as of late. Its been rather apparent to me recently, that I shouldn't be on the computer as much as I have been at times! It would be great to be able to just work on free software projects and make money at it too ;) 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. Coming to speak of tickets, it is currently not obvious to know what people are working on and what bugs are looking for volunteers. Here's a suggestion: * If a ticket's status is "assigned", the person listed as "owner" is planning to fix it - preferably in the next few weeks. * If a ticket's status is "new", the person listed as "owner" is somewhat thinking of fixing it, or can share some thoughts about it, but is not planning to fix it in the near future. * If a ticket is looking for volunteers, it should be owned by a new virtual user called "nobody" or something similar. This should be the default for newly created tickets. 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. The number of developers right now is low enough to where we can probably simply communicate about what we are working on. 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". Perhaps adding a special user, as you suggested, is the best option. But maybe that is overly complicated at the moment and we can just keep track of what each person is working on. If this is not fine-grained enough, one could write something more explicit as a ticket comment. What do you say? // David Thanks for keeping things on track. I'm going to try and put some time into FluidSynth this week and do my best to get something working in regards to the thread queue implementation. Cheers! Josh Green
