-
Notifications
You must be signed in to change notification settings - Fork 172
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
Instrument editor love #1301
Instrument editor love #1301
Conversation
361f968
to
9ed1c7d
Compare
I have one more commit pending before this pull request is complete ... |
* deleting first and last point is only allowed when they are the last ones. * deleting the first or last point deletes the other end. * clicking on a wave with an empty envelope inserts to points at both ends
* align logic between SampleEditor & MainSampleWaveDisplay * don't change slider while dragging so that when you start editing start frame, you don't mess with end frame jumps.
8b4c80a
to
4e5fc43
Compare
Ok, I'm done with Sample Editing 😀 |
That's quite fast 😄 . I'll try to take a look within the next days. |
Hey @charbeljc , As these are improvements rather than bug fixes could you change the target to branch You do not need to close this one and open a new one but can just press the "Edit" button to the right of the title of this PR and select a different branch via a combo box. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution! I like it a lot!
Could you also have a look at the coding conventions in the DEVELOPERS file in our repo? I know that our code right now is quite a mess. But if we all stick to the same conventions it will become more easily readable in the future.
I also found two further inconsistencies in the Sample Editor (which are probably not related to your PR)
- open the SampleEditor -> enter a large value in the spinbox of the "Start" and press enter -> both the values in the spinboxes of "Start" and "Loop" get updated but only the "S" line gets moved in the wave display while "L" remains at zero.
- right to the "Play original sample" button there is a the label "new sample length" which seem to show incorrect values until the "E" marker is moved.
void setUnclean(); | ||
void setClean(); | ||
|
||
bool m_bSampleEditorClean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about making this variable private? Also, could you initialize it in the constructor of SampleEditor
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done, see 397034a
} | ||
|
||
void SampleEditor::valueChangedStartFrameSpinBox( int ) | ||
{ | ||
testpTimer(); | ||
m_pDetailFrame = StartFrameSpinBox->value(); | ||
if (m_pDetailFrame == __loops.start_frame) { // no actual change | ||
if (! m_bAdjusting ) on_PlayPushButton_clicked(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice feature. I like it!
QApplication::restoreOverrideCursor(); | ||
InstrumentEditorPanel *panel = InstrumentEditorPanel::get_instance(); | ||
panel->selectLayer( panel->getSelectedLayer() ); // reselect layer to trigger update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIU the purpose of this line is to call the updateDisplay( panel->getSelectedLayer() )
method of the m_pWaveDisplay
member in the InstrumentEditor
, right? How about introducing a new public member, like InstrumentEditorPanel::updateWaveDisplay( int )
, that does the job more explicitly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see 499fbca
bool m_bStartSliderIsMoved; | ||
bool m_bLoopSliderIsMoved; | ||
bool m_bEndSliderIsmoved; | ||
|
||
Slider m_SelectedSlider; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you initialize the variable in the constructor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done, see 7106762
update(); | ||
if (propagate()){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't in the current implementation returnAllMainWaveDisplayValues()
and thus also propagate()
do always return true
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum, you are right ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see cb9866a
} | ||
|
||
//loopframeposition | ||
else if (ev->y()<=65 ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be sure. Due to this changes dragging the start marker further than the loop and end marker will move the latter ones while the end marker can only move the loop one and the loop one can move none. Is this intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this was for consistency with the spinbox behavior. When you try to decrease loop_frame before start_frame, the spinbox clip it at start_frame. Let me know what you think about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see. I think it's fine.
@@ -283,3 +303,26 @@ void MainSampleWaveDisplay::mouseReleaseEvent(QMouseEvent *ev) | |||
|
|||
|
|||
|
|||
|
|||
void MainSampleWaveDisplay::chooseSlider(QMouseEvent * ev) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you feel about the y-coordinate based selection approach for the sliders that was implemented previously? I like your approach using the Manhatten distance a lot more but am still a little bit confused about it's y component. But I never really used the SampleEditor in a productive way so I do not know whether the vertical selection emulating the grabbing of the labels is necessary/handy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the y target coordinates, I choose mostly the y location of the slider's labels (S, L, E), also, the slider selection is done on mouse press and never change while dragging.
Before, the selected slider could change while dragging, furthermore, there was a dead zone between each slider influence.
The previous behavior could you drive nuts ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely. It's a huge improvement. The only thing I found a little bit strange was that clicking in the space between two adjacent sliders in order to move one of them there yields different results depending on the y coordinate of the mouse pointer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely. It's a huge improvement. The only thing I found a little bit strange was that clicking in the space between two adjacent sliders in order to move one of them there yields different results depending on the y coordinate of the mouse pointer.
Yeah, but I think we can get used of this behavior. At least we can make a mental model from it, and having the actual slider selected highlighted helps a lot.
painter.setPen( QPen(lineColor, 1 , Qt::SolidLine) ); | ||
painter.drawLine( envelope[i]->frame, envelope[i]->value, envelope[i + 1]->frame, envelope[i +1]->value ); | ||
if ( i == selected ) | ||
painter.setBrush( selectedColor ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about to draw the value of the selected point in here as well? This way it just needs to be hovered and not clicked for the user to inspect its value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done, see 2b6ff4c
// if only 2 points, remove them both | ||
envelope.clear(); | ||
} else { | ||
envelope.erase( envelope.begin() + m_nSelectedEnvelopePoint ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This statement needs to be wrapped in an if ( m_sSelectedEnvelopePoint != -1 )
or Hydrogen will segfault when right clicking in an empty part of the TargetWaveDisplay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch 😁, see 29edd84
update_envelope(envelope, m_nSelectedEnvelopePoint, m_nX, m_nY, m_nSnapRadius); | ||
} | ||
} else if (ev->button() == Qt::RightButton ) { | ||
//remove point |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about setting m_sInfo = ""
when right clicking to etablish a feeling of "nothing happens" when right clicking in an empty part of the TargetWaveDisplay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done also, see 2b6ff4c
@theGreatWhiteShark Thanks for your review, I addressed most of your comments and I should be really done this time. |
I'll have a look at this later ! (and also, I will try to follow developper's style guide) |
a257d8e
to
03b9c18
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice.
There are still some oddities but they were most probably already present so you do not need to fix them.
- the aforementioned: open the SampleEditor -> enter a large value in the spinbox of the "Start" and press enter -> both the values in the spinboxes of "Start" and "Loop" get updated but only the "S" line gets moved in the wave display while "L" remains at zero.
- Open the SampleEditor -> change something and hit the "Close" button -> a dialog "Unsave changes..." will pop up and the user has to consent to discard the changes -> clicking "Ok" and reopen the SampleEditor by clicking "Edit Layer" again -> the same popup shows up again. I think the second one is a dud.
- When entering a fresh instance of the SampleEditor the value of the
EndFrameSpinBox
looks perfectly fine. But as soon as the mouse pointer enters theMainSampleWaveDisplay
it is reset to 0 bySampleEditor::getAllFrameInfos()
what causes some other oddities. The slider, however, stays at it's correct position. - The first value change in the Start, Loop, and End spinboxes is discarded and, instead, the slider is shown in the DetailWaveDisplay. It would be nice to update the DetailWaveDisplay as soon as the spinboxes have focus and make the first change affect the value as well.
But again: this is more a list of things I noticed that still need to be fixed and not a list of things you have to do for this PR to get merged. 😉
update(); | ||
mouseUpdateDone(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come you mark the state of the SampleEditor unclean once the user enters the MainSampleWaveDisplay using the mouse? This makes the "Apply Changes" not flat and indicates something has changed. Changes via drag should be already covered by the call of mouseUpdateDone
in mousePressEvent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How come you mark the state of the SampleEditor unclean once the user enters the MainSampleWaveDisplay using the mouse? This makes the "Apply Changes" not flat and indicates something has changed. Changes via drag should be already covered by the call of
mouseUpdateDone
inmousePressEvent
Hum, actually, it does not mark the editor as changed, only setClean()/setUnclean() does that. I should maybe rename mouseUpdateDone()
to something like mouseActionDone()
In addition, could you add all the changes in the UX to the ChangeLog once you rebased on |
Ahem, the ChangeLog... Those are my weak point... 😄 I just rebased this PR on development branch, see #1302. I would be glad if it could be merged soon, because I have interesting things to come, namely python bindings for the core library, UI as a shared library, with python bindings also, and it starts to make quite a big stack of commits 😁 See #1303 for the bindings 😀 |
Ok, second batch for the instrument editor, which become finally mostly usable 😁
On the technical side, wave widgets now track mouse movements continuously, this allow us to highlight envelope points before we drag / delete them, and see why editing start/loop/end frames in main widget is broken (final PR to come 😀 )
@theGreatWhiteShark if you could have a look ...
Regards.