Class: AVProcessor

[Dean Roddey]

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.

[pjgregory]

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

[pjgregory]

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

[pjgregory]

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

[Dean Roddey]

The Z1_ should be before Source, not before the prefix. The bit before the # is purely the prefix. So AVPRC#Z1_Source.

[Dean Roddey]

I removed the power fields from this guy, which would now be implemented via the Power device class.

[Dean Roddey]

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.

[Bugman]

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

[Dean Roddey]

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]

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.)