[ardour-users] Unified Tempo Map?!

[Ben Powers]

"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.

Ben Powers
OutofOrder Productions
out-of-order.ca / bennyp.no-ip.org

p.s. does jack/ardour/hydrogen have a development wiki?