benniy

dear all – a riddle i'm lacking to verbalize, yet i'd be gracious for any help with:

i'm trying to distribute arbitrary values of a fixed range (for instance a counter from 0-1000) on a temporal axis.

when my "temporal function" is linear, the incrementation of these values is linear, too (so, each increment takes 1ms). yet, i would like to be able to modify the temporal funktion, retaining the relation between overall increment of 1000 and duration of 1000ms.

how on earth can i do that? any hint in any direction would be fantastic.

*somehow kind of like this, but much more complex:

very-complex-rescaling-remapping

i think you need to preserve the average gradient of the line to be always the same value-- in other words, your non-linear straight-line segments, the gradients-per-unit-time must add up to the same value as the single constant-time-passing line.

so if your reference gradient is (counts/milliseconds)= 1000/1000 = 1, then the same average gradient must be preserved over the different line segments in the non-linear mapping

i think this is a calculus-like problem:
i think you need to preserve the average gradient of the line to be always the same value-- in other words, your non-linear straight-line segments, the gradients-per-unit-time  must add up to the same value as the single constant-time-passing line.
so if your reference gradient is (counts/milliseconds)= 1000/1000 = 1, then the same average gradient must be preserved over the different line segments in the non-linear mapping


thanks so much. this sounds very plausible - wow! ... do you have any hint as for how to achieve this? something tells me i will potentially need recursive code (having so little clue about this stuff :|)

actually had another think about it-- to be more precise it's the average *weighted* gradient, ie the gradient of a segment multiplied by the time it lasts for-- add these values up (one for each segment): this is the value that need to be preserved

I'm not sure what you want to actually do though-- I have a feeling it could be quite straightforward-- ie the line object ostensibly does these calculations for you anyway...

", the last section of which is devoted to 'timepoint stretching' with nonlinear transfer functions.

Here's an article on "Techniques for Polytemporal Composition", the last section of which is devoted to 'timepoint stretching' with nonlinear transfer functions.


if I got your problem right, here's how I would solve it:

... but feel free to tell me if I missed the point!

Hi,
if I got your problem right, here's how I would solve it:

@chris – as mentioned in the facebook thread: excellent work! thanks a ton!

@floating points – you're explanation makes the underlying concept quite more clear to me... chris dropped the bomb i think, but i'll see if his article is applicable for my purpose and might get back to your approach.

@andrea – thank, too.. yet, maybe i haven't made my goal clear enough. chris' article states it very well:

"The principle that underlies tempo rubato is that the tempo of the different voices of a composition might flex subtly, with the performer(s) nevertheless remaining aware of the other voices so that an important global tempo is maintained. If one voice "steals time" by speeding up or slowing down relative to another voice, either the other voices must do likewise to stay synchronized, or that stolen time must be "given back" by flexing the tempo commensurately in the opposite direction. The assumption of synchrony is that all tempi are constantly in a 1:1 relationship, but if that ratio changes slightly for a time, it must be changed in an opposite manner for a comparable amount of clock time in order for the two tempi to resynchronize."

hello folks,
@chris – as mentioned in the facebook thread: excellent work! thanks a ton!

@andrea – thank, too.. yet, maybe i haven't made my goal clear enough. chris' article states it very well: 

"The principle that underlies tempo rubato is that the tempo of the different voices of a composition might flex subtly, with the performer(s) nevertheless remaining aware of the other voices so that an important global tempo is maintained. If one voice "steals time" by speeding up or slowing down relative to another voice, either the other voices must do likewise to stay synchronized, or that stolen time must be "given back" by flexing the tempo commensurately in the opposite direction. The assumption of synchrony is that all tempi are constantly in a 1:1 relationship, but if that ratio changes slightly for a time, it must be changed in an opposite manner for a comparable amount of clock time in order for the two tempi to resynchronize."


... Hi Benny — for some reason, I can't read the reply that you apparently posted (it appears in the Forums index page). Would you mind posting it again?

