UI change for sync groups

[pippin]

Yea, I think the idea of virtual players is not bad, I like the concept, too, just trying to get my head around how that could work for a Squeezebox system.

Switching playlists to another player, BTW, wasn't the use case I meant above although in the Squeezebox world the only way to really do that is through a sync action.
My use case often is that I listen to something e.g. In the kitchen and then I want to add the living room if I start to move between the two. Without stopping the music in the kitchen.

So with virtual players you would then switch a playlist to a virtual player which might include the original player? How does that work in CC? Both technically and UI-wise?

[mherger]

UI change for sync groups

> But with virtual players, this is what you would get. If you change the
> volume of one slave player, then only its volume changes. Only when you
> change the volume of the virtual player itself will a proportional
> change on all volumes happen. So if you don't want that, always use
> slave volumes. That the conceptual difference between a group and a
> virtual new player.

Ok, I see. But I don't see this happen... That would be a massive change
to LMS. Handling synced players is all over the place. Introducing yet
another related, but different approach would be a big involvement.

What I could imagine is the group approach. That would mostly be UI
changes, plus a way to define and handle saved sync groups.

I'll have to play with the virtual player idea. Mentally, at least. Can
you send me a pull request when done? :-)

--

Michael

[philippe_44]

> But with virtual players, this is what you would get. If you change the
> volume of one slave player, then only its volume changes. Only when you
> change the volume of the virtual player itself will a proportional
> change on all volumes happen. So if you don't want that, always use
> slave volumes. That the conceptual difference between a group and a
> virtual new player.

Ok, I see. But I don't see this happen... That would be a massive change
to LMS. Handling synced players is all over the place. Introducing yet
another related, but different approach would be a big involvement.

What I could imagine is the group approach. That would mostly be UI
changes, plus a way to define and handle saved sync groups.

I'll have to play with the virtual player idea. Mentally, at least. Can
you send me a pull request when done? :-)

--

Michael

