[PD] achieving smooth tempo change

[Lorenzo Sutton]

Hi,

You don't provide any detail about your project/use case so it's very 
hard to try and give suggestions on such a theoretical base.

Your initial similarity with DAWs is somewhat misleading as you mention 
a global setting (that is correct most DAWs/sequencers have a general 
BPM setting). But then you state (if I understand correctly) that you 
don't want to use a global tempo/timing source in your project ("keeping 
time locally").

Independent time objects in environments like Pd are intrinsically... 
independent (I would say that's a neat feature!): you can of course find 
ways to have these objects 'communicate' with each other.

Something which might (or might not) be relevant is that you can also 
use audio-rate objects (i.e. phasor~) to do timing. For example a 
phasor~ with a frequency of 1 Hz has a period of 1 second, etc. 
(samphold~ might also be relevant??).

But as said if would really be helpful to know what you're trying to 
achieve ;)

Lorenzo.

On 11/02/2016 06:14, Liam Goodacre wrote:
> Any DAW or sequencer has a global setting which allows you to change the
> tempo smoothly across all elements. But fool around on PD for a while
> and you will realize that this is not a simple operation. If you have
> more than one time object going at once, it is very hard to keep them in
> time with each other while changing the period.
>
> Consider the example of two metros set to 500 and 1000 ms, banging in
> synch with one another. The "cold" inlet of both are connected to a
> float, with the second one being multiplied by 2 along the way. I'm sure
> you don't even need to try this to know that the two metros will quickly
> faze out quite if you scroll through the value. The metro duration
> updates only  after the  cycle is complete, so one updates before the
> other and it quickly gets chaotic, especially if you drag the value for
> more than one complete metro cycle. Of course you could keep them in
> time by using a trigger to reset the metros, but this is not good from a
> musical perspective, because I don't want to go restart the bar every
> time I change the tempo. Another possibility is to store the new time
> value and load it only when both cycles coincide. This should keep both
> metros in time, although the transition wouldn't be very smooth.
>
> [line] works differently, in that the time is specified in the "hot"
> inlet. But this also doesn't update smoothly if you interrupt it with a
> new message before the cycle has finished, because the new value
> sent to it will take the last point as a starting point. The total
> duration of its cycle will be {elapsed time} + {new time}, which isn't
> very good if you want to change tempo smoothly. I worked on trying to
> solve this for a while, and came up with a prototype solution which I am
> attaching. It works by taking the new time and subtracting it from
> elapsed time for the new value, so that the line finishes its cycle as
> if the new time value had been given at the beginning. The patch works
> reasonably well for one iteration, but completely fails for more than
> one (ie. if you scroll through the time values). I still haven't figured
> out why.
>
> Before I open up for suggestions, here are a few other points:
>
> 1. The simplest solution to this would be to have one and only one time
> object, set to say 1/16th beat or whatever is the smallest time interval
> you want, acting globally on all other sequenced events. This would work
> simply and elegantly, but unfortunately it is not an option for my
> project. Keeping time locally is essential to me, and I would sooner
> give up tempo change altogether than give this up.
>
> 2. Another option would be to use the [timer] object, either as an
> alternative to the others, or to help calculate feedback for them. I'm
> hesitant to do this because a: it seems like it would require more CPU
> and b: it it seems like an empirical solution to a deterministic
> problem. My intuition says that this
> problem can be solved mathematically, without resorting to measurement.
> However, I am willing to be convinced that this is the right way to go.
>
> 3. I assume that [line] and [line~] will work identically in this
> regard, and that [delay] and
> [metro] will work similarly. But [line] and [delay] work in very
> different ways, and so the solution, if it exists, is likely to be quite
> different for these objects. Ultimately I want to find a solution for
> all time objects, so I'm willing to hear anything you've got!
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>