On Mon, Oct 14, 2013 at 06:19:25PM +0200, Dario Casalinuovo wrote: > > I have with a my own project, the problem of making a media_node > communicate with another thread. Imagine a producer/consumer node which > have to receive data or media_events from the thread A dispatching them to > the system mixer. Inversely it have to receive data from the mixer from > some input and dispatch it to this thread. The latter could be done by > calling a owner's method, more like it's already done in BSoundPlayer. > > But the BeBook states "Note, however, that your application should never > directly call any of your subclass' functions; instead, you should register > the node with the media roster, and control it via BMediaRoster calls, just > like any other node, by using the media_node that describes your node". > > So...how can i schedule programmatically events to the node from the extern? > I tried to find in the BMediaRoster a method related to some message > passing between the app and the node, but it looks like there isn't any. > I'm considering to create BLooper owned by the node and shared with the > app, the looper will be used to notify that there's data available and will > share some memory with the app. Is it correct to do it this way? If not how > this is assumed to be done? I'm afraid I'm having some difficulty understanding exactly what you need to do, and what you think is preventing you from doing it. Maybe you could expand a bit. If, though, you're reading that statement from the BeBook as meaning that you can't call *any* methods in your derived node class, that's not what it's trying to say. [I don't think it's very clearly written!] Any methods that you've added yourself to the class can of course be used as you like. The paragraph is referring to the MediaNode base methods that you may have to implement to give it the desired behaviour. And when you are working with, say, a BBufferConsumer, there are certainly methods you will want to call yourself -- like SendBuffer(). There's probably no need for a separate looper, unless the messages you're sending are going to have to queue before being acted upon or something. Hope that's of some help. -- Pete --