I handle simultaneously several midi in/out sources in real time, all those peripherals exchange standard midi events as well as custom mixing automation events encapsulated in midi sysex in real time. I must re-route and treat some of these mixed events but different threads treat sysex events and non sysex event. It's a multiple producer /multiple consumer scheme, where consumers are selective (those consuming sysex don't consume non sysex data and vice versa). I would be more than happy if I could select a different message queue (i.e: 2 independant queues) for non sysex data and sysex data but don't think it's possible with pm ? So my solution based on 'listening' before consuming messages is fast and easy to manage. (I could have read the unified midi buffer an splitted it myself into 2 sysex and non sysex queues but it's more work and will slow down things unnecessarily)
Thanks, Fabien >I don't understand what you are doing. The sysex_in_progress flag is set >and cleared asynchronously by the midi input handler. If your client >code is doing something that depends on this flag, it seems likely that t>here is a race condition. I'm not opposed to extending the API to >enable a different way to structure client code if there really is a >correct way to use sysex_in_progress. >-Roger Fabien Costantini wrote: > In my current code, > I must sadly rely on on PmInternal real structure which is very dirty. > Thus, I am constrained either to give the portmidi/pm_common include path to > my project > or duplicate the type definition, both alternative are just as bad. > > But the only thing I use/need in PmInternal is the sysex_in_progress flag. > ... _______________________________________________ media_api mailing list media_api@create.ucsb.edu http://lists.create.ucsb.edu/mailman/listinfo/media_api
