[ardour-users] Unified Tempo Map?!

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[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?
_______________________________________________
ardour-users-ardour.org mailing list
[hidden email]
http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org
Reply | Threaded
Open this post in threaded view
|

[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
_______________________________________________
ardour-dev mailing list
[hidden email]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org