[PD-dev] tooltips ideas

[IOhannes m zmoelnig]

geiger wrote:
> 
> On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
>> geiger wrote:
>>> On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
>>>> one problem with the tool tips patch is, that miller accepted my patch
>>>> for up/downsampling long ago (btw, i am very thankful for this): both
>>>> use the arguments to the [inlet~], but disagree on the meaning of these
>>>> arguments.
>>> I think this is not the real problem, as up/downsampling could be
>>> specified through other means and backwards compatibility could be
>>> maintained easily.
>> seems like a bit blindfolded...
> 
> why ?

sorry: this line should really have read:
"seems like i am a bit blindfolded"
i didn't want to insult anybody, just wanted to express that probably i 
am not seeing the wood through all the trees (or however this is 
translated into english)

> 
>> the simplest way would of course be to just ignore the fact (on the
>> users side) that there is an additional word (e.g. "linear") in the
>> comment.
> 
> thats a good idea, one could then implement the different upsampling
> methods through standard pd objects that take a zero padded input
> signal.

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...

> 
>> 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...

> 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.

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)

> 
> 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 :-)


mfg.asdr.
IOhannes