Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixed recording of sustained midi notes #3710

Merged
merged 3 commits into from Jul 26, 2017
Merged

Conversation

@serdnab
Copy link
Contributor

@serdnab serdnab commented Jul 20, 2017

Fixes #1700.
This recovers the behavior done by 4b340f7, and later lost.
When a midinoteff comes from midi, and sustain pedal is pressed, the noteplayhandle pointer don't get nullified, so later, when sustain pedal is released, it can catch that pointer to emit the signal that recording of note is finished.

{
if (nph != NULL)
{
if (nph->isReleased())

This comment has been minimized.

@PhysSong

PhysSong Jul 20, 2017
Member

I think using && is better than using many if() clauses. In if (A && B), B isn't evaluated when A is false, maybe you know it already.
So it is safe to write like if (nph != NULL && nph->isReleased()) and that will make the code cleaner.

This comment has been minimized.

@tresf

tresf Jul 20, 2017
Member

is safe to write like if (nph != NULL && nph->isReleased())

Or if you believe in such a thing... :) if (nph && nph->isReleased())

@PhysSong
Copy link
Member

@PhysSong PhysSong commented Jul 20, 2017

Should the target branch be master? #1700 is in 1.2.0 milestone.

@zonkmachine
Copy link
Member

@zonkmachine zonkmachine commented Jul 20, 2017

Should the target branch be master? #1700 is in 1.2.0 milestone.

Yes, or we backport to stable-1.2.

@serdnab I've tested this and it works fine. It can't be tested completely because of #3537.
As commented in the review you can cut down the number of if()'s.
Would it be rude to suggest you to have a look at #3537 too?

@serdnab
Copy link
Contributor Author

@serdnab serdnab commented Jul 21, 2017

Made the shortening of the if's.

Would it be rude to suggest you to have a look at #3537 too?

I will take a look at it.

@@ -304,6 +311,25 @@ void InstrumentTrack::processInEvent( const MidiEvent& event, const MidiTime& ti
}
else
{
if (isSustainPedalPressed())

This comment has been minimized.

@zonkmachine

zonkmachine Jul 21, 2017
Member

I think you can write this into an if else with the else above to simplify it further.
And then lines 324-326 can get one tab each.

@zonkmachine
Copy link
Member

@zonkmachine zonkmachine commented Jul 21, 2017

I will take a look at it.

Awesome!

I restarted the Travis build. It sometimes will fail for reasons that are not related to the changes made.

@serdnab
Copy link
Contributor Author

@serdnab serdnab commented Jul 21, 2017

Addressed the remarks.
I realized that the "else" is not necessary, if not isSustainPedalPressed(), m_sustainPedalPressed is already false.

@zonkmachine
Copy link
Member

@zonkmachine zonkmachine commented Jul 21, 2017

I realized that the "else" is not necessary, if not isSustainPedalPressed(), m_sustainPedalPressed is already false.

So, drop the test and just let there be: else

@serdnab
Copy link
Contributor Author

@serdnab serdnab commented Jul 23, 2017

I believe you misunderstood me.
The if(isSustainPedalPressed()) is necessary because m_sustainPedalPressed can be true or false, what is not necessary is a possible "else" for the if(isSustainPedalPressed()) clause.

@zonkmachine
Copy link
Member

@zonkmachine zonkmachine commented Jul 24, 2017

I believe you misunderstood me.

I believe you're right there... :)
Looking at this again.

what is not necessary is a possible "else" for the if(isSustainPedalPressed()) clause.

This is true, but the if( event.controllerValue() > MidiMaxControllerValue/2 ) above it still needs the else. You're testing a state, but this is the event that sets the state. Maybe you can show how you're thinking in code instead?

@PhysSong
Copy link
Member

@PhysSong PhysSong commented Jul 24, 2017

@serdnab Or you can drop else if you put current else if clause first, though current code looks better. I suggest keeping this code.

@serdnab
Copy link
Contributor Author

@serdnab serdnab commented Jul 24, 2017

I am not explaining well, then you are not understanding.
Anyway, the code I intend is the current one.

@zonkmachine
Copy link
Member

@zonkmachine zonkmachine commented Jul 24, 2017

The only difference I see is that with dropping the test you have a built in safe guard in case of an unexpected state. When we get a pedal off command when m_sustainPedalPressed is false. This may never happen and/or may not have any side effects at all. I don't know if I'm being picky here. If other developers are cool with this I vote merge.

@PhysSong
Copy link
Member

@PhysSong PhysSong commented Jul 24, 2017

@zonkmachine I suggest merging without more change.

@zonkmachine zonkmachine merged commit 2464a57 into LMMS:master Jul 26, 2017
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@zonkmachine
Copy link
Member

@zonkmachine zonkmachine commented Jul 26, 2017

OK. Squashed and merged. Thank you so much Andrés for fixing a long standing bug!

@PhysSong
Copy link
Member

@PhysSong PhysSong commented Jul 26, 2017

@zonkmachine backport?

zonkmachine added a commit that referenced this pull request Jul 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.