[Clam-devel] Ladspa Plugins using embeded Networks

[Hernán Ordiales]

On Tue, Jul 29, 2008 at 4:41 PM, David García Garzón
<dgarcia at iua.upf.edu> wrote:
> Network based ladspa plugins are already usable:
> - The network is now embeded into the plugin so you are not limited to a
> single CLAM based plugin indicated by CLAM_NETWORK_PLUGIN_PATH.
> - Metadata is not hardcoded but writen on user code. (id, label, name, maker,
> copyright).
> - More than one network based plugin can be defined in a single dll
>
> Take a look to the source code that a user should write to generate a plugin.
> I really like it :-)
>
> https://iua-share.upf.edu/svn/clam/trunk/CLAM/examples/PluginExamples/ClamLadspaPluginExample/MyClamLadspaPlugin.cxx
>
> The rest of code files in the folder are to be moved to CLAM core once the API
> is stable
>
> Next step is generating them from the NetworkEditor ;-)
>
>
> Some implementation details follow for those interested on how to embed data
> files in the executable.
>
> At last i didn't use the hack i explained in my previous mail using ld or
> objcopy. It worked with programs, even i did some SCons tool to have them
> built and to rename the symbols as you want. But when i tried to link the
> generated object into a shared library, it complained about using different
> binary formats and i couldn't figure out how to change it.
>
> I considered the following command i found on a mailing list:
>
> (echo "const unsigned char binary_data[] = {"; od -txC datafile.xml |
> sed -e "s/^[0-9]*//" -e s"/ \([0-9a-f][0-9a-f]\)/0x\1,/g" -e"\$d" |
> sed -e"\$s/,$/};/") >myfile.c
>
> Which generates c code representing the content of the file (i didn't believe
> either, try it). But it requires some tools such as 'od' and 'sed' that i
> don't know if they are present in all the platforms (specially windows). I
> discarded implementing that on python or in C if i found a better solution.
>
> The final solution was using the GNU assembler directive .incfile which had
> the advantage of being able to name the symbol as you want. By using a
> parametrized macro i managed to make it very easy to include different files
> in code:
>
> /// Include a given file as binary data
> /// @arg varname is the variable that will hold the var (const char[])
> /// @arg file is an absolute path or a relative path from the build point (not
> from the source file!!)
> /// @todo Try to make CLAM_EXTERNAL_FILE_DATA work with path relatives to the
> source that uses the macro.
> #define CLAM_EXTERNAL_FILE_DATA(varname, file) \
> asm ( \
> "  .section \".rodata\"\n" \
> "   .type " #varname ", @object\n" \
> " " #varname ":\n" \
> "   .incbin \"" file "\"\n" \
> "   .byte 0\n" \
> "   .size " #varname ", .-" #varname "\n" \
> ); \
> extern const char varname[]; \
>
> This is used like this:
> CLAM_EXTERNAL_FILE_DATA(myFile, "path/from/working/dir/file.clamnetwork")
>
> The only drawback left for the solution to be perfect is that the file name
> must be relative to the working dir of the compilation, not relative to the
> source dir as it is logic. But gas is not that logic. In any case this seems
> a minor drawback.
>
> David.

great! i should try all those things ASAP

-- 
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9