|
Next revision
|
Previous revision
|
doc:tips [2013/09/24 09:05]
michael created |
doc:tips [2013/09/24 11:51]
michael |
| |
| Maybe I'll come back and do all of this in one of my HTML tutorials, or maybe I'll do it on the wiki, or most likely I won't do any of it at all. I have so little free time these days. I've already blown out most of my time for today without actually getting to enjoy playing the damn guitar that I'm trying to write this score for. | Maybe I'll come back and do all of this in one of my HTML tutorials, or maybe I'll do it on the wiki, or most likely I won't do any of it at all. I have so little free time these days. I've already blown out most of my time for today without actually getting to enjoy playing the damn guitar that I'm trying to write this score for. |
| | |
| | **TRICK** The triplet-based MIDI file imported with funky properties on the notes, making them all triplets and yet not triplets. The way to clean up the melody (all quarter notes) and the bass (all dotted half notes) is to Select All -> Phrase -> Un-tuplet, then Select All and Ctrl+4 or Ctrl+2 Ctrl+. as appropriate. This takes care of that problem without hand hacking XML. |
| | |
| | The greater issue is that Rosegarden apparently mangles the import of triplets from MIDI, and doubtless while recording also. Worth investigating, I suppose, although there are 5,001 different kinds of weird tuplets in the real world, like 17 in the time of 64, and the most we could ever hope for is to handle triplets correctly. Even then, it would only be machine-generated triplets that were very precise mathematically, and not at all loose and human. It's probably a lost cause even bothering, is what I'm thinking. |
| | |
| | **NOTE** So apparently this problem has come up before, and there's already a way to deal with it from inside Rosegarden. Phrase -> Make Tuplet, check the "[x] Timing is already correct; update display only" box. |
| | |
| | Good news is this works perfectly for sorting out this mangled mess. Bad news is this function only works on one beam group at a time. Select 100 of them, apply, 99 to go. It looks like there is no way to avoid having to go into this dialog and set everything back up for every bloody triplet group. This would be a particularly obnoxious thing to hack into the XML manually, however, because every tuplet group needs an ID and so on and so forth. It would take me about as long to do all that as it would to jerk off the GUI 15,000 times. Sooooo... Let's try to make this make tuplet group thing iterative, shall we? |
| | |
| | ====== Bah ====== |
| | |
| | So TupletCommand is really cheap. It gets a segment and a start time and a list of parameters of what you're trying to make, then it modifies the first n events and bails out. It's not at all aware of selections, and can't be made to work on a selection without some pretty heavy lifting. |
| | |
| | Ideally it would take a selection, not a segment, and it would work on groups of n until it ran out of events in the selection. Don't make six triplets in one giant beam group, make a group of three, then another group of three, until you're done. |
| | |
| | I could do this, but it's really a tall order to solve a problem nobody else has ever complained about. |
| | |
| | I'm just going to suck it up and fix one group at a time. It's only 48 measures. |
| | |
| | |
