[Clam-devel] Ladspa Plugins using embeded Networks

[David García Garzón]

A new chapter on the wiki that explains how to build Ladspa with the new 
infrastructure (still not from the NetworkEditor but extremely close!!)

David.



El Wednesday 30 July 2008 21:31:35 Hernán Ordiales va escriure:
> 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/Cla
> >mLadspaPluginExample/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