Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#390 Velocity Property Ruler not easy with chord

open
nobody
matrix (17)
1
2012-09-16
2008-07-15
No

When dealin with Chords is so hard to choose the correct velocity bar. Maybe it could be selected when the note is selected.

Flávio

Discussion

  • Logged In: YES
    user_id=2012615
    Originator: YES

    Ok, Some screenshots to get better.
    File Added: Captura_da_tela.png

     
  • Logged In: YES
    user_id=2012615
    Originator: YES

    Another screenshot self explained.
    File Added: Captura_da_tela-1.png

     
  • Logged In: YES
    user_id=663564
    Originator: NO

    I agree with this one. Another problem is that the rulers use a single-pixel red border to show which object is selected, and this is both inconsistent and difficult to see.

    Just because I agree does not mean this will be done anytime soon though, I'm afraid. We do have a user who is already supposed to be looking at issues like this, with some promise of future patches. It might happen. If it doesn't happen, it will probably take more than a year before anyone has a chance to look at this issue. Possibly longer. Make that probably longer. Probably between two and four years.

     
  • I agree with you and i have also this problem with Cubase SX etc.
    One simple developing task would be to highlight the bar as selected when the actual note
    is select in the matrix bar then enshure it's drawn in front of all velobars on same time.

     
  • Threw an eye onto the source and what i can see there is no (nice) way to communicate the selection between the ControlRuler class and the Matrixview, but i saw that the selection is internally stored within the MatrixView Class...
    A neat thing would be that the "Segment" had an EventSelection internal of the segments Current selection so NotationView/Matrixview and other editors etc. could share the same selection within same segment and also this opens an door for communicating which events are selected to others that implements the SegmentObserver interface, which could have (de)selectedEvent(Event *e) and then it would be easy to have ControlRuler which is a SegmentObserver to observe changes in selection and take action from that... im sure that other
    code could be interested into this thing.

    hmm think i missed something here i assumed that an note event is the same event that contains the actual velocity...

    anyways, any developer who want to give some response to this conclusion?

     
  • I've been thinking about this. I don't think having one selection that can belong to multiple views simultaneously actually strikes me as a good idea. I've been thinking about how I work with Rosegarden, and I very much expect one selection per view. I might have different selections inside the same segment in different views for different reasons. I think it would be hard to make this work so that it never got on my nerves, and not getting on my nerves is an important benchmark for any proposed change. It would be a lot of work to create something experimental that might well get shot down the first time it did something I didn't want to happen, which seems complicated to avoid.

    I'm all for some solution to the underlying problem of not being able to manipulate velocity very effectively for individual notes inside a chord though. Can you figure out a way do that without fundamentally changing how selections behave across views? If so, that seems like the least controversial approach.

    I think velocity is, in fact, a property of a note event, BTW. I'm not absolutely sure without checking, but I'm pretty sure. Velocity is different from the other rulers in this respect.

    You know, as far as that goes, since velocity is already different anyway, I wouldn't mind a special mode where velocity could be shown directly on the note heads, with some option to turn it back off. Hold some modifier key or something to move the velocity (instead of the pitch) up and down, probably with a little tooltip box to show the changing value as a number to go along with the color. That way it could work with exactly the same selection mechanism as the notation editor itself, and we could just ditch the velocity ruler entirely. The only thing about this approach that seems tricky to get right from a user perspective is replacing "draw property line" with something that would make sense directly inside the notation editor.

    Anyway, I hate to put the brakes on interesting new ideas, but this all sounds like way more than I want to figure out how to port across to the Qt4 branch. It would probably be best to think about this for now, and then actually do something about it when the new line of code is ready to build on. Probably, though I'm not saying I absolutely wouldn't consider doing this in the old KDE/Qt3 line of code. It rather depends on how involved it becomes, really.

     
  • Good points... hmm i like the idea of changing velocity on induvidual note in the actual matrixview but not a replacment for velocity working process, it might be an neat feature to the core functionality but not the actual solution to handle velocity, my first thoughts that i didn't mention was to use an observer pattern for EditView/ControlRuler to pass selection events between them, might be useful in the future for other events, or maybe replacing the semantics when adding and removing individual notes without redrawing the whole ControlRuler... anyway i havent looked deep enough to the code for this one
    so its more assumptions, but maybe this is the solution?

    But as i see the simplest solution would be that meta-key drag note up and down for changing velocity, keeps changes isolated to the matrix view... I'll give that a try...

     
  • Okej i went thru som semantics in the code and came up with a new tool velocity, it works like the resize tool in the matrixview,
    select the notes you want to change the velocity on, then drag up/down to add a delta to the notes existing velocity, the delta value ranges between -127 to 127 is displayed in the contexthelper while draggin and when mouse button is released the velocities of selected notes are updated,
    the updates of the values are done using macro so undoing changes are possible, i have some fixes to do before i create a inital patch for this new VelocityTool...

    This gives me a good workflow changing velocity systematic and also gives a quickfix on the problem chaing velocity on a chord note...

    I also looked into the sources for the velocity ruler and there is a Z on each item so somekind of ordering when draing items are availble
    the Z is incremented each time a controleritem is added and maybe a a function thats takes an eventselection as an argument in the controlruler
    which implementation ensures that the controlleritems matching the events in selection has the highest Z ordering might be a fix..
    I dont know if the VelocityController is accessible from matrixview but i'll be soon know about this :)

    i need some feed back onto this so i dont spend to much time into something that noone wants :)

     
  • Emanuel Rumpf
    Emanuel Rumpf
    2008-11-04

    i need some feed back onto this so i dont spend to much time
    into something that noone wants :)

    Holla ! I want it. I'm not None ! :-)

    I just discovered, that it's possible to select a single velocity and press [ (AltGr + 8 on german keypad) to send it to the back, making velocities below appear. Although that's not the fastest and most intuitive.
    You sometimes have to press many times before something happens. That's why I thought that function was broken.

    If we had a method for showing the velocities of overlapping notes at once... any ideas how to?

     
  • Now i need some help, the new velocitytool is implemented and works like a charm, it uses the
    ChangeVelocityCommand to update the velocities using a delta, but there is something wrong..

    ChangeVelocityCommand.cpp

    // round velocity up to the next multiple of delta
    velocity /= m_delta;
    velocity *= m_delta;
    velocity += m_delta;

    ^ What is this, why round the delta by this?
    lets take this example...

    vel=100
    m_delta=-32

    I would expect a change of velocity to 68 but with that roundings it ends up with 64...

    Also i tried a Z ordering fix on the ControlRuler wich works out nice, Z is set to 60+Height and makes the highest bars draw back and the lowest in the front...

     
  • Chris Cannam
    Chris Cannam
    2008-11-05

    I can't completely explain that bit of code, even though I wrote it.

    I imagine the justification was that it works as a "snap to grid" rather than a pure increment/decrement -- for example if delta is 10, it's somewhat tidier to make the command always target a multiple of 10 than to go up to 127, then down to 107, 97, 87 etc.

    It is probably a good idea to leave the default behaviour alone, just because it's what we've been using for some time, but do feel free to make the command able to work in the way you expect (for example by adding a flag) as well.

     
  • Consider it as done... and now it works like intended

    added a bool argument to the ChangeVelocityCommand constructur and a default value for always rounding, except specified false that is true relative..

     
  • Ok heres comes a patch:

    Addition:
    New velocity tool in the Matrix editor named velocity, works like resize tool but you change the velocity on single/selected notes by moving mouse up/down the amount is showed in the helpcontext (statusbar)

    Changes:
    - Fixed ChangeVelocityCommand constructur for bypassing rounded velocity
    - Change the way Z ordering is done in ControlItem (This will probably break those [ ] haven't check that one yet), this affects all ControlRulers, and enshures that a high bar never is drawn in front of a lower bar, making them disappear.