audio ports (was Re: [Clam-devel] Demo today report)

[Pau Arumi]

En/na Xavier Amatriain ha escrit:
> David, I don't understand your answer so I doubt anyone else on the list 
> will, can you rephrase it?
> In any case, using AudioIn/OutPort seems like very error prone. I did 
> not know about this, did you
> realize that this is exactly what I am using in the SamplebySample 
> processing and in my case this
> is called InDataPort ?

i bet you know about AudioPorts.
AudioInPort and AudioOutPort are in CLAM from the very beginning of 
streaming support, and they are used widely.
An AudioInPort is not just a typdef of InPort<TData> it wrapps the 
inter-processing buffer (stream) with an Audio object. This is very 
convenient since most of time-domain functions in CLAM uses Audio 
objects as parameters and not TData C arrays.


some interesting greps in CLAM/src:
* InPort<Audio> is used by 3 classes. and for a good reason, i think.
LPC_AutoCorrelation.hxx
EnvelopeModulator
EnvelopeExtractor
* InPort<TData> is not used
* AudioInPort is used a lot


> In any case, what is the solution to my/Alex's problem?
David already made the point, but to be more concrete:
- use AudioInPort and AudioOutPort
- write the algorithm in a method like this:
bool Do(const Audio& in, Audio& out)

now i'm thinking in make the "minimal processing" in the wiki use 
audioports...

> David García Garzón wrote:
>> The Ports are In/OutPort<Audio> instead AudioIn/OutPort which are in 
>> fact In/OutPort<TData>. As the template type is different they are not 
>> connectable.
>>

however note that AudioOutPort and InPort<TData> (and viceversa) 
*are* connectable. because AudioOutPort derives from OutPort<TData>

pau


>> We were thinking on using this distinction in our benefit to 
>> differentiate streamed audio which can be received with overlap and 
>> windowed buffers which have the overlap given. This way we ensure that 
>> once windowed, the buffers are kept with the proper way. I used this 
>> style on the LPC analysis.
>>
>> David.
>>
>>
>>
>> On Dimarts 05 Juny 2007, Xavier Amatriain wrote:
>>  
>>> I have unsuccessfully tried to figure out what the problem is but I
>>> can't find any reason. I am attaching the "offending" processing class.
>>> Apart from that all I did was add it to the ProcessingTree and tried to
>>> r'n'r ;)
>>>
>>> On Tue, 2007-06-05 at 15:53 +0200, Pau Arumi wrote:
>>>    
>>>> En/na Xavier Amatriain ha escrit:
>>>>      
>>>>> 2) When I added the new processing in the NetworkEditor I could not
>>>>> connect the ports! This
>>>>> is new to me, I have done this many times before and never experienced
>>>>> that behavior. Maybe
>>>>> it was a silly coding mistake but everything was pretty 
>>>>> straightforward
>>>>> (Audio ports). I will look
>>>>> into the code on Monday but maybe somebody has some idea what might
>>>>> have gone wrong.
>>>>>         
>>>> did you find the reason? send a patch if not. i'm curious about it.
>>>>       
>>
>>
>>
>>   
> 
> 
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel