Re: [fluid-dev] MIDI mode

[David Henningsson]

address@hidden 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