Media API -- too much?

[rjh]

I would change the storage type of the list item to a class, so the display string and the icon image URL would be seperate items. Then the UI can display as needed. I will have another property for the value. I guess I don't have a problem with an object property that the plugin could use as needed. I am just a little concerned about performance. This entire list object is serialized and deserialized over the channel between HS and the plugin. The more stuff we put in there the slower it will be, and use more memory. A list with 5000 tracks might take forever to pass. So I suggest keeping the data HS stores to a minimum:

* Display String
* Icon URL/Path
* Value as integer

All of the above will need to be passed to the HSTouch client and you will get back the value when something is selected. For multiple selections, SetIOMulti would be called with an array of all items selected (supports that already).

Thank you checking with Spud, I was concerned as well that he did not chime in. I (and bet others as well) agree to keep the interface as simple as possible. I am not fully following your suggestion: are you suggesting to encode (html tag?) the icon URL in the existing string list? Would the value be a separate vector of string or integer, or encoded in the existing string list? Either approach would work.

If multiple items are selected in the listbox, would setMultiIO be called once for all selected entries or called multiple times once for each selected item?

Again just need to understand how you want to design it, implement it and makes most sense within the existing HS3 architecture.

[pcp]

I would change the storage type of the list item to a class, so the display string and the icon image URL would be seperate items. Then the UI can display as needed. I will have another property for the value. I guess I don't have a problem with an object property that the plugin could use as needed. I am just a little concerned about performance. This entire list object is serialized and deserialized over the channel between HS and the plugin. The more stuff we put in there the slower it will be, and use more memory. A list with 5000 tracks might take forever to pass. So I suggest keeping the data HS stores to a minimum:

* Display String
* Icon URL/Path
* Value as integer

All of the above will need to be passed to the HSTouch client and you will get back the value when something is selected. For multiple selections, SetIOMulti would be called with an array of all items selected (supports that already).

Thanks Rich that clarifies and similar to what I was thinking and that would work for me. One suggestion is to add another bit to data HS stores (the 3 you list above) to indicate to the UI renderer to add an indicator that further navigation is possible (like the > on the right in the screenshot below). Alternatively this could be a URL but takes more space or 8 byte char flags (1 used for the > indicator, 7 bit flags for future).

[rjh]

The click events is new, and knowing how the item was clicked is important, but I will have figure out how to get that information to the plugin. Right now, a selected item is passed to the hstouch plugin and then the control pair is looked up. I think a new property will need to be added to the control pair that is set telling you how the pair was selected. Does not look too difficult.

Adding an attribute integer to the pairs is probably the best way to allow us to add attributes to the pair without breaking any classes. That will give us many bits to set for the options you are suggesting, like adding the indicator to show that more information is available.

I would like to keep the listbox simple as mentioned, allowing for other controls in the list item could be a bit of work and I'm not sure its necessary for this. For a full controller, we can just create a group of controls as an example browser and the user can modify as needed. The HSTouch Designer allows for grouped items to be saved as a single entity and added to the page as one.

I think I'd be fine with just an Object Value or ID.

On top of having:
1/ an icon_URL or image_URL capability in the "visible" part
2/ the capability to have multiple selections
3/ to have event notifications such as single click, double click, cntrl click, shift left/right click would be quite important
4/ The ability to control which events (say only single click, single selection)
5/ the ability to highlight entries would be important as well.

A while back, I envisioned this listbox to be the replacement of the MediaAPI. This would have meant that if you were in the HSDesigner and selected Music (or Media), you would be presented with Media items (players, servers..) to control and associated controls (back button, load xyz ...). It would have been a lot more user friendly for HST designers out there but it would have meant that we had to all agree on some "discovery" protocol, where HST Designer would query Media PIs for info. In the same vein, the proposal was to start with a "Media dedicated" Device_Type type (DeviceTypeInfo.eDeviceType_Media.Root perhaps :-)), where this list box obviously would be front and center, but Media PI authors would add other controls to this device and HST could present all the controls as a combined set when selected by a designer. Do I make sense?

Example: I would create ONE HS device_type Media.root, add the list box, add buttons such as "back", "all genres", "all tracks", "pause", Play" ... Which is is pretty much what I'm doing today, just that I don't have the listbox nor will HST Designer show this grouped as the "new Media API". If we were to now let's say add a "pair type" to the VSPair, we could now enforce some proper use of types which will make it even easier for HST Designer to figure out where, for example, the play button is.

