[LINUX/MAC/WINDOWS] Active/Passive Multi Zone Audio Support

Just came across this xbmc forum thread where work very much in line with my above thinking has already been done within the addon/plugin framework. I'll point that author here and ask questions there as perhaps it is a better thread for now to voice those questions... at least until the subject matures a bit and devs don't have their hands so full with more important things (gimmie TV!! ). I swear, when I finish residency and go from being a slave to just very busy, I'll pick python back up and learn some real programming language and maybe actually help with xbmc (if not perfected by then) instead of just flicking ideas into the wilderness as if the devs are just sitting there waiting for inspiration.

osli Wrote:Just came across this xbmc forum thread where work very much in line with my above thinking has already been done within the addon/plugin framework. I'll point that author here and ask questions there as perhaps it is a better thread for now to voice those questions... at least until the subject matures a bit and devs don't have their hands so full with more important things (gimmie TV!! ). I swear, when I finish residency and go from being a slave to just very busy, I'll pick python back up and learn some real programming language and maybe actually help with xbmc (if not perfected by then) instead of just flicking ideas into the wilderness as if the devs are just sitting there waiting for inspiration.

Thanks Again! Lots of work ahead....

This is for topfs2... a quick and dirty GIMP mockup based on the Confluence skin. Homescreen modified for multizone...



Uploaded with ImageShack.us

Too busy?

In case you missed it, the only change was the addition of the left sided hiding menu blade found in many sections like weather, system, etc. Here's the horribly convoluted overly busy multizone control page/blade...



Uploaded with ImageShack.us

And really, when you get down to it, if xbmc instances can all communicate with each other this is all you need.

A listing of zones showing what is currently playing (or if nothing, system status, in this mockup in parentheses such as (OFF) or where in the GUI that instance is currently (WEATHER)).

Two options:
(1) Control (radio button 'on' and zone highlighted), and monitor (arrow). Control simply means the local xbmc is now controlling the actively selected zones, which may or may not (as in this example) include the local instance. When you have whatever zones active that you wish, local, another, multiple, whatever, leave the Zones blade and return to your normal XBMC experience. The key is that now all of your actions of navigating through menus, selecting tv streams or stored media, changing system settings, turning up the volume... will issue commands to the active zones. If you want only local control, select only the local zone. If you want to only change what the kids are watching, select only that zone and not local.

(2) Monitor (right arrow on whatever zone is currently in selection focus). This just clones your local instance to the same stream or media file as the selected instance. Now that I think of it, you need some way to know which zone is in selection focus (though not necessarily selected as active), so I guess the blue should be in focus and the radio button should signify active. Only needed one "blue" highlighted zone in my mockup. Shoot me.

But I hope this illustrates that perhaps the GUI isn't such a hurdle if there is work and thought put into how multizone/multi-instance/multi-something actually works. My goal was to show that not much really needs to be added to the GUI. XBMC already has about the best GUI (in as many flavors as you want!) possible allowing full control over anything and everything. No need to recreate methods for selecting media or anything else, just a method of specifying "for which XBMC?" And for the little time I spent on this, I'm sure there are plenty of much more talented skinners that could do a more polished job.

You said "show me an example" before it would even be considered for support among core devs and core xbmc function (i.e. not needing a plug-in that can never operate as elegantly - no disrespect intended teshephe). Does this example even come close?

osli Wrote:In case you missed it, the only change was the addition of the left sided hiding menu blade found in many sections like weather, system, etc. Here's the horribly convoluted overly busy multizone control page/blade...

that is dead simple... my 1 yr old could use that. I really don't understand what you think is so convoluted and busy. Not sure how you posted this message... the forum must be impossible for you to navigate... and I bet you don't go to restaurants that have more then 2 items on the menu?

I was being sarcastic, but then you probably were too.

tbh I am not a fan of the suggestion while I can agree its not overly complicated, more dialogs means more work for skinners and since this is such a minimal amount of people that would use the feature it would probably just annoy skinners. And skinners already have tons of dialogs and windows to do so adding more is not a good thing always. Still this is what I want to see, proper mockup how it could work which aren't overly complicated so keep it up!

At any rate, if thats all you need a script fits the bill perfectly. What you would need is perhaps a way to add widgets to the home screen in an abstracted matter (like kde4 or android). Now thats a feature suggestion that could actually be interesting...

If you need to play audio from client a to client b then it starts to become harder to manage in core and I really doubt that will happen. But if widgets would be popular and this widget would be popular who knows, as it stands now its months of work for something perhaps 1% would use.

I can appreciate that it would add complexity for skinners. I took a look at the confluence artwork and XML files and was amazed at how much work must go into producing a skin. But were talking about a single additional dialog requiring only a couple of graphics which should be leveraged wholesale from existing pages functions, so I can't imagine that this is any serious increase in the time required to produce a skin in the big picture. But if it can be added on as a script that ties directly into the homescreen and core functions like this then I'm going to certainly learn more about that as I get time.

The more I think about it the more I see the major roadblock is actually having xbmc act as a listening client like streamcast stuff. Otherwise, you might be telling six xbmc instances to all pull the same song or video from the server simultaneously, which is a huge waste of bandwidth and could cause problems. I don't think devs are interested in separating xbmc into explicit server and client components to have it function in this way and I can't blame them. If that ever becomes a popular idea then that would be the ideal time to revisit this one.

In the meantime I'm going to be very busy but I've been looking for a reason to learn something more than an interpreted language so maybe this will be motivation. Again, I think the possible benifits and future flexibility go far beyond simple multizone audio.

Great mockup. In general it would be great to have this function. The UI can even be reduced to three additional functions in the context menus:

- one in the library view of the content saying: play to location (and a dynamic list of xbmc instances on the local network - recognized by upnp protocol or so. This can be used to remote control á xbmc instance / start playback in a different room).

- the second on the playback menu (M-Key) saying extend playback to (with a popup of active xbmc instances) to add playback of the running content to other rooms (multiroom / multizone playback, master/slave, where this instance becomes the master)

- third: a new button next to the system / playlists button saying Join Playback Zone (with a popup of running xbmc instances), so one can join to a running instance in a differend room as a slave and making the remote instance the zone master.

The slave can always stop playback / escape the Zone by pressing the stop button.

Of course a full remote control an overview what is running now on any instance and options to join or leave a zone is much more sophisticated - but if the skinner-work is the issue - two small buttons and a context menu entry can almost do the trick in conjunction of a network discovery function.