Strange behaviour on close notes when using amsynth as ardour plugin

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Write a simple track in ardour3 with chords, every chord has to begin 
exactly at the end of the last
2. Play or export

What is the expected output? What do you see instead?
I should hear the chords, sometimes I can listen only to one note (top or 
bottom).

What version of the product are you using? On what operating system?
Amsynth 1.4.1 (but the same happens on 1.4.0) with Ardour 3.5.357, using Gentoo 
Linux 32bit with jack 0.121.3 on an i5-3570.

When correcting the duration of the chords (shortening just a little bit), the 
problem doesn't occur anymore.

Using amsynth standalone this doesn't happen.

I also tried to create the same track on rosegarden and then import the mid 
file in ardour, with the same result.

Attaching the ardour session.

Original issue reported on code.google.com by maurizio...@gmail.com on 15 Apr 2014 at 11:04

Attachments:

• amsynthbug.zip

[GoogleCodeExporter]

Thanks for the concise bug report and for attaching a test session :)

I have just loaded it up in Ardour 3.5-357-gce4d125 with amsynth 1.4.2 (just 
released) and have not yet observed any dropped notes after looping that bar 
for a few minutes.

How often is the problem happening for you?

I am on an x64 system though - not sure if that could be making a difference.

Original comment by nickdowell on 16 Apr 2014 at 8:41

[GoogleCodeExporter]

Thank you for amsynth :)
This happens everytime (once the track is created the problem is always in the 
same points), but sometimes if I delete a note in the chord and then recreate 
it, it plays another one. For instance, if I have a C/E/G chord in which ardour 
plays only the C, if I delete it and then write it again, sometimes it plays 
only the E or G note.

I'm afraid that this is also related to the early and not yet mature status of 
MIDI support in Ardour, but maybe not. I'm going to test it against Rosegarden 
and let you know if something changes.
It may also be worth noting that since I'm using Gentoo my sistem is a deeply 
custom one, so this bug could be related to a mixture of variables. I'm also 
waiting for help on the Ardour channel on freenode, maybe I can have a larger 
userbase to understand what the problem is.

I'm attaching the export of the test session I sent in the report.
I tested with your 1.4.2 release and the problem still occurs.

Original comment by maurizio...@gmail.com on 17 Apr 2014 at 9:24

Attachments:

• session.mp3

[GoogleCodeExporter]

I have just pushed a change to the git repository which I am hopeful will fix 
this issue.

If you could give it a try and let me know whether it helps, that would be 
great :)

Original comment by nickdowell on 18 Apr 2014 at 9:36

• Changed state: Started

[GoogleCodeExporter]

Unfortunally I tried it but it looks like the problem still occurs.
I've made a couple of tests with rosegarden and I have found different (but 
maybe related) problems: when the track is stopped while playing a chord, once 
the playback is resumed (in a different point), it still plays the previous 
notes, and they are played until those note are effectively played in the 
track. I know that rosegarden doesn't use lv2 (it's labelled as DSSI in the 
synth selector), but maybe this can be related to some internal "midi" exchange 
problem.
I've made some tests using calf organ in the same session I sent earlier and 
every chord is played without problems.

Original comment by maurizio...@gmail.com on 18 Apr 2014 at 12:08

[GoogleCodeExporter]

I've added some logging code to show the note events being received by amsynth.

If you rebuild amsynth and run Ardour from the command line you should see 
messages like the following:

note  48 on   @    0
note  55 on   @    0
note  64 on   @    0
note  48 off  @  896
note  55 off  @  896
note  64 off  @  896
note  50 on   @  896
note  54 on   @  896
note  62 on   @  896
note  50 off  @ 1792
note  54 off  @ 1792
note  62 off  @ 1792
note  47 on   @ 1792
note  53 on   @ 1792
note  62 on   @ 1792
note  47 off  @  640
note  53 off  @  640
note  62 off  @  640
note  48 on   @  640
note  52 on   @  640
note  60 on   @  640
0x7fe2a8018800 note 48/0 was already on, now at 2
note  48 off  @    0
note  48 on   @    0
note  52 off  @    0
note  55 on   @    0
note  60 off  @    0
note  64 on   @    0

That warning message is coming from ardour itself, and could be significant...

Please see if these logging statements show any missing note events on your 
setup or if note offs are being sent after not ons (which would immediately 
kill the said note, explaining this issue) - thanks.

Original comment by nickdowell on 18 Apr 2014 at 6:08

[GoogleCodeExporter]

We are getting close, maybe :)
This is the output, as you can see I get only one note on events after the 
first chord.

note  48 on   @    0
note  55 on   @    0
note  64 on   @    0
note  48 off  @    0
note  55 off  @    0
note  64 off  @    0
note  54 on   @    0
note  54 off  @    0
note  62 off  @    0
note  50 off  @    0
note  47 on   @    0
note  47 off  @    0
note  53 off  @    0
note  62 off  @    0
note  48 on   @    0
note  48 off  @    0
note  52 off  @    0
note  60 off  @    0

So this can be an ardour related bug, maybe.

Original comment by maurizio...@gmail.com on 19 Apr 2014 at 1:09

[GoogleCodeExporter]

Yes we are close :)

The missing note ons definitely correspond with what you are describing.

I've added even more logging which should reveal whether it's ardour not 
sending them, or amsynth dropping them somewhere, if you could re-run your test 
and post the logs again that would be very helpful, thanks.

Original comment by nickdowell on 19 Apr 2014 at 12:07

[GoogleCodeExporter]

That's it:

                          LV2 MIDI: 90 30 40  @    0
                          LV2 MIDI: 90 37 40  @    0
                          LV2 MIDI: 90 40 40  @    0
note  48 on   @    0
note  55 on   @    0
note  64 on   @    0
                          LV2 MIDI: 80 30 40  @    0
                          LV2 MIDI: 80 37 40  @    0
                          LV2 MIDI: 80 40 40  @    0
                          LV2 MIDI: 90 36 40  @    0
note  48 off  @    0
note  55 off  @    0
note  64 off  @    0
note  54 on   @    0
                          LV2 MIDI: 80 36 40  @    0
                          LV2 MIDI: 80 3e 40  @    0
                          LV2 MIDI: 80 32 40  @    0
                          LV2 MIDI: 90 2f 40  @    0
note  54 off  @    0
note  62 off  @    0
note  50 off  @    0
note  47 on   @    0
                          LV2 MIDI: 80 2f 40  @    0
                          LV2 MIDI: 80 35 40  @    0
                          LV2 MIDI: 80 3e 40  @    0
                          LV2 MIDI: 90 30 40  @    0
note  47 off  @    0
note  53 off  @    0
note  62 off  @    0
note  48 on   @    0
                          LV2 MIDI: 80 30 40  @    0
                          LV2 MIDI: 80 34 40  @    0
                          LV2 MIDI: 80 3c 40  @    0
note  48 off  @    0
note  52 off  @    0
note  60 off  @    0

I suppose that events starting with 90 are NoteOns, whilst 80 events are 
NoteOffs.
So, if I'm getting this correctly, this is a problem within ardour itself, 
isn't it?

Original comment by maurizio...@gmail.com on 19 Apr 2014 at 8:55

[GoogleCodeExporter]

I finally had a moment with one of ardour maintainers and we were able to track 
the problem. The problem is within jack (jack1) itself, since until version 
0.124 there was a bug in the midi buffer. I quote:

ardour gets the MIDI buffersize from jack. LV2 adds some overhead.  and jack1 
had a bug. it announced too small buffers. jack1 prior to 0.124 used the same 
buffersize for midi as for audio (jack period dependent) that is not right.

The simple solution is to increase the frames/period size, which in my system 
is pretty low (128), but this means an increased latency.
Alternatively, in some versions prior to 0.124 it is possible to set the midi 
buffersize (-M), which is available on 0.121.3. It has to be set before the 
device flag in the jackd command line (using qjackctl it is ok to set it in the 
server prefix).
This can be useful if one doesn't want to upgrade to an instable release (or to 
jack2); I was able to set it up to 4096 (setting it at 8192 doesn't allow me to 
start jack) and now I get every note.

So, the issue is finally resolved!

Thank you so much!

Original comment by maurizio...@gmail.com on 20 Apr 2014 at 12:01

[GoogleCodeExporter]

Great! glad to hear it's resolved now.

Thanks for letting me know :)

Original comment by nickdowell on 20 Apr 2014 at 2:45

• Changed state: Done