View Issue Details

IDProjectCategoryView StatusLast Update
0007059ardourbugspublic2017-11-18 00:45
Reporterdwrunyon Assigned Tonmains  
Status assignedResolutionopen 
PlatformPCOSDebianOS VersionJessie
Product Version5.4 
Summary0007059: Silent MIDI Notes
DescriptionMultiple copies of 1st region, consecutive, first note of copies is silent.
Steps To ReproduceOpened this project, which was originally created in 3.5.403~dfsg-3 (from Debian stable repos), in 5.3 and worked. Then upgraded to 5.4 and discovered the issue. Uninstalled 5.4, reinstalled 5.3 and worked again. Repeated this process 3 times now and issue is always present in 5.4 but 5.3 is fine. Also tried recreating the MIDI sequence from scratch in a fresh MIDI region and issue persisted.
Additional InformationMIDI track outputs to Yoshimi, then Yoshimi into audio track.
TagsNo tags attached.


has duplicate 0007184 closed First MIDI note not playing 
has duplicate 0007074 assignedtimbyr Looping MIDI adds silence at the beginning of the loop 
has duplicate 0007168 new Duplicated MIDI regions don't play first notes 
related to 0007508 new 6.0: loop playback omits the first note 



2016-10-04 03:51


whoknows.tar.gz (13,847 bytes)


2016-10-04 11:28

developer   ~0018755

I can confirm this in 5.4 with the Session you have attached and a new test Session I created.

Just trying to bisect it now but it takes a while. I definitely tested this case after the MIDI looping fixes went in and it was working then.


2016-10-04 13:23

developer   ~0018758

OK, I bisecting failed as I cannot reproduce with self build for version tagged with 5.4

But, after longish process of elimination it seems like this is only an issue with an optimized build. I tried the nightly 5.4.10 debug release and it does not have this issue but the 5.4.10 optimized build does.

If you could confirm it would be appreciated.


2016-10-04 15:38

reporter   ~0018759

I'm afraid that kind of thing to be a good bit beyond my knowledge. I have never self built anything.


2016-10-04 20:02

developer   ~0018764

Sorry, I should have been more explicit, I'm not asking you to build anything.

Can you please download a debug build from and confirm whether or not you can still reproduce this issue with a debug build.

You do not have to remove any other installed versions.


2016-10-04 20:25

reporter   ~0018765

OK, confirmed, the issue isn't present in 5.4.10 debug.


2016-10-05 01:09

reporter   ~0018768

Just a note to say that I have noticed this problem with 5.4 self-build as well.


2016-10-05 02:09

developer   ~0018770

Last edited: 2016-10-05 02:15

After bisecting this with an optimized build the first bad commit appears to be 395183ee, the two commits before that(2c7a5815 and 21054f6d) don't build but c0344db3 is good.

So there seems to be some difference between c0344db3..395183ee that is causing this behaviour only in optimized builds.

I'm assigning this to the author of those changes, hopefully he can confirm and will have a better idea about what the issue is. I don't have any more time do look into this right now.


2016-10-12 21:49

administrator   ~0018797

tim - thanks for the careful bisection and analysis of this issue.


2016-10-15 15:44

reporter   ~0018819

I've tested your session with current git and it seems to work as expected
on an optimized build.
4faf44588f should have fixed this, so testing with current nightly builds
would be appreciated.


2016-10-17 00:43

reporter   ~0018828

Just tested 5.4-146-g29f6044 optimized and the issue persists.


2016-10-17 12:08

reporter   ~0018829

Sorry to hear that, alas i cannot reproduce this.
To help me do so, could you tell me what snap setting you're using when copying
the regions?
Could you also eliminate yoshimi from the equation by using a synth plugin
on the midi track?
Is that different at all?



2016-10-17 21:40

reporter   ~0018834

I use "magnetic" on the grid, and just copy however many times to somewhat random spots, and then go back and scoot them into position against each other. Yes, just created a new MIDI track with the generic synth selected and issue is still present. I forgot to check exact version of Ardour, but it was the latest 32 bit optimized demo from the nightly page. I am still using 5.3 myself, without this particular issue. Much appreciated.


