|
|
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
doc:tips [2013/09/24 10:35]
michael |
doc:tips [2022/05/06 16:07] (current)
|
| |
| 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. | 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. |
| |
| |
|
|
