Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: AVProcessor
#11
They shouldn't have any prefix. They aren't part of the standardized device classes, so they are just regular old fields. This is important because any field that has a # in it has to be a device class field. There's various places where the text before the # is gotten and converted into a device class enumeration, so only device class defined fields can use the prefix.

On the PDL front, though it couldn't make use of any CML base class that might be created for that device class, the fact that it's PDL doesn't make it a second class citizen. Just make sure the manifest indicates the version architecture is 2 and that it lists the device classes supported. As long as you do that, name the fields appropriately, and follow the rules for that device class, then it's as much a V2 drivers as anything else.
Dean Roddey
Explorans limites defectum
Reply
#12
Dean Roddey Wrote:Just make sure the manifest indicates the version architecture is 2 and that it lists the device classes supported. As long as you do that, name the fields appropriately, and follow the rules for that device class, then it's as much a V2 drivers as anything else.

I am still on the 4_3 documentation and it is not clear how to modify the Manifest to set the version 2 and to support 2 devices classes Audio and AVProcessor. Could you post an example code segment here please.

PJG
Reply
#13
Forget this. I have found that I can open the manifest for the foobar V2 player, so I can copy the fields from there.

PJG
Reply
#14
A small funny in my PDL Meridian driver. If I name a field as say

AVPRC#Source

,there is no problem. If however, I add the zone prefix as it says I should in the documentation

Z1_AVPRC#Source

, then the driver fails to initialise. It is the same for all the fields in the AVPR class. Yet AVPRC#Source_Z1 works so it cannot be the name length.

PJG
Reply
#15
The Z1_ should be before Source, not before the prefix. The bit before the # is purely the prefix. So AVPRC#Z1_Source.
Dean Roddey
Explorans limites defectum
Reply
#16
I removed the power fields from this guy, which would now be implemented via the Power device class.
Dean Roddey
Explorans limites defectum
Reply
#17
I just implemented a Marantz 8801 that does the AV Processor, Power, and Audio device classes. I also implemented Tuner, but couldn't get it to work so removed it for now. If it's reported as working well, I'll post it (and include it in the next beta) as an example I guess. It supports V1 and V2 modes, but the V1 functionality is exactly the same, to make it easier on me during implementation. Just the field names, and the reporting itself as supporting device classes, is different.

For a while, it'll be difficult not to do V1 versions in some cases, particularly if someone is commissioning it and isn't on the latest betas. And it just wasn't worth doing a new driver at this point and not making it V2 compatible.
Dean Roddey
Explorans limites defectum
Reply
#18
Dean Roddey Wrote:I just implemented a Marantz 8801 that does the AV Processor, Power, and Audio device classes. I also implemented Tuner, but couldn't get it to work so removed it for now. If it's reported as working well, I'll post it (and include it in the next beta) as an example I guess. It supports V1 and V2 modes, but the V1 functionality is exactly the same, to make it easier on me during implementation. Just the field names, and the reporting itself as supporting device classes, is different.

For a while, it'll be difficult not to do V1 versions in some cases, particularly if someone is commissioning it and isn't on the latest betas. And it just wasn't worth doing a new driver at this point and not making it V2 compatible.

Dean: Is this the best example out there? I will be modifying a Pioneer Elite driver in CML so would like to look at how this is done for a V2 driver. If another AVR example is better than this let me know (e.g. the new Denon you posted?).

Bugman
Reply
#19
The new Denon one is probably simpler since there's less stuff implemented so far (only zone 1.) But, otherwise, they are probably equally relevant.

Really, from a driver point of view, there's not much different. It's mostly the naming of fields, which is driven by the device class definitions over in the other forum section. And in the manifest you indicate it's V2 and what device classes it implements.

Presumably for that device you would implement the AVProcessor device class, along with Power and Audio.
Dean Roddey
Explorans limites defectum
Reply
#20
I made a small change to this device class. Instead of requiring that the sub-unit prefixes be Z1, Z2, etc... that is just the default names, and the driver can (and hopefully will) allow the user to name the zones in order to make the field names more portable to other hardware (by just using the same name for whatever zone happens to be used in the new setup.)
Dean Roddey
Explorans limites defectum
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Class: Security Dean Roddey 34 35,406 01-02-2019, 12:26 PM
Last Post: Dean Roddey
  Class: Weather Dean Roddey 6 6,682 10-11-2018, 11:09 AM
Last Post: Dean Roddey
  Class: Thermostat Dean Roddey 17 26,453 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 20,818 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 9,526 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 9,778 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 10,611 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 26,981 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 7,185 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 8,736 07-31-2014, 10:14 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)