[Clam-devel] Patch: embedded diagrams widgets for faust plugins

Natanael Olaiz nolaiz at gmail.com
Sun Jun 22 12:18:52 PDT 2008


El 06/22/2008 08:33 AM, Pau Arumí escribió:
> On dg, 2008-06-22 at 06:57 -0300, Natanael Olaiz wrote:
>   
>> Pau: this is just a simple embedding diagram inclusion using your code, 
>> and an alternative method using QLabel instead QSvgWidget.
>> What do you think?
>>     
>
> I'm very happy that you have taken the Faust integration task! 
> It looks really nice and useful.
>
> A couple of questions: 
> Shat is the trade-off between QLabel and QSvgWidget? (I have no idea
> what QLabel does)
>   
I first tested with QLabel, without including the QSvgWidget header on 
RunTimeFaust. QLabel can print text or image, so I load a QPixMap to 
show it. But the major problem is that the Pixmap keeps a fixed size....
Then I tried QSvgWidget, which doesn't have that problem. I just keep 
the QLabel method in case you want to discuss the QSvgWidget header 
inclusion.
But I think that QSvgWidget is clearer and better...

> Do processing boxes get the "right" size automatically? (I remember this
> was a problem in my first experiment)
>   

The processing boxes gets the right proportion, but not size (too 
little). I will make it to load it bigger...
Maybe make them fixed-proportion resize could be useful too.. but I'm 
not sure (some diagrams are too large in one axis but not the other...)


>> BTW, using "~"instead of "home" doesn't work in my machine (that's 
>> because the commented entire path).
>>     
>
> "~" was a quick hack. Yes kick it out.
>   

OK, anyways I'll use the environment/default paths..

>> Two questions:
>>     1 - how to manage the shell for recompile faust modules on Windows? 
>> (there is a && equivalent, or it needs to execute one command after the 
>> other?)
>>     
>
> I wouldn't mind making fast compilation crossplatform at this point.
> As you say in the other mail, neither LADSPA is available in CLAM for
> windows.
> BUT: This (cross-platform LADSPAS, and LV2) is something that we should
> have. There is no big technical problems that prevents doing this. And
> those plugins fills a lot of "holes" in CLAM repositories.
>   
OK, let's discuss it later.

>>     2 - what would be the default paths for faust plugins and sources? 
>> what about let's move the "~/src/faust/..." to (if exists) 
>> $FAUST_PATH+"/..." or homePath()+"/..." ?
>>     
>
> Yes. Actually, this should be done like LADSPA paths. Research that
> code, if it is not in your cache (and reuse if possible)
>
>   
OK.

> Some improvements to the patch:
>
> * Try being  more explicit in vars names in RunTimeFaustLibraryLoader
> (avoid reusing "name")
> * Metadata attribute "diagram"->"svg_diagram" or "diagram_file"
> * In ProcessingBoxEmbeddedWidget +123 I would collapse the two ifs in a
> single one.
>   
I can test if exists "category" and "svg_diagram" at once.... but I 
think is clearer to get the category attribute and compare to "FAUST" later.

BTW: we need to check if it's a FAUST plugin? What about making that 
embedded widget for every object that have "svg_diagram" attribute?

> * We should check if the svg file exists, and if not, we could embed the
> faust logo (to be gathered)
>
> It is ok to check it in. As usual, test, commit and refactor and test.
>
> BTW, do you know if latest Qt versions allow svg navigation?
>   

I don't know.... I will check on the docs...


Regards,
Natanael.

> That's all for now. Keep up the great work!
>
> Pau
>
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>   





More information about the clam-devel mailing list