Suggestion: Export entity AEM to XML

[ahogen]

This would put an actual use to the statements made by Jeff Koftinoff in some of his presentations about being able to work with XML files as complete AEMs for a given device/endpoint. I don't have access to the IEEE 1722.1 standard, so I have no idea what this XML is supposed to look like.

Having an export_aem ENTITY [int::index] [string::output_file] type command in avdecccmdline would allow a user to grab the entire entity's AEM and put it in an XML file. This XML file could then be inspected manually or used in other programs/utilities.

Currently, being stuck with various commands and queries is fine for quick visual checks of AEM values, but doesn't work well when you want to actually do something externally with that information.

[ahogen]

Some of Jeff's mentions of AEM XML files

• https://avb.statusbar.com/files/presentation/avdecc-aes-ny-2013.pdf
• https://avb.statusbar.com/files/presentation/AES/AES-2014-implementing-AVDECC-koftinoff.pdf (basically the same)

Just found these XML files here. Could these be used as examples/templates for an XML export?

• avdecc.xsd
• bareminimum.aemxml
• simple1.aemxml

Also note some of the files named "aemxml" over here, however they look a little older.

Again, since I don't have access to the actual IEEE 1722.1 standard, I don't know what is and is not compliant with the current standards.

[jdkoftinoff]

See the xsd file and example at http://grouper.ieee.org/groups/1722/1/contributions/xml/

…

On Jun 28, 2017, at 11:42 AM, Alex Hogen ***@***.***> wrote: This would put an actual use to the statements made by Jeff Koftinoff in some of his presentations about being able to work with XML files as complete AEMs for a given device/endpoint. I don't have access to the IEEE 1722.1 standard, so I have no idea what this XML is supposed to look like. Having an export_aem ENTITY [int::index] [string::output_file] type command in avdecccmdline would allow a user to grab the entire entity's AEM and put it in an XML file. This XML file could then be inspected manually or used in other programs/utilities. Currently, being stuck with various commands and queries is fine for quick visual checks of AEM values, but doesn't work well when you want to actually do something externally with that information. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jdkoftinoff]

The xsd file is complete for the current standard

…

On Jun 28, 2017, at 12:23 PM, Jeff Koftinoff ***@***.***> wrote: See the xsd file and example at http://grouper.ieee.org/groups/1722/1/contributions/xml/ > On Jun 28, 2017, at 11:42 AM, Alex Hogen ***@***.***> wrote: > > This would put an actual use to the statements made by Jeff Koftinoff in some of his presentations about being able to work with XML files as complete AEMs for a given device/endpoint. I don't have access to the IEEE 1722.1 standard, so I have no idea what this XML is supposed to look like. > > Having an export_aem ENTITY [int::index] [string::output_file] type command in avdecccmdline would allow a user to grab the entire entity's AEM and put it in an XML file. This XML file could then be inspected manually or used in other programs/utilities. > > Currently, being stuck with various commands and queries is fine for quick visual checks of AEM values, but doesn't work well when you want to actually do something externally with that information. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. >

[jdkoftinoff]

The interesting issue with the xsd file is that if you have an invalid AEM entity model then you end up with an invalid XML file. This is handy in one sense that you can't create an invalid AEM model using a validated XML file. The flip side is that if you have an existing entity with a broken model (refs to invalid descriptors etc) and read the descriptors you can't generate an XML file to represent the broken model.... The code at https://github.com/jdkoftinoff/jdksavdecc-c/blob/master/include/jdksavdecc_descriptor_storage.h Allows for a generic way to store an arbitrary entity model, suitable for using as configuration of an end station AEM...

…

On Jun 28, 2017, at 12:33 PM, Jeff Koftinoff ***@***.***> wrote: The xsd file is complete for the current standard > On Jun 28, 2017, at 12:23 PM, Jeff Koftinoff ***@***.***> wrote: > > See the xsd file and example at > http://grouper.ieee.org/groups/1722/1/contributions/xml/ > >> On Jun 28, 2017, at 11:42 AM, Alex Hogen ***@***.***> wrote: >> >> This would put an actual use to the statements made by Jeff Koftinoff in some of his presentations about being able to work with XML files as complete AEMs for a given device/endpoint. I don't have access to the IEEE 1722.1 standard, so I have no idea what this XML is supposed to look like. >> >> Having an export_aem ENTITY [int::index] [string::output_file] type command in avdecccmdline would allow a user to grab the entire entity's AEM and put it in an XML file. This XML file could then be inspected manually or used in other programs/utilities. >> >> Currently, being stuck with various commands and queries is fine for quick visual checks of AEM values, but doesn't work well when you want to actually do something externally with that information. >> >> — >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub, or mute the thread. >>

[andrew-elder]

Looks interesting Jeff. Is there an example floating around that uses the storage .h file?

[jdkoftinoff]

No public examples, sorry. However the intent is that eventually we would make this specific binary file format a standard way of communicating entity models. A work flow can be: 1. Define aemxml file for your model perhaps using a GUI. 2. Associate symbol names (ascii numbers) with interesting descriptors in the aemxml model. Example: symbol 1 gets associated with volume control descriptor. Symbol 2 gets associated with Panpot control descriptor, etc. 3. Generated binary version of aemxml file using this file format. See it includes association of descriptor with symbol numbers... 4.create your embedded Avb device code which loads this binary AEM file at boot. 5. When the device receives a any. AEM command it looks up the symbol for the associated descriptor. If it finds symbol 1 it dispatches the command to the hard coded function which handles set/get etc commands for the volume control 6. When the device receives a read descriptor command it looks up the descriptor from the file, puts it in the transmit packet buffer and fills in any dynamic data values before sending it out to the controller. This mechanism makes it easy to provide the ability to customize the entity model for a device without having to recompile your program code.

…

On Jun 28, 2017, at 1:08 PM, andrew-elder ***@***.***> wrote: Looks interesting Jeff. Is there an example floating around that uses the storage .h file? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jdkoftinoff]

Also see the associated c code https://github.com/jdkoftinoff/jdksavdecc-c/blob/master/src/jdksavdecc_descriptor_storage.c The code to generate is incomplete: https://github.com/jdkoftinoff/jdksavdecc-c/blob/master/src/jdksavdecc_descriptor_storage_gen.c

…

On Jun 28, 2017, at 1:08 PM, andrew-elder ***@***.***> wrote: Looks interesting Jeff. Is there an example floating around that uses the storage .h file? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[andrew-elder]

Thanks for the comments Jeff.