fluid-dev
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]