You are here

Tempo map changes and automation

I have a project that consists of several midi tracks. I added some automation to the volume of some of these tracks. Unfortunately, I have found that if I then make any alteration to the tempo map - e.g. slightly adjusting the tempo of a section - the automation ends up in the wrong place in the music.

The release notes for v.0.9.36 include "Fixed a yearlong bug in MIDI file import/export of tempo, time and key signatures and markers, to severely wrong locations". I thought that this probably meant that the problem was solved. So I installed the new version. (I was previously using 0.9.35.)

Unfortunately the bug with the automated passages is still there. Is there some workaround for this problem, so that I can keep my automation linked to the correct moments in the music?


rncbc's picture

no. if you change the tempo-map after automation is laid out, the curve points remain at their absolute timeposition iow.. it doesn't change relative to new metro/BBT scale. sorry.
UPDATE: I was wrong, sorry! As a matter of fact, automation curves *do actually* follow tempo-map changes and do so for quite some time now; my bad!

though, this still has nothing to do with the "yearlong bug" whosoever, as it related to MIDI file import (and not automation).

can you please show us, with a couple of before-and-after screenshots, perhaps, how it goes wrong for you?


I don't know if it is a solution, but I suggest you automate it from the midi editor, editing the midi volume of the clip, instead of the track automation.

Doing it this way has another advantage. You can copy the volume drawing from a clip on one track and paste it into another clip on another track, if you want multiple tracks to behave similarly.

If what you want is to use a slider instead of drawing, you can do it from a midi controller with a slider and recording within the midi editor.

If you do not have a controller with a physical midi slider, you can use a smartphone or tablet connected by USB; there are many free apps that work as midi controllers.

Or simpler, download the AppImage of VMPK virtual midi controller on your Linux and use it in the Qtractor midi input.

File attachments: 
rncbc's picture

I also don't know it that's a solution or rather an entire alternative to the OP's problem...

anyway, as I've given an update above, the problem might be somewhat concealed in a way that I don't grasp atm. ;)


I attach 2 screenshots of a short test file, using qtractor 0.9.36.

Before.png shows the file after adding some simple volume automation, with the nodes approximately at the start of bars 3, 4 and 5.

After.png shows the same file after making tempo changes at various points. I found that changing the tempo mostly did not affect the placing of the automation nodes relative to the music, but when I changed the opening tempo (Bar 1) that threw the automation out of sync., as shown. If this were generally true then there would be an easy workaround: simply have a silent bar or two at the start of the piece (which I normally do anyway) and set the actual required opening tempo a bar or so later.

Unfortunately further experimentation has shown me that intermediate tempo changes also sometimes (but not always) throw things out of sync. Reversing those changes does seem to revert things to how they were before the change was made, but again, I'm not 100% sure whether that is always true. Neither can I understand why some changes wreck the synchronization, and others don't.

Using midi velocity is not a solution, I'm afraid. In fact, I do make most of my changes using velocity. But, as I understand things, it is not possible to alter the velocity of a note once it is sounding. So far as I can tell, then, the only way to produce effects like sforzando-piano on a note, or a crescendo through a long note is to vary .the volume. Those are the only times I resort to doing this: I do everything else regarding loudness changes by adjusting the midi velocity of notes.


File attachments: 
rncbc's picture

hi, hmm...

seem to fail in reproducing this..., maybe my fault but,

let's have a look at the attached screenshots...

b. this is the "before" situation where I tried to replicate yours as much as possible:

a. and this is "after" a tempo change (60bpm) is added to bar 4, which resembles the same "after" of yours screenshot, at least on the tempo map timeline:

however, while yours seem wrong as you kindly report, mine looks perfectly right--or am I missing something?

please tell the exact steps you do between the "before" and "after" situations of yours, as I maybe missing something or even the whole picture.


