Re: xPLMediaNet Devices Controlling Devices - important please

["UKHA" <ukha@xxxxxxxxxxxxxxxxxxxxxxx>]

On 01/04/2005 at 18:29 Tony Tofts wrote:

>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)

Is this with regard to syncing devices? My preferred method is - as you
probably guessed - to have it working as it is now. Often I'll sync the
devices from my computer room and start them playing and then wander into
one of the other rooms.. where I control them. It also means I don;t need
to rush back to the room where the 'master' is if I want to contol them.

>
>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.

I understand this, but wouldn't it make sense to do something like:

if alldevices == thesametype then
control and display on all
else
lock all but master

even then I'm not sure I like the idea of locking the display/control. What
If I press stop on the master and then forget about it and go out, then
SWMBO tries to put music on from a slave?





Andy




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