[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Tuning and sysex messages
From: |
David Henningsson |
Subject: |
Re: [fluid-dev] Tuning and sysex messages |
Date: |
Sat, 26 Sep 2009 14:39:09 +0200 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
address@hidden skrev:
> Some more FluidSynth commits. Seems I've had a bit of free time as of
> late. A bad economy can be a good thing! ;)
It's not easy to keep the balance of money and time, it is difficult to
have both at the same time ;-)
> The tuning system is now thread safe and additionally now does tuning
> adjustments in real time to existing voices (as per the MIDI tuning
> standard).
Nice :-)
> 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?
> 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.
> Function prototype:
You forgot the @since tag ;-) , otherwise it looks good to me.
// David