j...@resonance.org wrote:
> Yes I did take your suggestions into consideration. I probably should
> have responded before just going ahead with implementing things, kind
> of a bad habit of mine, which probably comes from many years of
> working solo on projects.
Will you be annoyed if I start to do the same?
1) We skip synth.midi-mode=gm/gs/xg for now, since it seems to require
additional thought and can delay the release of 1.1.0.
2) We add synth.note-off-percuss=ignore/process which defaults to ignore
(and "process" will behave as today). This will ignore all note off's on
channel 10 (#9) for now, so people will have to live with long guiros
unless they change the setting. This seems quick and easy to implement.
The objection I have to adding a synth.note-off-percuss setting, is that
it doesn't really address the issue directly. I think we are mainly
addressing GM/GS/XG MIDI modes for playback of MIDI files.
I think we can easily address more issues by just adding the setting,
such as the drum pad (which is likely to send on #10 by default, but
probably does not have long guiros).
By adding
that setting we would either need to continue supporting it and add
synchronization with a midi-mode setting, when it is added, or simply
remove it in future versions.
Right, but this is easily fixed with an "auto" option which lets the
midi mode decide which way to go. We could make that the default.
I think it would be better to simply add
the midi-mode parameter now, knowing that it isn't fully GM/GS/XG
compliant, but that it is moving in that direction. Users have already
been using FluidSynth in GM/GS mode, expecting it to work accordingly.
Anything we do to make it more GM/GS compliant, the better. This change
will mean that many more GM/GS MIDI files work as expected, though there
will still be some that don't behave correctly due to other areas of
non-compliance.
In weighing out the 2 options, I think adding synth.midi-mode now, makes
the most sense as far as keeping backwards compatibility.
If you still feel strongly that this isn't the right way to go, please
do convince me otherwise! :)
What currently makes me feel a bit uneasy in the context of that we're
trying to release soon, is the half-implementation of things; such as
sysex support in the midi files but not in the midi drivers, and GM/GS
support for note-off-support but not GM/GS support for ignoring bank
switches, more than one drum channel (or was that XG?), etc.
Btw, does it make sense to add both a GM and a GS mode at this time, if
there is no difference between them?
3) After 1.1.0, we could consider implementing more of gm/gs/xg,
including switching between them, and reconsider things as delaying
note-offs (at least as a setting), and specials for the long guiro.
In the interest of making more MIDI files "just work", I think having
SYSEX auto-selection is pretty important.
Also remember that some users will play MIDI files through the alsa-seq
driver instead of using the fluidsynth executable directly.
I doubt users will manually
set the MIDI mode for the particular file they are playing (they
probably don't even know or care what standard it is using). They
simply just want it to work. For this reason, I think leaving it as a
manual setting only, wont really provide much benefit.
But, assuming most MIDI files that does not contain a midi mode sysex
command are GM files, wouldn't just the note-off-percuss setting do a
good job for now?
Hope that helps clarify my own thoughts on resolving these issues. A
decision needs to be made as to what we do for 1.1.0. This initial code
change seems simple enough and should be easy to extend in a backwards
compatible manner. If you still feel very strongly that this isn't the
right direction, we can simply remove it and hold off till the next
version.
I do think we should have a synth.midi-mode setting (at least in the
future), but it must be possible to make it not control how to treat
note offs at the percussion channel. Otherwise it will never be possible
to do the right thing for custom (non-GM) drum maps. Also Christian's
argument makes much sense to me.
// David
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev