[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] 1.1.0 release TODO and commit status
From: |
josh |
Subject: |
Re: [fluid-dev] 1.1.0 release TODO and commit status |
Date: |
Mon, 19 Oct 2009 14:20:55 -0700 |
User-agent: |
Internet Messaging Program (IMP) H3 (4.1.6) |
Hey David,
Quoting David Henningsson <address@hidden>:
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.
Sounds good. I'll do that.
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.
Ahh, on closer look, I see what you mean (timer callbacks are passed
total time since start).
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).
I don't know of anyone using FluidSynth where it would need to run for
48+ days, but.. Lets just leave it the way it is now, we can always
add a new function in the future which takes a 64 bit long long, as
you suggested. We could then run FluidSynth for ~585 million years ;)
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.
Sounds good to me. Lets just leave it then as it is now.
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.
Ok, I'll fix this. Seems like now is a good time to do this, it being
a new 1.x point release.
// David
Josh