xml_decorator Application in MLRT
Introduction
The xml_decorator is a member of the Markup Library Rendering Tools (MLRT). It's location in the MLRT build tree is illustrated in the diagram below.
The xml_decorator Application
Markup Library Rendering Tools (MLRT) Download
Our multithreaded software framework provides a loose development paradigm wherein important parameters and constants are stored in multilevel XML files. It turns out these XML files are very useful for signal processing applications where they serve as a convenient store for the myriad parameters needed as well as the topology of the target processing system. Our approach is to create a library of common functional elements, each identified uniquely by a GUID, using C++ source code files with markup fields referencing specific XML file entries. Our xml_decorator program, distributed in source-code form, reads the Markup Library Rendering Tools (MLRT) and, using the files in this library, generates the source code files. These source code files form, when built, an executable application with the desired functionality.
Since xml_decorator program is itself written in C++. It's easily built and can be called from or called by most any other software. Application build tool configuration is also simple. With modern GNU build tools the (-O3) setting is sufficient to generate high-efficiency SIMD code in this fashion. Since this minimalist approach to the fast synthesis of signal processing software appears to boost productivity and reduce errors, we are offering this software free of charge in C++ source code form.
xml_decorator Application Download/Examination
XML_Decorator is an application, build from C++20 source code, that reads the Processor Specification File (PSF) file, and, using the files in the Markup Library Rendering Tools (MLRT) Library, produces a subdirectory of C++ source code files ready for the build.
PSF for a 2-channel audio processing chain:
Example of a Program Specification File (PSF) for an Audio Signal Processor Example
Marked-up source files from the library for an Overlap-and-Add Linear Convolution subroutine:
OverlapAndAddFiltering.h_t
OverlapAndAddFiltering.cpp_t
Signal Processing Application Build Procedure
The procedure to build an executable processor from a Processor Specification File (PSF) is illustrated in the diagram above. A PSF, which is an XML type file, is the definition of the desired program functionality and topology. The files in the C++ Processing Elements Library (PEL) are just marked-up versions of parallelized C++ language modules. For instance, the Overlap and Add Linear Convolution algorithm, or FIR Filtering, is an example of a basic operation in the form of a C++ source file with markups (links two paragraphs below). When these markups are satisfied, the module is ready for the build. The algorithm's parameters, such as the filter length and the location of the filter coefficients, are held in the PSF [xml] file. Note, it is important that the compiler knows the target processor at compile time to get the best performance from the generated executable. Building on the target platform is easiest as the tools can assume the target processor type and operating system. If you need to build the software on a remote machine, make sure you specify the target CPU and operating system correctly for proper operation and high performance.
The xml_decorator Application
The xml_decorator application is used to root the MLRT Library onto a target system. As we are interested in operating system and chipset-independent software, we use the xml_decorator application to root the library onto the target system. CMAKE is required for the build though this source code can be build independently if desired. It's a simple (vanilla) build.
—Move the MLRT Library to any convenient location to serve as the MLRT Library root
—Move into relative folder 'tools/xml_decorator'
cd tools/xml_decorator # Use the appropriate 'cd' command here (OS dependent step)
—Build the source code by running the CMAKE commands
cmake -B build
cmake --build build
—Run the xml_decorator application using a PSF file (PSF.xml below) and generate output files into the specified output directory. Use the current directory for no output directory is specified.
build/xml_decoratror <PSF.xml File> <Output directory else use current directory if empty>
Sample Output
>> xml_decorator PSE.xml {[Output Path] use current directory if unspecified}
The folowing output is produced
>>xml_decorator: source:"program.xml"
target:"WORK"
[ProcessTemplate 7.11968s] //Program/Modules/WAV_File_In_001
[ProcessTemplate 10.552s]
//Program/Modules/FirFilterFourierCoefs_001
[ProcessTemplate 14.0411s]
//Program/Modules/Overlap_and_Add_Filtering_001
[ProcessTemplate 5.90786s] //Program/Modules/WAV_File_Out_001
[ProcessTemplate 8.46751s] //Program/Modules/SubSpaceFilter_001
[ProcessTemplate 6.10518s] //Program/Modules/WAV_File_Out_002
<<xml_decorator: Complete at 20230403_114537
Detailed Information
Tags and Markups
The most commonly used PEL File markup is the value replacement operation or just VAL. As an example, if the xml_decorator application comes across a VAL markup in the text (e.g. {VAL params/val}). If the PSF File section is given as
<root>
<Tag>
<label>Label</label>
<uuid>
<params>
<val>12345</val>
<val_ref>//Tag/params/val</val_ref>
</params>
</Tag>
</root>
Then, when the Tag function is being rendered, the markup string {VAL params/val} is replaced by
{ VAL params/val } ===> 12345
{ VAL label } ===>
Label
Markups can be placed anywhere in the PEL library files. Each processing object has a unique tag (Tag in the example above). A markup is enclosed in curly brackets. It starts with a command string (VAL in this example).
An XML field may contain the address of another cell as in this example. Here // indicates the root of the XML File
{ VAL params/val_ref } ===> 12345
As an example of a full PSL File take a look at: Full Program Specification File (PSF) Example