[Clam-devel] Sample by Sample Processing in Network Editor
xavier at create.ucsb.edu
Thu Dec 21 10:36:51 PST 2006
On Thu, 2006-12-21 at 19:33 +0100, Pau Arumi wrote:
> my first thought is that we really need to integrate this
> development/experiments into subversion.
> why not to have simple proof-of-concept networks and do all
> infrastructure changes in svn.
> the benefits are clear:
> - you provide use cases for pushing development and research
> - we can help much more in your use cases
This would be great. I think that CLAM does need to offer at least a
minimal infrastructure for sample-by-sample processing. There are a few
minor problems though. First, most of the processings I am using are
so specific to this app that it would make no sense to add them to
the repository. So I will have to create
a dummy network with some general-purpose processings (no biggie). Also
this requires modifying the default Network policy to Blocking and using
RtAudio instead of PortAudio so this is something I am not sure you want
to go back to.
If you think it would be interesting as I said adding a couple of
processings and the network is simple but what about the other issue?
Add a few defines here and there?
> 1. redrawing methods depend on timers (since NetEdit4) and it's not
> on Do basis. what are the synthoms?
I am profiling with Rational Quantify on Windows and I see the Graphics
thread consuming more time than the processing one. Functions like
PortWire::draw were called on the order of 2x times the Do was called
(12000 vs. 5000 for instance). I am saying "were" because in the latest
profile runs that I have just done I am not seeing this behavior (weird,
I will report on this later but I am thinking that this might not the
> 2. i think it could be more efficient if we get rid of
> different-port-size matching. but more in a policy way than a TData
> specialiation. but lets analyse first the situation.
> are you compiling in release? all regions related checkings are done
> should) only in debug and they are expensive. apart from checkings
> operations of produce() and consume() are expensive? have you done
Hey, who do you think you are talking to? I am the master of
profiling ;) So, yes, I am running with full optimizations active and
the problem is not in the debug checkings. Just so you have an idea,
here is one of the most expensive operations:
(and inside of it the SreamImpl::RegionHasAdvanced and
* Xavier Amatriain *
* Associate Director - MATi *
* Research Director - CREATE *
* UCSB, Santa Barbara CA *
* 1-(805)- 893 83 52 *
More information about the clam-devel