[Clam-devel] Ladspa Plugins using embeded Networks

[Natanael Olaiz]

LadspaMetadataEditor.ui uses QFormLayout, which is since Qt 4.4.

I updated my Qt and the compilation works... but it seems to have some 
library issue (I was afraid to remove my old distro Qt, so it was there 
too...), and when I try to execute it crashed.
Anyway, for users using the default Qt package on Ubuntu Hardy that 
would not compile, similar to the previous scons issue... We want that?

Regards,
Natanael.

El 07/29/2008 04:41 PM, David García Garzón escribió:
> 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.
>
> 													
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>