[clam-devel] Sample by Sample Processing in Network Editor

[Xavier Amatriain]

Find attached a dummy network with sample by sample processing that is 
not able to execute on real-time. Compiled the
Processings into NetworkEditor, open the included network and have fun! 
If we deem it necessary I can commit things to
svn but we will have to decide where to put them.

And don't forget to select Blocking NP!

ps. You won't be able to reconfigure processings or add them from the 
menu as for that you would need to modify a couple
more files, but at this point I don't think it is needed.

Pau Arumi wrote:
> En/na Xavier Amatriain ha escrit:
>> 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.
>>
>>   
> no way back. rtaudio is about to be deprecated.
> but you can choose blocking NP in linux.
> ok now i remember: you need to develop in windows, then let's maintain
> the rtdependency as a delta till we implement AudioOut in PortAudio
> (blocking mode). this task should be really straightforward.
>
> don't you have more important changes beside that?
>
>> 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?
>>   
> the other issue is blocking-NP in windows i guess.
> for me is ok both options:
> - maintain the delta in NetworkEditor/main
> - add defines and get rid of delta
> it's not really important since we can test it (blocking NP) in linux.
>
>>> 1. redrawing methods depend on timers (since NetEdit4) and it's not 
>>> done 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
>> issue).
>>
>>   
> david asks: and how many times NetworkCanvas::draw gets called?
>>> 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 
>>> (or should) only in debug and they are expensive.  apart from 
>>> checkings what operations of produce() and consume() are expensive? 
>>> have you done any profiling?
>>>     
>>
>> 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:
>>
>> WritingRegion::Produce
>>
>> (and inside of it the SreamImpl::RegionHasAdvanced and
>> PhantomBuffer::Touch)
>>   
>
> interesting.
>
> how about PhantomBuffer::UpdateBeginning and UpdatePhantom? they should
> be zero.
>
> StreamImpl::RegionHasAdvanced should do all things inline. can you see
> more about this?
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: forCLAMDevel.zip
Type: application/octet-stream
Size: 7712 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20061221/448b9092/attachment-0005.obj>