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