MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007120ardourfeaturespublic2016-11-16 10:522017-08-02 15:09
Reportermagnetophon 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusfeedbackResolutionopen 
PlatformlinuxOSNixOSOS Version16.09
Product Version5.4 
Target VersionFixed in Version 
Summary0007120: Please use a gain-reduction meter as the inline display of the compressor.
DescriptionThank you very much for the inline displays!
I've always been a bit jealous of the Harrison console inline scopes ;)

The current compressor display, while pretty, takes up a lot of pixels, and those are precious if you use a lot of plugins and sends.
I'm on a 1920x1080 screen, btw.

It also is not as immediately informative as a GR-meter is:
- the level meter doesn't factor in the attack and release.
- even if it did, you'd still have to interpret the result (mentally multiply the curve with the level), to 'see' what your compressor is actually doing, iow the gain-reduction.

I'd prefer a simple and small inline GR-meter, with the current display in the full interface, if at all. Imho the curve is useful, but mainly to develop a mental model of compressors while learning about them.

In my dream world, you'd have the choice of a GR-meter or GR-scope for the inline display, and a meter+scope+curve in the interface.

TagsNo tags attached.
Attached Files? file icon a-comp-gr-demo.mp4 [^] (1,928,142 bytes) 2017-07-13 08:45
? file icon a-comp-narrow-demo.mp4 [^] (541,267 bytes) 2017-07-13 12:46

- Relationships

-  Notes
(0019877)
johmue-eo (reporter)
2017-07-13 08:48

I put a small bar into the inline display to show the GR. Furthermore I made the graph honor the attack and release parameters.

I attached a small video showing a demo on this. There's still the graph in visible, taking screen estate, but would this be a step in the right direction?
(0019878)
magnetophon (reporter)
2017-07-13 12:27

Hi johmue-eo,

Many thanks for working on my suggestion!

It's definitely a step in the right direction:
It fully fixes the first half of my issue, which is that the old visuals don't tell you much.

To me, moving the graph to the plugin window and rotating the inline GR meter to horizontal would be even better:
I think for a quick overview you only need the GR, and for developing a mental model of a compressor, it's fine to have the graph in the plugin window.
IMHO, once you have that mental model, the graph doesn't help you at all.

What do you use the graph for?
Do you agree it's mainly 'training wheels'?

Do you ever run out of screen real-estate in the mixer?
I have a template with a high-pass, a compressor, an EQ, 4 effect sends and 4 headphone sends, and that fully fills the space on a 1920x1080 screen.
(0019879)
johmue-eo (reporter)
2017-07-13 13:01

I now made it responsive to the width of the channel strip.

If the channel strip gets narrower than a certain value, it switches from the graph view to a simpler bar view with two bars indicating the output level and the gain reduction.

In the simple mode it takes the full height, it is allowed to take. So it doesn't fix your issue of running out of screen estate vertically.

About your remark that the graph is useless I disagree. Actually it is useless as it is in Ardour 5.10. as it does not honor the makeup gain. That's why I came up with PR #346.

I usually use the graph to see when and how much the compressor goes into compression and when I'm done with threshold and ratio I tweak makeup gain until the compressed signal more or less meets the unity line.

Using the graph I see:

* how much the compressor goes into compression.
* if it does not go into compression, how far it is from compression.
* if it does go into compression, how high the output level is compared to the output level of the uncompressed signal.

It's probably a matter of how you are used to work.
(0019880)
magnetophon (reporter)
2017-07-13 14:34
edited on: 2017-07-13 14:40

I agree I was a bit harsh on the graph, and I can see it's usefulness now.

Does that warrant a place for it inline though?
Is that info you can and need to see at a glance, when looking at the overview of your mix?
Or is it more something you use for initial setup and during the fine-tuning of the channel?

If you do feel you can and need to see this info at a glance, how would you feel about having just a horizontal input, GR and output bar, with a visual indication of the threshold?
That would give you the same info in less pixels.

It wouldn't visualize knee, but you could see that in the graph in the plugin.
Plus of course the effect of the knee can be seen in the GR.

(0019881)
johmue-eo (reporter)
2017-07-13 22:47

I agree that in an ideal world, we would have the graph only in the GUI of the plugin. But that implies, that the plugin had a GUI, which it does not at the moment.

Before writing a plugin for it, we would need to have a definite decision of the Ardour core developers on which GUI toolkit to use.
(0019882)
magnetophon (reporter)
2017-07-13 22:54

Great to hear that you agree!
Let's see what the core devs think.
(0019889)
x42 (administrator)
2017-07-15 05:20

The envisaged solution here was to add some LV2 meta-data: "also include inline-display on generic UI". The displays are scalable and the generic UI coudl show it at a (much) larger size.


That needs a bit of work on the plugin-side to be efficient:
The a-plugins currently have a singleton instance for the inline-display. The display is cached at the most recently requested size. If you continuously render 2 or 3 different sizes, the plugin re-allocates the display every time. Currently that can already happen with the editor-mixer + mixer at different width.
(0019906)
magnetophon (reporter)
2017-07-19 10:25
edited on: 2017-07-19 10:27

Thanks everybody for your time so far.

@x42: What would you say about having the graph only on the gui, and having a horizontal GR-meter as the only thing inline?

(0019917)
johmue-eo (reporter)
2017-07-21 06:20

Experimental branch to address this: https://github.com/Ardour/ardour/pull/365 [^]
(0019942)
johmue-eo (reporter)
2017-07-31 13:34

Feature implemented in 5.10-416. Please test and give feedback on GUI details. See the points raised in https://github.com/Ardour/ardour/pull/370 [^]

- Issue History
Date Modified Username Field Change
2016-11-16 10:52 magnetophon New Issue
2017-07-13 08:45 johmue-eo File Added: a-comp-gr-demo.mp4
2017-07-13 08:48 johmue-eo Note Added: 0019877
2017-07-13 12:27 magnetophon Note Added: 0019878
2017-07-13 12:46 johmue-eo File Added: a-comp-narrow-demo.mp4
2017-07-13 13:01 johmue-eo Note Added: 0019879
2017-07-13 14:34 magnetophon Note Added: 0019880
2017-07-13 14:36 magnetophon Note Edited: 0019880 View Revisions
2017-07-13 14:40 magnetophon Note Edited: 0019880 View Revisions
2017-07-13 22:47 johmue-eo Note Added: 0019881
2017-07-13 22:54 magnetophon Note Added: 0019882
2017-07-15 05:20 x42 Note Added: 0019889
2017-07-19 10:25 magnetophon Note Added: 0019906
2017-07-19 10:27 magnetophon Note Edited: 0019906 View Revisions
2017-07-19 10:27 magnetophon Note Edited: 0019906 View Revisions
2017-07-21 06:20 johmue-eo Note Added: 0019917
2017-07-31 13:33 johmue-eo Note Added: 0019941
2017-07-31 13:34 johmue-eo Note Deleted: 0019941
2017-07-31 13:34 johmue-eo Note Added: 0019942
2017-07-31 13:34 johmue-eo Status new => feedback


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker