[Clam-devel] Ladspa Plugins using embeded Networks

[Pau Arumí]

That's absolutely great! A big step forward to make CLAM more useful.

I'm missing a simple SConstruct, so users can compile their own plugins
on a clam independent directory. Is this planned?

I see that the NE support (metadata editor) is on the way. This will be
even more great. Couldn't we make it Qt4.3 compatible? Ubuntu Hardy
(and, I think, other major distros) doesn't ship with Qt4.4)

P


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