# Tempo/time signature markers: fixed manual time editing when project measure offset exists
# Time signatures: fixed inserting and snapping when time signature denominator is not 4
+ Time signatures: preference to allow mouse editing of time signature position to create partial measures in the previous time signature
+ Time signatures: time signature changes that truncate the previous measure are marked with "*"
+ Tempo envelopes: less chaotic editing when there are linear tempo transitions
# JS: more tweaks/bugfixes
This one is still in there but thanks for tempo love!
Quote:
Originally Posted by musicbynumbers
If you open up the master tempo map (as a separate envelope), create a time selection then use the envelope's fader to create new tempi at both the start and end of the time selection you get craziness happening at the end area with new tempi being created every time you adjust the fader.
I'm not sure if there is actually a way or use for this anyway with tempi right?
You can see that the red notes velo's can be selected with the mouse one by one... but not with a 'rubber band' [marque]
...that is a rt. clk and drag. And you can see it does work on other notes is they are included but still misses the red notes.
I think it's kinda important that it work nicely even [especially] on the smallest bit at the top of the lane...
Whachatink?
Well here's an interesting bug for you:
Set a couple of time signature markers in an empty project, visibly apart. Edit the first one to be a gradual tempo change; it slides a bit to the right. Set the ruler to musical measurements for maximum effect. Drag it back where it should be. Now stare in befuddlement at the screen. Maybe say, "wtf?!" Ok well it's not all that dramatically exciting, but I'll be damned it if ain't a bug.
Btw, I'm sure I've complained of this before, but there is still a problem with copying regions containing midi items whenever gradual tempo changes exist. The contents of the midi items in the resulting region are almost always wrongly shifted. Some survive, but I can't predict which ones or why and the tempo markers don't copy reliably with this method either. Just pointing it out since devs seem to be focused on tempo bugs for the moment...
As Eric mentioned, the trick is to include the top of velocity/CC bars inside the marquee. Thinking behind this feature is that you can select ranges of velocity/CC values with the marquee (eg only your high velocity notes, leaving out the lower ones or vice versa.
You can start the marquee inside the horizontal separator bar above the velo lane, or marquee upward to get the highest values:
I don't think there is an option to switch it off.
It's been working like this since CC selection was implemented (v3.something), please let's keep the pre-release forums for issues related to the current pre version at hand.
Yeah that thing really irks me... I wish we had a mouse modifier to override that marquee behavior, so that everything that marquee even TOUCHES gets selected...
However I can say with confidence, that the current behavior busts my balls when I'm editing sustain pedal and generally all events below the value of 8.
Yeah that thing really irks me... I wish we had a mouse modifier to override that marquee behavior, so that everything that marquee even TOUCHES gets selected...
Agreed. That and/or allow a larger zone at the top of each CC bar to be selectable. Other hosts draw a selectable handler on the top of each bar.
You can see that the red notes velo's can be selected with the mouse one by one... but not with a 'rubber band' [marque]
...that is a rt. clk and drag. And you can see it does work on other notes is they are included but still misses the red notes.
I think it's kinda important that it work nicely even [especially] on the smallest bit at the top of the lane...
Whachatink?
I right vlivk on the Piano Editors note to grab the notes I want re arranged, but it's usually just kick and snare.
But it is a PITA doing zippered snares, so I inset 128th notes, then use the envelope in the MIDI Item for the dynamics.
Thanks Devs as I like watching the grid follow my markers now wherever they go, and the extra options have enabled me to remove that damn dongle, and use Spubase as a Jagermeister Coaster.
Yeah that thing really irks me... I wish we had a mouse modifier to override that marquee behavior, so that everything that marquee even TOUCHES gets selected...
One of my CAD programs works like this:
If you start the marquee on the RIGHT and move LEFT it selects anything it touches.
If you start the marquee on the LEFT and move RIGHT it selects anything it encompasses.
However I can say with confidence, that the current behavior busts my balls when I'm editing sustain pedal and generally all events below the value of 8.
I guess I misunderstood you. If you meant a marquee function which would select all events that occur on the horizontal range of the drawn marquee, disregarding whether a bar was actually touched or not, then I'm with you, even though it can be worked around using time selection instead of marquee.
I read it as "an event bar would need to be touched somewhere to get selected". That wouldn't change anything at all with very small values, and it would be inconsequential (all high value events in the area would always get selected, but not all low value events), sort of like a high pass filter for marquee selection.
Actually I don't have difficulties selecting low value events with the current function:
but I do like Evan's proposal of a small zone on top of event bars a lot. It would serve as a margin helpful for marqueeing both kinds of extreme values and also help with grabbing minimum values, which is the finicky part for me - I often select it and then swipe it so I have a grab-able bar... even though it went nice in the above screencast - I was just lucky this time .
Still, I find this isn't the right time to discuss it it in the pre-release thread. I'd prefer if people concentrated on the timesig/tempo stuff (that's always been over my head, so I can't really help, but would love if they get it right, so even a dumbnut like me can handle it) and the other news of the current releases. If we want to discuss it further I propose to create a thread (or find an existing one) over in the forums. I'll gladly move the posts regarding CC and velocity handling there.
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by gofer
[...] Still, I find this isn't the right time to discuss it it in the pre-release thread. I'd prefer if people concentrated on the timesig/tempo stuff (that's always been over my head, so I can't really help, but would love if they get it right, so even a dumbnut like me can handle it) and the other news of the current releases.
Here's one that has not been addressed at all yet, and imho is the worst design flaw in REAPER, definitely the biggest related to tempo: we still can not change tempo while playing using a musical timebase, or hell breaks loose (which also implies REAPER can not follow an external sequencer's tempo accurately). Since schwa recently confirmed this to be incorrect and unexpected behavior, I'm keeping my fingers crossed to see any changes.
Quote:
Originally Posted by gofer
If we want to discuss it further I propose to create a thread (or find an existing one) over in the forums. I'll gladly move the posts regarding CC and velocity handling there.
Please do. This is a major workflow impediment. Another possibility: add a few 'empty' pixels around the values, as is done for adjacent track envelopes. With REAPER's envelope lanes it is much easier to marquee select ('lasso') all values including the extremes than with its MIDI event lanes.
Btw, the issue does not affect only velocity and CC but *everything* in MIDI item event lanes.
I'd also like to see an option to edit 14 bit values using MSB and LSB bytes in a *single* value from 0 to 16383, instead of seeing separate MSB and LSB values. Currently it is almost impossible to perform any useful editing on them at all.
Thanks guys for clearing me up on the velo bar marque selection thing... and yes, I can see how it works now and it's not too bad.
If I start the margue from below and drag it up, it makes it more easily possible to get those 127 velo's
Now I'd have to say it works pretty well and it was a misunderstanding on my part [sorry 'bout that]
The idea of a px or two of 'free space' above the max values might be a good one... but now that I just know to drag the 'box' upward it may not be needed.
Sorry for dumping in the pre release thread, but thought is was a 'bugger'... Ollie, or MOD's feel free to move it.
gofer: "...please let's keep the pre-release forums for issues related to the current pre version at hand."
gofer is offline Report Post Reply With Quote
gofer and all... listen, sorry I only thought it was something broken in the current pre...
Now I find a couple other things that seem broken in the Midi Ed. Actions... should I not mention them here? If not, then where?
Location: Near Cambridge UK and Near Questembert, France
Posts: 22,754
(grin, holding up banner) Wot we wont are MIDI luv. when do we wonnit? NOOOOOW!
Can I point you all in the direction of my thread in MIDI and other stuff called 'New way of looking at MIDI stumbling blocks'?
I would love some kind of reaction to the Amiga screen shots posted there, even if it is only scorn and derision....
ctrl + shift + horicontal drag, linear style, snap disabled
1) Latter points (unselected) are moving
2) Second selected point is moving relative to beat-position
3) Tempo-points are snapping to grid while snap is disabled
It would be nice if we could edit tempo envelopes by dragging vertical edges left/right. Currently you can only drag horizontal edges up/down but, for example when tempo mapping variable tempo recordings, it would be more accurate and intuitive to drag the vertical edges left/right.
As pre8 says, there are some difficulties when adjusting time-marker and using linear style:
1) In this case there's a bug giving point 3 a wrong value (it should increase, not decrease. (Point 4 remains it's beat-position as it should))
2) On the above example it's now impossible to right-click point 3 (see rpp)
3) The question, regardless of this bug, is: How should Reaper handle this?
I'd say as a default, regarding this and linear style, Reaper could
- add two tempo-points, one one frame before the time signature, one one frame behind point 3 , then altering the envelope segment.
This would however cause an issue if mouse-up, the tweaking again, because then the time-sig would have two new points before itself.
- add one point, one frame after point 3, setting it square and adjust that. (Maybe point 3 would need to be set square as well.)
It would alter the tempo-line in an maybe unwanted way, but would maybe be the best alternative.
- or leave it as it is.
Then an FR: Wouldn't it be nice to be able to select one or more points before the time-sig. Then shift-dragging the time-sig would adjust the selected points ?
I hope this is not the wrong place for it , but i have never seen these actions before and I thought they may be new?
Doesnt this show a sort of "proof of concept" of selcting midi events by specific criteria, and then modifying them in MULTIPLE midi items frome the arrange window? Wow what a sentence^^
And then would i be wrong in assuming..makes an ass out a me^^....that its now possible to have a "Transform" window where u could enter ur selection criteria and also choose how u want ur editing implemented across mul. midi items from the Arrange window? I hope that makes sense.
Hi everyone
Now that we are getting ruler love, wouldn't it be great to be able to snap to frames, or seconds? Now we are ONLY able to snap to beats, which is hard when you are doing stuff for video.
The 60 bpm workaround is not good when you have music AND sfx in the same project, which is how lots of us work here.
Is there anything we can do about it?
Thanks a lot, I don't post much here, but am busy using Reaper a bunch of hours a day
Well here's an interesting bug for you:
Set a couple of time signature markers in an empty project, visibly apart. Edit the first one to be a gradual tempo change; it slides a bit to the right.
I'm not seeing this. For example, say you have these tempo changes:
If you change the 2nd tempo change to a gradual transition, the following tempo change will move to the right:
Which is correct, because the tempo now transitions from 120 to 90 between 2.1.00 and 3.1.00. The average tempo for that measure is now 105, rather than 120, so the 3rd measure starts later.
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by schwa
I'm not seeing this. For example, say you have these tempo changes:
If you change the 2nd tempo change to a gradual transition, the following tempo change will move to the right:
Which is correct, because the tempo now transitions from 120 to 90 between 2.1.00 and 3.1.00. The average tempo for that measure is now 105, rather than 120, so the 3rd measure starts later.
I don't think it is correct. It only looks that way if you look at it from an inappropriate perspective, namely absolute time. But it's not a bug. It's only pointing out a related major design flaw.
It can only be correct if the timeline does NOT properly reflects the *musical* timebase. And the fact that the timeline does not reflect musical time can only lead to the conclusion that REAPER still is not taking musical timebase seriously.
In musical time, for this example, the 3rd measure still does *not* start later in musical time, it is still the exact same beat. So I see no reason at all to move it to the right. Much like I don't see why the entire display needs to zoom/unzoom on changing the tempo. The only thing that should change visually in this example is the absolute time value indication (changing from 0:05.000 to 0:05.285).
The only thing that should change visually in this example is the absolute time value indication (changing from 0:05.000 to 0:05.285).
I am not sure I get your point. You say that if, for example, I have two 4/4 measures: the first one is 120 bpm and the second one is 240: both should visually have the same *visual length* in reaper? Like this:
^^ IMO - yes - if the ruler is beat based then faster tempo sections should show the same physical length on the ruler. If the ruler is time based then it should show a shorter length for the faster bars.
think of the ruler as if it was a score of music in a single horizontal line - you would not expect faster tempo sections to appear to be 'shorter' in physical length on the page would you?
^^ IMO - yes - if the ruler is beat based then faster tempo sections should show the same physical length on the ruler. If the ruler is time based then it should show a shorter length for the faster bars.
This is a nice idea, but what happens when you select both beats and time to be shown in the ruler?
If you plan on removing the "zoominess" of tempo changes, at least leave it as an option.
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by miche
I am not sure I get your point. You say that if, for example, I have two 4/4 measures: the first one is 120 bpm and the second one is 240: both should visually have the same *visual length* in reaper? Like this:
instead of how it's now:
Yes. If you want the horizontal axis to represent *musical* time, there is no reason at all to have different lengths for the exact same *musical* length (exactly one bar, in the exact same time signature).
My motivating example is simply changing the tempo for any project using musical timebase, regardless of time signature changes and pre-programmed tempo changes. There is no reason for changing the display (rescaling horizontally) when changing tempo.
I can see how some 'mixed' mode between absolute timebase and musical timebase would make a lot of sense as well. But it does not make any sense at all to have no way to just show stuff using the musical timebase, while the user has explicitly told REAPER that he *wants* to use a musical timebase for the entire project. That just looks like a textbook example of "premature optimization," and a pretty bad one if you ask me. If the user has told REAPER to use musical timebase, and is editing, for example, a MIDI part of four measures, and then changes the tempo from 120 to 100 BPM, why would the display have to be adjusted automatically, without any option not to do so?
v4.23pre9 - May 9 2012
but thanks for tempo love!
it never did! other stuff came up instead tonight but "one of these days..." 
Linear Mode
