The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[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

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.