Yes, the lack of this node quite astonished me. =20 Especially since I wanted it exactly for the purpose=20 set out in the one example I started. (Audio out and record to disk.) As David so aptly pointed out, there is an issue of copy vs. passing buffers. Perhaps a good splitter node would have two different types of outputs: "copy" and "pass" buffers. There might be only 1 pass buffer, or perhaps more... (if you had some sort of concept like "const" passing, where the buffer would not be edited downstream, then downstream nodes could possibly share a buffer) 1 is probably a reasonable start though. :-) This analysis will focus primarily on the 4 missing parts of the API though, and not on my wish list for new functionality. (to the extent I can restrain myself :-) ) Since I believe it is related to the decoder/extractor selection problem, I will also be looking at streaming media to some extent. Right now I have to get back to work though. :-) Andrew -----Original Message----- From: "David Shipman" <unlyrn@xxxxxxxxxxxxxxx> Date: Tue, 13 Aug 2002 23:18:19 NZST (+1200) > >http://wiki.bebits.com/page/OpenBeOS.MediaKit > > Interesting. A question though. > > Is there really a need for a splitter node=3D3F > > Cannot an input be connected to multiple outputs without the need for > a > special node=3D3F With the current mediakit design - no, it can't. (I presume you mean one output to many inputs..) A consumer node receives buffers - which it must either pass to another node, or "recycle". Most filtering/processing nodes will simply pass on the buffer directly, rather than copying its contents - but in order to send to an additional destination, the node needs to create an additional buffer. I have a working audio splitter node which does just that - I imagine it should be easy enough to adapt for other formats. David Shipman