Re: [fluid-dev] MIDI mode

[David Henningsson]

address@hidden wrote:
> 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.

It was more of a question about how to work best as a team - it is about 
walking the thin line between two ditches (does that expression exist in 
English as well? :-) ), one ditch being that we're just talking and 
nothing is being done, and the other ditch being that everybody change 
and commit things according to his own mind. Somewhere in the middle is 
where we can be most productive together!

And as you now have taken the time to listen and answer to my concerns, 
I'm not annoyed anymore. :-)

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

The simple answer to that, is that if you're unsure, take it up with the 
fluid-dev list, and follow the recommendation ;-)

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

Recommend static buffer to avoid malloc, and since we're probably going 
to need a MAX_SYSEX_BYTE_COUNT sooner or later anyway.

> - Add SYSEX to winmidi driver looks EASY (event based)
> - Adding SYSEX to midishare also looks EASY (event based)

Feel free to go ahead and add SYSEX support to the MIDI drivers - as 
long as you're able to test it, at least.

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

Point understood, just make a note somewhere in the documentation that 
the synth.midi-mode does not do much at the moment.

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

Just to make it harder for us, they decided on four different ways to go...

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

If there is no difference; either just add GM (preferred), or add GS, XG 
and GM2 (to indicate future improvements). Does that make sense to you?

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

It is difficult to know how the majority of people use FluidSynth, but 
if we want MIDI files to "just work", they should default to ignoring 
(or delaying) note-offs at the percussion channel. I think there are a 
lot of MIDI files out there that does not have any a proper midi mode 
SYSEX, perhaps even the majority of them.

On the other hand, we have people relying on sound effects not being 
looped endlessly (as pointed out by Christian).

To default to delaying the note-off is the only solution I can see which 
will solve both use cases reasonably, but if that is unacceptable to you 
I think it is a difficult decision whether to make GM or "generic" the 
default.

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

Good :-) Then will you add both synth.note-off-percuss and 
synth.midi-mode (if they aren't there already)?

> To me, your continued enthusiasm in the project is far more valuable 
> than any of these decisions.  

And so is your continued enthusiasm also, of course.

// David