On Sun Sep 10 22:16:58 2023 +0000, Michael Stefaniuc wrote:
As this puzzled me too and to document it for posterity: While there is a dmime/graph.c that implements an DirectMusicGraph object that one has nothing to do with the IDirectMusicGraph interface implemented by the DirectMusicPerformance object. The MS documentation for IDirectMusicPerformance8::GetGraph() explains it in the remarks.
Yes, the documentation is actually quite cryptic at first. The difference is this:
* The IDirectMusicGraph class and its interface handle a graph of tools, and is responsible for "Stamping" messages with the next tool in the graph, or return DMUS_S_LAST_TOOL if the last tool has been reached.
* The IDirectMusicPerformance also implement IDirectMusicTool interface, acting as the "output tool" that is described in the documentation, translating messages to the ports.
* IDirectMusicPerformance also implement a IDirectMusicGraph interface, but only for convenience and to wrap the internal tool graph, intercept the DMUS_S_LAST_TOOL status returned by the internal graph, and stamp the messages with the output tool.
(This means, if messages are stamped with the internal graph, they will be processed by all its tools, but then it will end with DMUS_S_LAST_TOOL and the performance output tool will not receive the messages)
Note that, according to the documentation and the tests, IDirectMusicSegmentState is also supposed to implement the same kind of graph wrapper, probably for the same purpose but passing the messages down to the performance when the segment graph has finished processing its messages. However, my current (limited) testing suggest that it doesn't work like that and that segment messages are only delivered to the segment tool graph, and not the performance tool graph... I think only the performance graph and tool are useful for the moment so I didn't look further.