Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Closed Issue

New action: Track hide audio controls Issue Tools
issueid=190 06-19-2009 05:35 AM
Human being with feelings
New action: Track hide audio controls
Be able to hide Vol,pan, audio Vu, audio track send knob

Objective:
-reduce clutter of useless audio controls on midi only tracks

The action would hide/unhide controls(on TCP and MCP):
-Volume slider
-Pan slider
-Vu meter (keep existing midi activity meter though)
-Send knob(s) in MCP (*see note below the pic)

The hide action would not be available if:
-Track contains audio items
-Track receives audio
-Track has any sends with Audio<>"none"

The unhide action would be triggered if:
-An audio item is placed on the track
-An audio send from this track is routed
-An audio receive to this track is routed

[edit: add picture]
Typical situation: hide-able areas are framed in red:

[*edit] MCP send knob itself is hidden but its container showing the name is still there. This allows to see the midi send destination and right click context menu access (be able to mute the midi send for example)
Issue Details
Issue Type Closed Issue
Project Deprecated REAPER issue tracker
Category GUI and graphics
Status Insufficient Votes
Priority 5 - Medium
Affected Version 3.04
Closed Version (none)
Yes votes 3
No votes 4
Assigned Users (none)
Tags (none)

06-19-2009 08:27 AM
-blšnk-
 
Sends make perfect sense with MIDI, so those shouldn't be hidden.
Reply
06-19-2009 08:47 AM
Human being with feelings
 
Quote:
Originally Posted by gofer
Sends make perfect sense with MIDI, so those shouldn't be hidden.
I must make it perfectly clear that I refer to "controls" as the GUI widgets ( knob,slider,bar graph, etc).
There is no GUI widget associated with MIDI sends.
There is with audio sends, however. It takes the form of a knob that appears on the mixer channel strip. It appears whenever a send is assigned even if it is configured as "Audio->none". It is useless clutter and a waste of GUI space (and "head-space") in this situation.
Reply
06-19-2009 09:29 AM
Human being with feelings
 
Quote:
Originally Posted by Guod3
I must make it perfectly clear that I refer to "controls" as the GUI widgets ( knob,slider,bar graph, etc).
There is no GUI widget associated with MIDI sends.
There is with audio sends, however. It takes the form of a knob that appears on the mixer channel strip. It appears whenever a send is assigned even if it is configured as "Audio->none". It is useless clutter and a waste of GUI space (and "head-space") in this situation.
Don't MIDI and Audio send the same in REAPER?
Reply
06-19-2009 09:32 AM
-blšnk-
 
Quote:
Originally Posted by labyrinth
Don't MIDI and Audio send the same in REAPER?
Yep, those send knobs handle MIDI or audio or both.

EDIT: Of course the knobs are redundant in the sense that moving the knob doesn't do anything useful, but still I want to see that the sends are assigned to have an overview of the routing. And I use the "clutter" to mute the MIDI send if needed.

Hey btw., would it maybe be a good idea to have the send value affect the velocity of notes that go along that stream?
Reply
06-19-2009 09:54 AM
Human being with feelings
 
Quote:
Originally Posted by gofer
Yep, those send knobs handle MIDI or audio or both.
Not true, at present. They're send audio level in dB.

The text label next to the (in the current context, useless) knob does provide a visual cue as to the routing. I would say to hide this knob but don't hide the text label would be the way to go.

CC's or other data modifiers (like velocity, as you suggest) would be a useful kind of knob to have but that is not this FR.
Reply
06-19-2009 10:20 AM
Human being with feelings
 
Quote:
Originally Posted by gofer
And I use the "clutter" to mute the MIDI send if needed.
We must be talking about different things because the widgets that the FR hide/unhide apply to have no MIDI function.
I will add some pictures to the presentation to make it really clear about this FR.
Reply
06-19-2009 10:41 AM
Human being with feelings
 
Quote:
Originally Posted by labyrinth
Don't MIDI and Audio send the same in REAPER?
Of course, but this has nothing to do with the FR.

The FR addresses the issue of functionless GUI elements.

As per FR, the moment the track sees:
an audio item,
an audio send,
an audio receive,
then these GUI elements become automatically unhidden because they are no longer useless!
Reply
06-19-2009 12:17 PM
-blšnk-
 
Ah, ok I always looked at the knob and the label as one entity. You're right with what you're saying, then. I could live with what you're proposing maybe, but rather would make the stuff you'd like to vanish useful.
Reply
06-19-2009 09:33 PM
Human being with feelings
 
Quote:
Originally Posted by gofer
Ah, ok I always looked at the knob and the label as one entity. You're right with what you're saying, then. I could live with what you're proposing maybe, but rather would make the stuff you'd like to vanish useful.
Me too, but this is simply not the FR.

Once the audio controls are hidden there is more space for the ReaControlMidi parameter knobs that are useful.

btw: there is now a picture to show the hide-able elements

This is a very "transparent" FR in that it has absolutely minimal footprint as far as users who have no use for this.
Reply
06-21-2009 05:48 PM
Human being with feelings
 
I would like to be able to see just the name number and knobs in certain situations...
Reply
06-21-2009 06:27 PM
Human being with feelings
 
I've created a similar FR, but one that's supposed to have wider scope.

http://forum.cockos.com/project.php?issueid=228

