macos ump endpoint backend

[timrae]

I'd like to use this repo for testing UMP IO in one of my projects, so would be great to get this WIP feature completed.

[jcelerier]

heya! thanks a lot! I'm actually in the midst of a fairly large refactor for this but it's been taking dust in the last months due to other work.
My current work (not pushed yet) is to separate things in two libraries:

• A library that handles the connection to the OS-provided context object for media operations.
  As on macOS it's pretty separate but for instance on Linux, JACK handles both MIDI and Audio, and PipeWire handles MIDI, Audio and Video communication from a single object.
  Having it being hidden inside libremidi has been quite the pain point for me: it means that an app needs to instantiate three times a pipewire_context to handle audio, video and midi where they could only have one lib that will give access to "the context object that the platform provides", which can then be plugged in libremidi or for instance cross-platform audio libraries such as RtAudio or libossia (the main thing I work on as part of https://ossia.io).
• A library that takes this context object and adds support for UMP on top of it, through this ump_endpoint concept.

Does that design make sense to you ?

[timrae]

@jcelerier
It's hard to say without getting into the weeds, but my first impression is that would be overkill creating a whole second library for creating the context because:

1. That's a totally different use case from this library that you would now need to maintain, do you really want that?
2. I'm concerned it would unnecessarily complicate the API of this library and add a new dependency, without adding much value
3. The "platform independent" part of the first library doesn't really make sense, as it's only really Linux that mixes non-midi capabilities in the same API. Windows UMP backend may also need COM apartment injection, but this just kind of shows to me that the contexts across platforms are fundamentally different types with different ownership models, so any Library 1 abstraction would be a thin per-platform wrapper with no real common interface, not a genuine unified abstraction.

What exactly is the limitation of the current "inject your own context" approach? Looking at the PipeWire backend, it seems the current context field in pipewire_input_configuration accepts a pw_main_loop* — but even with that injected, libremidi still creates its own pw_context and pw_core internally, so you'd still end up with a separate daemon connection. Is that the core of the pain point? If so, would extending the injection to also accept an already-created pw_context*/pw_core* solve it, without needing a separate library?