Play is silent inside piano-roll

[repsej]

Sometimes all notes in a track are silent when pressing play inside the piano roll - but they play fine from the song editor.

Bug found - seems to be ye good ole "off by one" :D

When track(n+1) is muted in the song editor - track(n) is muted inside the piano roll.

Example:

Say I have two tracks: 1) drums and 2) bass

If I mute the bass in the song editor - then the drums are muted when inside the piano roll.

[repsej]

And it always happens on the last track!

(Might depend on what it finds in that piece of uninitialized memory :)

[tresf]

Thanks kindly for reporting this. Possibly related to #1111.

[krafczyk]

I can't seem to reproduce this issue.. has a fix been merged for this already?

[Sti2nd]

UPDATE: Could reproduce with the steps below.

[krafczyk]

Okay, I think I've managed to reproduce the issue, however it's a bit different then what is reported.

Here's what I have to do for a minimal reproduction:

1. Open a new project
2. Open the piano roll editor for the default triple oscillator.
3. Lay down a few notes
4. Press the play button inside the piano roll, and see that the sound works as expected
5. Go to the song editor, and mute the beat/bassline
6. Press the play button again inside the piano roll, and see that now the sound is muted.

Now, I've played around for a while with this bug, and I've found a few interesting clues.

1. This bug concerns the sound produced when you press 'play' inside the piano roll. It does not concern adding notes, or clicking notes on the keyboard.
2. This depends on the existence of a beat/bassline entry in the song editor
3. If you remove all beat/basslines from the song editor, pressing play inside the piano scroll will produce sound as expected
4. Only the 'first' beat/bassline entry matters. I guess these are stored in some kind of vector, so whatever beat/bassline is at index '0' will cause this bug. If you have others, they don't matter. It also doesn't matter if you rename this 'first' one. If you have others, and you delete the current 'first', another will take it's place.
5. It does not matter what is in this 'first' beat/bassline entry. it can be empty, or have whatever you want.
6. Only certain instruments seem to be affected I'll include a list at the bottom.
7. The order of the instruments in the song editor does not matter. only whether the 'first' beat/bassline entry is muted, and whether the instrument is an 'affected' instrument.

The list of affected instruments is as follows:

• Triple Oscillator
• Organic
• Vibed
• Watsyn
• Bit Invader
• Monstro
• Nescaline
• AudioFileProcessor
• FreeBoy
• Kicker
• SID
• sfxr
• patman
• mallets

The list of unaffected instruments is as follows:

• ZynAddSubFX
• LB302
• OpulenZ
• Vestige
• sf2 player

Please let me know if you can reproduce this bug, given the above information!

[krafczyk]

I've tested more instruments, and I've updated my original list. I think I've tested them all now.

[musikBear]

same as #947

[krafczyk]

I've explored the history a bit. This bug has been around at least since 2012. Probably earlier.

[krafczyk]

Okay. I've found the source of the bug.

Instrument tracks having their 'bbTrack' property filled with the bbtrack corresponding to the track content object number of the object currently being played.

If you add multiple track content objects to the triple oscillator in the example above, let's say 4, and then you add 4 bbtracks, the nth track content object will be muted while being played inside the piano roll if the nth bbtrack has been muted.

This behaviour is clearly wrong, and I'm submitting a pull request removing this behaviour. I've tested it with a few projects and I can't find any adverse affects from this fix.

[badosu]

As #1157 was merged I guess this issue is fixed?

[diizy]

On 12/26/2014 12:41 PM, Amadeus Folego wrote:

As #1157 #1157 was merged I guess
this issue is fixed?

No it wasn't and this probably won't be until 2.0.

[badosu]

Oh sorry, I just missed that it actually was not merged.

[tresf]

Bumping to 1.3 because Vesa said we could. :)

[zonkmachine]

I can reproduce this in 1.0 and 1.1.3 but not in current master f99dba5

[kungfooman]

I got the same problem in 1.1.3, deleting the Bass Lines fixed it (thanks krafczyk for the info).

Oh, I should probably use the Beta version then, since the 1.1.3 seems to be 2 years old.

[zonkmachine]

Oh, I should probably use the Beta version then, since the 1.1.3 seems to be 2 years old.

Correct. You can get the latest 1.2.0-rc3 here: https://lmms.io/download/#windows
Testing is appreciated! 😉

[zonkmachine]

This is fixed. Somewhere in the work around LMMS Memory Manager #1088 this was fixed.
I couldn't pinpoint the commit as the build fails around where the Memory Manager was introduced but here are, in my opinion, the most likely commits to have fixed this.
I'm closing this issue but please reopen if it reappears.

More likely:

commit 857de8d
Date: Wed Aug 27 00:59:49 2014 +0300

Huge structural changes
Well, this commit got a bit out of hand, what with 26 files changed. Oh well.

Basically, we're using the buffermanager to dispense temporary buffers for playhandles and audioports to use.
This allows us to change the way playhandles work. Earlier, playhandles of the same track were waiting in line
to push their output to the audioport. This was of course inefficient, so now they just register themselves to the port,
then the port handles mixing the buffers.

Caveat: this is still a work in progress, the vol/pan knobs on instruments are temporarily non-functional - will be fixed in
the next commit, but I have to get some sleep nowcommit 857de8d2c829dc688745f41ba8eddbe148a63a20

commit 1864dcf
Date: Fri Aug 29 20:24:24 2014 +0300

Fix bugs

commit 7bc97f5
Date: Sun Aug 31 13:44:28 2014 +0300

Fixes

Less likely:

commit dc4bfdc
Date: Sun Oct 12 00:59:50 2014 +0300

Various fixes and precautions
Samplebuffer: reload all samples when samplerate changes. This is because of the way LMMS uses samples: we always resample all samples t$
LadspaEffect: some safeguards for the non-inplacebroken plugins which use the same buffer for input and output. Theoretically, if some p$
FxMixer: fix effect processing in multichannel-chains

commit 68b5a21
Date: Tue Sep 2 23:25:05 2014 +0200

Initialize BufferManager from within Mixer

Avoid crashes caused by worker threads accessing the buffer manager
before it is initialized. Therefore initialize it from within the
Mixer constructor which has the side effect that it gets initialized
in console-only rendering mode as well.

commit 1deb80a
Date: Wed Aug 27 23:08:22 2014 +0300

Finish audioport rehaul, get vol/pan knobs working again, also some bugfixes
We're now doing the vol/pan stuff in audioport, since this way we avoid the pointless repetition of doing it in the playhandles