Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 44
  1. #21
    How about we
    • define the command as accepting tagged arguments, so you could send a command like 'getexternalvolumeinfo player:00%3a04%3a20%3a11%3a22%3a33' to tell the plugins to only report on the player 00:04:20:11:22:33, or plain old 'getexternalvolumeinfo' to get info about all players
    • use tagged data with string values for the notifications instead of 1/0, e.g. "relative:true", "precise:true", "plugin:MyPluginName"? This would allow us to extend the concept to cover other volume-like capabilities, e.g. the Denon plugins might want to advertise their ability to set dynamic range compression (let's not worry now about how iPeng would request "night mode"!)


    Would that second idea really be an improvement, or just extra, over-engineered hassle for everyone?
    owner of the stuff at https://tuxreborn.netlify.app/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  2. #22
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    14,781
    Quote Originally Posted by peterw View Post
    Would that second idea really be an improvement, or just extra, over-engineered hassle for everyone?
    Wouldn't have phrased it that way

    I'll try some client-side optimization first, maybe I can catch this by waiting half a second and aggregating some calls.

    In most cases it's not _that_ big an issue anyway. There's a bad habit in iPeng in that it requests all player's status twice on startup (haven't found out, why, some fairly complex notification schemes behind this) and then right now I get a growing (by square) number of notifications (1 player: 3 notifications; 2 Players: 16 notifications, 3 players 27 ...)
    The notifications are small so usually not a big thing. But then, with 20 players and 1200 notifications...

    I think IF I can't get around this, I would prefer something else: to send the player id as a tag with the notification.
    That way, I could subscribe to 'getexternalvolumeinfo' on the server level and just send the command every time the list of players changes. Although this would definitely be less elegant (breach of encapsulation).

    I kind of like the tagged answers, yet do we need this? I was close to proposing a bit-mask (that's what I use internally) but then I remembered we are dealing with Perl...
    ---
    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. #23
    Would you prefer not to use notifications? I thought notifications would simplify things -- you'd send 2 commands at startup and get 2 + N responses (where N = players with external volume control). [Frankly, I hadn't thought about the new player scenario.] Would you prefer a more typical CLI model that requires you to ask about specific players?

    Bitmasks would work, though I prefer named tags simply because it's easier to add new tags than decide on what value to assign to a new feature to express in the bitmasked value. And of course I'm happy to add a tagged response value to identify the player. In the text/telnet CLI it's obvious what player a notification applies to, that's why I didn't already do so. But if there's value for you, great, let's add that.
    owner of the stuff at https://tuxreborn.netlify.app/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  4. #24
    Senior Member Aesculus's Avatar
    Join Date
    Jan 2008
    Posts
    406
    Quote Originally Posted by peterw View Post
    How about we
    • use tagged data with string values for the notifications instead of 1/0, e.g. "relative:true", "precise:true", "plugin:MyPluginName"? This would allow us to extend the concept to cover other volume-like capabilities, e.g. the Denon plugins might want to advertise their ability to set dynamic range compression (let's not worry now about how iPeng would request "night mode"!)


    Would that second idea really be an improvement, or just extra, over-engineered hassle for everyone?
    My latest plugin version (1.5) does this via the player settings menus. See:
    http://code.google.com/p/denonavpcontrol/wiki/HowToUse
    Chris

  5. #25
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    14,781
    Quote Originally Posted by peterw View Post
    Would you prefer not to use notifications? I thought notifications would simplify things -- you'd send 2 commands at startup and get 2 + N responses (where N = players with external volume control). [Frankly, I hadn't thought about the new player scenario.] Would you prefer a more typical CLI model that requires you to ask about specific players?

    Bitmasks would work, though I prefer named tags simply because it's easier to add new tags than decide on what value to assign to a new feature to express in the bitmasked value. And of course I'm happy to add a tagged response value to identify the player. In the text/telnet CLI it's obvious what player a notification applies to, that's why I didn't already do so. But if there's value for you, great, let's add that.
    Hm, let me try a bit first.
    Knowing the player is not the issue - it's similarly obvious, actually it's much better as it is now from that perspective.

    Tagged values are probably a better idea, though. Makes parsing data more straightforward.

    Also, I believe a notification is generally fine, I think the main issue here is the way I handle players and subscriptions. It's all nicely encapsulated but due to that a bit redundant on the feedback side. I simply hadn't expected commands sent to one player to go through to others.

    I think I will keep the subscription on the player side by sync the command on the server side to try to only send one per player count change incident. That should be fine then.
    ---
    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. #26
    Senior Member Aesculus's Avatar
    Join Date
    Jan 2008
    Posts
    406
    Quote Originally Posted by peterw View Post
    Would you prefer not to use notifications? I thought notifications would simplify things -- you'd send 2 commands at startup and get 2 + N responses (where N = players with external volume control). [Frankly, I hadn't thought about the new player scenario.] Would you prefer a more typical CLI model that requires you to ask about specific players?

    Bitmasks would work, though I prefer named tags simply because it's easier to add new tags than decide on what value to assign to a new feature to express in the bitmasked value. And of course I'm happy to add a tagged response value to identify the player. In the text/telnet CLI it's obvious what player a notification applies to, that's why I didn't already do so. But if there's value for you, great, let's add that.
    Peter: I am getting errors on the statement:
    Code:
    Slim::Control::Request::notifyFromArray($client, ['getexternalvolumeinfo', 1,   1,   string(&getDisplayName())]);
    Errors:
    Code:
    0013:    frame 8: main::main (/opt/ssods4/var/home/SqueezeboxServer/slimserver.pl line 1065)
    0012:    frame 7: main::idle (/opt/ssods4/var/home/SqueezeboxServer/slimserver.pl line 574)
    0011:    frame 6: Slim::Control::Request::checkNotifications (/opt/ssods4/var/home/SqueezeboxServer/slimserver.pl line 605)
    0010:    frame 5: Slim::Control::Request::notify (/share/MD0_DATA/.qpkg/SSOTS/var/home/SqueezeboxServer/Slim/Control/Request.pm line 856)
    0009:    frame 4: (eval) (/share/MD0_DATA/.qpkg/SSOTS/var/home/SqueezeboxServer/Slim/Control/Request.pm line 2105)
    0008:    frame 3: Slim::Web::Cometd::__ANON__ (/share/MD0_DATA/.qpkg/SSOTS/var/home/SqueezeboxServer/Slim/Control/Request.pm line 2105)
    0007:    frame 2: Slim::Web::Cometd::requestCallback (/share/MD0_DATA/.qpkg/SSOTS/var/home/SqueezeboxServer/Slim/Web/Cometd.pm line 733)
    0006:    frame 1: Slim::Control::Request::renderAsArray (/share/MD0_DATA/.qpkg/SSOTS/var/home/SqueezeboxServer/Slim/Web/Cometd.pm line 871)
    0005:    frame 0: Slim::Utils::Log::logBacktrace (/share/MD0_DATA/.qpkg/SSOTS/var/home/SqueezeboxServer/Slim/Control/Request.pm line 2303)
    0004: 
    0003: [10-01-29 12:16:07.2362] Slim::Control::Request::renderAsArray (2303) Backtrace:
    0002: [10-01-29 12:16:07.2255] Slim::Control::Request::renderAsArray (2303) Error: request should set useIxHashes in Slim::Control::Request->new()
    Any ideas?
    Last edited by Aesculus; 2010-01-29 at 13:23.
    Chris

  7. #27
    Quote Originally Posted by Aesculus View Post
    Any ideas?
    Do you have a &getDisplayName() function that returns a valid string token (e.g. my &getDisplayName() returns something like 'PLUGIN_DENONSERIAL' which is defined in strings.txt). I was trying to make that fairly universal, as getDisplayName() used to be a required method in Plugin.pm, so many of us keep implementing it. It's probably been replaced by an element in install.xml, so you might just want to hard-code that.

    pippin, I'd love to switch to tagged values. Please let me know if you'd like a new build. I figured the iPad announcement might be keeping you busy. :-)

    I haven't looked at Chris' code, but I had an idea about night mode. Jive menus are supposed to have unique IDs. I wonder if Chris could register menu IDs like 'Plugins.DenonAVPControl.00:04:20:11:22:33' for the root of a given player's settings menu, and then return with his notfications a tagged value with that menu ID. iPeng could then know to add some little settings icon for that player, and load/show that menu if the user requested the extended settings for that player/amp.
    owner of the stuff at https://tuxreborn.netlify.app/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

  8. #28
    Senior Member Aesculus's Avatar
    Join Date
    Jan 2008
    Posts
    406
    Quote Originally Posted by peterw View Post
    Do you have a &getDisplayName() function that returns a valid string token (e.g. my &getDisplayName() returns something like 'PLUGIN_DENONSERIAL' which is defined in strings.txt). I was trying to make that fairly universal, as getDisplayName() used to be a required method in Plugin.pm, so many of us keep implementing it. It's probably been replaced by an element in install.xml, so you might just want to hard-code that.
    I have a getDisplayName() routine so thats not it.

    From a Google search:

    useIxHashes indicates that the response is expected to serialised on the cli and so order of params and results should be maintained using IxHashes.

    Not sure what IxHashes are.
    Chris

  9. #29
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    14,781
    Quote Originally Posted by peterw View Post
    pippin, I'd love to switch to tagged values. Please let me know if you'd like a new build. I figured the iPad announcement might be keeping you busy. :-)
    A lot of things keeping me busy right now
    But yes, please do one and maybe define some tags before that
    I haven't looked at Chris' code, but I had an idea about night mode. Jive menus are supposed to have unique IDs. I wonder if Chris could register menu IDs like 'Plugins.DenonAVPControl.00:04:20:11:22:33' for the root of a given player's settings menu, and then return with his notfications a tagged value with that menu ID. iPeng could then know to add some little settings icon for that player, and load/show that menu if the user requested the extended settings for that player/amp.
    Hm, you mean to only have it present on activated players?
    I know Chris has somehow managed to do this after lots of trying but don't remember, how. His menus now show up in the player context menu in iPeng (iPeng shows anything that is a sub menu of the playersettings menu).
    ---
    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

  10. #30
    Quote Originally Posted by pippin View Post
    Hm, you mean to only have it present on activated players?
    Yes. I was thinking about the volume slider for a player using Denon AVP Control. Since there's more to volume than just the gain setting, I thought it might be cool to have an icon by the volume slider for a player using Denon AVP Control for quick access to things like night mode dynamic range compression.
    owner of the stuff at https://tuxreborn.netlify.app/
    (which used to reside at www.tux.org/~peterw/)
    Note: The best way to reach me is email or PM, as I don't spend much time on the forums.
    Free plugins: AllQuiet Auto Dim/AutoDisplay BlankSaver ContextMenu DenonSerial
    FuzzyTime KidsPlay KitchenTimer PlayLog PowerCenter/BottleRocket SaverSwitcher
    SettingsManager SleepFade StatusFirst SyncOptions VolumeLock

Posting Permissions

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