[Clam-devel] Re: faust status

[Natanael Olaiz]

El 07/08/2008 02:38 PM, Pau Arumí escribió:
> I've looked at the patch. Go ahead and commit. And maybe I'll propose
> some refactoring afterward. Great work!
>   
OK.

> On dl, 2008-07-07 at 19:25 -0300, Natanael Olaiz wrote:
>   
>> El 07/07/2008 02:12 PM, Pau Arumí Albó escribió: 
>>     
>>> Hi Natanael,
>>> could you please remind me the status of your Faust work? 
>>>       
>> Here is the last path about that I made. 
>> It doesn't need to have Faust installed, just to have the .dsp source
>> files on '$FAUST_PATH/examples' (or ~/.faust/examples), the 'faust'
>> compiler on  '$FAUST_PATH/compiler' (or ~/.faust/compiler) and the
>> 'ladspa.cpp' on '$FAUST_PATH/architecture' (or ~/.faust/architecture).
>> It allows to recompile all found .dsp from the NE main menu as your
>> original code, but without using 'make' (to avoid needing faust
>> installed). Also it allows to browse the .svg and edit the ,dsp code
>> from the processing context menu (and for now there is a dummy
>> "recompile" option too):
>>     
>
> I'm not sure whether t we want NE to know how to compile faust scripts
> (maybe yes, but want to think more about it). If faust Makefile would
> provide an option to use the local faust binary it would be easier,
> right? We could propose a Makefile patch to faust devels.
>   

The major problem is that Faust doesn't support by now (at least I 
didn't found) defining the libraries path when you call it, just search 
by default at /usr and the active path (that's because I change to the 
'architecture' path when calling the compiler)

Another option could be making an external script which do the actual 
compilation tasks (i.e. doing also the searches for the compiler and 
libraries)..

>> I think there is a pending patch and some questions, right? 
>>     
>>>   
>>>       
>> Yes:
>>       * What do you think about the factory changes? I created
>>         CLAM::Factory::ReplaceCreator (and Registry/FactoryRegistrator
>>         related methods) to use instead of AddCreatorWarning in case
>>         that plugin already exists on reloading. It erase the original
>>         creator and create a new one. Is that good? I didn't found any
>>         other way to erase just a single creator for the dynamic
>>         plugin's loading...
>>       * I created
>>         'RunTimeFaustLibraryLoader::GetCompilePluginCommands' which
>>         uses the previously created
>>         'RunTimeLibraryLoader::CompletePathFor' to return the
>>         compilation commands. I putted there because I though is more
>>         related to the specific Faust library loader, but I'm using it
>>         from MainWindow as a kind of static method. Anyway, I can't
>>         define as static because CompletePathFor uses
>>         'RunTimeLibraryLoader::GetPaths' which is not static (also I'm
>>         using CompletePathFor from MainWindow to search for the .dsp
>>         directory). What do you think about that? Put the methods on
>>         MainWindow instead? Duplicate the GetPaths code and make them
>>         static? Make another code file to manage the faust compilation
>>         and related tasks?
>>       * I don't like the method that I used to deal with calls to
>>         MainWindow from the canvas (the NetworkCanvas emit signals
>>         catched from MainWindow, which calls back to
>>         NetworkCanvas::getFileNameToBrowse). Plus, I'm getting some
>>         messages when I run the NE:
>>                 QMetaObject::connectSlotsByName: No matching signal
>>                 for
>>                 on_action_Reload_Faust_Plugins_triggered(RunTimeFaustLibraryLoader&)
>>                 QMetaObject::connectSlotsByName: No matching signal
>>                 for on_action_Processing_Launch_Editor_triggered()
>>                 QMetaObject::connectSlotsByName: No matching signal
>>                 for on_action_Launch_Editor_triggered(QString&)
>>                 QMetaObject::connectSlotsByName: No matching signal
>>                 for on_action_Processing_Launch_Browser_triggered()
>>                 QMetaObject::connectSlotsByName: No matching signal
>>                 for on_action_Launch_Browser_triggered(QString&)
>>         How do you suggest to manage that? I think using the context
>>         menues on the canvas is the comfortablest way to put those
>>         commands, but the needed code has not much to do in NE...
>> Well... for now I think these are my main doubts. :)
>>     
>
> I'll look at these issues later (anyway they are not important enough to
> keep you back from commiting)
>
>   
OK, now I'll commit it. Thanks!


> P
>
>
>
>
>