j...@resonance.org 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
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev