Re: [fluid-dev] MIDI mode

[josh]

Quoting David Henningsson <address@hidden>:
> 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?


Not sure what you mean by that.  Are you truly asking a question or  
stating that you are annoyed?  I realize now that I was inspired to  
just code it and ask questions later, which seems to not have been the  
best coarse of action.

If you are truly asking the question, would I be annoyed if you just  
implemented something and then asked for opinions later, the answer  
is, that I don't think I would be annoyed, since it would be easy  
enough to change things as needed once we came to some sort of  
agreement.  Sometimes its easier to just implement something, to test  
and/or show what we have in mind.


> > > 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).


Understood.


> > 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.


Ok, I think having an "auto" value for synth.note-off-percuss could  
work.  It would also allow the user to tweak that particular  
functionality, even if gm or gs mode is enabled (when it has other  
side effects in the future).  We could also add other values to  
note-off-percuss, such as "gm" to ignore all but guiro and whistle, if  
it seems desirable.


> 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.


I understand your concern and I think it is well founded.  Its  
difficult for me to make releases sometimes, for the simple fact that  
I don't know when to stop adding new features, leading to endless  
development cycles.  I have a pretty clear idea of how to resolve the  
issues you stated, but the decision is, should I just backtrack what I  
have done and apply it to the next release, or finish the job?  I tend  
to want to just forge ahead and do the following, since I don't think  
it would require a lot of extra time:

- Add SYSEX handling to ALSA driver (difficulty level of EASY)
- Add SYSEX handling to MIDI parser, would cover JACK, core MIDI and  
OSS (MEDIUM difficulty, SYSEX messages would need to be allocated or  
large enough static buffer provided in parser)
- Add SYSEX to winmidi driver looks EASY (event based)
- Adding SYSEX to midishare also looks EASY (event based)

I would still like to try and make my point, that any closer we get to  
complete GM/GS handling is much better than it is now.  I don't think  
the decision is either having no support or complete support.  While  
having partial support is not ideal, I don't think it will upset  
anyone or cause any incompatibilities if we provide more complete  
GM/GS implementations in future releases (in an API compatible  
fashion).  I think users have already been expecting GM/GS support  
from FluidSynth.

This page looks nice for MIDI standards comparisons:
http://en.wikipedia.org/wiki/Comparison_of_MIDI_standards

In summary concerning percussion channels: Seems GM is fixed to  
channel 10.  GS can use 1 channel for percussion (but I guess it can  
be any channel?).  XG can have any number of percussion channels.  GM2  
uses channel 10 and 11 for percussion.  So it seems we'll need to deal  
with this in the future to some extent.


> Btw, does it make sense to add both a GM and a GS mode at this time, if
> there is no difference between them?


Maybe not, but they are separate SYSEX messages and it is indicative  
to the user as to which mode the MIDI file uses and is easy to build  
on in future versions.


> > > 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.


Adding SYSEX support to the ALSA driver is trivial.  Thanks for  
reminding me that the drivers are lacking support.


> > 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?


So you think FluidSynth should default to GM behavior then?  Perhaps I  
misunderstood you, though.  I'm pretty reluctant to do that, since I  
think there are a lot of users using FluidSynth in a generic way (not  
GM or GS).  I think we should just rely on users needing to manually  
switch it to GM or GS mode or sending a SYSEX command to do so.

I agree though, that note-off-percuss could probably provide the  
needed functionality for now, but I can also see how it would work  
fine in conjunction with midi-mode and would pave the way for future  
GM/GS improvements.


> > 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.


I am also starting to like the note-off-percuss setting, for the added  
flexibility.  I still think we should have midi-mode though, even  
though its not yet fully compliant.  It would at least give the user  
or us an idea of what the MIDI file is expecting as far as behavior.   
As I mentioned, I think users are already expecting GM/GS compliance,  
so we aren't giving them any false impression more than what they  
already have and we can indicate in the release notes that it is not  
fully GM/GS compliant yet.


> // David


I hope that helped clarify things a little.  I feel like I have a  
pretty good vision of what needs to happen and would like to just  
focus on it.  I'll give it a time frame:  if the SYSEX and midi-mode  
handling is not to some sort of stable releasable state by the end of  
this coming weekend, I'll back track and remove things as needed.

To me, your continued enthusiasm in the project is far more valuable  
than any of these decisions.  So if you still feel strongly apposed to  
my thinking, I don't think its worth trying to shoe-horn in something  
at the last minute, especially if there are objections.

Josh