Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.3 Beta Discussion Thread
#11
royalj7 Wrote:This might not be high on the list, but I consider myself the target audience for the auto-gen functionality Smile, and I would love to see a 1024x768 template size.

I would second the vote for adding 1024x768 for some older legacy touchscreens.
Thanks,
Dave Bruner
Cool
#12
Dean Roddey Wrote:It's something that's on 'the list', and I've put some thought into how it might happen. As we've discussed before, things like real multi-touch wouldn't really have much application, since you don't get to size/rotate things in the IV. But ballistic scrolling and perhaps some gestures (which don't actually require that any application level code understand more than one touch point, only that they are understood down at some low level where they can be translated into some sort of call to do something) would be useful.

Of course I don't have any multi-touch capable device, and it would be a joke to try to support it even if I had one if that device was some separate tablet type thing and I had to copy changes to it and try to test them without any debugging capability. The ballistic scrolling wouldn't require that since it requires only a single touch point anyway, but actual multi-point gestures would.

This may be what you mean by ballistic scrolling but I'll put my $.02 in on what I feel is a critical feature request: revamping the way music is displayed/ scrolled within the IV. I personally find the interaction with the library to be unacceptable from an interface standpoint and has always been my biggest hangup with CQC. The system absolutely needs to be more dynamic in browsing through media.

What I would love is for media library info to be truly scrollable within its widget in the interface...as in all of the info is loaded locally and you can swipe scroll through just like on every single other device/ application out there. CQC is years behind in this regard and I don't see how it can be anything other than a non-starter for potential buyers these days. It would be a huge win to have a list-driven media browser that is dynamic. Say what you want about iTunes and the i* device music app but Apple knows how to build an interface that is intuitive and just works. Replicating that type of interface is sorely needed.

Building upon that concept, I see a lot of potential in building database-based widgets where dynamic scrolling happens based on swipe commands within the widget. This would unlock a different way to interface with a template. Browsing through media is an obvious fit but the same concept would work great for lights, weather info, or whatever. Interface devices have plenty of memory to handle pushing the info directly to the device rather than having to load at the server and display page by page at the device.

Not sure how big a change this would require or how incrementally these features could be added but I think this should be a priority as it would push CQC forward in key areas that the interface currently falls very short.
#13
The gotcha is that most such applications are probably dedicated to a specific metadata program, or they are just directly accessing that data on disc and don't care if they interfere with anyone else using it at the same time, i.e. multiple simultaneous users and editing of the data at the same time. And they probably don't care if they basically eat the server CPU while they are doing it. So they just don't have our complications.

A big problem is that, as soon as we go through the trouble to suck over all that info, the user could reload the repository driver, and because most repositories provide us with no real means of correlating previous and new content, all of the info you just sucked over would be invalidated and would have to be pulled over again. We would have no idea what changed and what didn't. Some folks have 60,000 track libraries. Pulling that over would be very non-trivial, particularly on tablets on the wireless network. That's probably 6000 to 10000 cover art images plus at least basic info for browsing at the top level.

So it will be tricky to do, though I have thought a lot about it recently and how it might work, and how we might have some sort of reasonable means of knowing whether what info we got on the last download of the browsing data is still valid and what's not. With cover art that's particularly difficult, since in many cases we have no direct access to the cover art at all, or the data itself for that matter, so we can't put some identifier of our on into it.

And it's gotten worse now because we now deal with incremental updates of the metadata, and we'd certainly not want to re-download all that stuff just because someone changed the user rating on an album or something. The new iTunes repo updates on the fly as the user makes changes, and they can change anything.

So, anyway, it's always been, and remains, a very complicated issue for us because we support lots of different metadata sources, and have to do so generically in order to allow them to be interchangeable, and we have to support multiple users and simultaneous editing gracefully, and can't afford to just pull everything down every time something changes.
Dean Roddey
Explorans limites defectum
#14
Dean Roddey Wrote:The gotcha is that most such applications are probably dedicated to a specific metadata program, or they are just directly accessing that data on disc and don't care if they interfere with anyone else using it at the same time, i.e. multiple simultaneous users and editing of the data at the same time. And they probably don't care if they basically eat the server CPU while they are doing it. So they just don't have our complications.

A big problem is that, as soon as we go through the trouble to suck over all that info, the user could reload the repository driver, and because most repositories provide us with no real means of correlating previous and new content, all of the info you just sucked over would be invalidated and would have to be pulled over again. We would have no idea what changed and what didn't. Some folks have 60,000 track libraries. Pulling that over would be very non-trivial, particularly on tablets on the wireless network. That's probably 6000 to 10000 cover art images plus at least basic info for browsing at the top level.

So it will be tricky to do, though I have thought a lot about it recently and how it might work, and how we might have some sort of reasonable means of knowing whether what info we got on the last download of the browsing data is still valid and what's not. With cover art that's particularly difficult, since in many cases we have no direct access to the cover art at all, or the data itself for that matter, so we can't put some identifier of our on into it.

And it's gotten worse now because we now deal with incremental updates of the metadata, and we'd certainly not want to re-download all that stuff just because someone changed the user rating on an album or something. The new iTunes repo updates on the fly as the user makes changes, and they can change anything.

So, anyway, it's always been, and remains, a very complicated issue for us because we support lots of different metadata sources, and have to do so generically in order to allow them to be interchangeable, and we have to support multiple users and simultaneous editing gracefully, and can't afford to just pull everything down every time something changes.


Forgetting about this gotcha for now, what about starting with creating the capability for a widget to have size beyond what is displayed on the IV to implement the dynamic scrolling aspect? One idea that comes to mind as a completely different way to approach this could be having an interface widget that has a specific displayed size property that can differ from the total actual size. When this is the case, you can "move" what is currently viewed within the displayed area of the IV through swiping gestures - but it needs to be where you actually slide widget content around as you gesture. The closest analogy in my mind is to think of it like viewing a webpage on a tablet where the entire page is loaded but you only see a portion of it at any one time because the rest falls outside the viewable area. You simply scroll down by swiping as you read. The only difference in this case is that we are talking about the gesturing and scrolling being constrained within a specific subpart of the viewer screen.

This could be an interesting workaround and one that would actually open all sorts of new ways to interact with a template that would eliminate the need for as many overlays and cross-template variables. And bringing this back to the original request around media browsing, the current media widgets use list based browsing so I can see the asis driver framework being maintained while "just" addressing the way that you interact with the widget in the IV.
#15
I just posted 4.2.900, our first 4.3 beta. It's in the usual sticky at the top of this section.

It includes a new RadioRA2 driver, which should also work with the Lutron Homeworks QS system. Until it's more official, there's a thread in the beta drivers section about it.
Dean Roddey
Explorans limites defectum
#16
Oops, I broke the CML editor, so don't install .900 if you need to edit drivers. I added some new hot keys and that involved making some changes to how character propogate and obviously regular characters are no longer propogating upwards to the editor window.
Dean Roddey
Explorans limites defectum
#17
I'm going to wait for the drop to fix the driver edits then since I will have to work with them to test it out.

Also before I read this I got an error during the install that the file:

CQCIntfEng_4_2.dll was missing

So it would not install. Downloaded twice to see if it was a bad install.
Thanks
George M
#18
That shouldn't be possible, but I'll take a look at it.
Dean Roddey
Explorans limites defectum
#19
George M Wrote:I'm going to wait for the drop to fix the driver edits then since I will have to work with them to test it out.

The issue, BTW, was with editing CML source code, not editing driver configuration.
Dean Roddey
Explorans limites defectum
#20
I just downloaded the zip and installed and it worked fine.
Dean Roddey
Explorans limites defectum


Possibly Related Threads...
Thread Author Replies Views Last Post
  Official 5.4 Beta Discussion Thread Dean Roddey 441 41,754 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.4 Beta Release Thread Dean Roddey 55 7,322 06-07-2019, 07:02 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 151,300 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 7,910 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 87,644 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 8,804 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 197,128 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 19,502 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 489,144 11-09-2016, 04:34 PM
Last Post: Dean Roddey
  Official 5.0 Beta Release Thread Dean Roddey 15 13,314 11-01-2016, 10:32 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)