I managed to create the patch, and ill post it here and the forwarded mail contains the information on what the patch does..
/Henrik Sourceforgeuser: hean01 <-----Ursprungligt Meddelande-----> From: SourceForge.net [EMAIL PROTECTED] Sent: 5/11/2008 2:07:54 PM To: [EMAIL PROTECTED] Subject: [ rosegarden-Feature Requests-2018387 ] Velocity Property Ruler not easy with chord Feature Requests item #2018387, was opened at 2008-07-15 05:50 Message generated for change (Comment added) made by hean01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=354932&aid=2018387&gro up_id=4932 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: matrix Group: None Status: Open Priority: 8 Private: No Submitted By: Flávio Luiz Schiavoni (schiavoni) Assigned to: Nobody/Anonymous (nobody) Summary: Velocity Property Ruler not easy with chord Initial Comment: 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 ---------------------------------------------------------------------- Comment By: Henrik Andersson (hean01) Date: 2008-11-05 14:05 Message: 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. ---------------------------------------------------------------------- Comment By: Henrik Andersson (hean01) Date: 2008-11-05 13:04 Message: 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.. ---------------------------------------------------------------------- Comment By: Chris Cannam (cannam) Date: 2008-11-05 12:17 Message: 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. ---------------------------------------------------------------------- Comment By: Henrik Andersson (hean01) Date: 2008-11-05 12:03 Message: 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... ---------------------------------------------------------------------- Comment By: Emanuel Rumpf (emrum) Date: 2008-11-04 20:17 Message: > 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? ---------------------------------------------------------------------- Comment By: Henrik Andersson (hean01) Date: 2008-11-04 18:28 Message: 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 :) ---------------------------------------------------------------------- Comment By: Henrik Andersson (hean01) Date: 2008-11-04 09:25 Message: 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... ---------------------------------------------------------------------- Comment By: D. Michael McIntyre (dmmcintyr) Date: 2008-11-04 02:03 Message: 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. ---------------------------------------------------------------------- Comment By: Henrik Andersson (hean01) Date: 2008-11-03 19:39 Message: 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? ---------------------------------------------------------------------- Comment By: Henrik Andersson (hean01) Date: 2008-11-03 16:08 Message: 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. ---------------------------------------------------------------------- Comment By: D. Michael McIntyre (dmmcintyr) Date: 2008-08-09 03:20 Message: 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. ---------------------------------------------------------------------- Comment By: Flávio Luiz Schiavoni (schiavoni) Date: 2008-08-08 17:06 Message: Logged In: YES user_id=2012615 Originator: YES Another screenshot self explained. File Added: Captura_da_tela-1.png ---------------------------------------------------------------------- Comment By: Flávio Luiz Schiavoni (schiavoni) Date: 2008-08-08 17:04 Message: Logged In: YES user_id=2012615 Originator: YES Ok, Some screenshots to get better. File Added: Captura_da_tela.png ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=354932&aid=2018387&gro up_id=4932 .
patch-hean01-20081105
Description: Binary data
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
