>if you change/add tempo map entries while only half your >network has completed a cycle, you're in deep sh*t. i >found the easiest solution to be preventing this from >happening in the first place.
two words i learnt from ardour-dev: accelerando, decelarando. think about it ;) >it does not, because any point in time can be expressed in >any domain. and to repeat, in stopped state all clocks are >frozen, no matter what they count. and to repeat again, >device-dependent units for information interchange across >implementation/abstraction layers are stoneage methodology. this isn't true. when "transport" time stops, free running audio time, as well as wallclock time continues to run. moreover, "transport" time can run backwards while other kinds of time run forwards. there is absolutely no mapping between "transport" time and a free running clock. >if you think in any form of transport time, be it ticks, >seconds or frames. this is the time context that plugins >operate in. any other concept of time is orthogonal. this is also false. plugins that want to measure time in absolute terms (e.g. a 150ms delay line) do not pay *any* attention to this concept of time. the fact that a transport has stopped doesn't change the way such a plugin operates in any way. >that's what a system-wide uniform time base requires. there is no uniform time. there are several timebases, most of which need to be uniform across the system, and a few of which do not. --p