[Clam-devel] Re: faust status

[Natanael Olaiz]

El 07/09/2008 04:33 PM, Pau Arumí Albó escribió:
> El dc 09 de 07 de 2008 a les 15:46 -0300, en/na Natanael Olaiz va
> escriure:
>   
>> El 07/09/2008 10:14 AM, David García Garzón escribió: 
>>     
>>> Wow. Dump such many screenshots to the Development screenshots wiki.
>>>   
>>>       
>> Added some, except the warning messages (maybe an animated gif could
>> be better for that). BTW, if we use just one script to compile the
>> faust files we could use QProcess.startDetached
>> (http://doc.trolltech.com/4.3/qprocess.html#startDetached) instead
>> QProcess.start (http://doc.trolltech.com/4.3/qprocess.html#start) and
>> manage it as background process, so the NE will not be 'frozen' when
>> compiling.
>>     
>
>
> Just checked that on-the-fly faust coding is working. Awesome!!
>
> Yes, a detached process will be nice. And yes, a make or scons script
> will be useful to avoid unneeded recompilations. 
>   
Here is the answer to my previous mail question. :)
The use of the script could also keep out some code of 
RunTimeFaustLibraryLoading...

> If I understand correctly we are not using the faust provided make to
> generate ladspas (.so) and diagrams (.svg) because it needs the faust
> binary in the PATH.
>   
Yes, the faust binary and ladspa.cpp (plus, you don't have a way to 
define the path for this last, that's because I run the compilation from 
that directory).

> Well, I think that requiring faust to be installed would be ok.
> Instructing a user to download faust or download and install faust
> doesn't make a big difference. Plus, we want to support the use case of
> faust installed from a package and user's .dsp in a local dir (in
> FAUST_PATH or FAUST_PATH/examples/).
>
> What do you think?
>
> Some small issues:
>
> - Dropped-to-canvas faust processings have tiny diagrams here. Would be
> feasible to scale them up?
>   
We need to define how to manage that. Using fixed sizes cause problems 
resizing the canvas, if not, is resized by the connectors/name (i.e. 
some changes are required there)... And some diagrams are really big to 
use its original size.
Opinions?

> - When clicking "Reload Faust modules" the warning window states "More
> related features like svg embedding, bla bla will come soon.". This is
> fortunately outdated. 
>   
I agree. I just kept it on this 'experimental' stage...

> - Proposed feature: when clicking this action, checks if the faust
> binary is available, if not a window promopts to install the tarball,
> with the url (not sure about instructing to install a package, because
> of the writable .dsp examples issue)
>   
Well, installing it on a user local directory would be good. If not, we 
could copy the examples main dir to a user one (to have write permissions).

> - Hey, your screenshots have Sinks and Sources with svg diagrams. But
> mines no. I want them! :-)
>   
Just in some of the tests, and looks nice. :)
It's just a matter to define the svg_diagram attribute on sink/sources 
using the same .svg of the icon. I didn't commit that because I don't 
know if that could slow down the Qt interface... (using embeded svg 
widgets -QSvgWidget- for several processings)
What do you think?

> P
>
>
>
>   
>> And thanks for improving the ugly format of the article and
>> screenshots!
>>
>>     
>>> On Dimecres 09 Juliol 2008, Natanael Olaiz wrote:
>>>   
>>>       
>>>> A simple overview of the actual Faust support:
>>>> http://iua-share.upf.edu/wikis/clam/index.php/Devel/Faust_support
>>>>
>>>> I think so many of those how-to steps could be managed by a faust
>>>> install/configuration script. What do you think?
>>>>
>>>> El 07/08/2008 09:50 PM, Natanael Olaiz escribió:
>>>>     
>>>>         
>>>>> Commited in two steps, and changed some names on MainWindow and
>>>>> NetworkCanvas. Now those names are a little bit large, but I think now
>>>>> them refers better to its uses.
>>>>>
>>>>> Commit 11582:
>>>>> * RunTimeLibraryLoader: Load() changed to virtual, added some
>>>>> commented debug messages, and minor changes on CompletePathFor()
>>>>> * RunTimeFaustLibraryLoader:
>>>>>    - implemented virtual Load() to search first for the examples faust
>>>>> dir
>>>>>    - added std::map GetCompilePluginCommands(std::string
>>>>> pluginSourceFullName) to get required faust compilation commands with
>>>>> the propers paths
>>>>>    - if plugin exists in factory, use ReplaceCreator instead
>>>>> AddCreatorWarningRepetitions
>>>>>    - added helpers: faustBinCommand() and faustLibIncludeFile()
>>>>>
>>>>> Commit 11583:
>>>>>
>>>>> * ClamNetworkCanvas:
>>>>>    - added signal: openFileWithExternalApplicationRequest
>>>>>    - added QString _fileNameToOpen (used when catching the previous
>>>>> signal on MainWindow), onOpenFileWithExternalApplication to set it and
>>>>> getFileNameToOpenWithExternalApplication() to get it
>>>>>    - added slot onOpenFileWithExternalApplication
>>>>>    - added "Open diagram with browser" item on processings context
>>>>> menu which have svg_diagram attribute
>>>>>    - added "Open source with editor" item on processings context menu
>>>>> which have dsp_source attribute
>>>>> * NewtorkEditor MainWindow:
>>>>>    - added slot on_action_Launch_Browser_triggered
>>>>>    - on_action_Online_tutorial_triggered() calls
>>>>> on_action_Launch_Browser_triggered
>>>>>    - added slot
>>>>> on_action_Processing_Open_File_With_External_Application_triggered,
>>>>> connected to ClamNetworkCanvas::openFileWithExternalApplicationRequest
>>>>> signal
>>>>>    - added messages on slot on_action_Compile_Faust_triggered, and
>>>>> changed to search the .dsp files on faust examples directory and
>>>>> compile them one by one directly (doesn't need to have Faust installed
>>>>> or makefiles)
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> Clam-devel mailing list
>>>> Clam-devel at llistes.projectes.lafarga.org
>>>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>>>>     
>>>>         
>>>
>>>   
>>>       
>
>
>