[Clam-devel] Demo today report

[David García Garzón]

Still an errata and In/Out mess, so rerephrased ;-) :

To shorten X = In/Out

Ports can be conected if they share the template type.

Most Audio related processings in CLAM use AudioXPorts, not XPort<Audio>.

An AudioXPort is a special class of port that derives not from 
XPort<Audio> but from XPort<TData> and gives an Audio interface maping to the 
TData stream. (Audio & GetAudio besides TData & GetData)

Your processing is using XPort<Audio> so you can't connect it to an 
AudioXPort.

Summary: That's the problem you have. You should use AudioXPort. Did you 
understand until here?


Now, you may ask, having two options for Audio is quite inconvenient, is that 
distinction needed?

My answer: Yes but we are not using them properly.

We are using AudioXPort everywhere. This is bad because AudioXPort put samples 
aside in a single stream and a reading processing can rechunk them using any 
window and hop size. Once you have windowed them with overlap, rewindow them 
differently just messes the audio. So after any windowing, audio's should be 
the tokens, not TData. And it should be TData until OverlapAndAdd 
reconstructs the stream again.



On Wednesday 06 June 2007 08:57:50 David García Garzón wrote:
> 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.