Re: [fluid-dev] Tuning and sysex messages

[josh]

Quoting David Henningsson <address@hidden>:
> > I'm now looking into implementing SYSEX message handling, for the MIDI
> > tuning standard in particular, though other things could be added, such
> > as a MIDI interface to the FluidSynth command shell.  So, for example,
> > any FluidSynth shell command could be embedded in a MIDI file! :)
>
> Eh...we don't have an official SYSEX ID, so that MIDI file would then be
> per definition malformed?


There is a 0x7D manufacturer ID, which is meant for "non-commercial  
use (eg schools, research, etc.)", although it does say that it should  
not be used in products released to the public.  If someone is just  
embedding stuff in their own MIDI files though, that is their own  
choice.  Not real sure about this one though, since it could be  
perceived as an issue if FluidSynth is distributed with some sort of  
custom SYSEX messages that piggy back off of 0x7D.  We are  
non-commercial though!


> > At the moment I'm thinking of adding a function like below, which will
> > take a buffer containing the body of a SYSEX message and a pointer to a
> > response buffer which might get filled with return SYSEX data (if its a
> > query for example).  Its a little awkward having to guess the maximum
> > size of the response buffer, but prevents the need to do a malloc (for
> > use in a high priority MIDI thread for example).  It might make sense to
> > also add a friendlier version which allocates the response.  At the
> > moment, I don't think there are any FluidSynth MIDI drivers which send
> > MIDI data, so this feature may require some changes to MIDI drivers.
> >
> > Comments?  Thoughts?
>
> While SYSEX is definitely something to implement and a precondition for
> implementing many other features (e g GM/GS/XG mode), implementing midi
> events of variable length would need buffer allocation and buffer
> deallocation every here and there. Don't underestimate the workload. I
> hate to turn your enthusiasm down, but I think it would be better to get
> 1.1.0 (or 1.0.10 if you would prefer) out the door before doing both
> this and multi-core features.


Too late..  Its already implemented ;)

SYSEX messages are now handled in MIDI files, using an additional  
paramptr field in fluid_midi_event_t for storing a pointer to the  
dynamically allocated buffer (the size is stored to param1).  The  
tuning bank/program RPN messages should also do what they are supposed  
to.  I added a "synth.device-id" parameter which determines the SYSEX  
device ID for tuning messages (defaults to 0).

I also added some additional public functions:
fluid_synth_activate_key_tuning
fluid_synth_activate_octave_tuning
fluid_synth_activate_tuning
fluid_synth_deactivate_tuning

which are like their current counterparts but take an apply parameter  
for determining whether the tuning change happens in real time or not.  
 The old routines have been reverted to their previous behavior of  
not being realtime.

I also did some cleanup: removed fluid_midi_send_event() and some  
other stuff in fluid_midi.c and fluid_chan.c.

I did some minimal testing: loaded up a 26 key scale exported from  
Scala in MIDI Tuning Standard format in a MIDI file and verified that  
it loaded properly.  I'm sure some additional testing is in order.

With all these additions, fluid_synth.c is growing quite large.  It  
would be nice to split it up.  I'm thinking something like:
fluid_synth_tuning.c: Tuning related functions, including SYSEX at the moment.
fluid_synth_core.c: Core synthesis functions (all the _LOCAL stuff and  
synthesis process routines).
fluid_synth.c: The rest, until we see additional logical divisions.

What do you think?


> > Function prototype:
>
> You forgot the @since tag ;-) , otherwise it looks good to me.

Thanks.  Got the @since tag in there now.  The prototype ended up  
looking a little different (removed the chan field, since it doesn't  
make sense for SYSEX and added a dryrun parameter for testing if a  
SYSEX message is supported).

> // David

Now on to the more interesting task..  Multi core support.  I had a  
look over the code last night.  It seems to be pretty logically  
divided, so I'm not expecting too much difficulty in adding this.   
Will be pretty cool too :)

I'm tempted to add a new SoundFont loader API for supporting 24  
bit/floating point audio and streaming.  Perhaps I can wait till 1.2.0  
though ;)  It would be good to make sure it is designed properly this  
time and I know you want to get a release out sooner rather than later.

Cheers,
Josh