[PD-dev] tooltips ideas

[geiger]

On Wed, 28 Jun 2006, IOhannes m zmoelnig wrote:
> > why ?
>
> sorry: this line should really have read:

ok, understood ... often I am just too paranoid. Sorry.

> i see. this sounds like a good idea to me (generally).
> probably not too many patches use up/downsampling anyhow.
> the question is, whether the zero-padded upsampling is the best choice...

I thought its the most general one, a resample object can use it
to do sample+hold, linear interpolation or any other type of filtering.
You could also just use a bunch of lop~'s, or you do a fft and cut off
the unwanted bins.
One good thing about it is that you can implement other more sophisticated
schemes without having to touch Pd's core code and sometimes even without
having to write in C/C++.

> >
> >> however, what exactly do you mean with "through other means"?
> >
> > One possiblity would be to supply the upsampling information together
> > with the upsampling factor, in the block object.
>
> i don't like that, since it does not allow you to have differently
> upsampled signals within one subpatch...

Yes, its less flexible.

> > Or the above mentioned method of having an object for different
> > up/downsampling methods.
>
> ...but otoh, both methods could coexist.
>
> the reason why i did not implement it like this was, that i wanted the
> parent patch not to have any knowledge about the samplerate of the child.
> the problem is rather with downsampling than with upsampling, since we
> have to decide beforehand, which samples are to be kept and which not.

If I remember correctly, you can do downsampling by lowpass filtering
inside the child, and let the picking of samples up to the inlet.
This should give you a perfectly downsampled signal (because you removed
the frequencies above the parents nyquist frequency). The only thing that
you need to know is the resampling factor in the child patch.

For resampling there is a very good webpage by J.O.Smith,
http://www-ccrma.stanford.edu/~jos/resample/resample.html

>
> i admit that it could have been done better (right now, if you really
> want "cleanly" resampled signals, you need to do filtering of the signal
> outside of the child anyhow)

Really ? Isn't that too late, as you already have the aliasing in the
signal ?

>
> >
> > I just wanted to state that there are solutions to the problem. Which one
> > gets chosen or if your proposal of #G objects get implemented can be
> > decided after considering advantages and disadvantages. The original
> > tooltips patch didn't interfere with the functionality of upsampling at
>
> right. i only wanted to ask kindly as which solutions you were thinking
> of. (and i got an answer already)
>
> > all, so calling my arguments blindfolded is a bit, hum, short-sighted, I'd
> > say.
>
> i'd even say, it is...blindfolded :-)

well for a misunderstanding it always takes two, I really have to
learn to read between the lines in a positive way.
Anyhow, apologies for the harsh words.

Günter


>
> mfg.asdr.
> IOhannes
>
>