Would it be possible to generate a class that contains all tables (and
their initialisers) and pass a reference to the instance::init() method?

Then it is up to the container to manage the lifecycle and allocation of
shared data.


Martin


On 08/06/17 12:14, Stéphane Letz wrote:
> The reason is that we want to share a unique table between all instances of 
> the class. But… it appears that:
>
> - even if the table is shared, the classInit code is actually called each 
> time in the instance::init(SR) method, which is rather stupid…((-; and 
> possibly problematic.
>
> - and the memory allocation strategy of this table is also not the same 
> across all backend (in faust2 branch). C/C++/LLVM backend use a shared table, 
> asm.js, WebAssembly, Interpreter backend allocate and fill the table in each 
> instance (the was simply done to ease the development of the backend…)
>
> - so we’ll have to rework this table memory allocation scheme in all backend 
> to be perfectly clean. Added on the « TODO »  list.
>
> Stéphane
>
>
>> Le 8 juin 2017 à 12:31, Martin Klang <m...@pingdynasty.com> a écrit :
>>
>> I've got another question regarding tables, hopefully not as silly as
>> the last one ->
>>
>> When creating a table in Faust it produces C++ code with a static global
>> variable to hold the data.
>>
>> `static float ftbl0mydspSIG0[65537];`
>>
>> (from example `generator/osci.dsp`, using Faust 2.0.a73, owl.cpp
>> architecture)
>>
>> Is there any way to instruct Faust to create this on the heap instead?
>>
>>
>> If I edit the generated code to make the table a non-static member
>> variable of the generated class, and change `classInit()` to not be
>> static, then I can create the class instance on the heap and it all
>> works beautifully.
>>
>> I imagine there's a reason why classInit() and the generated tables are
>> static.
>>
>>
>> Martin
>>
>>
>> On 06/06/17 15:58, Stéphane Letz wrote:
>>>> Le 6 juin 2017 à 16:50, Martin Klang <m...@pingdynasty.com> a écrit :
>>>>
>>>> Hello list, this is my first post - Martin in London here!
>>>>
>>>> I develop the OWL Pedal / Modular, an embedded platform which runs FAUST.
>>>> We're trying to get up to speed with the latest version, but have hit a
>>>> couple of snags.
>>>>
>>>> Somewhere between v0.9.85 and 0.9.90 it seems that optimised versions of
>>>> math functions have been introduced that are based on lookup tables.
>>>> E.g. sin/sinf().
>>> We are not generating any optimized version of math functions based on 
>>> lookup tables....
>>>
>>>> With the OWL, our trig is already optimised, so the generated tables are
>>>> actually populated from our implementation. And the FAUST tables are way
>>>> too big for us: 65k of floats is 4x our total memory footprint for patches!
>>>>
>>>> This applies to both the master and faust2 branches. They generate
>>>> different code, but with the same size tables.
>>>>
>>>> Is there a way to turn this off and use the system math functions instead?
>>>>
>>>> thanks!
>>>>
>>>>
>>>> Martin
>>>>
>>> Please send me example of .dsp files (and possibly the generated C++ code 
>>> also) that are showing the issue. 
>>>
>>> Thanks
>>>
>>> Stéphane 
>>>


------------------------------------------------------------------------------
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

Reply via email to