* Includes feature branch: configurable naming for in-project MIDI items
* Includes feature branch: updated Windows manifest for newer OS features
* Includes feature branch: always running non-bypassed FX when the UI is visible
* Includes feature branch: crossfade new recording with existing media items if configured
* Includes feature branch: video from background projects
* Includes feature branch: FX containers
* Includes feature branch: improvements to aligning takes after recording
* Includes feature branch: arrange view override mouse modifier sections
* Includes feature branch: toolbar armed/special animations
* Includes feature branch: pooled and unpooled ARA edits
* Includes feature branch: fixed lane comping
* Includes feature branch: shortcut import/export improvements and multiple main keyboard sections
* Includes feature branch: preview item selection for grouped tracks
* Includes feature branch: GR metering as embedded UI for third-party VSTs
* Includes feature branch: media item fixed lanes
+ API: update UI in response to I_DSTCHAN for sends [t=278144]
+ Subprojects: fix potential crash when pasting subproject and copy media on paste is enabled [t=278130]
+ Tracks: add actions, context menu entries to add spacers before or after tracks
# Media item lanes: action to copy unsynced media items to new lane will preserve any parts of unsynced comp areas that do not match up with media items
# Media item lanes: allow dragging comp area when mouse is over lane collapsed up/down buttons
# Media item lanes: fix incorrect fadeout applied when comping [p=2669187]
# Media item lanes: ignore customized mouse modifiers when clicking on TCP lane rocker button and lanes are collapsed
# Media item lanes: revert "if "monitor track media while recording" is enabled and recording creates a new lane, play the new lane in addition to all previously playing lanes"
# Recording: crossfade new recording when preference enabled to overlap and crossfade on split (ignore toolbar autocrossfade button for this purpose)
# WALTER: fix default for master.tcp.fxembed [t=278221]
This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.
# Media item lanes: revert "if "monitor track media while recording" is enabled and recording creates a new lane, play the new lane in addition to all previously playing lanes"
Schwa: why reverting it?
* Includes feature branch: visual track spacers
+ Tracks: add actions, context menu entries to add spacers before or after tracks
I requested I think this long time ago. Looking forward to see how it works.
[*]# Media item lanes: action to copy unsynced media items to new lane will preserve any parts of unsynced comp areas that do not match up with media items
For me it is perfect how it works now.
Quote:
[*]# Media item lanes: allow dragging comp area when mouse is over lane collapsed up/down buttons
Thank you, but I found that takes now switch with double click from the arrows instead of a single click.
Quote:
[*]# Media item lanes: fix incorrect fadeout applied when comping [p=2669187]
Previously it was removing every area when recomping new edits, but made it impossible to know if there are any other sources bellow the deleted area. Now when recomping it keeps the initial area position and adds the length of the new edit.
This is useful because we can continue comping on that part when only the comp lane is visible and also works as an indicator to know that there are some sources below, in case we move something on that area and we don't want to delete other sources accidentally.
[*]+ API: update UI in response to I_DSTCHAN for sends [t=278144]
This commit hasn't worked for me in 6.78+dev0415. First test was simply creating a send from channels 1-4 to 1-4 – destination dropdown shows up blank still.
Edit: Further testing confirms that in fact send creation needn't be included in the script. Just setting I_DSTCHAN with SetTrackSendInfo_Value() on an existing send reveals the issue.
Currently there's no way to move all comp areas as a group with the items when only one lane is visible. With RE it's moving the items but removes the areas and the same happens when selecting them both with marquee.
Love the separators - would it be better if they didn't follow the "odd/even tracks" tinting preference? Don't quite see the advantage, if anything it diminishes the impact of being a separator.
It would be great if there was a preference in media explorer to send each of our samples to a separate fixed lane on the selected track from right click menu.
Love the separators - would it be better if they didn't follow the "odd/even tracks" tinting preference? Don't quite see the advantage, if anything it diminishes the impact of being a separator.
I don't think they do? Afaict the spacers are colored the same way as empty arrange space below all tracks regardless of whether they precede or follow an odd or even numbered track.
I don't think they do? Afaict the spacers are colored the same way as empty arrange space below all tracks regardless of whether they precede or follow an odd or even numbered track.
I suppose that ferropop means that the odd/even tinting should apply to track groups separated by track spacers
Sexan has developed an impressive spaghetti routing, but unfortunately, it cannot be implemented on the fx container routing system as it has not been enabled on your side (due to limitations).
Similarly, MPL and other scripters have been unsuccessful in creating a functional parallel routing effect that permits parallel routings between plugins with wires and they also said it's not possible to create it currently due to reaper's limitations.
I, along with other users, am willing to pay scripters for this capability, but they have deemed it impossible. Is there any way to make this feasible for scripters or perhaps for you to implement it?
Having an effective fx routing capability would significantly enhance my music and mixing, more so than any other feature.
This script showcase how useful it would be to be able and move comp sections as one item and show lanes with our comps when we want to recomp/edit them.
Long time ago there was a build or two with a container item but unfortunately was abandoned.. Maybe would be nice to be revived and use it with fixed lanes in a similar way?
I think another idea that comes in mind is if we had fixed lanes grouping options with lead and follow with REs. Lead could be the comp lane and follow the sources in fixed lanes.
That way we could group the items in comp lane and move them with the rest in lanes, and at the same time be able and move the sources independently.
I don't think they do? Afaict the spacers are colored the same way as empty arrange space below all tracks regardless of whether they precede or follow an odd or even numbered track.
Sorry I meant the odd/even bars tint settings - in theme settings.
The spacers are treated the same way as empty arrange view space below tracks. There is a theme color for "empty arrange view area vertical grid shading", if you set that to the same color as "empty arrange view area" then there won't be any vertical shading for either the spacers or the empty area below tracks.
???
To me this looks like a really great impressive Spagetti Diagram GUI Builder example but has nothing to do with routing with routing whatsoever. Audio / Midi / Parameter-Modulation Routing in a DAW might be one of many possible application for this. Logic flow diagrams ( -> https://www.google.com/search?client...bih=1230&dpr=1 ) is another one.
-Michael
i don't know the intensions of the spacer, but would be cool if with a modifier and resizing the track TCP bottom or Top would create the spacer instead, and at that moment the resizing of the spacer would already be happening during our drag.
start drag tcp bottom height down -> the spacer is created and immediatly is defining it's size while we still dragging. maybe this could work for resizing too. and maybe for deleting?
if viable, I think this would more intuitive?
Schwa, could i have a word about my last question?
This is useful because we can continue comping on that part when only the comp lane is visible and also works as an indicator to know that there are some sources below, in case we move something on that area and we don't want to delete other sources accidentally.
Yeah, it's fine. Makes sense. [edit] PS double-clicking on a spacer to add a track below, esp. in a folder is great.
This script showcase how useful it would be to be able and move comp sections as one item and show lanes with our comps when we want to recomp/edit them.
Superglue will support as best as possible once the lanes API has solidified
Quote:
Long time ago there was a build or two with a container item but unfortunately was abandoned.. Maybe would be nice to be revived and use it with fixed lanes in a similar way?
This is one thing that makes me think schwa and Justin may be considering some sort of repeatable pooled container functionality once fixed comps is deployed & ironed out
Double clicking the spacer creates a new track at spacer+1
I feel the track should be inserted right after the spacer
Deleting the track before a separator removes the spacer (*)
Dragging a track above a spacer inserts the track before the separator (which is great!)
But then you can't drag it back below the spacer, and if you drag it somewhere else the spacer follows which doesn't feel right to me. (*)
A small inconsistency:
For a spacer created with "Track: Insert visual spacer after tracks", on to next track "Track: Remove track spacers" doesn't work but "Track: Insert visual spacer before tracks" does. (*)
(*) I think a couple of these are due to tracks "owning" spacers.
In my mind a separator should just "be there" and allow tracks to move freely around it.
About the actions: maybe they should be "Toggle" rather than "Insert" ?
also "separator" could be a synonym for "spacer" in the action list
(*) I think a couple of these are due to tracks "owning" spacers.
In my mind a separator should just "be there" and allow tracks to move freely around it.
Yeah I think spacers ought to be a sort of empty non-registered track substitute rather than a hanger-on to another track's data. Then they can be dragged around & expanded freely. (I mean after all why should they all be required to be the same? Then users can use them to separate groups and subgroups differently etc.)
The spacers are treated the same way as empty arrange view space below tracks. There is a theme color for "empty arrange view area vertical grid shading", if you set that to the same color as "empty arrange view area" then there won't be any vertical shading for either the spacers or the empty area below tracks.
I don't know if this is possible, but it would be really nice to be able to individually color spacers. This is what I'm doing currently, except that I have to use tracks to do this and it would be really nice to use spacers instead.
Yeah I think spacers ought to be a sort of empty non-registered track substitute rather than a hanger-on to another track's data. Then they can be dragged around & expanded freely. (I mean after all why should they all be required to be the same? Then users can use them to separate groups and subgroups differently etc.)
Agreed +1 also the individual color..
Although that space could be cool as a toolbar-ish thing for the new custom TCP actions presented a while ago. Don't know if it's there still.
Agree with all the feedback so far about spacers. They should be free to insert and drag, resize, color etc. without being tied to or influenced by tracks and their positions. Especially the quirks outlined by souk21 shouldn’t be happening. But I am sure all of this will be ironed out soon. It is a great proposal already.
And yeah, I also hope the custom buttons feature will soon be worked on again. That has the potential to become an insanely powerful feature if fleshed out, limited only by the imagination of the user.
unfortunately, it cannot be implemented on the fx container routing system as it has not been enabled on your side (due to limitations).
Similarly, MPL and other scripters have been unsuccessful in creating a functional parallel routing effect that permits parallel routings between plugins with wires and they also said it's not possible to create it currently due to reaper's limitations.
Maybe your explanations are not clear enough about what you want devs to do. For example, what specifically "reaper's limitations" there are?