[openbeosmediakit] Re: BroadcastNewParameterValue - issues, solutions?
- From: "Marcus" <dos4gw@xxxxxx>
- To: openbeosmediakit@xxxxxxxxxxxxx
- Date: Fri, 23 Aug 2002 02:31:43 CEST (+0200)
David Shipman wrote 12 days ago:
> Hi all...
>
> I'm currently finishing off the interface code for the system mixer
> addon, and thought it would be an opportune time to address a concern
> regarding BControllable nodes and the way their interfaces are updated.
I'm answering a little late, but I'm currently implementing the media kit
notifications (BMediaRoster::StartWatching), and I didn't know what
you were talking about when I read your email some time ago.
> Currently, many nodes will not update their display in accordance with
> parameter values changing - that is, if you change the value by some
> other method (another app, a different view of the same controls, etc),
> the controls will not move.
Ok, this is bad.
It looks like there is no automatic way to synchronize updates.
I *assume* that the BView that is presenting the controls
(which is the defualt BMediaTheme) uses BMediaRoster::StartWatching
to be notified when someone calls BroadcastNewParameterValue.
Well, I may be completly wrong here, but I need to implement
BControllable::BroadcastNewParameterValue() and this was my idea
how it may work.
> Only nodes that implement BroadcastNewParameterValue() in their
> SetParameterValue function update correctly - Be's Audio Mixer is an
> example of one such node.
Hu=3F Can you explain this a little more=3F Who does call the
SetParameterValue=3F
Is it the media theme=3F
I'm about to write a small test programm that will print out all notifications
that the media kit provides through the BMediaRoster::StartWatching,
expect it in CVS tomorrow.
> However, there are (I feel) significant problems with this solution. At
> the very least, it means SetParameterValue is called twice for every
> update - once for the initial value, and then again when the broadcast
> is received. If you have several views open representing the same
> controls, the situation is even worse - it will send a Broadcast
> message for each view!
Thats really bad.
> In certain conditions (such as when there are 3 or 4 views open to the
> same control), the Broadcast messages will become slightly delayed,
> resulting in a constant loop of updating parameter values - try it some
> time, its a real mess!
A mess, yes. I plan to implement notifications using a queue. Whenever
something happens that causes a notification, this event will be send
to the media=5Fserver and appended to a queue. A thread in the server
then does the sending of events to all different notifiers (applications)
that are monitoring the events.
The advantage is that the node causing the notification will not be
stalled because of some slow recevier. Of cause, this may/will slightly
delay notification messages.
> According to the BeBook, in the MediaTheme section -
> " if an application uses MakeControlFor() to create individual controls
> rather than letting ViewFor() set up the entire view, the application
> assumes responsibility for setting the control's value in response to
> value change messages. "
>
> I presume this to mean that the BMediaTheme returns handling code for
> changing parameter values - so a possible solution would be to use
> MediaThemes that set the display directly, rather than calling SetValue
> (and triggering another round of updates...)
Don't know. Too complicated for 2:30 am.
But I agree that we need automatic updating without causing duplicate
messages.
Marcus
Other related posts:
