OK, well, obviously just writing this made me rethink a bit, and I managed to
get client B running in the correct thread, so it receives notifications and
immediately sees changes to the system setup. So that’s great.
I’m still intrigued to know why it wasn’t seeing anything before though, when
it had no callback - seems like maybe the callback addition triggers something
in the client which sets a different mode, or ignores a cache, or ...
something? Would love to know how that works and what the rationale is, if
anyone has any info!
Otherwise, please ignore, nothing to see here ;-)
> On 7 Apr 2018, at 12:37, Igor Clark <igor.cl...@gmail.com> wrote:
> Hi folks,
> Question in the subject might sound odd, but I've got a C system which for
> various reasons has 2 separate processes A and B, each with its own
> MIDIClient object.
> Client A has a MIDINotifyProc callback, which works fine and receives
> Client B doesn't run as the main thread in its process (and can't because of
> the way the system is set up), and so it doesn't have a MIDINotifyProc,
> because (AFAICT) running outside the main runloop it doesn't (and can't)
> receive MIDINotifications.
> When I add or remove a MIDI device to or from the system, client A's
> MIDINotifyProc gets called as expected, and client A can see the new source,
> destination and device lists correctly. However client B doesn't see anything
> different, even after calling MIDIRestart() (although that causes a
> MIDINotification to be sent to client A!).
> I'm not sure what's happening under the hood, but it seems like client B has
> some caching or similar behavior. I do need to be able to see changes in
> client B in order to respond to them though. Can anyone explain, or have any
> ideas on how to address this?
> Thanks very much!
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (Coreaudiofirstname.lastname@example.org)
Help/Unsubscribe/Update your Subscription:
This email sent to arch...@mail-archive.com