Re: [fluid-dev] MIDI mode

[josh]

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

That expression seems to describe things well and I've never heard it  
exactly as such, but I'm sure there are pretty close equivalents in  
English.

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

Good to hear!

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


I ended up implementing it like that, 1K should be plenty big enough  
for any SYSEX message we'll be handling.  I just realized though, that  
I don't think I tested the MIDI parser much prior to commit.  I'll do  
that.


> > - 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 added support to all drivers and tested them.  MidiShare ended up  
being not entirely trivial and the winmidi driver was just a plain  
PITA!  Really brain dead API they got going for MIDI on Windows.  Had  
to spawn a separate thread to re-add SYSEX buffers for use by the  
driver, since trying to do so within the MIDI input callback was  
causing deadlocks, despite many examples on the net which do exactly  
that (probably a per MIDI driver issue).

MidiShare support seems broken.  I had to hack up the source code to  
get it to even build on my Linux system.  It seemed like it would  
accept 1 event and then get in some sort of locked up state, hitting  
CTRL-C in the gdb debugger and then continuing, would cause all the  
queued events to be processed.  This bug seems to have been present  
prior to me adding SYSEX support, so its not related.  I'm not certain  
if this is a problem with FluidSynth MidiShare support or MidiShare on  
Linux.  I think the MidiShare project might be kind of dead, judging  
from the lack of releases and activity on their web site.


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


Sounds good.


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

Yeah, no doubt.  GS and XG have quite a lot of quirky features too,  
which I'm not too keen on implementing.

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

Its tempting to add all of them and the relevant SYSEX On/Off  
messages, just for the usefulness as an indicator.  So if the user  
notices it saying XG, they can be pretty sure things are going to be  
fairly broken, if its trying to use any of the extended features.

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

I think its probably better for FluidSynth to default to the "plain"  
case, for backwards compatibility, etc.  But that does mean that GM or  
GS might need to be manually enabled if a MIDI file lacks the proper  
SYSEX commands.  Perhaps some sort of auto-detect on the SoundFont  
instrument names could be done to guess if its a GM or GS SoundFont?   
But that could confuse the user too, if it gets enabled when the user  
doesn't want it.


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


I think the answer to that, is to always honor note-offs for looped  
instruments.


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


"generic" sounds like a good name for what I have been calling the  
"plain" option, I'll use that instead.

I think its kind of hack-ish to have a delay parameter, since choosing  
the proper value has some pitfalls.  It could still end up cutting the  
sound short and then only for certain instruments in certain SoundFont  
files, leading to inconsistency between instruments and confusion as  
to what is wrong.

I just realized that a per channel Volume Envelope Release offset  
generator could be set, which would extend the release stage of any  
instruments on a particular channel.  If we added some shell commands  
to allow for generators to be set on a per channel basis, then that  
would give the user the ability to set that.  A feature to add in the  
next release maybe.


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


Yeah, I think I will add both of them.  One issue I can see though, is  
that it might be nice to have the note-off-percuss setting be handled  
instead by a per channel ignore-noteoff setting.  That would be a lot  
more flexible, since you could then specify that behavior on any  
channel.  Maybe the MIDI router would be the best place for that.


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

Still having fun :)

> // David

Well it seems I kind of missed my deadline to get the MIDI mode stuff  
sorted out.  I should have that done within the next day or so though.  
 I spent a lot of time working on the Windows build of FluidSynth.   
Fixed a lot of bugs and got the TCP server working, more details in  
another email.

Josh