Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Open Bug

Accurate Representation of Envelope Values Issue Tools
issueid=980 08-18-2009 09:09 AM
Human being with feelings
Accurate Representation of Envelope Values
Envelope visualizations should be proportional to the values they represent

This is a simple request, and it is one on which my purchase of Reaper hinges:

Visualizations of envelopes should be proportional (either linear or logarimithmic...or selectably either) to the values they represent. The top ot the fader's throw should be the top of the envelope lane. The bottom of the fader's throw should be the bottom of the envelope lane. Everthing in between should be evenly proportional. PERIOD.

Anything else is confusing and makes no sense. Currently (as of 3.101), if I record volume automation, anything above 0dB is represented as a FLAT LINE of envelope points--which contain accurate values for the fader movement I recorded, but are a.) visually useless, and b.) impossible to manually edit. Is there any logic behind basing the vertical position of an envelope point on a numerical dB value of the track fader (which is relative and can change based on the user-definable fader dB range), rather than the throw of the fader itself (which is what the envelope is actually controlling)?

...And that's in '-inf to 0' mode; '-inf to +6' is even weirder, less linear and more baffling....

Up should be up, down should be down, from top to bottom.
Issue Details
Issue Type Open Bug
Project Deprecated REAPER issue tracker
Category Editing behavior
Status Confirmed
Priority 4
Affected Version 3.101
Fixed Version (none)
Users able to reproduce bug 15
Users unable to reproduce bug 2
Assigned Users (none)
Tags (none)

08-18-2009 02:14 PM
Human being with feelings
 
Some screenshots?
Reply
08-18-2009 02:41 PM
Human being with feelings
 
Here's a shot of what I mean. Not much to see...but that's kind of the problem. A fader ride should look like a roller coaster, not a straight line. The top of the lane seems to be defined as '0dB', not 'top of the fader throw'. That doesn't make sense to me.
Reply
08-18-2009 02:48 PM
Human being with feelings
 
Quote:
Originally Posted by VariMu
Here's a shot of what I mean.
Where?
Reply
08-18-2009 02:48 PM
Human being with feelings
 
...It might help if I remembered to post the link, right? Sorry--here it is:

http://img35.**************/img35/9747/reaperd.jpg
Reply
08-18-2009 02:59 PM
Human being with feelings
 
Ok, I agree. Reproduced too. Not cool!
Reply
08-22-2009 04:28 PM
Human being with feelings
 
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.
Reply
08-24-2009 08:04 AM
Human being with feelings
 
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?
Reply
08-24-2009 08:19 AM
Human being with feelings
 
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".
Reply
08-24-2009 08:46 AM
Human being with feelings
 
Quote:
Originally Posted by inthepipeline
The question is... is this a bug, or is it by design?
If it is by design, then I would like to know what useful purpose one could possibly have for not being able to see or edit any positive-value automation points on the volume envelope.

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.
Reply
08-25-2009 04:31 AM
Human being with feelings
 
Discussed here in detail some time ago:


http://forum.cockos.com/showpost.php...8&postcount=44
Reply
08-25-2009 05:20 AM
Human being with feelings
 
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.
Reply
This petition for a change to Awaiting Feedback was rejected
03-26-2010 03:38 PM
Human being with feelings
 
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
Super Moderator (no feelings)
 
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.
Reply
03-26-2010 11:51 PM
Human being with feelings
 
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.
Reply
03-27-2010 06:04 AM
Human being with feelings
 
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.
Reply
03-27-2010 06:46 AM
Super Moderator (no feelings)
 
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.
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 05:28 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.