As I mentioned previously, in my small test file I found that the automation stayed correctly aligned with the beats whilst I made several changes. just as yours did. But when I changed the opening tempo (i.e. Bar 1) I got the messed up version shown in my second screenshot. I can't remember the exact changes I made or in what order. But the final change - the one that caused the mess - was definitely at Bar 1.

I thought that this might mean that it was only Bar 1 tempo changes that ever cause a mess, and I could easily work around that. But since my previous post, I have experimented with making tempo changes in my actual project, and I find that tempo changes at intermediate places in the music can also cause the automation curve to end up in the wrong place. I have just tried this again: in my main project, I changed the tempo of a single bar from 152 to 160, and the volume curves later in the movement ended up in the wrong places. When I changed this bar back to 152, the curves were restored to their correct places.

rncbc's picture

wholly cow! we're getting somewhere now! :(...

yes, it seems that changing the baseline tempo (eg. from the toolbar) and while the playhead is located somewhere between the beginning and the first tempo map change node, then automation points gets into trouble... :S

is that the only case? or are there something else?

ps. ok. got it! as a matter of fact (again), automation curves only get rescaled correctly over _two_consecutive_ tempo changes and only... all gets lost over the third and beyond (yes, the first base counts as one in this rule...) gotta fix that :!o.O(...)

pps. hopefully fixed in qtractor >= v0.9.36.9git.08960f

I can't wait to try out your latest version to see whether it has solved the problem!

Slightly OT, but I'd be grateful for your advice: if I do 'git pull origin develop', do I have to do a complete recompilation, or is there some way to short-cut this and just install the changes?

rncbc's picture


sorry for the delay and yes you'll surely need to recompile the whole thing, or else, if you still have the previous build subdir available, it might just be a matter to run `cmake --build build` ...


I have spent some time editing my main project this afternoon, using qtractor v, I used the new legato and articulation options, which are very useful, but more importantly I moved my few bits of volume automation back to their correct places in the music.

Unfortunately I find that there are still some weird things going on with tempo changes. When I make a change in the Tempo Map, I often find that another unwanted change is made, either earlier or later in the music than the actual change I made. I have also found the the automation is now all out of place again.

Over the next few days I'll try to make a short test file and then make a note of every change I make, and any unwanted side-effects that occur. Perhaps that will help to pin down exactly why these strange things are happening.


Further to my previous comment, I have now found a short sequence of operations which shows (at least on my machine) automation curves ending up in the wrong place.

The problem actually seems to appear when a session is reloaded after having been saved. So everything is OK, but upon reloading the session the automation is found in the wrong part of the music. In addition, I almost always find that some tempo changes have been altered when I reload a session.

Here is what I did. I have gone into detail about some things, just in case I am actually doing something incorrectly.

Open qtractor (I am currently using v.
Save new session
Set quantization to 'Beat'
Create MIDI track and new clip.
Set tempo to 120 4/4
Add a note in bar 8, just to give the clip some length,
Click on Automation button - Select - Track 1 Volume; Mode - Linear
Click on Automation button - Play
Add Nodes at bar 4 (100%), bar 5½ (0%), bar7 (100%)
Add tempo change at bar 3: 176 4/4
(Automation still correctly extends from bar 4 to bar 7)
Save file.

Up to here everything works fine.

When a new session is started and the file is reloaded, I find that:
a) The tempo at bar1 is now 176 as well as at bar 3. On one occasion, they were both 174!
b) The automation curve is now a bar and a half too late, commencing at bar 5½.

I'll be very interested to know whether other people get a similar result.

rncbc's picture

may you check again whether you're making those tempo-map editing _while_ playback is rolling?
what happens if you don't, that is, do all the editing while playback is stopped/paused?

The whole thing was done without playback. The steps I took were just those that I listed.

Incidentally, in my main project not only have some of the tempo changes been altered, but Markers are all mixed up. (My markers show the actual bar numbers in the original score.) For instance, at one point I now have the following sequence in my Tempo map (MIDI bar no and marker):

