The C interface lacks MIDI receiver user data

Developer's Forum for discussion of bugs, code, and other developmental aspects of the Munt Project.

The C interface lacks MIDI receiver user data

Postby realnc » 2016-1-26 @ 17:09

I tried using the C interface, but it's not very useful right now. The various callbacks of mt32emu_midi_receiver_i have no user data argument (void*), so they have no way of knowing where to send the data they get (like which mt32emu_context to use.)

All of these functions should have an extra "void *userData" argument. mt32emu_set_midi_receiver() should also take such an argument, which it then always forwards to the various callbacks. Setting a receiver would then look like this:

Code: Select all
mt32emu_set_midi_receiver(myContext.d, myMidiReceiver, myUserData);


The callbacks would then always receive the 'myUserData' pointer.

Alternatively (or perhaps even better), mt32emu_midi_receiver_i_v0 should have a "void* userData" member, which the callbacks can then access easily through their 'instance' argument.
realnc
Member
 
Posts: 143
Joined: 2010-10-13 @ 11:02

Re: The C interface lacks MIDI receiver user data

Postby sergm » 2016-1-26 @ 18:59

The approach used when those interfaces were thought up was to make them binary compatible with the majority of C++ compilers (i.e. in the COM style). However, that actually breaks the portability paradigm of the project, so I changed my mind about that.
Still, I think having a multiple of callback functions with static type checking is good and better than a single callback with typeless arguments. But, as you noted, the instance pointer semantic should change.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: The C interface lacks MIDI receiver user data

Postby realnc » 2016-1-26 @ 19:27

I'm not proposing a single callback though. Just a new void* argument to the existing callbacks, or a void* member in the mt32emu_midi_receiver_i_v0 struct.

This is pretty much the norm for any sort of C callback system. There's no other way to forward user-context to callback functions.
realnc
Member
 
Posts: 143
Joined: 2010-10-13 @ 11:02

Re: The C interface lacks MIDI receiver user data

Postby sergm » 2016-1-27 @ 07:12

Of course, there are conventional ways for callbacks in C. But I'm talking about implementations widely used in C++. Every single callback function takes the instance argument which can be used as a pointer to the object (agree, this is not obvious). Exactly the same way is used for mt32emu_context:
Code: Select all
union mt32emu_context {
   const mt32emu_service_i *i;
   struct mt32emu_data *d;
};

You may also use a cast to get the same effect, as you would cast a void*. The only difference is that you add the pointer to the virtual table at the top of your data structure (as C++ usually does when constructing such polymorphic objects). I hope that explains the idea :)

Anyway, I agree this way is pretty unnatural for C, and we cannot guarantee 100% binary compatibility with C++, so it should change. I only want to find a usable C++ wrapper for these callbacks, so the CPU won't do 3 indirect calls each time the callback is invoked.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: The C interface lacks MIDI receiver user data

Postby realnc » 2016-1-27 @ 07:21

Ah, I see. Yeah, it wasn't obvious that this isn't some reserved, internal "don't touch" mechanism.
realnc
Member
 
Posts: 143
Joined: 2010-10-13 @ 11:02

Re: The C interface lacks MIDI receiver user data

Postby BootBoyer » 2016-3-31 @ 07:31

it is looking that the approach used when those interfaces were thought up was to make them binary compatible with the majority of compilers.
Still, I think having a multiple of callback functions with static type checking is good and better than a single callback with typeless arguments. But, as you noted, the instance pointer semantic should change.
BootBoyer
Newbie
 
Posts: 1
Joined: 2016-3-31 @ 07:16


Return to MT-32 Development

Who is online

Users browsing this forum: No registered users and 1 guest