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 ?
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.
e.g [inlet~ linear center frequency] would do linear resampling and have a tooltip "linear center frequency" which in fact should read only "center frequency" but might be ok as a simple workaround (requires the user to be aware of the whole thing); even better if you do [inlet~ linear - center frequency]....
I think for backwards compatibility it is enough to detect "linear" and do the right thing. I do not expect that everybody will add tooltips to the inlets everytime.
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. Or the above mentioned method of having an object for different up/downsampling methods.
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 all, so calling my arguments blindfolded is a bit, hum, short-sighted, I'd say.
Günter