30 "Bar 27" (N.B. this is correct)
36 "Bar 92"
38 "Bar 35"
44 "Bar 94"
48 "Bar 95"
92 "Bar 89"

No wonder my tempo changes are all mixed up too!

rncbc's picture

hi, here we go again :)

tried to follow your exact steps and ended up with like is shown below:

now, reloading this session doesn't seem to give anything strange; it always loads exactly as shown above.

maybe I'm missing something kept untold?


"Mysteriouser and mysteriouser!"

I just followed my own instructions, and when I saved and reloaded the session it was fine, just as you found.

However, if I save the file, shut qtractor down, then restart it and load the file in, the data is corrupted as I reported previously. I saved the file again under a new name, and did 'diff' on the 2 files. I attach an image of what diff produced.

Clearly the two files ought to be the same. But they are not. The altered basic tempo is clearly shown. I don't pretend to understand why the automation appears in the wrong place, but presumably it is something to do with the tempo having been improperly changed at some point. If I had changed the bar 1 tempo from 120 to 176 myself in qtractor, I think the automation would still be in the right place. But somehow, something seems to be going wrong in reloading the file after shutting down and reopening qtractor.

File attachments: 
rncbc's picture

hmm, are you by any chance, under pipewire-jack and not genuine jackd(bus) ?

anyway, but most specially if pipewire-jack is in charge, try to switch Transport > Mode to None or Master, and never to Slave nor Full. check whether the "mysterious" behavior is then gone or not present anymore...


I thought I was using pipewire, but if I do 'ps -e | grep jack' it tells me that jackdbus is running.

As for the Transport Mode, mine was set to "Full". I have now changed it to "None", and tried following my instructions from yesterday a couple of times. And I think you have solved the problem, because when I reload the file after closing and reopening qtractor,, everything seems to be as it should be.

I have no idea what the Transport Modes mean, but I suspect that I must have set it to "Full" because "None" sounds as if I wouldn't be able to play the contents of the file at all. Clearly that is not the case.

So far, then, it seems as if you have solved the problem of moving automation and wild changes to tempo and markers. Thank you very much indeed for all your help.

rncbc's picture

note that having jackdbus running doesn't tell you a thing, whether your A/V system is under pipewire service or else...

try this:
systemctl --user status pipewire

big question here is, are you actually running genuine jackd OR the so called pipewire-jack substitution where pipewire seamlessly emulate the ol'jack service and infrastructure?

onto the later case, if it's true, then let me tell that pipewire-jack still falls short on some niche situations, most specially on the jack-transport/timebase sync (better say async) situation... and it still have shortcomings on most recent rc ones (v0.3.85 here), so that's why I suggested you to get the qtractor transport mode to not listen to it--it's still not on par to true-jack. nuff said ;)

you've been advised ;)

'systemctl --user status pipewire' produces this output:

● pipewire.service - PipeWire Multimedia Service
Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled)
Active: active (running) since Tue 2023-11-14 20:43:31 GMT; 1 week 1 day ago
TriggeredBy: ● pipewire.socket
Main PID: 1462 (pipewire)
Tasks: 3 (limit: 8728)
Memory: 11.7M
CPU: 1h 19min 19.267s
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
└─1462 /usr/bin/pipewire

and then a load of lines like this:

Nov 22 19:03:24 eros pipewire[1462]: spa.alsa: front:1: follower avail:479 delay:479 target:1024 thr:1024, resync (1 missed)

So I suppose that means I'm using pipewire-jack. As you can probably guess, I haven't the slightest idea how to change to using the proper jackd.

Anyway, the good news is that the simple change in the Transport Mode setting seems to have solved the problem. I have spent some time this evening repairing the considerable damage that had happened to my current main project, and despite saving, restarting qtractor and reloading the file, everything still seems to be in the right place.


Add new comment