I'm thinking about retiring so I guess with my D-minus rating in Perl, I'll be ready in a few years, unless you like the concept and make it happen in a couple of weeks (please don't wait the end of my development minus 2 weeks to start )

[philippe_44]

I'm re-opening this thread because I'm seriously thinking of developing this "virtual player" idea. It will be a real challenge for me as I don't know the inside of LMS very well, but before banging my head too much against the wall, can somebody with the right expertise tell me if the idea of adding of creating a virtual player is doable? i.e. players that have no slimproto interface, are not discovered but are created "artifically" inside LMS. A few hints on how to start would be very helpful

[Mnyb]

I'm re-opening this thread because I'm seriously thinking of developing this "virtual player" idea. It will be a real challenge for me as I don't know the inside of LMS very well, but before banging my head too much against the wall, can somebody with the right expertise tell me if the idea of adding of creating a virtual player is doable? i.e. players that have no slimproto interface, are not discovered but are created "artifically" inside LMS. A few hints on how to start would be very helpful

In baby steps ? I have simple plugin idea involving a virtual player of a sort .

Playlist creation and saving in LMS always involves adding the tracks to a player and then save the playlist .

But what if your player(s) already busy playing other stuff ?
I work around this by using my desktop Squeezelite instance , which rarely is used these days as my boom is in the same room.

What about a dummy player that existed just for having the rigth pane view of player to create and save playlists ?

[philippe_44]

In baby steps ? I have simple plugin idea involving a virtual player of a sort .

Playlist creation and saving in LMS always involves adding the tracks to a player and then save the playlist .

But what if your player(s) already busy playing other stuff ?
I work around this by using my desktop Squeezelite instance , which rarely is used these days as my boom is in the same room.

What about a dummy player that existed just for having the rigth pane view of player to create and save playlists ?

I'm not sure I'm following (or we are already one the same page ).

My virtual players should be really virtual, but with the full attribute of a real player so that they have playlist, volume and all sort of things. When (eg) "play" is requested on such virtual player, all the associated players should be grouped (in the LMS sense of grouping) together (unless they already are), one should be "elected" as the master and play shall be send to that "real" master. If further down the master is switched off, another one of the group shall be elected (I assume this is needed in LMS' group concept). If a play is sent to another virtual player that share one real player with the first virtual one, then that real player shall be removed from the LMS group associated with the first virtual player and allocated to the new group. But for all that to work, I assume that I can create that fake player.

Are you thinking of having all virtual players to be real squeezelite instances and do the magic grouping / ungrouping using these as the masters? Even if I do that, I still need a "special category" of players where I can overload the various function, but I guess I could look in the slim/player foler and look how I could do new type of player that would be matching my new modified squeezelite instance

[philippe_44]

Question for Michael (or a deep enough expert on LMS core)

> But with virtual players, this is what you would get. If you change the
> volume of one slave player, then only its volume changes. Only when you
> change the volume of the virtual player itself will a proportional
> change on all volumes happen. So if you don't want that, always use
> slave volumes. That the conceptual difference between a group and a
> virtual new player.

Ok, I see. But I don't see this happen... That would be a massive change
to LMS. Handling synced players is all over the place. Introducing yet
another related, but different approach would be a big involvement.

What I could imagine is the group approach. That would mostly be UI
changes, plus a way to define and handle saved sync groups.

I'll have to play with the virtual player idea. Mentally, at least. Can
you send me a pull request when done? :-)

--

Michael

If I can direct one question to you Michael, before trying the baby step with a set of "fake" squeezelite players (that I know how to do very well know ) but I'd like to know if it's possible to create such virtual player purely in LMS in Perl. I this is a dead end, I don't think I'll try because although the idea of a fake squeezelite instance is good to start, ultimately it means handling real audio content for it which I don't like. So if I can't have a player that is just a container for playlists, volume, commands & control (start, stop pause ...) and in fact a "link" to a real LMS group, then I don't think its worth the effort.

[mherger]

UI change for sync groups

I'm sorry, totally missed that one...

> If I can direct one question to you Michael, before trying the baby step
> with a set of "fake" squeezelite players (that I know how to do very
> well know ) but I'd like to know if it's possible to create such
> virtual player purely in LMS in Perl.

I'm sure it's possible. But unfortunately I can't say for sure how hard
it would be. I guess you'd have to create a new Slim::Player::xXX class,
inheriting from Slim::Player::Client. This could potentially be done as
part of a plugin, outside LMS.

--

Michael

[mherger]

UI change for sync groups

> I'm sure it's possible. But unfortunately I can't say for sure how hard
> it would be. I guess you'd have to create a new Slim::Player::xXX class,
> inheriting from Slim::Player::Client. This could potentially be done as
> part of a plugin, outside LMS.

I've been thinking over this idea a little more... There are technical
challenges, and UX challenges. Inheriting from Slim::Player::Player
might be one way to go. Groups would show up as any other player,
keeping compatibility with client software. You pick it, start playback,
and it would set up the syncing if needed.

Sync group management in existing software (incl. the web UI, if not
modified) would list the real players as synced to the sync group proxy
player ("Upstairs"): "Upstairs, Bedroom, Kid's room". The individual
players keep their own playlist.

Changing the sync configuration from any of the members would behave the
same as any synced group of players. They can leave the group any time
they want. You could end up with one controller controlling the sync
group, but all member unsynced, resulting in no playback at all. But the
next time the sync group is "powered on", it would re-connect all other
players. UX challenge...

Sync group aware clients could use the new player model string to
customize the UI to eg. show the sync groups in some other UI element.

Sync groups need to connect to LMS automatically when LMS is started,
using some fake MAC address. They come with their own set of prefs.

My optimistic thinking tells me that this would be the most compatible,
least technically involved approach, ignoring some of the UX challenges.
Not perfect, but a huge improvement anyway.

--

Michael

[philippe_44]

> I'm sure it's possible. But unfortunately I can't say for sure how hard
> it would be. I guess you'd have to create a new Slim::Player::xXX class,
> inheriting from Slim::Player::Client. This could potentially be done as
> part of a plugin, outside LMS.

I've been thinking over this idea a little more... There are technical
challenges, and UX challenges. Inheriting from Slim::Player::Player
might be one way to go. Groups would show up as any other player,
keeping compatibility with client software. You pick it, start playback,
and it would set up the syncing if needed.

Sync group management in existing software (incl. the web UI, if not
modified) would list the real players as synced to the sync group proxy
player ("Upstairs"): "Upstairs, Bedroom, Kid's room". The individual
players keep their own playlist.

Changing the sync configuration from any of the members would behave the
same as any synced group of players. They can leave the group any time
they want. You could end up with one controller controlling the sync
group, but all member unsynced, resulting in no playback at all. But the
next time the sync group is "powered on", it would re-connect all other
players. UX challenge...

Sync group aware clients could use the new player model string to
customize the UI to eg. show the sync groups in some other UI element.

Sync groups need to connect to LMS automatically when LMS is started,
using some fake MAC address. They come with their own set of prefs.

My optimistic thinking tells me that this would be the most compatible,
least technically involved approach, ignoring some of the UX challenges.
Not perfect, but a huge improvement anyway.

--

Michael

Thanks Michael - Sorry I missed your reponse, I've been away due to personal challenges. I will start to look in that direction and report if I make some progress. That's the only thing I'm missing from LMS (okay, I'd like also to find a way to synchronize CC players, but this one is very unlikely to happen).

[philippe_44]

I've created the data structure for Groups and started thinking about it more, but unfortunately I'm hitting a rock now. Player inherits from Client and Client itself is a StreamingController object (created by its new(), it's not inherited). Problem is that as soon as a StreamingController is created, seems that I'm opening a can of worms as it wants a real socket to communicate to. I feel I don't need to create a StreamingController objects as all the playlist and stuff like that are hold by Client, but I'm failing to get a way to overload properly the new() method of Player (Client) to avoid creating a StreamingController object.

[mherger]

UI change for sync groups

Oh... it looks as if you run into a similar problem I recently run into
when playing with the idea of a web based player... crap. I liked the idea.
--

Michael

[philippe_44]

Oh... it looks as if you run into a similar problem I recently run into
when playing with the idea of a web based player... crap. I liked the idea.
--

Michael

I've not given up yet, but it seems that I'll need to "import" a lot of code. I'm think of direclty copying "client.pm" and starting from there. Do you think that'd be doable? Sorry for the basic question, but, at the end, what object is creating an entry in Player's list?

[philippe_44]

Oh... it looks as if you run into a similar problem I recently run into
when playing with the idea of a web based player... crap. I liked the idea.
--

Michael

Another option is to create a squeezelite instance which does nothing, but create a subclass of "squeezebox2" dedicated to that, but that hurts my view of elegance as this instance will be streamed data and everything for nothing - such a waste.

[mherger]

UI change for sync groups

> I've not given up yet, but it seems that I'll need to "import" a lot of
> code. I'm think of direclty copying "client.pm" and starting from there.

Yeah, OO is a nice concept... but sometimes you have to somehow hack
around it.

> Do you think that'd be doable? Sorry for the basic question, but, at the
> end, what object is creating an entry in Player's list?

TBH: I don't know...

--

Michael