As I said, this was a long time ago, I'll settle for the MediaListbox

Cheers, Happy New Year and best wishes for 2016. Any of you going to CES2016 this week? We could hook up.

Dirk

[rjh]

I mentioned on another post that I can add a single int value, call it "Attibutes" and we can use all the bits for special functionality and add flags as needed. This information would also need to be passed to the HSTouch clients since it defines some of the UI.

Thanks Rich that clarifies and similar to what I was thinking and that would work for me. One suggestion is to add another bit to data HS stores (the 3 you list above) to indicate to the UI renderer to add an indicator that further navigation is possible (like the > on the right in the screenshot below). Alternatively this could be a URL but takes more space or 8 byte char flags (1 used for the > indicator, 7 bit flags for future).

[dcorsus]

I mentioned on another post that I can add a single int value, call it "Attibutes" and we can use all the bits for special functionality and add flags as needed. This information would also need to be passed to the HSTouch clients since it defines some of the UI.

Could this bit be used to "highlight" an entry. Example: let's say the listbox is representing the current queue/playlist and the highlighted item is the one currently playing. Possible?

On a different but related topic. I'm with Rich on the risk/issue with user selections that end up in too many items like: "All Tracks". Do we have a suggestion or opinion how to deal with this?

Alternatives:
1/ it is up to the PI author do deal with this. This means an author would restrict the # entries and add entries like "Next" & "Previous" to the listbox items. This is by far the easiest. As a spin on this alternative, the PI author could add a level of navigation for example limited by starting characters like "A", "B" ....
2/ The same as above but now HS Touch PI does it, based on its own knowledge about memory limitations versus performance. Not sure I would like this option at all but .... see next option
3/ The list gets dynamically transferred from either PI or from HST PI to the clients based on where they are in their scrolling. So if you scroll down and before you reach the end, the client informs HST PI and the next batch of entries are transmitted ... just in time. A lot of browsers work that way. Obviously this is where I would like to get but probably hardest to implement but could improve performance overall a lot as you would only have to transmit the info (list box entry objects) based on the turn-around-time to have client tell HST "I need more at bottom or top" and HST either from own info or from PI to get it in time to send to HST Client in the background. If you time it right, user will never know, at worse on occasion he/she may have to wait briefly for the info to come in. I think with a few new events, this could be implemented in not such a hard way, would require HS client to generate "reaching top/bottom" events upon which the PI repopulates the listbox. Challenge obviously for the HS client is to do this without the user noticing

Opinions?

Thanks

Dirk

[rjh]

For this one, lets get it working returning all requested info, then test. I was looking at doing this in HS2, but it turned out to be pretty quick and even thousands of tracks loaded ok. I am sure there is a limit, but I'm not sure what it is. Probably would be best for the plugin and client to manage this as some plugins may not bother dealing with it and the user experience would be bad. I could automatically add a "Next" entry to the end of the list if it got too large, then request the next chunk. The plugin would simply keep a copy of the entire list until its changed. Also, if they are on a slow connection, I could change the batch size. Although, who would control media over a cellular connection?

Could this bit be used to "highlight" an entry. Example: let's say the listbox is representing the current queue/playlist and the highlighted item is the one currently playing. Possible?

On a different but related topic. I'm with Rich on the risk/issue with user selections that end up in too many items like: "All Tracks". Do we have a suggestion or opinion how to deal with this?

Alternatives:
1/ it is up to the PI author do deal with this. This means an author would restrict the # entries and add entries like "Next" & "Previous" to the listbox items. This is by far the easiest. As a spin on this alternative, the PI author could add a level of navigation for example limited by starting characters like "A", "B" ....
2/ The same as above but now HS Touch PI does it, based on its own knowledge about memory limitations versus performance. Not sure I would like this option at all but .... see next option
3/ The list gets dynamically transferred from either PI or from HST PI to the clients based on where they are in their scrolling. So if you scroll down and before you reach the end, the client informs HST PI and the next batch of entries are transmitted ... just in time. A lot of browsers work that way. Obviously this is where I would like to get but probably hardest to implement but could improve performance overall a lot as you would only have to transmit the info (list box entry objects) based on the turn-around-time to have client tell HST "I need more at bottom or top" and HST either from own info or from PI to get it in time to send to HST Client in the background. If you time it right, user will never know, at worse on occasion he/she may have to wait briefly for the info to come in. I think with a few new events, this could be implemented in not such a hard way, would require HS client to generate "reaching top/bottom" events upon which the PI repopulates the listbox. Challenge obviously for the HS client is to do this without the user noticing

