View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007059 | ardour | bugs | public | 2016-10-04 03:51 | 2017-11-18 00:45 |
| Reporter | dwrunyon | Assigned To | nmains | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | PC | OS | Debian | OS Version | Jessie |
| Product Version | 5.4 | ||||
| Summary | 0007059: Silent MIDI Notes | ||||
| Description | Multiple copies of 1st region, consecutive, first note of copies is silent. | ||||
| Steps To Reproduce | Opened 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 Information | MIDI track outputs to Yoshimi, then Yoshimi into audio track. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
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. |
|
|
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. |
|
|
I'm afraid that kind of thing to be a good bit beyond my knowledge. I have never self built anything. |
|
|
Sorry, I should have been more explicit, I'm not asking you to build anything. Can you please download a debug build from nightly.ardour.org 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. |
|
|
OK, confirmed, the issue isn't present in 5.4.10 debug. |
|
|
Just a note to say that I have noticed this problem with 5.4 self-build as well. |
|
|
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. |
|
|
tim - thanks for the careful bisection and analysis of this issue. |
|
|
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. |
|
|
Just tested 5.4-146-g29f6044 optimized and the issue persists. |
|
|
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? thanks |
|
|
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. |
|
|
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. |
|
|
|
|
|
Test session with issue is midilooptest (attached). Simply added a-Reasonable-Synth track and made quarter notes (percussive) region, duplicated it several times. |
|
|
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) |
|
|
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. |
|
|
nick_m recently did some more commits that he believes should fix this issue. Please let us know if it does. |
|
|
Thanks for your note. Using rev 5.4-221-g5743013 Intel 32-bit the issue is still present using attached midilooptest session. |
|
|
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. |
|
|
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? |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
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). |
|
|
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? |
|
|
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. |
|
|
ohzbees, If you can still reproduce the issue with a version >= 5.4.226 then please attach the session to this report. |
|
|
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! |
|
|
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. |
| 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 |