Unfortunately, it's not that well fleshed-out, but I think the idea is fairly solid. Check-check it.
Reply
06-22-2009 03:30 AM
Human being with feelings
 
Joe2, the only thing missing from that FR you posted is what goals you have. A lot of the time, the developers have come up with a good solution to a problem of the users, if they knew about the problem.

Guod3, I support your idea, but as Gofer stated, sends are responsible for both midi and audio. When sending midi data from one track to the next, the MCP panels are the most practical way to set sends/receives up quickly and see how the routing is configured in general. The routing matrix just gets too unwieldy and slow to use.

If it's a spark the developers need to rid the midi-containing and routing tracks only, then I hope this is it.

It's worth considering, making a function that creates a new midi track from which only midi is routed to the target track.

A right-click function or icon that says "Make MIDI track beaneath selected track that has one MIDI All Channels send routed to the selected track, 'Parent/Child Send' deactivated and no track controls is doesn't need" .

I'd use a function like that because templates have sends that point to anything outside their template, so I'll either have to create a dozen 'midi' tracks as described above up-front, and delete them, or set them up as the idea spells out, which would give new users a good way to get started that way as well.
Reply
06-22-2009 04:26 AM
Human being with feelings
 
Quote:
Originally Posted by semiquaver
I would like to be able to see just the name number and knobs in certain situations...
Ive edited the FR so that the behavior of the MCP send knob hide is to still be visible without the audio knob. This means that you can see the midi send destination and right click mute it etc.
If you want to see the audio send knob, then you would "unhide audio track controls"
Reply
06-22-2009 04:29 AM
Human being with feelings
 
Quote:
Originally Posted by joe2
I've created a similar FR, but one that's supposed to have wider scope.

http://forum.cockos.com/project.php?issueid=228

Unfortunately, it's not that well fleshed-out, but I think the idea is fairly solid. Check-check it.
Configurable track panels was my first thought, but when considering the design decisions and ramifications its scope could be rather large, and it may be better to move towards this in "baby steps". That is the intention of this FR.
Reply
06-22-2009 04:33 AM
Human being with feelings
 
Quote:
Originally Posted by airon
Guod3, I support your idea, but as Gofer stated, sends are responsible for both midi and audio. When sending midi data from one track to the next, the MCP panels are the most practical way to set sends/receives up quickly and see how the routing is configured in general. The routing matrix just gets too unwieldy and slow to use.
Hopefully the edit regarding what "hide" does to MCP send knob addresses this.
Reply
06-22-2009 04:54 AM
Human being with feelings
 
Quote:
Originally Posted by airon
I'd use a function like that because templates have sends that point to anything outside their template, so I'll either have to create a dozen 'midi' tracks as described above up-front, and delete them, or set them up as the idea spells out, which would give new users a good way to get started that way as well.
Its been my experience that templates save the routing to other tracks that are included in the template. References to tracks "outside" the template are automatically removed in the saved template.
A track saved as a template in the "hide audio" state would by definition have no audio routings.

The action you speak of could be implemented as an extension (by whom, I dont know...) as an intermediate stage of evolution.

The idea is to keep this FR as transparent and simple as possible, only keeping essential elements that would be a big improvement IMO.

If you wanted to add another midi track or part to a VSTi, simply invoke a template for the midi part and assign its routing to the VSTi. Not a huge workflow overhead, I would have thought. Alternatively, as you suggest, one could save templates with various numbers of "child" tracks e.g 4,8,16 and delete the excess tracks, as required.
Reply
06-22-2009 05:31 AM
Human being with feelings
 
Quote:
Originally Posted by airon
Joe2, the only thing missing from that FR you posted is what goals you have.
I *do* tend to write those first drafts inadequately. :-) Goals are simply about "uncluttering" workspace; trying to increase the speed/comfort of my workflow by only seeing the information I want to see. Furthermore, I rarely *click* any of the TCP controls, so they're more about visual feedback and project management than actually "using" tracks, for me. (I'll edit this into that FR!)

Quote:
Originally Posted by Guod3
it may be better to move towards this in "baby steps"
Absolutely. (Indeed, I can't think of many "substantial" features recently which have just popped up.) And even if the TCP was configurable in the way I've suggested, I'd still want as many actions as possible to affect that configuration on the go!
Reply
06-22-2009 12:51 PM
Human being with feelings
 
Quote:
Originally Posted by Guod3
Its been my experience that templates save the routing to other tracks that are included in the template. References to tracks "outside" the template are automatically removed in the saved template.
A track saved as a template in the "hide audio" state would by definition have no audio routings.
That was my intention when I wrote the sentence, but I should have reread what I wrote :).

Quote:
The action you speak of could be implemented as an extension (by whom, I dont know...) as an intermediate stage of evolution.

The idea is to keep this FR as transparent and simple as possible, only keeping essential elements that would be a big improvement IMO.
Couldn't agree more.

An inspector type of sub-view of a selected track could house the Parameter knobs one can have, which would shave even more possibly unnecessary stuff away from the TCP.

Btw, the screensets do not include the width of the TCP either. Bummer I think as well.

Quote:
If you wanted to add another midi track or part to a VSTi, simply invoke a template for the midi part and assign its routing to the VSTi. Not a huge workflow overhead, I would have thought. Alternatively, as you suggest, one could save templates with various numbers of "child" tracks e.g 4,8,16 and delete the excess tracks, as required.
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 02:41 AM.


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