[Clam-devel] Demo today report

David García Garzón dgarcia at iua.upf.edu
Tue Jun 5 23:57:50 PDT 2007


Rephrased:

Ports can be conected if they share the template type.

An Audio{In/Out}Port is a special class of port that derives not from 
{In/Out}Port<Audio> but from {In//Out}Port<TData>.

So, {In/Out}Port<Audio> and Audio{In/Out}Port do not share template type and 
they cannot be connected.

Most processings in CLAM use AudioInPorts, not InPort<TData>.

Your processing is using {In/Out}Port<Audio> so you can't connect it to an 
Audio{In/Out}Port.

Until here what you need to know to solve the problem.

Now, you may ask, this is quite inconvenient, is that distinction needed?

I say, yes, but we are using that distinction wrongly. Ie. We are using 
XAudioPort every where.

Which should be the distinction?

AudioXPorts are good when data is continuous, while XPort<Audio> is good once 
we have Windowed it (when Audios are tokens which may contain overlapping 
samples among them)

Why? because once you have windowed the audio you can't take audio in a 
different shape (overlap+hopsize) without breaking the algorithms and tha'ts 
something we allow now and forces us to configure every audio output with 
same overlap and size.

I don't know if you understand the later part but i am in a hurry, now. I'll 
rephrase it later if needed. The important thing is that you understand why 
they cannot be connected with your current code: XPort<Audio> and AudioXPort 
do not share the template type.


On Dimecres 06 Juny 2007, Xavier Amatriain wrote:
> 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 ?
>
> In any case, what is the solution to my/Alex's problem?
>
> 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.
> >
> > 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.



-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20070606/3f75c05e/attachment.sig>


More information about the clam-devel mailing list