2016-10-18 06:11

reporter   ~0018835

Reproduced this using a-Resonable-Synth and nightly 5.4-154-g4661412)
Intel 32-bit

Attaching session. Using percussive notes, and duplicating a region, the first note of the duplicated regions is silent. Grid snap setting.


2016-10-18 06:17


midilooptest.tar.gz (9,647 bytes)


2016-10-18 06:19

reporter   ~0018836

Test session with issue is midilooptest (attached). Simply added a-Reasonable-Synth track and made quarter notes (percussive) region, duplicated it several times.


2016-10-18 08:15

developer   ~0018838

This appears to be an issue with only 32-bit builds, I can still reproduce with a nightly build 5.4.172 (32-bit) but not with 5.4.134 (64-bit, the most recent gcc5 nightly build)


2016-10-24 15:56

reporter   ~0018851

The issue being limited to 32-bit would explain why more people don't seem to be complaining about this. It is a deal-breaking bug with anyone wanting to create a drum loop. I anticipate tracking it down will be hard.


2016-10-24 21:43

administrator   ~0018852

nick_m recently did some more commits that he believes should fix this issue. Please let us know if it does.


2016-10-25 04:09

reporter   ~0018853

Thanks for your note. Using rev 5.4-221-g5743013 Intel 32-bit
the issue is still present using attached midilooptest session.


2016-10-25 07:23

reporter   ~0018854

Just tried the midilooptest example. Looping the entire arrangement, on each pass the problem persists. The first note of the first copy (ie the first note of bar 2) is omitted on playback. Looping merely that region plays without fault. Playing through once without looping plays without fault.

Playback when looping the entire arrangement is flawless when "Do Seamless Looping" is disabled.

This is with rev 5.4-226-g927b16a self compiled from git. My machine is Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz on 64 bit Xubuntu 16.04.


2016-10-25 10:40

reporter   ~0018855

thanks for the tests.
to better understand this, i'd like to eliminate a couple of code paths.

when seamless looping, does the problem persist if the MIDI preference for
"MIDI read ahead time" is set to something between 0.4 and 0.6 seconds?

does the problem persist if midilooptest is altered so that the notes always
alternate in pitch?


2016-10-25 10:53

developer   ~0018856

The fixes for this issue are only included in nightly builds >= 5.4.226

Reproducing this issue with a 32bit optimized build with 5.4.221 is expected.

After trying myself with 5.4.226, at first I could not reproduce any missed notes with the midilooptest session with or without seamless looping, looping or with normal playback etc, but after playing around for a while I can reproduce the missing first note of bar 2 if seamless looping is enabled and the MIDI read ahead time is 1.0 seconds or greater in the preferences dialog. If the Midi read ahead time is less that 1.0 seconds the note plays as expected.

I would guess that this is a separate issue with MIDI read ahead time changing output.

What do you have MIDI read ahead time set to?

Can you confirm that reducing the read ahead time makes the session play as expected?


2016-10-25 11:09

reporter   ~0018857

I can confirm that on rev 5.4-226-g927b16a reducing the MIDI read ahead time to 0.5 sec causes the session to play as expected.


2016-10-25 17:23

reporter   ~0018860

on nightly 5.4-226-g927b16a Intel 32-bit (Linux)

I do *not* see the issue, no matter if Midi readahead is set to 0.5, 1, or 2 and seamless looping is on or off. just did a complex drum loop over 5 bars and it played correctly. Will keep playing to see if anything crops up.


2016-10-25 22:07

reporter   ~0018861

more info: If I open up OLD sessions (pre 5.4-226), the issue of silent first notes *remains* no matter what I do (MIDI readahead + seamless loop combos), but if I delete the first notes and re-add them, then the there is no issue (it plays fine). So, it seems like the fix is in the note creation procedure(s).


2016-10-28 04:15

developer   ~0018865

I just tried to reproduce this again by creating a Session with the official 5.4 32bit linux release and then opening it with 32bit nightly version 5.4.230 and all the notes play correctly with 5.4.230

I also tested both the midilooptest and whoknows Sessions attached to this report. The official 5.4 32bit build fails to play the notes at region start but the notes play correctly in 5.4.230