... Hi Benny — for some reason, I can't read the reply that you apparently posted (it appears in the Forums index page). Would you mind posting it again?
Thanks,
aa


hei andrea... yeah, the forums are a little messy, i think :)

summing it up: chris' article is insanely on point (and i think floating points clever insight helps me alot, too...). thanks to all you guys including yourself, andrea.

@andrea: i may have not made my approach completely clear. chris states is very well in his article:

"Timepoint stretching. The principle that underlies tempo rubato is that the tempo of the different voices of a composition might flex subtly, with the performer(s) nevertheless remaining aware of the other voices so that an important global tempo is maintained. If one voice "steals time" by speeding up or slowing down relative to another voice, either the other voices must do likewise to stay synchronized, or that stolen time must be "given back" by flexing the tempo commensurately in the opposite direction. The assumption of synchrony is that all tempi are constantly in a 1:1 relationship, but if that ratio changes slightly for a time, it must be changed in an opposite manner for a comparable amount of clock time in order for the two tempi to resynchronize."

hei andrea... yeah, the forums are a little messy, i think :) 

summing it up: chris' article is insanely on point (and i think floating points clever insight helps me alot, too...). thanks to all you guys including yourself, andrea. 

@andrea: i may have not made my approach completely clear. chris states is very well in his article: 

"Timepoint stretching. The principle that underlies tempo rubato is that the tempo of the different voices of a composition might flex subtly, with the performer(s) nevertheless remaining aware of the other voices so that an important global tempo is maintained. If one voice "steals time" by speeding up or slowing down relative to another voice, either the other voices must do likewise to stay synchronized, or that stolen time must be "given back" by flexing the tempo commensurately in the opposite direction. The assumption of synchrony is that all tempi are constantly in a 1:1 relationship, but if that ratio changes slightly for a time, it must be changed in an opposite manner for a comparable amount of clock time in order for the two tempi to resynchronize."


@chris: i've tried to recreate your patch but i can't get it to work :/ any hint (or place to download it)? would really love to play with it.

Thanks Benniy for reposting (and sorry for misspelling your name above!)

Well, I think that Chris's article states very elegantly what I tried to show with my patch.

If, within your conceptual framework, time is sampled (rather than continuous) this means that you only have to take care that the sum of all the durations of your time grains is equal to a given number — 1000, in your specific case.

So my suggestion is to draw whatever function you like in a multislider (but it might as well be a different object, such as function), compute its sum and use it to normalize all the steps of the function itself. If the steps of the function you drew, summed together, amount to 100, then by multiplying each step by 10 you get a sum of 1000. You can apply this to any function you want to draw, as long as the sum of its steps is not 0. (My patch only does this calculation, it doesn't "play" the sequence: but it's pretty easy to do it by replacing the uzi with a delay, whose delay time is, for each new bang, the element previously returned by zl.lookup).

So my suggestion is just that you can draw whatever function you like in a multislider (or in a function object, or wherever you want

Well, I think that Chris's article states very elegantly what I tried to show with my patch. 

So my suggestion is just that you can draw whatever function you like in a multislider (or in a function object, or wherever you want


"As long as the transfer function begins at point 0, 0 and ends at point 1, 1, the two time streams will be synchronized at those points. Additional convergence points will occur whenever the transfer function crosses this unity line. "

here's something I could think of that's as simple as possible to illustrate that : (sorry not addressing your posted patch)

I like this line in Chris' paper:
"As long as the transfer function begins at point 0, 0 and ends at point 1, 1, the two time streams will be synchronized at those points. Additional convergence points will occur whenever the transfer function crosses this unity line. "

here's something I could think of that's as simple as possible to illustrate that : (sorry not addressing your posted patch)


 in the article, plus a few other relevant examples.

Here are links to the examples in the article, plus a few other relevant examples.


P.S. The audio file needed for the last two examples is 

P.S. The audio file needed for the last two examples is here.


very complex rescaling / remapping ?