Opinions?

Thanks

Dirk

[pcp]

For this one, lets get it working returning all requested info, then test.

Absolutely agree... and as Dirk mentions the plugin author can deal with it while we learn more and have real exposure/feedback.

Although, who would control media over a cellular connection?

Me... to give folks at home a scare and reminder I am still part of the family especially when traveling extensively for work ... but I can use an event for this, no need to browse...

[dcorsus]

Any progress?
Thanks
Dirk

[pcp]

Rich, any update and eta for support in hs3 of what we discussed above?


Sent from my iPad using Tapatalk

[pcp]

Rich any update? Can we put all this media stuff behind us? Thanks

[pcp]

Rich are you planning to support what we discussed in earlier post to be able to use devices as browsers? Any update would be appreciated. Thanks.


Sent from my iPad using Tapatalk

[rjh]

I believe all the developers that use the media API are on board with this. So far, it should work with you creating devices. I believe the only work item on my end is to allow the value pairs to be easily reloaded after a device is created. This is for handling the loading of media items. While you can already do this in HS3 using the CAPI calls, I need to make some changes to the HSTouch clients and server so it can detect and reload the changes.

So I guess the next step is for someone to create the devices and prove that it works ok. This can be a template for other developers.

Rich are you planning to support what we discussed in earlier post to be able to use devices as browsers? Any update would be appreciated. Thanks.


Sent from my iPad using Tapatalk

[pcp]

I believe all the developers that use the media API are on board with this. So far, it should work with you creating devices. I believe the only work item on my end is to allow the value pairs to be easily reloaded after a device is created. This is for handling the loading of media items. While you can already do this in HS3 using the CAPI calls, I need to make some changes to the HSTouch clients and server so it can detect and reload the changes.

So I guess the next step is for someone to create the devices and prove that it works ok. This can be a template for other developers.

Rich,

Are you saying you implemented the changes described in above post 31 (http://board.homeseer.com/showpost.p...7&postcount=31) and the click event described in post 33 (http://board.homeseer.com/showpost.p...postcount=33)?

Months ago, I tried to create a device with a List_Text_from_list vsPair to test as a media browser, but could not get it to work; the control selection list did not appear in the HS3 status page. Below is the code I used at the time. What did I miss? Do you have an example how it should be configured to work? What should the value be to select items?

        MediahRef = hs.GetDeviceRef("Media Browse")
        If MediahRef <= 0 Then MediahRef = hs.NewDeviceRef("Media Browse")

        dv = hs.GetDeviceByRef(MediahRef)
        dv.Address(hs) = "SqueezeBox-Browse"

        dv.Location(hs) = IFACE_NAME
        dv.Last_Change(hs) = Now
        dv.Device_Type_String(hs) = "Browse Device"
        dv.Interface(hs) = IFACE_NAME
        dv.InterfaceInstance(hs) = instance

        hs.DeviceVGP_ClearAll(dv.Ref(hs), True)
        hs.DeviceVSP_ClearAll(dv.Ref(hs), True)

        Pair = New VSPair(HomeSeerAPI.ePairStatusControl.Both)
        Pair.PairType = VSVGPairType.SingleValue
        Pair.Value = 1
        Pair.Status = ""
        Pair.Render = Enums.CAPIControlType.List_Text_from_List
        Pair.StringList = {"Featured", "Local Stations", "Shows", "Stations"}
        hs.DeviceVSP_AddPair(dv.Ref(hs), Pair)

        hs.SetDeviceValueByRef(dv.Ref(hs), 1, True)
        dv.MISC_Set(hs, Enums.dvMISC.SHOW_VALUES) 

Update: I tried the above again with the latest HS3 release version, and it now shows up as multi selection dop list. When I select items, SetIOMulti is called with the list of selected values. How do I specify the list of selected entries in the Pair.StringList?