|
|
|
08-18-2009 02:14 PM | ||
|
||
Some screenshots?
|
08-18-2009 02:48 PM | ||
|
||
Quote:
|
08-18-2009 02:48 PM | ||
|
||
...It might help if I remembered to post the link, right? Sorry--here it is:
http://img35.**************/img35/9747/reaperd.jpg |
08-18-2009 02:59 PM | ||
|
||
Ok, I agree. Reproduced too. Not cool!
|
08-22-2009 04:28 PM | ||
|
||
Two people couldn't confirm this bug? Really? You two lucky folks can record volume automation between +6 and +24 and get a nice pretty roller-coaster in the lane? Please let us know what your automation and fader range settings are so that we can duplicate your un-bug-ness.
|
08-24-2009 08:04 AM | |||
|
|||
This is nothing new. It has been so for many versions. I agree that the automation curve should echo the position of the fader in visual terms. That is certainly what I would like to see.
Eg. if a vertical fader of a certain fader length could be placed next to an automation lane with the same height, the automation on that lane should accurately reflect the position of the fader. The question is... is this a bug, or is it by design? |
08-24-2009 08:19 AM | |||
|
|||
definitely a bug, by "design" would means bad design... so a bug anyway.
I never noticed it, i think only volumes (track or plugin volumes) are affected by this issue because of their range that can go "hot". |
08-24-2009 08:46 AM | ||
|
||
Quote:
Some features/lack of features are a matter of preference--there is an upside and a downside; some like it and some don't. This issue, on the other hand, does not have an upside. (Or does it?) If there are users who cherish the fact that fader rides above 0dB look like straight lines in the automation lane, speak up. We'll move this out of the tracker and have a conversation about it. However, I have strained my imagination, and cannot think of anything even remotely useful about visually-rendered automation curves that look different from the values they represent. For me, this is not just a bug--it is a deal-breaking bug. I am a mostly-audio person, and volume automation is a crucial feature. |
08-25-2009 04:31 AM | |||
|
|||
08-25-2009 05:20 AM | |||
|
|||
I suffer A LOT to having 6 db in one half of the vertical space while, like Pipeline has said : "Everything below around -30dB (around 30% of the fader travel) is represented in around 3% of the envelope at the bottom of the lane".
Think about what it would be if you could see the points above +6 db with this curve ! The simpler option would be to link the fader's curve, that can be more or less log or linear, to the enveloppe curve that is actually invariable. By the way, there is a graphic bug since a few versions : when I shift-drag the volume line at the top of an item, before I saw the db value. Now as soon as the mouse pointer is not above the item, the db value disappears. |
This petition for a change to Awaiting Feedback was rejected
03-26-2010 03:38 PM
|
|||
|
|||
Almost posted a new report, but this one is too closely related. There are several envelope inconsistensies in the ReaPlugs (still in Reaper 3.4.) that actually prevent me from using automation:
ReaComp: - release goes from 0-200ms as fast as it goes from 4900-5000ms. - ratio (1 > 2 = 91 > 92) - hi-pass (0 > 220Hz = 19780 > 20000) - attack, RMS size, ... - treshold should be more linear (now: -inf > -33.2 = -0.5 > 0.0) ReaGate: - treshold should be more linear (now: -inf > -33.2 = -0.5 > 0.0) - attack, release, hold, hi-pass, lo-pass, RMS size. ReaDelay: length, hi-pass & lo-pass filters. Making the envelope range reflect the fader range would solve most of those. |
03-26-2010 08:39 PM | |||
|
|||
This BR (again on the border between FR and BR) is already set to "confirmed". Even if your Rea* plugin issue will be solved by fixing/implementing this, it doesn't add anything to the actual report and it's unclear on what you expect feedback and from whom.
|
03-26-2010 11:51 PM | |||
|
|||
I think there have been cases where a bug has been fixed only partially, because related issues were not clearly brought up. I just wanted to prevent that. And perhaps make some publicity to an issue that bothers me (*bump*).
This issue has been presented and confirmed 7 months ago. A comment from developers would be cool. Didn't mean to be bothersome. |
03-27-2010 06:04 AM | |||
|
|||
We can't have automation represent many different things accurately unless Reaper somehow knows what they represent. For native parameters (track volume, pan, Rea* parameters etc.) that could work, but it would *not* work for VST/AU parameters without us telling Reaper what they represent (or, more precisely, what their value range represents and how it is scaled). Since to me the latter is *much* more important, I'd much rather have an option to configure automation value representation manually than expecting Reaper to show it 'correctly' automagically.
|
03-27-2010 06:46 AM | |||
|
|||
Sorry, but
1. Bumping is not allowed in here. 2. No matter how much it bugs you or anyone, when stuff gets love is entirely at the discretion of the devs, which are aware of the open bugs, that's the very reason why we have this database. 3. This is may be a pretty non-trivial fix and these things often can't be fixed on-the-fly without the risk of breaking things. Reaper is developed "live" and has to maintain downward compatibility with projects, which limits the feasibility of doing this stuff quickly. I'm leaving this up for another 24hrs and then I'm going to clean up this issue thread. |
Issue Tools |
---|
Subscribe to this issue |