[Clam-devel] SMSSynthesis

[Pau Arumi]

Answering both Greg and Xavier:

En/na Greg Kellum ha escrit:
> My reasons for thinking so are: 
> One, I think one should program with the users in mind that don't know 
> very much about how the application works, and such users won't know to 
> look into the configuration dialog to disable two unused ports.  And 
> these two ports can make a significant difference in an application's 
> performance.  My own application runs 10% with those two unneeded IFFTs 
> disabled.

I think we can safely require clam users (or NE users to be
precise) to know how to use ports, controls and configurations.
I mean, when a user want to use an algorithm he/she have to be
aware of its configuration parameters.

> Two, we have to keep in mind that CLAM is first and foremost a C++ 
> library for audio and music, and it's unlikely that a programmer looking 
> at the API for SMSSynthesis would know to navigate through 
> SMSSynthesis's nested configuration elements to set the right flags to 
> disable those two out ports. 

The same goes for the C++ developer/user. The processing's config
is something the developer must have in mind. However, I think
nested configurations are evil (at least in cases where root
parameters have to be synchronized with embedded parameters). In
this case, the "Disable Residual IFFT" should clearly be a root 
parameter. Why shouldn't it?

Summing up I'm slightly more inclined towards the
configurable-ports solution because I'm more concerned about
consistency than ease of use. Given a processing, a user should
know whether it's possible to disable part of it and, if so, how to
do it. In other words, to be consistent, the
optimize-unconnected-ports should be in every processing with
multiple out-ports. Though it was easy to do for SMSSynthesis it's 
overkill for a general solution.
In a way, it reminds me the current spectrum refactoring: by doing
spectrum conversions explicit, processings are now much simpler,
and the user is aware of what non-functional issues are going on.

Now we'd like to hear David's opinion :)

pau