ohzbees, The midilooptest Session attached to this report was created with a version < 5.4.226. Are you saying that the the midilooptest Session doesn't play correctly for you with a nightly build >= 5.4.226?


2016-10-28 19:21

reporter   ~0018868

I used 5.4.154 to make the original midelooptest session and that session now plays without error in 5.4.226.

Other sessions, I think those I made in 5.4.0 seem to have the error when opened in 5.4.226 until I re-add the starting note(s).

I can try to be more precise if it helps.


2016-10-29 10:25

developer   ~0018869

ohzbees, If you can still reproduce the issue with a version >= 5.4.226 then please attach the session to this report.


2016-11-03 16:36

reporter   ~0018905

Thank you all very much for the time and effort investments in not only this issue, but the entire project. I am a homeless person attempting to create some music to sell (and as pure self therapy). I have been experiencing a lot of difficult personal daily logistical challenges and am not always able to enjoy circumstances that lend themselves to involvement in these kinds of things, but will do what I can when I can if needed. Bless you all!


2016-11-27 01:36

reporter   ~0019057

Sorry for the delay in getting back to this. I just tried rev 5.4-456-g5bf8a55
Intel 32-bit and my more complex drum loop plays as expected (no silent notes)

Playing the same loop in 5.4.226 resulted in silent notes.

Something must have changed post 226 for this to work for this particular loop.

At any rate, it seems ok for me now.

Issue History

Date Modified Username Field Change
2016-10-04 03:51 dwrunyon New Issue
2016-10-04 03:51 dwrunyon File Added: whoknows.tar.gz
2016-10-04 11:28 timbyr Note Added: 0018755
2016-10-04 11:28 timbyr Status new => confirmed
2016-10-04 13:23 timbyr Note Added: 0018758
2016-10-04 15:38 dwrunyon Note Added: 0018759
2016-10-04 20:02 timbyr Note Added: 0018764
2016-10-04 20:25 dwrunyon Note Added: 0018765
2016-10-05 01:09 killermike Note Added: 0018768
2016-10-05 02:09 timbyr Note Added: 0018770
2016-10-05 02:09 timbyr Assigned To => nmains
2016-10-05 02:09 timbyr Status confirmed => assigned
2016-10-05 02:15 timbyr Note Edited: 0018770
2016-10-12 21:49 paul Note Added: 0018797
2016-10-15 15:44 nick_m Note Added: 0018819
2016-10-17 00:43 dwrunyon Note Added: 0018828
2016-10-17 12:08 nick_m Note Added: 0018829
2016-10-17 21:40 dwrunyon Note Added: 0018834
2016-10-18 06:11 ohzbees Note Added: 0018835
2016-10-18 06:17 ohzbees File Added: midilooptest.tar.gz
2016-10-18 06:19 ohzbees Note Added: 0018836
2016-10-18 08:15 timbyr Note Added: 0018838
2016-10-24 15:56 ohzbees Note Added: 0018851
2016-10-24 21:43 paul Note Added: 0018852
2016-10-25 04:09 ohzbees Note Added: 0018853
2016-10-25 07:23 killermike Note Added: 0018854
2016-10-25 10:40 nick_m Note Added: 0018855
2016-10-25 10:53 timbyr Note Added: 0018856
2016-10-25 11:09 killermike Note Added: 0018857
2016-10-25 17:23 ohzbees Note Added: 0018860
2016-10-25 22:07 ohzbees Note Added: 0018861
2016-10-28 04:15 timbyr Note Added: 0018865
2016-10-28 19:21 ohzbees Note Added: 0018868
2016-10-29 10:25 timbyr Note Added: 0018869
2016-11-03 16:36 dwrunyon Note Added: 0018905
2016-11-27 01:36 ohzbees Note Added: 0019057
2016-12-22 00:08 x42 Relationship added has duplicate 0007184
2016-12-22 00:20 x42 Relationship added has duplicate 0007074
2016-12-22 00:54 x42 Relationship added has duplicate 0007168
2017-11-18 00:45 x42 Relationship added related to 0007508