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

    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
    14,202
    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
    3,362
    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, GGMM E5

  4. #14
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,362
    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, GGMM E5

  5. #15
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    14,202
    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,803

    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
    3,362
    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, GGMM E5

  8. #18
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,362
    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
    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, GGMM E5

  9. #19
    Senior Member Mnyb's Avatar
    Join Date
    Feb 2006
    Location
    Vństerňs Sweden
    Posts
    16,171
    Quote Originally Posted by philippe_44 View Post
    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 ?
    --------------------------------------------------------------------
    Main hifi: Touch + CIA PS +MeridianG68J MeridianHD621 MeridianG98DH 2 x MeridianDSP5200 MeridianDSP5200HC 2 xMeridianDSP3100 +Rel Stadium 3 sub.
    Bedroom/Office: Boom
    Kitchen: Touch + powered Fostex PM0.4
    Misc use: Radio (with battery)
    iPad1 with iPengHD & SqueezePad
    (spares Touch, SB3, reciever ,controller )
    server HP proliant micro server N36L with ClearOS Linux

    http://people.xiph.org/~xiphmont/demo/neil-young.html

  10. #20
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,362
    Quote Originally Posted by Mnyb View Post
    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
    Last edited by philippe_44; 2017-10-29 at 02:08.
    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, GGMM E5

Posting Permissions

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