Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17
  1. #11
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    19,538

    UI change for sync groups

    > May I ask what you do not like in the way CC works? (just trying to
    > understand )


    Meant to add that to my previous posting... Volume handling. I don't
    want volume to be synced, not even relatively. I want to up the volume
    in the kitchen without upping it in the living room.

    --

    Michael

  2. #12
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    13,956
    Quote Originally Posted by philippe_44 View Post
    I agree it can be a can of worm, but as you said, by forcing a few options, I still think you can have something more convenient than what we have today. My bad I missed that when I tried to use the Synchronizer the first time, but it does most of what's expected, no? The inconvenience is the need to navigate through another menu to activate/deactivate sync groups.
    Sure, the problem is: whichever option you enforce to go away, 50% of your users won't like it and want it the other way around...

    That's the thing with removing functionality, it's not as easy as not having it in the first place.
    And that's what I meant with "it usually works for any individual user but not in a general case". It will be easy to find a solution that works for you but not for Michael, for example (re: volume above).

    In addition there are a few design changes required:

    To me, what CC do is pretty good, i.e. creating virtual players.
    That whole functionality would have to be added to LMS, especially the virtual player's playlist, although SyncOptions does some of this by saving the previous playlist.

    - on/off states stays as they were before pressing play
    - if you want to switch all on/off all, switch on/off the virtual player
    Umm... No, it does not. It doesn't HAVE and on/off state. That's something else (in the Squeezebox system) as the "play" state. That was one of my points: having these various mixed options complicates things a lot.
    This was my Sonos example, they do this the same way as CC but to do this in a Squeezebox system you'd either have to enforce the "Sync Power" option, something currently nobody uses and which would break a lot of users' use cases (most people sync a lot of players and then turn on the ones they actually want to play) or you'd have to do away with the state altogether which would break a lot of amplifier/home automation integrations.

    - volume changes work as a ratio of the individual volumes, until you set the virtual player to 0, in which case it restarts with all equals
    I think this one could be solved by having it like in iPeng where it works like in CC by default but you can still access all individual player volumes.
    As of my statistics Michael is pretty alone with his dislike of this, a huge majority of iPeng users for example leaves this at the default (relatively synched volume), yet still... Some might not like it...

    - the most recent virtual player who wants to use a player wins across other virtual players
    - the conflict of an individual player synchronized with a member of the group (virtual player) does not exist as you're playing to a virtual player, made of N players, so every player not under that "virtual" umbrella is ignored.
    So I understand that it unsyncs players not part of the most recent virtual player?
    Sorry, I only have a single CC so can't really test this right now.

    - playlist is an attribute to the virtual player, so the idea of master (at least from a user point of view) does not exit
    Can I move an existing playlist to the virtual player or how does it work if I want to continue playing what I'm currently playing but in a whole group (I think that's the most common use case)?

    I feel that thinking "virtual player" and not "group" is more than a suttle difference and simplifies the problem. Still, I obviously have not spent as much time as you did, so I've probably made a few logic faults,
    I don't think so. The only logical fault you've made is that CC is not Squeezebox. Squeezebox users have different use cases they are used to and that they have built their systems to.
    You can't just start from scratch as if they didn't exist, CC could do that.

    I've even designed a system last year built entirely on Squeezebox but exclusively controlled through an App which did something pretty similar to this but this was for a new hardware system and it was possible to leave complexity out because there were no devices relying on it.
    Is it possible? Sure.
    Will it work for some users? Sure.
    Will it work for the majority of users with any given setup? I don't think so.
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 9, the Universal App for iPhone, iPad and Apple Watch

  3. #13
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    2,971
    Quote Originally Posted by mherger View Post
    > May I ask what you do not like in the way CC works? (just trying to
    > understand )


    Meant to add that to my previous posting... Volume handling. I don't
    want volume to be synced, not even relatively. I want to up the volume
    in the kitchen without upping it in the living room.

    --

    Michael
    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. The group is missing a lot of attributes and has to rely on his members attributes, not a virtual player. And groups mean a many-to-many equal relationship but virtual player means a one way (top bottom) organization, not bottoms up. I agree that one of the consequences is that you must use a remote to handle the virtual player as using one of the physical player does not do anything to the virtual player. Maybe this is the big inconvenience
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express

  4. #14
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    2,971
    Quote Originally Posted by pippin View Post
    So I understand that it unsyncs players not part of the most recent virtual player?
    Sorry, I only have a single CC so can't really test this right now.
    Yes, that's the idea although it not exactly "unsynced" if you look at that from a virtual player point of view - players never "unsync" they play whatever their virtual player master tell them to do, unless they are required to play something direclty. If you have 3 players and (1,2,3) and 2 virtuals (A,B) and A=(1,2) and B=(2,3). When B plays, whatever was happening to 2 stop for in favor of what you play on B. 2 does not "unsync" from 1, for that matter. If just after you start playing on A, then 2 will play whatever you've started while 3 will continue to play what was playing on B. And so on

    Can I move an existing playlist to the virtual player or how does it work if I want to continue playing what I'm currently playing but in a whole group (I think that's the most common use case)?
    I don't know. But for me the idea if you are playing a playlist on a physical player 1 and want to continue what you're playing to a virtual player B, it would simply a classical transfer action
    I don't think so. The only logical fault you've made is that CC is not Squeezebox. Squeezebox users have different use cases they are used to and that they have built their systems to.
    You can't just start from scratch as if they didn't exist, CC could do that.
    Understood and just for clarity I'm not the rep of Google CC's
    I've even designed a system last year built entirely on Squeezebox but exclusively controlled through an App which did something pretty similar to this but this was for a new hardware system and it was possible to leave complexity out because there were no devices relying on it.
    Is it possible? Sure.
    Will it work for some users? Sure.
    Will it work for the majority of users with any given setup? I don't think so.
    Yes, but the reason why I was suggesting the idea of virtual players is because it would not modify the habbits of users the way they interact with groups currently, but by adding this new entity of virtual players it would offer a alternative way of playing synchronized music.

    But again, all this is just for the sake of bouncing ideas with you guys
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express

  5. #15
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    13,956
    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?
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 9, the Universal App for iPhone, iPad and Apple Watch

  6. #16
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    19,538

    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

  7. #17
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    2,971
    Quote Originally Posted by mherger View Post
    > 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 )
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •