Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 4.4 Beta Release Thread
#11
Version 4.2.910 is posted. This one includes some small fixes and improvements, a new driver, and support in the auto-generation system to configure invocation of some global actions that you can use to provide customization of the functionality without changing the actual generated templates. See below for details, and note that these are not supported yet in the Android app, only in the generated templates.
  • Add support to the Brultech driver for the 'polarized' watts info, and the corresponding polarized watts and calculated polarized kWH fields.

  • Add a new driver for the RCS Zigbee enabled thermostats, using the XBee system to interface CQC to the Zigbee network. Use the same field names as the existing serial version, to make transition easier.

  • The room config/auto-gen stuff currently provides a three state enablement scheme for some of the optional functional areas, not used, display, or control. This is just too complicated to support, so dump the Display and just have it be Not Used or Used. That will simplify things a lot more. Any existing Display settings will get changed to Used.

  • The PLM Insteon driver probably isn't much used these days, but update it with semantic field type info to make it auto-gen system friendly.

  • Some recent changes caused a problem where activating a tab in a tabbed window inside a dialog would cause issues sometimes with the activiation going back to the original owning frame window when the dialog box is closed, requiring a click to get activation back.

  • Add support for some global actions to the auto-gen system, which can be used both by the auto-generated templates and any iOS, Android, etc... XML GW based clients that use the auto-gen configuration data. This involves additions to the room config classes, adding to the XML GW, and a fair bit of work adding a new config tab to the room configuration info. There are some run upon entry to particular overlays, and some that are for invocation by the user explicitly.

  • Update the auto-generated templates to make use of the new global actions above. The 'on entry' type actions are just invoked automatically upon entry if configured, and the power on/off ones will drive buttons on the templates.

  • The combo box class is incorrectly passing on cursored item events when the drop down list is being moved across. We really only want to store the new value or send a notification of a change if they actually select a new item, so if they arrow when the list isn't displayed, or when they make a mouse or keyboard selection from the dropdown list. This also means that it will correctly not change value if you pop up the list, move the selection around, and then hit escape to not make a selection.

  • The Tray Monitor needs to deal with the fact that it might not have successfully gotten the name server entry removed when it went down, so it needs to be tolerant of it already being there if it comes back up quickly (before the entry has timed out due to lack of renewal.)

  • The cast and aspect ratio don't seem to be working on the device simulator audio driver, perhaps because it assumes it only plays audio. But it's very convenient to use it for standalone testing of movie functionality as well, so fix that.

  • The standard (Windows) RIVA client is incorrectly exiting when you do File -> Log Off. It should just disconnect and start asking for a login again.



On the global actions, there are:

On Entry. These are invoked when you select a particular functional area (overlay) from the tool bar. They give you a chance to set up other stuff to be correct for that selected function, such as selecting AV processor or MZ audio inputs, and that sort of thing. These are available for music, movies, and the Roku. Others will be added as required.

Power Off/On. For music and movies currently the are power off and power on options. If configured, these will be invokable from buttons on the media browser overlay (the appropriate ones for the current media type being browsed.) So you can use these to power up/down a home theater or audio system or whatnot. You could choose to do no On Entry stuff and put all of that into the Power On command, so that it only happens if you make it happen.


You can pass parameters to them. These can include variable references if that is convenient. Some you might want to use are GVar:CurOverlay and GVar:CurRoom, so that the actions you invoke can respond to these values, allowing you to have fewer, parameterized actions, or you can have separate ones for each possible action in each possible room, however you want to do it.

This should make the auto-generated templates considerably more useful for a lot of folks, so hopefully it's worth the effort required to implement. Let me know how it goes, or if there are some others that would be hugely bang for the buck to support.

I'll see about getting it into the Android app now.
Dean Roddey
Explorans limites defectum
#12
Version 4.3.911 is posted. This one has a couple small fixes but mainly it just gets support for the new global actions supported added to the auto-generation stuff into the Android app.
  • Update the auto-gen based Android app to support the new global action stuff added in the previous drop. On the movie and music player screen, if the power on/off global actions have been defined for that media type, there will be buttons to invoke them, else they won't show up.

  • Change the Android app so that the "I'm working, please wait" type progress bar so that it shows up on the title bar when needed. This means the same one can be used by any activity that needs one, so move the support for it down into the common activity base class, and updates any other activities that need such things to use it so that they will show the progress bar.

  • IPV6 numeric addresses with explicit port numbers are potentially ambigous, because it's not possible to be sure if the last :xx value is a port or part of the IP address. So numeric IPV6 addresses are supposed to be bracketed when formated out, e.g. [::1]:8888, so update our URL parsing and formatting code to handle this.
Dean Roddey
Explorans limites defectum
#13
Version 4.3.912 is posted. It has a few new features and a couple fixes. It now adds set points support to Z-Wave thermos (via the VRCOP driver), and adds a new 'security mode' which lets you have a popup up come up after a period of inactivity, which the user has to be able to dismiss in order to get back to the underlying stuff. If the popup requires a password it basically becomes a 're-validate after timeout' sort of function, as with the Windows screen saver requiring login after it kicks in.
  • Add ButtonHold and ButtonMTap options to the UserAction events sent out by the Lutron RA2/HQ driver, so that you can use those types of button interactions to do things in addition to just the button press.

  • Add a 'secure mode' to the IV, tied in with the auto-blanker stuff. In the IV's SetBlankerOpts action command, there are now two new parameters, in addition to the timeout period. One is a path to a template and the other is a template parameters parameter. If the path is set, then when the blanker kicks in, it will invoke this template as a popup. When the blanker is dismissed, the popup will be there. The user will have to dismiss it in order to get to any underlying stuff. If it requires a password before it will dismiss, then it is effectively providing a 'secure login after timeout' type of functionality. Note that the blanker will only kick in if the viewer is the active application, whereas the security popup will kick in either way. We have to be sure to suppress this when running viewer windows in the Admin Intf.

  • Popups typically dismiss themselves upon an Escape key. This was never an issue before, but the new secure mode stuff above requires that it not do that when the secure popup is up. So we now have to pass a flag into the popup invocation code to indicate whether the current popup can respond to an escape or not. If it doesn't, then the only way to get rid of the popup is do what it is asking you to do. Be aware during designing this popup that, if you create one that can't be dismissed, then you will have to kill the viewer, since the escape key won't get you out.

  • Add support to the Leviton ZWave driver for high/low set point fields on the thermos. They are only enabled if async notifications are enabled, else it would be just too much polling to add still more things to the thermos that have to be polled. Low is the heating set point and high is the cooling set point. You can still set them via the Command field as before, but they are now directly writeable as well. Thermos are marked by default as supporting async notifications, since the assumption is that most would.

  • Add thermo specific configuration options for C/F temp scale so that each thermo can be configured for the desired scale. It's the per-module type combo box in the lower right when you are configuring a selected module. It will default initially to F.

  • Bizarrely the defaulting of the result return for a popup template was never getting initialized to false so that it would return false upon hitting the Escape key (i.e. exiting the popup without an explicit Exit() command in the popup), though I never ever saw it do otherwise until now. Must have just been pure luck for all these years. Weird. But it gets correctly initialized now.
Dean Roddey
Explorans limites defectum
#14
Version 4.3.913 is posted, which has a new driver, a fix for the Russound driver, and a couple small fixes.
  • There were an issue in the Russound RNet driver wrt to doing zone status queries for zones above 6, i.e. for anything on controllers past the first one. So it wouldn't see initial values for those zones when the driver starts up, and might not respond correctly to incoming reports from the keypads.

  • Add a new driver that is like the CML based generic TCP/IP passthrough driver, but that can listen for a connection instead of make one. So we need to implement that same functionality but in C++ since only C++ drivers can listen for connections.

  • Up the time that the Event Server waits after startup before it starts processing incoming triggers, to give drivers more time to come up. But, move this pause to after it initializes the ORB and registers itself, so that at least you can get to the configuration dialog while it's waiting. It was 20 seconds, make it 45 seconds to see if that holds off triggered events until any drivers that are likely to come up have done so.

  • In the auto-gen templates, we shouldn't invoke the enter music/movies global action just for going back to the browsing screen from the now playing screen. If we see that the current overlay indicates we are already in the same media mode section, don't re-invoke.
Dean Roddey
Explorans limites defectum
#15
Version 4.3.914 is posted. This one has a number of fixes, a new driver, and the beginnings of dipping the toe into the new 'V2 Driver Architecture' stuff. There is one potentially breaking change, though only if you are using some of the device simulator drivers, which few folks would be.
  • Create a new HTTP based trigger driver. This one will accept HTTP GET commands. The resource part of the URL becomes the action key. Any query parameters become a parameter to the action invoked. It uses transient connections, so you connect, send the GET, wait for the reply, then close, as generally a simple HTTP client would do. You tell the driver what port to listen on. Since it's an IR/Trigger type of driver, you train it using the same client interface as any other IR receiver or trigger driver.

  • The regular generic trigger drivers, when in training mode, need to split out the key part of the incoming text and only store that as the training data, so that you can train it correctly even if you have the separator and parameters on the incoming text.

  • Start updating the device simulator drivers to the new V2 architecture, as test cases. Hopefully this doesn't break anything critical, since they are just simulators. But I can't afford the overhead of supporting them in old and new modes. So far done are IO, Security. The rest will be done in subsequent drops. If you have either of these loaded, they will fail to load. You will need to unload and reload them, so that the new manifest will be used.

  • The Lutron RA2 driver, when an exception occurs, should be checking to see if it's a serial or socket connection and leaning towards comm resource cycling, whereas right now (some code having been copied from the old driver) it's leaning towards connection cycling, which can leave the socket created but not connected, so that it will fail again when it tries to connect, possibly ad infinitum.

  • The XMLGW is not correctly encoding the CQCGW:Limits attribute, which might have a single quote in it. The GW uses single quotes, so that will cause a parsing failure in the client.

  • The main template of the wide screen auto-gen stuff, and the now playing screen, should be using the new capability of setting the current cover art widget to the current item cookie, so we can see the cover art for the individual item's collection even when playing through a playlist.

  • Only store the 'SystemOn' value in the Russound RNet driver when the incoming msg is for a zone on the first controller. Ignore it for other controllers.

  • Looks like the Z-Wave thermo mode is gettable, so if the thermo is marked async, make the mode field readable, get the initial value, and watch for async reports.

  • A tricky issue in the Omni driver will cause it not to always send out lighting load event triggers. The problem is that, unlike the other types of trigger sending units, lighting loads can be changed wither via field write or via external event. We were only sending out a trigger upon receiving a change report from the Omni. But, in the case of a field write, the value of the field was updated when the Omni acknowledged the change command. So, by the time the report of the change echoes back from the Omni, it doesn't look like a change in value, so the trigger isn't sent. We need to send a trigger at the point where the outgoing command is successful, AND upon getting a report of change. In the former case we won't send a dup since the thing that is preventing the correct sending of the trigger now will prevent the duplicate trigger as well. The sending of the trigger upon receipt of a change report will only happen if it's due to an externally driven change. Oy!

  • Update the Omni TCP (v1.3), Elk M1 (v2.2), and device simulator security drivers to support the change in one of the backdoor queries, the one that gets the areas and their associated fields. It now also returns the area alarm status field, in addition to the area arming status field. The auto-gen now depends on this (as defined in the ongoing device classification definitions) though it is not yet using it, so these guys need to conform or they won't work with auto-gen.

Dean Roddey
Explorans limites defectum
#16
Version 4.3.915 is now posted. This one introduces ballistic (or inertial or whatever you happen to call it) scrolling, to complement the gesture based scrolling invocation that we added before. So it should now react much like what folks are used to these days. This won't happen on RIVA clients, for the usual reasons, only on the IV clients.

So far the cover art browser, the advanced media item browser, the tool bar, and all of the ones that are variants on the basic horz/vert list browser have been updated. The media list browser and calendar are known not to be done yet, and maybe there's some other obscure one I'm forgetting. But the ones done are far and away the majority of scrollable widgets used.

I won't absolutely guarantee that it will work with focus images, since I've not tested out those scenarios yet. But, in theory, you wouldn't be using focus with a client you are directly interacting with anyway, so I wasn't too worried about leaving that for now.

I'm pretty confident it's working right, but it was a stupid amount of work and complexity to figure it out. So of course you might find something I missed. Worst case though it would only possibly confuse the viewer, nothing on the backend should be affected by this since it's all graphics stuff. Well, the RIVA server potentially but only because it's sort of a client but just running in the background. Just let me know if you see anything where it doesn't look like it's updating right, or of course if it gives an exception or something. There might be some obscure corner cases I've missed, no matter how many variations I've tried.

On the CAB, when you select a title set with multiple collections, it scrolls upwards to expose the collections. To get back up to the title level, drag down to pull the titles back down again.

Note that it's not inertial in the sense that it moves further if you flick faster. That's not been implemented. It's just that it doesn't move page to page anymore, it slides from one to the other in that ballistic type mode where it's fast at first and then slows down as it approaches the new system. I selected settings that I thought provided a nice looking, but not annoyingly long slide, but let me know if you think it's not optimal.
  • Do a first cut at implementing inertial scrolling in the IV. This cut includes the CAB, the advanced item browser, the toolbar, and all of the variations on the horz/vert list browsers.
Dean Roddey
Explorans limites defectum
#17
Version 4.3.916 is posted. This one has more work on the inertial scrolling stuff. Mainly it's to get what I have out there before I embark on a considerably more dark and dangerous rework to allow overlays to be scrollable.

I was going to do that for this round, but it just turned out that no matter what I did I was stymied for various technical reasons because of the way things are structured. So a couple days of getting nowhere before I finally conceded that it's going to take a fairly heavy attack to make it happen. So I wanted to get this much more straightforward stuff out here first.

This one adds scrolling for the media list browser and the calendar widgets, and spiffs up some of the stuff done in the previous drop.
  • The Tray Monitor's iTunes tab isn't quite getting the counts of titles and tracks with issues right. So fix that, and also add a failed tracks counter in addition to the existing ignored tracks counter. Add more verbose logging (to the tab's log window) in those cases where things failed or sufficient info was not available.

  • If the C++ RIVA client gets an exception back from the server while processing a template, it just falls over. It should put the login screen back up.

  • Take another whack at the inertial scrolling stuff. Go back and improve a bit on the existing work from the last drop and add support to the media list browser and calendar widgets as well. Was going to do overlays, but I couldn't get it done. Every direction I turned I was smacked down. So that's going to take a considerably heavier attack to get working.

  • Catch any exceptions that occur during the drawing of each widget, and log the type and name of the widget, to help with any issues of that sort that might occur in the field.

  • If an overlay has a border, it's not shown in the designer.

Dean Roddey
Explorans limites defectum
#18
Version 4.3.919 is posted. This is a 'Big Update' as they are known technically in the business, so there are things to be aware of. I will post the changes list here and then follow up with a higher level discussion of what to be aware off.
  • The field enumerated image widget loses its assigned images when you edit it. An invalid flag is causing the widget to think that all of the fields being passed to it are being set as the new current field, which overrides previously set info.

  • Update the media playlist item class to hold a repository moniker. This is a necessary step towards getting rid of the need for media renders to have fixed associations media repositories. This way, the repo moniker can be queued up with the playlist items, and therefore items from multiple repos can be queued up at the same time. The repo association is still there, and will be used if none is passed in to the PlayMedia or EnqueueMedia fields, and it is also used in random play from category mode.

  • Also add a unique id to each new playlist item that is added to a playlist. It will be used for other things later, but for now it provides a way to delete and selection playlist items now that cookies aren't necessarily unique in the list (could be the same cookie from different repositories.)

  • Update the playlist format/query methods to include the new playlist ids and the per-item repositories, so that they can be made use of on the client side as required. And update the CML wrapper of the playlist manager to expose these new values.

  • Add a 'user data' value to media playlist items. This allows renderer drivers to put some data into each queued up playlist item if needed, to track some association with an external player or whatever is required. Add it to the AddMedia method, so that it will be added to any playlist items added.

  • Update the AddMedia method of the playlist manager class so that it will accept either just a cookie, as it does now, or a cookie, space, and repository, to support the new scheme. If only a cookie is passed, then the default repository is used and queued up in the new items. If a repo is passed, then that is used. Since renderer drivers were just passing the provided value to the playlist manager to add new items, they should work with either existing user code or new V2 stuff that passes the repo in.

  • Drop the media changer manager driver. No one uses changers anymore, and it's a burden to keep it up. So just let it go.

  • The Sonos specific ZP driver is looking for Previous for the Transport field's previous track command, but the actual value in the field's limits is Prev, so get that fixed.

  • Update all the existing shipped renderer drivers to support the new V2 scheme, and be as backwards compatible as possible, though it won't be 100%. We just use two manifests, one of which sets the V2 scheme. The drivers look at the driver architcture version, and do one thing or another. This involves changing the names of fields to match the V2 scheme when in V2 mode mostly, and the del/select playlist item changes.

    There will still be more work to do on the renderers, to add more device class support, such as standardization of transport controls and such.

  • The auto-generation system now will only work with renderers in the V2 driver architecture mode. So, for those folks using auto-generation, they will have to update their renderer drivers to the V2 versions, and regenerate their templates.

  • The pressed image support for the toolbar is drawing everything pressed after the recent inertial scrolling updates.

  • The text in the dimmer popup of the auto-generated template stuff isn't being set up, so it just shows what's there in the original source templates from which the auto-gen is being done.

  • Update the auto-generated template stuff to use the new input-capable progress bar in the dimmer popup, and use a light image progress bar to set the light level instead of a slider. So just drag on the light bulb up and down to set the level.

  • Add support for native multi-touch gestures under Win7/Win8 when there is appropriate hardware installed. This requires creating a loadable gesture processing interface, which will be loaded dynamically based on the OS version. It can't be hard coded in since that would cause it to fail to load on XP/Vista. So if on Win7 or up, we load the multi-touch engine and ask it if multi-touch hardware is available. If so, we use that engine. Else, no gestures will be available. Note that this means the old 'faux gestures' are no longer supported, only native multi-touch.

  • Update the Overlay widget to allow the contents of the overlay to be scrolled if it is bigger than the overlay itself. This is quite complex. It will only be allowed if the overlay has a flat background fill color, it can't be transparent. If multi-touch is available, then two finger scrolls will always scroll the containing overlay, even if you start the gesture over a widget. For single finger scrolls, you have to hit the overlay background for it to see the gesture or a non-gesture oriented widget, else it goes to the widget you actually start the gesture over.

  • The XM Channel driver is faking a bit of media renderer functionality in order to use Media Image widgets to display cover art. This won't work anymore due to changes mentioend above. Renderer drivers don't return cover art anymore. So, the faux cookie field it provided was changed to a CurArtURL field and the current URL for the cover art written to that. This means that the field based Web Image widget can be used instead, and likely will perform better as well. But it does mean you will have to make this change in your templates, else you won't get any cover art anymore from this driver.

  • It was always a side effect that the CQCMediaInfo CML class's GetItemList() method would return both the items in a collection from the repository, and the info in a renderer's playlist. The changes above mean this won't work anymore. That method is purely now for repository queries, to get the items in a collection. A new LoadFromRendPL(moniker, setids) method was added to the playlist manager class to allow you to just load up a playlist manager object with a list of items from a renderer. This also gives you access to all the info available. The setids parameter indicates if you want to keep the list item ids from the source driver, or allow the target PL manager to assign new ones to them.

  • For now, the XMLGW will continue to have a single call for both. It will do one or the other based on whether the collection cookie is empty or not. If empty, then it assumes it's a playlist query. Later this should be updated to have two distinct calls as well. In the case of querying a playlist, you will get back a CQCGW:Ids list, in addition to the stuff that was already there. These are the list item ids mentioend above, now used to select or delete a playlist item.

  • Create a standard C++ media renderer base class and port all the existing C++ renderers to be based on that. This will make it far easier to maintain and update the renderer drivers moving forward. It makes it far easier to support a standard renderers.

  • Create a standard CML media renderer base class and port all the existing (shipped) CML renderers to be based on that. As above in the C++ world, this gets rid of redundant code and makes standardization easier. Later we'll get rid of all of the C++ renderers by exposing via CML the functionality they require, and only have one base class. But, for now, we have two. Oh well, better than 10 or more, all done separately. This also requires implementing all the random category playlist mode stuff for CML as well as some other supporting functionality.

  • Zoom Player and TheaterTek don't seem to support IPV6, so force IPV4 name resolution in their respective driver manifest files. Otherwise entering the target host name, instead of IPV4 address, can fail to connect if IPV6 is enabled on the machine where they are running (since that will be the preferred address type.)

  • Now that we can support multi-touch gestures, the RIVA protocol needs to be expanded to support sending these commands to the RIVA server, which will pass it to the IV engine. These are in addition to the regular mouse events it currently supports. This wil be backwards compatible with older RIVA clients, who will only send the original mouse type events.

  • Update the C++ RIVA client to support the new gesture sending msgs added above.

  • Add a command to the Logo Image widget to allow users to change the image repository path dynamically at viewing time.

  • Update the server side driver selection dialog to display more info, now that we are starting to have V2 compatible drivers showing up, though it'll be sort of lightly populated until more of them are converted.

  • Update the server side driver info dialog to show driver prompts, so that the user can see the values used to configure the driver as it currently is installed. Change it to use a list, so that we can display an open ended list of values.

  • Add support for velocity to the gesture handling, so that the distance scrolled can be affected by the velocity of the gesture. Go back and update all the widgets other than the CAB (which is purely page oriented) to support it.

  • The recent changes to the media list browser, to make it smarter about skipping over the collection level when you select a music title that only has one collection. It just skips forward to the item level instead. It wasn't updating all the level/index tracking data and would get an error if you made a subsequent selection.
Dean Roddey
Explorans limites defectum
#19
As you can see, the 4.3.919 update is pretty big. It includes some major changes that are necessary to keep moving CQC forward into the future. This post is just to provide some guidance on what to expect.

Gestures

We now support real multi-touch gestures. For the moment, the old faux gestures supported original are not available, so there is no gesture support on XP/Vista. We'll see what we can do to get that back, but can't make promises. That was a beta thing, and some beta changes don't survive.

On Win7/Win8 you know have real gestures, and it works quite nicely. All of the scrollable widgets can be scrolled with finger swipes. They are velocity sensitive so a slow swipe moves less distance than a fast one (except the CAB which is purely page oriented and moved page at a time no matter what.)

This doesn't affect people on no-touch systems. Everything still works via a mouse just as it always did. And if you are on a non-multi-touch touch screen, that is really just a mouse to CQC so that will work the same as before as well (modulo the faux gestures stuff mentioned above.)

On a multi-touch display, things like the slider, progress bar (if it has a writeable field), and volume knob, i.e. things that actually have to be dragged to change them, you have to do a press and hold, then drag. Once the OS gives you the press and hold indicator (usually a circle around the press point I think), then you can drag.

For regular 'button click' type operations (select something in a list or tool ba or CAB, click a button, etc...), just do a short press and release. That shows up to the program as a mouse left button press, release.

Note that gestures do not involve any press/release, so you can't do OnPress or OnRelease type commands where gestures are involved.


Overlay Scrolling

The templates loaded into overlays can be larger than the overlay and can be scrolled now as well. That is currently only supported via gestures, i.e. there aren't yet any commands you can send to the overlay to scroll it.

The general rule is, if you do a single finger swipe over the background of the overlay, or over any non-scrollable widget, then the overlay will see that and scroll the contents if appropriate. If you have scrolled it such that the whole visible area is covered by a scrollable widget, you can also do a two finger swipe gesture, which is always passed to the underlying overlay.


V2 Driver Architecture

We've begun what will ultimately be a fairly long process of standardizing drivers. We are defining 'device classes' and any driver can implement one or more of these. This provides standard ways for CQC to interact with device drivers, which is something that is very important, and one of the worst decisions we made in the early years of CQC, not to go this route to begin with.

Though this does not mean that drivers can't provide functionality above and beyond these device classes, it does mean that any code that limits itself to working within these standard interfaces should be pretty well able to swap one device for another, or create logic or interfaces that are applicable to any compliant drivers.

It also doesn't mean you have to use the V2 drivers. You can stick with V1 for now, though there will still be some small things you have to deal with after you upgrade.

We are going to inevitably have to go through a fairly long period where there are V1 and V2 drivers out there. Right now there are only a small number of V2 drivers, but there will be more and more moving forward. Where possible existing drivers will be set up to be 'bi-modal', and there will just be two manifest files, one loading it as a V1 and another as a V2. Where that's just complicated, the old driver will be left in place and a new one started. That new one will be the future ultimately, so we'll be encouraging people to migrate forward any time it's feasible.

Mostly it'll be changes in fields, to end up with standard field names, that have standard meanings. Often they will be quite like what was already there in the V1 driver, or pretty similar. So mostly the changes won't be huge or anything. The biggest change is the use of a 'device class prefix' on field names. So a field name like MyPlayer.PlayMedia, becomes MyPlayer.MREND#PlayMedia, to indicate it's a media render field. The primary reason for this is that device classes and drivers aren't one to one. Drivers often will implement multiple device classes, and to avoid field name clashes, the device class fields have to indicate which class they are related to.

The driver selection dialog has been expanded to show much information about drivers, so that as more of them become V2 compliant you can see that they are or not, and if so what device classes they support.


Media Renderers

For this round, the primary thing we've addressed in terms of the V1/V2 thing above is to get all the media renderers updated. So you will now see V1 and V2 versions of the media renderer drivers. For the most part everything is backwards compatible but there are couple small things you'll need to adjust for. And, if you are using a third party renderer driver, it'll need to be updated a bit, even if it's not going to support V2 mode immediately (or ever.)

Beyond the V1/V2 stuff, which won't affect you if you are using a V1 driver, there are also some changes that will affect you, either in that you need to make a slight adjustment, or you'd probably want to use it even if you don't have to. These are:

[INDENT]Default Media Repo - Currently you must have a default repository associated with each media renderer. This is because the clients queue up media cookies associated with that repo, and the renderer needs to go grab metadata about each one as it comes up as the active playlist item.

This is no longer required. You can now queue up both a cookie and a repository. And each playlist item stores the cookie and the repository together. This means that a renderer can have stuff queued up from multiple repos. If you don't pass the repo moniker, then the default is used, so it's backwards compatible.

Even if you do that, the repo is still queued up in each playlist item, so that means the playlist doesn't have to be emptied (and won't be anymore) if you change the default repo.

PlayMedia vs. EnqueueMedia - Traditionally these have been asymmetrical, in that writing an item cookie to PlayMedia was used to select that one as the active item, whereas writing any other cookie type to PlayMedia flushes the list and loads up the new stuff. This has been changed now so that they both act exactly the same. PlayMedia with an item cookie will just clear the list and load that one item.

Selection of a new playlist item, or deletion of an item, is now done via a unique id that is assigned to each item as it is added to the playlist. So this is a change you will have to adjust for. There is a new runtime value when you select an item in an item list browser, which is the unique id. You will pass this id to the SelPlaylistItem or DelPlaylistItem fields to do these operations now.

This is also required because the cookie by itself is no longer guaranteed to be unique. Since items from multiple repos can be queued up on the playlist, it could be impossible to know which of two songs with the same item cookie you are referring to.

Later these ids will also be used to make the updating of media item list widgets much smoother, instead of just emptying the list and reloading it each time the list changes, but that hasn't been done yet.

Standard Base Class - To make things vastly more straightforward there is now a standard base class from which media renderers can derive. It handles all of the grunt work and the actual derived driver class only needs to deal with the stuff specific to its device. This greatly reduces redundancy and makes it much easier to make changes and have all of the drivers manifest those changes without being affected.

You can still do it all yourself if you need to, but it's very, very much suggested that you base your renderer driver off of the new base class. All of the shipped renderers have been so updated.

