[ardour-dev] Re: [ardour-users] Unified Tempo Map?!

[Shayne O'Connor]

Ben Powers wrote:

> "Hey all you out there in Audio Land!"
>
> I've got a problem and think it would benefit all of us to solve it,  
> here's my (possibly whack) suggestion:
>
> ===The Track:
> I have an 8 minute song recorded in the park, off-the-cuff, as one  
> sample. I want to produce it, adding drums, effects, the whole  
> shpeil. Being totally improv, the song does not fall exactly on the  
> beat each time, and there are many tempo changes, some small and  
> barely noticeable and some drastic.
>
> ===The Problem (from the user's perspective):
> In order to play the drum track behind the big sample and make it  
> sound good, I'd have to put in all sorts of fiddly little tempo and  
> meter changes at odd places in the track. Due to the design of the  
> system, it's easy to assign them to musical time (4th bar 3rd beat),  
> but very hard to assign tempo changes to time code (by  
> HH:MM:SS:frames). This makes it next to impossible to produce the  
> track the way I'd like to, using Ardour and Hydrogen.
>
> ===The Problem (from the developer's perspective):
> The tempo map for one song might be really simple (one tempo for the  
> whole track), but another song might be really complex (many tempo  
> changes, rubato, accelerando, retandando, etc, etc. Furthermore, each  
> app has it's own way of handling tempo maps.
>
> I think it's pretty clear that it would be good to have some form of  
> unified tempo map system in place. Once we set the size of jack's  
> shared memory for the session, it's hard to change that in realtime  
> (if the tempo map gets big).
>
> ---possible solution---
> We could create a new daemon to handle tempo map across the session,  
> and launch it at the same time as jack, with plenty of inter-process  
> communication. This daemon would be launched through qjackctl/ 
> jackpilot/whathaveyou and have an option to set shared memory size at  
> launch (documentation would explain the relevance to the user). When  
> the size of the tempo map exceeds the shared memory alloted, the user  
> would be notified that the session should be saved and restarted with  
> a higher shared memory size - perhaps this could be automated for the  
> user once she gives her approval.
> ---possible solution---
>
> I'm not sure if that makes any sense from a developer's standpoint,  
> but it sounds plausible to me. Could we do this? This would make the  
> Free Software Sound Studio a force to be reckoned with. Let me know  
> what you think of this cockamamy scheme.


while i definitely would like to see something *like* this (i have had 
my own brain-fucks trying to implement a simple tempo change within a 
song being built in hydrogen/ardour), for the song you are wanting to 
record i'm not sure if it would be necessary ...

if it is an eight minute song recorded in one take, with no consistent 
tempo, your best bet would probably be to just ignore the tempo/time 
signature of ardour and play hydrogen with your midi keyboard in 
real-time ... you could do it a layer at a time (kick and snare first, 
then add in some hi-hats, toms etc). this is what i've been doing with a 
song built from an out-of-time bass-line sample. way easier than trying 
to map the tempo and then program the drums with your mouse.

but, yeah - i'm glad someone has bought this up, because it is *the* 
feature that is missing from the relationship of hydrogen/jack/ardour.

shayne