Re: [fluid-dev] 1.1.0 release TODO and commit status

[David Henningsson]

address@hidden wrote:
> Here is my current FluidSynth TODO list for 1.1.0:
> - Fix documentation issues (private files in files list, missing docs)
> - Add new functions in fluid_synth.c to public headers.
> - fluid_sequencer_process() relative time?
> - Revert to incremental instrument selection per channel
> - Update FluidSynth man page
> - Change yes/no settings to boolean options with yes/no string 
> compatibility code.
> - Have shell "help" command default to "help help" to list help topics.
>
> Let me know if there is anything I have missed.

Before I once again forget to say it; I think config.h.in should be 
removed and ignored from svn, we keep checking it in just because we 
have different toolchain versions.

> David: What do you think about converting fluid_sequencer_process() to 
> use relative time instead of absolute?  Would there be any reason to 
> move backwards in time?  

No, not really, it's made that way out of simplicity. If you change it I 
assume you're going to need to keep an extra variable somehow - it is 
called both from seq.c and seqbind.c, from both sample and system 
timers, which work the same way.

And a lot of other things will probably stop working after 49 days (e g 
fluid_timer) so I don't really think it is important (but if we want to 
fix it in the future, an easy way out is to make it a long long).

> Ebrahim mentioned that he preferred the previous default instrument 
> assignment, which was incremental program numbers for each channel.  

It annoyed me, so I changed it. Besides being more GM compliant, there 
are several piano midi files out there that lack program change 
messages, and they now sound correct.

> This is nice for just testing out different instruments at high speed, 
> by just switching channels.  

Hmm...why would it be easier to switch channels than to switch programs?

> When we add real GM support, the 
> instruments can be reset to Piano for all channels when GM mode is 
> entered.  It might be good to keep backwards compatibility with previous 
> versions of FluidSynth in this regard.

It's a point in having backwards compatibility, but I think it is more 
important to have it consistent with the GM standard in this case.

> Most boolean setting options in FluidSynth are currently string values 
> with yes/no options.  This seems semi inconsistent and messy, since 
> there is at least 1 boolean parameter which is an integer 0/1 with a 
> TOGGLE hint.  I'm tempted to turn all boolean options into integer ones, 
> but still allow for string assignment of yes/no (maybe even 
> true/false).  This would likely be transparent to most programs.

I have also been thinking about something similar.

// David