Standard Media State and Transport - One part of the standardization is also things like standard transport commands, volume/mute, and player status, which are very important. The renderers all have a standard MediaState and Transport field now, instead of whatever proprietary field they had before. In theory we could have kept the old one as well, but since some breaking changes were being introduced it was best to just toss that and greatly simplify supporting V1 and V2 modes in the same drivers. So, if you are using such fields (the ones that indicate playing, stopped, paused, etc...) you'll have to update to use this new field.

[/INDENT]


Auto-Generation

The auto-generation system will only now work with V2 renderer drivers. Of course if you are just using auto-generation, it doesn't matter. Just unload the V1 version and load the V2 version and re-generate your interfaces. If you are using both auto-generated stuff and manual stuff, you'll have to adjust for this. The field names will be different, and the stuff mentioned above about playlist manipulation (if you aren't using auto-generated stuff to do it) will have to be dealt with.
Dean Roddey
Explorans limites defectum
#20
I made a good bit of progress tonight on the final step in the standardization of the media renders, setting up new device classes for transport/media state and audio control (volume/mute) and I'm updating the base class and renderer drivers to use these now. That will really get the actual renderer driver classes down to just the bare essentials of dealing with their device specific stuff. The base class handles fields writes for volume, mute, and transport and just does a call to the derived class to handle the operations.

I'll try to get this done quickly and get another drop out, since it will also have some small breaking changes, then that will be it for the media renderer changes, and presumably any more breaking changes related to device class stuff for this release. Then I can update the auto-gen stuff so that it should now work without issues with any compliant media renderer, and it'll allow it to be a bit fancier now since it can safely get more standardized info.

I know it's kind of a pain to have to deal with these changes, but they are pretty small and easy to adjust for. The other alternative would have been to just leave the existing drivers behind and create new ones, which would have pretty much meant never really improving the existing ones. This way, even if you chose not to upgrade for a while to the new V2 complaint modes of the drivers, you'll still get any improvements over time since they are the same drivers in V1 and V2, with just different field names and some extra functionality in some cases in the V2 drivers.

Once I get the next drop out I'll work on updating the Android app to work with the changes, and it will benefit in the same ways.
Dean Roddey
Explorans limites defectum


Possibly Related Threads...
Thread Author Replies Views Last Post
  5.5 Beta Discussions Thread Dean Roddey 9 401 07-21-2019, 05:17 AM
Last Post: Dean Roddey
  Official 5.5 Beta Release Thread Dean Roddey 3 193 07-21-2019, 05:15 AM
Last Post: Dean Roddey
  Official 5.4 Beta Discussion Thread Dean Roddey 441 44,711 06-15-2019, 02:33 AM
Last Post: Bugman
  Official 5.4 Beta Release Thread Dean Roddey 55 8,013 06-07-2019, 07:02 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 156,889 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 8,344 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 89,898 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 9,066 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 201,304 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 19,995 05-12-2017, 05:44 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)