Looking at the items that can be changed with client info, or port info, I think there is little likelihood that applications are going to be changing this information more than once in the lifetime of a client, or a port. So far, my application hasn't detected any changes to port information after it starts tracking a port (though it doesn't track everything about a port.) This is certainly because the port info is given at the time of port creation. Of the several DAWs that I tested, when you change their MIDI configuration - rather than change the port info of their existing ports, they simply delete them all, and recreate the ports as needed, which is broadcasting PORT_EXIT and PORT_START events anyway. In either case, this isn't a broadcast concern as these events are relatively rare. Client info is a bit different, as you must create your client first, then set info. So the CLIENT_START event would be followed by one or more CLIENT_CHANGE events. This is exacerbated because the helper functions for setting client name, event filter, etc... which each get the client info, set one field, and set the info back. So true, this change would cause a broadcast of a few events each time a client is created... But again, in the scheme of things, client creation is a relatively rare occurrence. In the absence of these events, applications like mine, have to periodically poll every client info and every port info to see if anything that they care about (like client name or port name) has changed. For now, since port info changes (at least of name or capabilities) is essentially non-existent, my application doesn't bother to poll ports. And for clients, since the changes only happen right after client start, my application simply sleeps a short interval after getting CLIENT_START, before reading the client info, giving the client process time to set the info up. Clearly this isn't optimal or infalible - but in practice it works, and polling info frequently seems too high a cost. Lastly, there IS one place in the code where PORT_CHANGE is sent. In seq_ump_client.c in the function update_port_infos(). In that case, interestingly, a port_info change is only considered if and only if the name or the capability fields are changed. That logic could be applied to your patch - but given how infrequent I suspect port (or client) changes are, it seems presumptive to be limiting what field changes an application would be interested in. Happy to dive into any more details you may need, — Mark
