Paul Davis wrote: >the problem is that many of the interesting data types are variable >sized. MIDI is the most obvious.
agree, though in the MIDI case i find that simply using one generic event type which can accomodate a fixed n >= 3 message bytes is sufficient, because the first (= status) byte states how many significant bytes the message has. >i think the right thing to do is to add information on whether ports >of a given type should participate in graph ordering. the default >would be just to use audio ports (perhaps). maintaining N graphs seems >like a very bad idea. the only goal of the graph is to establish a >call order; if connections between ports of type "foo" make no >difference to this, they can be safely ignored; if they can't be >ignored, then by extension they have to used in computing the graph. yep. another approach would be to flag plugins/clients telling whether they take part in the audio cycle at all. there may be plugins operating entirely on non-audio data that need to run in the audio cycle because an audio plugin feeds them, and they in turn feed another audio plugin. tim
