>
> PortMidi expects strings to be of type char *, but I think the Windows
> winmm library, which includes the MIDI functions, comes in different flavors
> including ASCII and multi-byte. ...
> It's probably a design error that device and interface names are 8-bit
> characters in PortMidi, although I'm not sure what's the "right" way to do
> it: always convert to Unicode? always convert to wchar_t? defer to the local
> system MIDI API types? use macros to allow single-byte or multi-byte
> versions?.
>
I just ran into the same issue when I tried to compile portmidi as part of a
Cinder project (see libcinder.org), where the default was to compile with
Unicode as the default. To fix this, I first went down the path of allowing
both single-byte and multi-byte versions of portmidi, depending on whether
UNICODE was defined, using the technique that Windows normally uses
(separate typedefs, macros, and functions where necessary). This worked
eventually, but was quite ugly and invasive overall, especially considering
that there are only a couple of strings exposed in the external interface of
portmidi. I then realized that even if you are compiling with UNICODE
defined, you can still use the ANSI versions of the Windows functions (by
invoking them explicitly - e.g. calling RegOpenKeyExA rather
thanRegOpenKeyEx). This
turns out to be much cleaner, and the changes are limited to pmwin.c and
pmwinmm.c. The original Windows project still seems to work, compiling it
with the Multi-Byte Character Set (non-UNICODE), but you can now compile and
use it in UNICODE mode as well. I've put my modified version of those 2
files here, if you want to consider using this approach:
http://nosuch.com/tmp/portmidi
There are comments in both files which explain the approach.
...Tim...
_______________________________________________
media_api mailing list
[email protected]
http://lists.create.ucsb.edu/mailman/listinfo/media_api
