I'd tend to agree with what Stéphane said, but there are two gotchas with
the LLVM-based embedded Faust compiler that I see.
First, last time I checked, clang/gcc -O3 still generated faster code in
some cases than the LLVM backend alone. In the past I've noticed this with
some rather simple Faust examples such as my organ.dsp, but I realize that
many of the internals in both the Faust compiler and the Faust standard
library have changed since then, so this might not even be true any more.
Second, last time I've checked the Faust compiler's internal memory
management didn't do any garbage collection on Faust's internal data
structures such as the deBruijn term trees. Is that still true? Because if
it is, it might become a problem in a live coding environment if you do a
lot of compilations and the environment keeps running for a *really* long
time (say, like in a DAW or sequencer application that might be kept open
for hours or even days if you're working on a session), since the Faust
compiler may start eating away more and more of your copious main memory.
;-)
So there may be good reasons to go the more traditional route of just doing
the compilation in a separate process and then simply reloading the
resulting shared libraries. My own pd-faust still does it that way, and it
works great, also on macOS and Windows. However, you *have* to make sure
that you properly unload the dlls using dlclose() before reloading them
using dlopen(). At least it will do the trick with the portable libtool
equivalents, lt_dlopen() and lt_dlclose(), which is what pd-faust actually
uses.
To do this properly, you may have to do your own reference counting on the
loaded libraries, and maybe also keep track of the timestamps of the shared
library modules so that you only reload them when they actually changed.
This is all done in pd-faust (or rather in pure-faust, the Pure module
which pd-faust uses to handle compiled Faust modules in Pure). If you're
interested then you may want to look at and grab some of the code around
`void module_t::reload()` in the faust.cc module here:
https://github.com/agraef/pure-lang/blob/master/pure-faust/faust.cc
HTH,
Albert
On Fri, Dec 1, 2017 at 3:01 PM, Stéphane Letz <l...@grame.fr> wrote:
> For a « live faust coding environment. » , why dont you try the
> libfaust+LLVM based approach? This would be much cleaner/faster than a «
> compile to C++ then load ad shared library model »
>
> Look here http://faust.grame.fr/news/2016/01/12/using-dynamic-
> compiler.html
>
> Stéphane
>
>
> > Le 1 déc. 2017 à 14:52, stijn . <stijn.v.b...@gmail.com> a écrit :
> >
> > Hi all,
> >
> > this is a topic not necessarily related to Faust, but it is a problem
> that I encounter while using Faust and I am sure some of the developers of
> environments like FaustLive or the Faust Playground have come across it as
> well..
> >
> > I managed to write my own architecture file that wraps the DSP in a
> shared library. Now I have a program that presents a live faust coding
> enviroment. The faust code is compiled live to a cpp file, which is
> compiled to a DLL which is loaded by the application.
> >
> > The problem arises when the faust code is changed by the user and the
> DLL/dylib is recompiled and reloaded live. Somehow OSX caches the shared
> library and refuses to load the newly compiled version, because it assumes
> it's already loaded.
> >
> > Did anyone come across this problem and think of a solution already?
> >
> > Thanks!
> >
> > Stijn.
> >
> > --
> > Stijn van Beek
> > e-mail: stijn.v.b...@gmail.com
> > tel.: ++31-6-22316389
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> > Faudiostream-devel mailing list
> > Faudiostream-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Faudiostream-devel mailing list
> Faudiostream-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
>
--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggr...@gmail.com
WWW: https://plus.google.com/+AlbertGraef
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Faudiostream-devel mailing list
Faudiostream-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
