[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: xPLMediaNet Devices Controlling Devices - important please
- Subject: RE: xPLMediaNet Devices Controlling Devices -
important please
- From: "Neil Frost" <neil@xxxxxxxxxxxxx>
- Date: Fri, 1 Apr 2005 21:52:13 +0100
Hi Tony,
I think locking is the best idea.
With the display, how would a display device control and device without
display??
E.g. an MVP controlling an Exstreamer???
-----Original Message-----
From: Tony Tofts [mailto:tony@xxxxxxx]
Sent: 01 April 2005 18:29
To: ukha_xpl@xxxxxxx
Subject: [ukha_xpl] xPLMediaNet Devices Controlling Devices - important
please
Hi all,
Would like some input from interested parties on devices controlling
devices...
Currently I have the rio client configured in such a way that it has 3
modes:
A) Master - a master is a device controlling a slave
B) Slave - a slave is a device being controlled
C) Normal - Neither a master nor slave - the default
Currently the local display and ir input are active, meaning a slave can
be
controlled at both ends - and the menu system can be seen at each end.
This
is fine for 2 rio's but not for different devices with different screen
sizes (menu lines)
This _could_ stay like this, but means a ton of complicated/duplicated
programming (and wasted processing/memory) to account for devices with
different size displays that I'd like to avoid, particularly as I want
to
keep the client modules as simple as possible for inclusion of new
devices
and for other developers to understand.
This also means that an mvp controlling a rio can have 10+ lines in a
menu,
rather than being limited to the 4 of the rio.
Therefore I think the local display should be locked out, and as nothing
can
be seen I think local ir control should also be locked out. Basically
the
device becomes dumb while under the control of another device. Thoughts?
Alternatively, the devices could negotiate the smallest screen size and
both
work to that? It means if controlling a slim on an mvp the menu would be
only 2 lines. What would users prefer?
Also, as the status screens on the devices are all different, I think
that
control should be automatically released when exiting the menu system?
The
master would return to where it was, so pressing enter would
automatically
restore the control of the same device. I see this master/slave
relationship
as a control one, not an emulation of all a devices characteristics (as
these will be too many and varied).
Also, by default when a device becomes a slave it will jump to the music
selection menu, though you can then navigate back to the devices own
front
menu if required
Please advise what you think, or any comments. Else I'll go for the
simplest
options above - giving the largest menu's possible.
Please note that this master/slave scenario is for music only at this
stage,
as a rio (or whatever) is not appropriate to control an MVP for
pictures/movies (though rio etc will be able to control music selection
on
an mvp)
Still trying to work out a good way of releasing a device from
slave/master
relationship if one of them is rebooted/powered off manually (e.g.
pressing
power on mvp actually turn's it off, which would leave the exstreamer
locked
out)
Regards
Tony
xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe: ukha_xpl-subscribe@xxxxxxx
To Unsubscribe: ukha_xpl-unsubscribe@xxxxxxx
xPL Main Index |
xPL Thread Index |
xPL Home |
Archives Home
|