[fluid-dev] Publish MIDI event constants

[Tom M.]

We have an open pull request that suggests to make various MIDI event constants public:

https://github.com/FluidSynth/fluidsynth/pull/468

In particular, enums 'fluid_midi_event_type', 'fluid_midi_control_change' and 'midi_meta_event' are requested to be public. The user argues that all those constants may be used in the midi player callback ( fluid_player_set_playback_callback() ).

I understand the need. However this step hasn't been done for >16 years. Perhaps to avoid that fluidsynth becomes a MIDI (parsing) library. So, before making any hasty decision, I would like to ask for opinions on this.

Tom

[Reinhold Hoffmann]

Hi,

I share the concerns to make these constants public.

In our app "fluidsynth" is just one kind of virtual midi device out of many
others. Other midi devices are keyboards, musical instruments with midi
interfaces, DAWs (Digital Audio Workstation), other synthesizers like
"Mircosoft Wavetable Synth", CoolSoft etc.

For all these midi devices this set of midi event definitions is required.
Using the fluidsynth's constants for events to/from non-fluidsynth devices
does not make sense at all and may result in an unmanageable library
dependency.

Midi devices have to comply with the official midi spec (see
https://www.midi.org/specifications). E.g. a keyboards manufacturer confirms
that the keyboard complies with this spec but the keyboard manufacturer does
not deliver a C-header file for software to be able to interface to the
keyboard through a midi interface. fluidsynth complies with the midi spec in
the same way.

Reinhold

-----Ursprüngliche Nachricht-----
Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=***@nongnu.org]
Im Auftrag von Tom M.
Gesendet: Samstag, 24. November 2018 10:42
An: fluid-***@nongnu.org
Betreff: [fluid-dev] Publish MIDI event constants

We have an open pull request that suggests to make various MIDI event
constants public:

https://github.com/FluidSynth/fluidsynth/pull/468

In particular, enums 'fluid_midi_event_type', 'fluid_midi_control_change'
and 'midi_meta_event' are requested to be public. The user argues that all
those constants may be used in the midi player callback (
fluid_player_set_playback_callback() ).

I understand the need. However this step hasn't been done for >16 years.
Perhaps to avoid that fluidsynth becomes a MIDI (parsing) library. So,
before making any hasty decision, I would like to ask for opinions on this.

Tom

[Marcus Weseloh]

Hi,

I also share the concern to make them public.

However... I think the request to have them public is perfectly
understandable. The documentation to fluid_player_set_player_callback is as
follows:

* Change the MIDI callback function. This is usually set to
* fluid_synth_handle_midi_event, but can optionally be changed
* to a user-defined function instead, for intercepting all MIDI
* messages sent to the synth. You can also use a midi router as
* the callback function to modify the MIDI messages before sending
* them to the synth.

So the intended use-case (intercepting TEXT events for a karaoke player)
seems to be in scope for this callback. We even have public
functions/macros available to get information about an event, like its type
for example. But if a user wants to actually interpret the returned
information, he needs to recreate fluidsynth internals in his own code.
That is a little inconsistent, in my opinion.

Cheers,

Marcus

[Rangel Reale]

Hello, I am the author of the pull request.

Maybe it should be better to create another separate public header, like
"midi_consts.h", so these constants, that are a liitle broad (NOTE_ON,
MIDI_TEXT) and can potentially clash with user constants, don't? So only
people who needs them includes it.

Regards,
Rangel

Post by Marcus Weseloh
Hi,
I also share the concern to make them public.
However... I think the request to have them public is perfectly
understandable. The documentation to fluid_player_set_player_callback is as
* Change the MIDI callback function. This is usually set to
* fluid_synth_handle_midi_event, but can optionally be changed
* to a user-defined function instead, for intercepting all MIDI
* messages sent to the synth. You can also use a midi router as
* the callback function to modify the MIDI messages before sending
* them to the synth.
So the intended use-case (intercepting TEXT events for a karaoke player)
seems to be in scope for this callback. We even have public
functions/macros available to get information about an event, like its type
for example. But if a user wants to actually interpret the returned
information, he needs to recreate fluidsynth internals in his own code.
That is a little inconsistent, in my opinion.
Cheers,
Marcus
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev