> That's exactly how I saw it working. Event-processing plugins that don't > mess around with tempo or time will just pass events on to downstream > plugs. I don't like the idea of passing things downstream. A plugin should not see events that are not meant for it. > The only complication is in developing merger filters, they will have to > allow (the user?) to select which inbound port's time context to honor. Or you let the merger subscribe to a time context itself by receiving tempo information. If it is the same as one or more of the feeders, great! If not, cope! > note and other musical events. However, if they are to flow downstream in > the same way, each plug must have a unique target-ID, such that it can > identify parameter messages intended for it. In the above case, the MIDI > processing plug needs to be able to ignore parameter events for the audio > plug sitting downstream. What we did with XAP was this: At init time, the plugin is asked for one event-target for each control. The event-target is a tuple of {list-head, cookie}. The Plugin provides the cookie which is meaningful within itself. When events get delivered, they include the cookie for their destination. Thus a plugin always knows which target was intended, even if it has only one list-head. Further, it allows the plugin to decide how many actual queues to sort events into, and how to arrange them. ---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission. Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe