From: Dan M. <da...@gm...> - 2009-07-22 18:15:53
|
Is there a way to insert a rest in the middle of a segment, and have the subsequent notes "shift to the right"? Currently, entering a rest in the middle of the segment seems to overwrite a range of notes (with silence). Similarly, is there a way to change a note's duration, and have subsequent notes shift to the right? Currently, double-clicking a note with the pointer tool and changing its duration in the dialog that pops up creates a new overlapping part (I am guessing that's what the orange segments in the yellowish strip above the staff signify; tooltips would have helped...) The score afterwards becomes uneditable, since there are now effectively two "parts" occupying the same staff. It's impossible to tell which note / rest belongs to which "part". There is no color code, no hints, nothing! (I get the same "multiple uneditable parts on a single staff" effect when importing MIDI, only on a grander scale). Thanks, Dan |
From: Jani F. <j.f...@gm...> - 2009-07-22 18:51:41
|
2009/7/22 Dan Muresan <da...@gm...> > Is there a way to insert a rest in the middle of a segment, and have the > subsequent notes "shift to the right"? Currently, entering a rest in the > middle of the segment seems to overwrite a range of notes (with silence). > One way I know is to select the notes first and then drag them right (click and hold). A rest is inserted automatically. > > Similarly, is there a way to change a note's duration, and have > subsequent notes shift to the right? > In notation editor, menu Adjust->Rescale->Double Durations? -Jani |
From: D. M. M. <mic...@ro...> - 2009-07-22 22:41:44
|
On Wednesday 22 July 2009, Dan Muresan wrote: > Is there a way to insert a rest in the middle of a segment, and have the > subsequent notes "shift to the right"? Currently, entering a rest in the > middle of the segment seems to overwrite a range of notes (with silence). Probably the closest you could come to accomplishing this, in theory, is to create a rest in some empty place somewhere, cut it, mark your paste point, and use Edit -> Paste... (not Paste, but Paste...) and then choose "move existing events out of the way (open-n-paste)" from the available options. In theory, but in practice, I just fooled around with this and have found it to be pretty useless for anything except making a mess of things. The best controlled way to do this would be to either manually cut/paste the notes out of your way or to work at the segment canvas level and cut the segment in two, move one half, and recombine them to incorporate the silence. You could also use the range cut/paste mechanism to move an entire slice of the composition (although this, too, has always been buggy.) > Similarly, is there a way to change a note's duration, and have > subsequent notes shift to the right? Other than the rescale option suggested, no. > The score afterwards becomes uneditable, since there are now effectively > two "parts" occupying the same staff. It's impossible to tell which note > / rest belongs to which "part". There is no color code, no hints, nothing! Rosegarden doesn't have any idea which notes belong to which part. This is a problem we absolutely do not have the brainpower to solve, so users are forced to resolve these overlapping voices into separate overlapping segments manually. It's a very tedious and unpleasant process, but we can offer no other solution. This isn't a matter of time and waiting, unless we're waiting on some really deep thinking dedicated music math guy to show up and provide the algorithm. We can't write it. Full stop. > (I get the same "multiple uneditable parts on a single staff" effect > when importing MIDI, only on a grander scale). Indeed. When recording MIDI too. It's greatly helpful if the source material only has one voice at a time, or at most two very clearly delineated voices that can be split at a certain pitch point (such as one rhythm per hand in a piano part.) The best we can do here is spotty at best. It's much easier to just work with source material and recordings that already have all the parts split out into separate voices. If you have something like a piano part with four distinct voices moving in two hands, you might as well just draw it all by hand, because you'll probably never sort the mess out any other way. -- D. Michael McIntyre |
From: Dan M. <da...@gm...> - 2009-07-23 02:47:07
|
> The best controlled way to do this would be to either manually cut/paste the > notes out of your way That's what I currently do -- cut to end of segment + append rest + paste. This seems like a simple operation which could be hard-coded into Rosegarden. At least for non-overlapping notes (single "part" staffs), I don't see what complications could arise. Alternatively, a simple "macro" system could let users accomplish trivial automation... I am talking about simple record-user-actions (i.e. keyboard and menu events) macros, not scriptability or anything clever like that. > Indeed. When recording MIDI too. It's greatly helpful if the source material > only has one voice at a time, or at most two very clearly delineated voices My material had a single "voice", but since some notes were sustained (even after subsequent notes started), Rosegarden imported an (uneditable) multi-part staff. I guess I have to play staccato to appease the import tool? An import option to cut old notes when new notes start could be an easy way out. Or maybe quantization can already do this? > have all the parts split out into separate voices. If you have something like > a piano part with four distinct voices moving in two hands, you might as well > just draw it all by hand, because you'll probably never sort the mess out any I guess; but at least for a single-voice melody line, one should not have to stoop to inputing notes with the mouse when a MIDI recording is available -- it seems clear how to handle this case. Thanks, Dan |
From: D. M. M. <mic...@ro...> - 2009-07-23 04:32:01
|
On Wednesday 22 July 2009, Dan Muresan wrote: > That's what I currently do -- cut to end of segment + append rest + > paste. This seems like a simple operation which could be hard-coded > into Rosegarden. At least for non-overlapping notes (single "part" > staffs), I don't see what complications could arise. The biggest one I can think of is the layout overhead of performing the operation. Let's say we have an "insert here and scoot everything to the right" function built out of a command to run a select command, a cut command, and a paste command. It would need to run all three each time you inserted a note, and then the layout would need to recalculate itself. Not so bad for, say, 50 bars of music, but if you try inserting a note at an arbitrary point in the middle of, oh, say a violin part from Beethoven's 9th symphony, then you're probably going to be sitting there a minute or two every time you insert a note. I've worked on full length pieces before, and the layout overhead can be quite dramatic and crippling. It's really more practical just to take the hit once, instead of incrementally, so an "insert n amount of empty space here" function makes a lot more sense. Another problem with the whole idea is that moving things by an arbitrary amount of space can frequently lead to complete chaos when notes cross barlines. I base this concern on experience with moving segments by arbitrary amounts with the shift key. This could happen very easily when moving things incrementally, one note at a time, and once that kind of thing happens, it's just misery to deal with. If we had this select/cut/paste thing, I'm not sure if I'd actually trust it not to do more harm than good. It could definitely be useful, and it could definitely cause misery. The proportion of one to the other is the only thing that remains to be seen, really. > Alternatively, a simple "macro" system could let users accomplish > trivial automation... I am talking about simple record-user-actions > (i.e. keyboard and menu events) macros, not scriptability or anything > clever like that. The first idea would be a lot easier to implement in this case. > My material had a single "voice", but since some notes were sustained > (even after subsequent notes started), Rosegarden imported an > (uneditable) multi-part staff. I guess I have to play staccato to > appease the import tool? It helps, and if it makes you feel any better, I'm a habitual legato player who is always having to go in and sort out this problem by hand myself. > An import option to cut old notes when new notes start could be an > easy way out. Or maybe quantization can already do this? No it can't, and that's not code I even try to work on, but the idea has merit. Some kind of "reduce this part to one voice" function that might at worst collapse some grace notes or whatever out of existence. It could get tricky in a hurry though, because of chords. I think chords are probably the root of a great many of our problems. Anyway, all good theoretical what if stuff here, but I do want to be clear that the current development line of Rosegarden still has many very serious and crippling problems, and just getting it as close to working as well as 1.7.3 did is our top priority, and probably the only priority we have time left to consider if we have any slight remaining hope of releasing this thing on schedule in October. -- D. Michael McIntyre |
From: Darcy K. <dar...@sy...> - 2009-07-23 22:47:42
|
I would prefer that no information gets lost, so, instead of collapsing notes out of existence, perhaps drop them onto another layer or track? Kind of like a "split to single voices" tool. D. Michael McIntyre wrote: > No it can't, and that's not code I even try to work on, but the idea has > merit. Some kind of "reduce this part to one voice" function that might at > worst collapse some grace notes or whatever out of existence. > > > |
From: Al T. <big...@sb...> - 2009-07-23 06:00:24
|
Dan Muresan wrote: > Is there a way to insert a rest in the middle of a segment, and have the > subsequent notes "shift to the right"? Currently, entering a rest in the > middle of the segment seems to overwrite a range of notes (with silence). > > Similarly, is there a way to change a note's duration, and have > subsequent notes shift to the right? Currently, double-clicking a note > with the pointer tool and changing its duration in the dialog that pops > up creates a new overlapping part (I am guessing that's what the orange > segments in the yellowish strip above the staff signify; tooltips would > have helped...) > Before you insert the note or rest, split the segment at that point, select the right one, and drag/move it to the correct time. I don't know of a sequencer that would automatically move everything after an insert. Since most people work with polyphonic instruments, it would make things virtually impossible if everything moved in response to a duration change or event insertion. -- Check out the website I've been cobbling together. It will never be done, but it's a start: http://www.thompson.linksysnet.com/Lateralforce/ My blog, with commentary on a variety of things, including audio, mixing, equipment, etc, is at: http://audioandmore.wordpress.com |
From: Dan M. <da...@gm...> - 2009-07-23 10:58:36
|
Thanks. To clarify some small points: > in the middle of, oh, say a violin part from Beethoven's 9th symphony, then > you're probably going to be sitting there a minute or two every time you > insert a note. You're right, that would be insane. The use cases I had in mind were: * inserting a note/rest, or altering the duration of an existing one, in the current bar (or at most in the previous bar) * inserting a number of bars in the middle of a long composition to add an extra section (subsequent notes would not be moved around in their bars, or forced across bar boundaries). Some of the previous replies have described more effective techniques than cut/paste, so thanks to everyone who chipped in. >> Alternatively, a simple "macro" system could let users accomplish >> trivial automation... I am talking about simple record-user-actions > > The first idea would be a lot easier to implement in this case. Not that I want to push the macro idea, but since this should not have appeared so complicated, let me explain. There would be a menu item "Record macro". When selected, RG would record all keyboard input and menu selections (but no mouse events) into an event buffer. At some point the user would select another menu item, "Stop macro", and the buffer of keyboard / menu events would be saved under some name. Later, the user would select "Perform macro" (and the macro name) and the exact sequence of keyboard/menu events would be played back into RG's event handler as if they came from the UI. Nothing fancy (like scripting, or interpreting mouse action on the score). Then again, not knowing the architecture of the code, maybe this *is* complicated. > It could get tricky in a hurry though, because of chords. I think chords are > probably the root of a great many of our problems. I understand. But even just enabling the user to enter melody lines (without chords) using a MIDI keyboard would be a huge improvement over mouse input. > and crippling problems, and just getting it as close to working as well as > 1.7.3 did is our top priority, and probably the only priority we have time Of course :) Maybe I should enter some of these things in the Sourceforge Tracker / feature requests. Best, Dan |
From: Julie S <msj...@ya...> - 2009-07-23 12:57:19
|
Hello Dan, Concerning your macro idea, Unfortunately, many actions and sequences of actions require the use to place the playback marker, or select events. That definitely, makes everything more complicated, specially if the macro starts with a playback marker command then wnats a selection to work with. No this definately is more complicated then an event logger. We have a GUI that relies heavily on user input. But, I'm not trying to shoot the idea down, just trying to be realistic that this is not that simple. The interface you propose sounds simple enough, but under the hood is a different story. Dan, > I understand. But even just enabling the user to enter > melody lines > (without chords) using a MIDI keyboard would be a huge > improvement > over mouse input. Well to be honest I never watched what RG does during MIDI for notation. Hmm... I'll have to try it out when I get a moment. I typically just record from the main window, and edit later. I don't really care what the notes look like, since I typically am trying to record a performance. But, if your trying to do notation, I'd imagine your playing style would need to change considerably. Earlier you wrote: An import option to cut old notes when new notes start could be an easy way out. Or maybe quantization can already do this? A monophonic interpreter could be very cool. I know I can set my keyboard to be monophonic. Sometime that is very useful. A import option might not be the best option, since RG has enough on its plate just trying to decide what belongs where and there would be even more potential for RG to get it wrong and users be frustrated. The more elegant way would be where the user puts all relevant events in a segment, then chooses the monophonic quantizer. I can envision the interface and the implementation fairly easily. Some basic defaults would be to play an event until another note event occurs or a distinct rest is encountered. When two notes occur on or about the same event time play the loudest note. A dialog box to adjust the parameters. This is definitely doable. But isn't the magic wand you where looking for. The user would need to clean up the segment enough to have all notes needing to be considered all in one segment. But, whose going to code I? I certainly don't have the time. So, we just have to throw it on the heap of ideas out there and wait for time, resources, and will to meet. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2009-07-23 14:25:26
|
On Thursday 23 July 2009, Julie S wrote: > Unfortunately, many actions and sequences of actions require the use to > place the playback marker, or select events. That definitely, makes > everything more complicated, specially if the macro starts with a playback > marker command then wnats a selection to work with. Something meant to work "from here to the end" doesn't seem that hard. Do a MacroCommand to call the equivalent of slotSelectToEnd() or whatever, then a CutCommand, then a PasteCommand after determining where to move the insertion point to. Put the MacroCommand on the undo stack. The last bit, working out where to paste, is the only part that seems terribly fiddly to get right, and I'd be a whole lot more worried about overhead and basic usability (ie. extreme slowness and a tendency to mutilate notation if not used very cautiously) than actually getting something like this started. The keyboard command macro approach OTOH seems much harder, because I have no idea off the top of my head how to make it work, or what kind of pitfalls I might expect. It would involve a lot more scratch work then. > A monophonic interpreter could be very cool. I know I can set my keyboard > to be monophonic. Sometime that is very useful. A import option might not > be the best option, since RG has enough on its plate just trying to decide > what belongs where and there would be even more potential for RG to get it > wrong and users be frustrated. I think the more likely solution would probably be a filter to run after the fact, like Split by Pitch. Not something that tried to work on the fly while Rosegarden might be doing a large number of other things simultaneously. This one I have no idea where to start on either, and the biggest problem isn't cutting long notes off when another note starts, but *not* cutting long notes off when another one starts if those long notes are all part of a chord whose notes are separated by some small space of time. That happens very frequently in real life, and that one puts me firmly into head scratching territory. The difference here is that individual voices/parts don't *have* to be monophonic, just monorhythmic, if that's a word. If you have two quarter notes in the same part, that's a chord. If you have a quarter note in one part and two 8th notes in another, that's two different concurrent voices occupying the same segment. Forcing these filtered segments to be monophonic would simplify things enormously, but it would never fly in the real world. A simple rolled chord could easily become a useless string of bizarre double dotted 64th notes or whatever. That means there either has to be some cutoff threshold, which could easily go wrong a lot of the time (forcing you to pick the best compromise by hand, the one that gets the largest amount of your part rendered correctly through a fiddly process of try and undo) or the code has to be smart enough to look both ways and make intelligent guesses about this sort of thing. It may not be as complicated as I fear, but it seems almost as hard as the problem of working out which notes belong to which voices. Anyway, it's all firmly in the territory of code I wouldn't attempt to do myself unless Chris dropped off the face of the earth for a long time first. -- D. Michael McIntyre |
From: D. M. M. <mic...@ro...> - 2009-07-24 01:56:45
|
On Thursday 23 July 2009, Dan Muresan wrote: > Not that I want to push the macro idea, but since this should not have > appeared so complicated, let me explain. It appears complicated to me because I have no clue off-hand how to go about recording this event buffer. I'd have to go on a shopping expedition and pore over API docs looking for ideas and inspiration. The other idea is something where I understand the gist of how it should all be strung together out of off-the-shelf components, and it's only a question of details. Some big details, and some big fiddling, but I'd know exactly where to begin. It makes a difference. > I understand. But even just enabling the user to enter melody lines > (without chords) using a MIDI keyboard would be a huge improvement > over mouse input. There's step recording too, incidentally. But still, yes, I get where you're going with all this, and I'm largely agreeing with the underlying ideas here. Which is not the same as saying "sure, I'll code that right away." Honestly, I'm not sure where I'd begin on such a beastie, because this is very firmly in Chris's usual territory. He's the closest we have to a dedicate music math hacker, and he's on vacation at the moment. > Of course :) Maybe I should enter some of these things in the > Sourceforge Tracker / feature requests. Indeed, and I hope I don't have to put them at "send us the patch" priority five years from now. I really do hope that. Right now, with so many more mundane things to grind through standing in the way of that release, this really isn't the time for big thinking stuff, but we have a tendency as a project to never get around to the big thinking stuff for one reason or another, and this is one areas where I'd like to hope the release after next might finally be able to address some of these niggling problems. Up to now, "not impossible" has been the bar, and a lot of things are "not impossible" but an incredible pain in the ass to accomplish. I want to raise that bar badly, but my work in that direction got interrupted by having to waste what will have been close to two years on this Qt4 port. Some great things are coming out of this port, and it's more than a mere exercise in moving sideways, but we are not moving very far forward in proportion to the number of hours we've had to burn to get there. This has been a very expensive endeavor. Very expensive. I'm glad you're taking all of this with a good attitude. I know it can be very frustrating when we have to say "yes, these are great ideas, but hurry up and wait." Unfortunately, that's all we can do at the moment. I really can't get sidetracked just now, or an October release is completely impossible, instead of merely improbable. I think on balance though, Rosegarden should start to make a lot of real progress on these issues in 2010 and beyond. I have traditionally tried to avoid as much development work as possible, and do anything else, but this port has forced me to just bulldoze my way through the obstacles, and get it done, because nobody else will. I'm a vastly better developer than I was a year ago, and I'm going to be taking on more and more challenging problems in the years to come. In the meantime, we appreciate your patience. -- D. Michael McIntyre |