Am Sat, 25 May 2013 08:59:58 +0200 schrieb Stéphane Letz <l...@grame.fr>:
[...]
> > Some obvious alternatives to the CFFI would be:
> >
> > - Cython, which is, to my understanding, not dynamic enough for what I
> > wanted,
> > but which can be used to wrap C++ code, so would have the advantage of not
> > requiring FAUST2.
> >
> > - the FAUST2 LLVM backend + Unladen Swallow, which ties you to CPython,
> > whereas
> > the CFFI works (or at least will work) with various Python implementations.
> >
> > - Ctypes, which is dynamic, like the CFFI, but supposedly not as nice to use
> > and slower.
[...]
>
> Have you ever thought about using the *dynamic* Faust technology in this
> application? That is libfaust + LLVM?
>
> Stéphane
Hmmm, no, I hadn't, because 1.) I hadn't really heard of libfaust before outside
of the Makefile and stupidly assumed it was an internal library (perhaps a more
prominent mention should be made somewhere in the docs?), and 2.) I sort of
took my first idea for an implementation and ran with it, just to get something
working quickly.
Now that you mentioned it, I have looked into it more and it looks like it won't
change much, other than that I don't have to spawn a faust process anymore, i.e.
dsp code -> faust2 -> C code -> CFFI -> Python object
becomes
dsp code -> libfaust -> C code -> CFFI -> Python object
However, you also mentioned LLVM: do I understand correctly that you mean using
the LLVM backend as (I think) it is used in Pure? That is, generate LLVM
bitcode and link that to Unladen Swallow/CPython (however that exactly
happens)? I dismissed it since that ties you to CPython 3.3+, as I mentioned
in my original email. Plus I like having a pure python solution :) .
Anyway, after lots of fiddling with compiler/Makefile.unix [0] and learning
about the "-rpath" linker option I eventually got libfaust.so and my test
program compile without messing with my system's LDPATH and have now tried it
out in a local branch following the scheme above.
While I think that I prefer using libfaust to spawning a faust process (it
feels more elegant, and the FAUST class and the instantiation overhead shrunk a
bit), I noticed one important (strange) difference between the two: the order
of meta-data declarations (i.e., the line order in the header and the order of
->declare() calls) changes between calls to compile_faust(). This renders the
cffi's caching mechanism useless and leads to re-compiling on every
instantiation. Simple inline code strings still cache fine, as long as they
don't contain more than one meta-data declaration. Here's an example:
$ diff -U4 test{1,2}.txt
--- test1.txt 2013-05-25 20:02:38.152409591 +0200
+++ test2.txt 2013-05-25 20:02:34.688500257 +0200
@@ -34,12 +34,12 @@
void* uiInterface;
} UIGlue;
//-----------------------------------------------------
-// version: "0.1"
// name: "Dattoro notch filter and resonator (Regalia)"
// license: "MIT"
// copyright: "(c)Marc Joliet 2013"
+// version: "0.1"
// author: "Marc Joliet"
//
// Code generated with Faust 2.0.a9 (http://faust.grame.fr)
//-----------------------------------------------------
@@ -84,14 +84,13 @@
free(dsp);
}
void metadatamydsp(MetaGlue* m) {
- m->declare(m->mInterface, "version", "0.1");
m->declare(m->mInterface, "name", "Dattoro notch filter and resonator
(Regalia)");
- m->declare(m->mInterface, "filter.lib/name", "Faust Filter
Library");
- m->declare(m->mInterface, "filter.lib/license", "STK-4.3");
- m->declare(m->mInterface, "filter.lib/reference",
"https://ccrma.stanford.edu/~jos/filters/";); m->declare(m->mInterface,
"license", "MIT");
+ m->declare(m->mInterface, "copyright", "(c)Marc Joliet 2013");
+ m->declare(m->mInterface, "version", "0.1");
+ m->declare(m->mInterface, "filter.lib/reference",
"https://ccrma.stanford.edu/~jos/filters/";); m->declare(m->mInterface,
"math.lib/name", "Math Library"); m->declare(m->mInterface,
"math.lib/author", "GRAME"); m->declare(m->mInterface,
"math.lib/copyright", "GRAME"); m->declare(m->mInterface,
"math.lib/version", "1.0"); @@ -100,13 +99,14 @@
m->declare(m->mInterface, "music.lib/author", "GRAME");
m->declare(m->mInterface, "music.lib/copyright", "GRAME");
m->declare(m->mInterface, "music.lib/version", "1.0");
m->declare(m->mInterface, "music.lib/license", "LGPL with exception");
- m->declare(m->mInterface, "copyright", "(c)Marc Joliet 2013");
- m->declare(m->mInterface, "filter.lib/author", "Julius O. Smith
(jos at ccrma.stanford.edu)");
- m->declare(m->mInterface, "filter.lib/copyright", "Julius O. Smith
III"); m->declare(m->mInterface, "filter.lib/version", "1.29");
+ m->declare(m->mInterface, "filter.lib/license", "STK-4.3");
m->declare(m->mInterface, "author", "Marc Joliet");
+ m->declare(m->mInterface, "filter.lib/name", "Faust Filter
Library");
+ m->declare(m->mInterface, "filter.lib/author", "Julius O. Smith
(jos at ccrma.stanford.edu)");
+ m->declare(m->mInterface, "filter.lib/copyright", "Julius O. Smith
III"); }
int getSampleRatemydsp(mydsp* dsp) { return dsp->fSamplingFreq; }
I don't understand why that happens when using libfaust but not faust, since
faust merely calls compile_faust_internal() :-/ .
[0] Gentoo's libtool is quite a bit newer than the one on Mac OS X and has
changed quite a bit, the libtool-1.3.5 package (the version I think OS X has)
only installs libltdl, and it appears the libtool developers *really*, *really*
want you to use automake, so I gave up and basically had the Makefile call "g++
-shared" instead.
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
