|
|
|
09-06-2016, 01:21 PM
|
#1
|
Human being with feelings
Join Date: Mar 2007
Posts: 479
|
v5.25pre1 - September 6 2016
v5.25pre1 - September 6 2016
+ Automation: improved point paste edge case behavior [t=180798]
+ MIDI editor: draw events at their precise integer MIDI tick location in piano roll view [p=1726217]
+ MIDI editor: fix CC display with multiple overlapping channels [t=177453]
+ MIDI editor: fix duplicate messages when editing bank/program event channel [t=180005]
+ MIDI editor: properly round event position when editing via list view or event properties dialog [p=1726314]
+ MIDI: fix overdub/replace recording to MIDI items that ignore project tempo
+ MIDI: improve behavior when stopping overdub/replace recording with held notes [t=180453]
+ Notation editor: add actions to explicitly minimize or un-minimize ties for selected notes [t=180345]
+ Notation editor: add preference to minimize ties for all notes by default [t=180345]
+ Notation editor: automatically position beamed tuplets, improve bracket positioning for non-beamed tuplets [p=1726081]
+ Notation editor: change voice for selected notes if appropriate when creating/modifying tuplet [p=1726071]
+ VST: improve behavior initializing resizeable VST3 UIs [t=181147]
+ Wave: support reading .wav files with 0-length data chunk
# MIDI editor: do not automatically enable channel filter on actions to set channel higher/lower for new events [t=181041]
# MIDI editor: fix selected CC item fill
# Snap window: fixed reversed selection/cursor snapping to markers/etc [p=1726315]
|
|
|
09-06-2016, 01:54 PM
|
#2
|
Human being with feelings
Join Date: Feb 2014
Location: Ukraine
Posts: 205
|
+ MIDI: improve behavior when stopping overdub/replace recording with held notes [t=180453]
# MIDI editor: fix selected CC item fill
Thanks for corrections!
|
|
|
09-06-2016, 02:26 PM
|
#3
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Woo-hoo! Starting v5.25 with amazing MIDI fixes!
I am not sure what "MIDI editor: fix selected CC item fill" refers to - is there perhaps a thread reference?
|
|
|
09-06-2016, 02:31 PM
|
#4
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,749
|
Quote:
Originally Posted by juliansader
I am not sure what "MIDI editor: fix selected CC item fill" refers to - is there perhaps a thread reference?
|
No thread reference, just something we noticed in testing. Previously a single selected CC event would draw the shading incorrectly unless the mouse was down.
|
|
|
09-06-2016, 02:49 PM
|
#5
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by mustgroove
+ MIDI editor: fix CC display with multiple overlapping channels [t=177453]
|
This is now working much better!
I would suggest just one further improvement, namely that shorter CCs should be drawn in front, otherwise they are concealed behind the longer ones, even when selected.
EDIT: Pretty colors!
Last edited by juliansader; 09-06-2016 at 03:00 PM.
|
|
|
09-06-2016, 05:20 PM
|
#6
|
Human being with feelings
Join Date: Jul 2006
Posts: 12,480
|
Quote:
Originally Posted by schwa
No thread reference, just something we noticed in testing. Previously a single selected CC event would draw the shading incorrectly unless the mouse was down.
|
Reference was there: http://forum.cockos.com/showthread.php?t=153085
@schwa: Selection all CCs in a lane disables the shading completely. Why that? FIXED
CTRL+Drag shows the shading but does nothing. Copy/moving of CCs broken?
Last edited by Dstruct; 09-07-2016 at 01:12 PM.
|
|
|
09-06-2016, 05:49 PM
|
#7
|
Human being with feelings
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,467
|
There are some really bad behaviors concerning takes after the last update.
I can illustrate using a single track. the same is true for multiple tracks as well.
http://imgur.com/a/lQStY
if two grouped items have the same take number selected, and are grouped - or even if both items are selected, clicking on a take will change the take in both items.
This makes comping pretty impossible!
|
|
|
09-06-2016, 06:38 PM
|
#8
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
Quote:
Originally Posted by James HE
There are some really bad behaviors concerning takes after the last update.
I can illustrate using a single track. the same is true for multiple tracks as well.
http://imgur.com/a/lQStY
if two grouped items have the same take number selected, and are grouped - or even if both items are selected, clicking on a take will change the take in both items.
This makes comping pretty impossible!
|
This was completely intentional:
Quote:
+ Take Lanes: obey multiple selected items/item grouping when switching takes via lanes
|
...perhaps we need to make an option. I'd like to avoid that.
For pre2, we'll make it not gang the take changes by selection, but still do it by grouping.
If the items must be grouped (must they be?!), temporarily disable grouping via the toolbar...
Last edited by Justin; 09-06-2016 at 06:49 PM.
|
|
|
09-06-2016, 07:23 PM
|
#9
|
Human being with feelings
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,467
|
Quote:
Originally Posted by Justin
This was completely intentional:
...perhaps we need to make an option. I'd like to avoid that.
For pre2, we'll make it not gang the take changes by selection, but still do it by grouping.
If the items must be grouped (must they be?!), temporarily disable grouping via the toolbar...
|
It don't think it's working as intended. When you slice up the items, with say 3 takes, everytime you switch an item from take 2 to take 3 - every single item that was on take 2 now moves to take 3. After you do this a few times eventually what happens is that every item is switching to the clicked take everytime - totally destroying your comp. In reality what needs to happen is that only items for that particular part in the group need to change - perhaps it needs to check and switch only items within the same time range as the clicked take/item. In a multitrack comp, the items would need to be grouped, so there is a real issue there.
The behavior must be a bug, because it's not consistent. If you have a grouped item and then you split it, it behaves differently than when you selected a bunch of already split items and group them. In first scenario, things pretty much work as intended, and the second scenario you see the behavior I described above where unintended items are switching.
This .gif may explain it a little better i hope.
http://imgur.com/FjshQpu
You see that i group the items, unselect everything. as soon as i change a take, everything moves from 2 to 1 when I click. Now you can't possibly create a comp without ungrouping everything and starting over. I then split the item on the end - you see that switching that take actually works as it should.
Last edited by James HE; 09-06-2016 at 07:40 PM.
|
|
|
09-06-2016, 07:40 PM
|
#10
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
Quote:
Originally Posted by James HE
If you have a grouped item and then you split it, it behaves differently than when you selected a bunch of already split items and group them.
|
If you group items, then split them, they become multiple groups. If you select a bunch of items and group them, they become one group.
|
|
|
09-06-2016, 07:43 PM
|
#11
|
Human being with feelings
Join Date: Jul 2009
Posts: 7,570
|
Generally speaking, you don't often group items across the same track, not after splitting.
X-Raym has a script for grouping items across tracks to avoid adjacent items being linked to each other.
https://www.youtube.com/watch?v=1ZGuvk7dzbc
|
|
|
09-06-2016, 07:52 PM
|
#12
|
Human being with feelings
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,467
|
Quote:
Originally Posted by Justin
If you group items, then split them, they become multiple groups. If you select a bunch of items and group them, they become one group.
|
ok... yeah I thought splitting an item put it in the same group.
this is starting to make sense now.
However, in a real world situation there is a workflow issue. We need a way to select a bunch of already split items and put them into logical groups so that we can take advantage- is there a way to do that? I suppose it could be scripted, but I think having this cooked into the install makes more sense. People really struggle with multitrack comping. Coming from Vegas, I can just do it like it was 1999 and it works perfectly But users that are more accustomed to other workflows definitely struggle.
|
|
|
09-06-2016, 08:03 PM
|
#13
|
Human being with feelings
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,467
|
Quote:
Originally Posted by EpicSounds
Generally speaking, you don't often group items across the same track, not after splitting.
X-Raym has a script for grouping items across tracks to avoid adjacent items being linked to each other.
https://www.youtube.com/watch?v=1ZGuvk7dzbc
|
Well if you recorded a track with version 5.23 and did some editing without grouping, then updated to 5.24 and you wanted to check out this new feature, it seems intuitive to select the items and group them and check it out.
thanks for the link to the script, useful, thanks.
I'm thinking with this new multi-track takes feature, there should be some native actions to really facilitate it, otherwise it just becomes another part of a huge jigsaw puzzle. Comping should really be easier.
|
|
|
09-06-2016, 08:13 PM
|
#14
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
yeah a native version of that script might be handy...
but also realistically one would group the items before doing a ton of splits, in real world use...
|
|
|
09-06-2016, 08:21 PM
|
#15
|
Human being with feelings
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,467
|
Quote:
Originally Posted by Justin
yeah a native version of that script might be handy...
but also realistically one would group the items before doing a ton of splits, in real world use...
|
agreed! I just got tripped up since I was testing the functionality of it and missing the obvious.
What if the default Group items command would bring up a dialog box if multiple items across tracks were selected asking "create multiple groups for adjacent items (selecting no will create a single group)" - and then individual actions for each mode as well?
Last edited by James HE; 09-06-2016 at 08:28 PM.
|
|
|
09-06-2016, 08:52 PM
|
#16
|
Human being with feelings
Join Date: Nov 2012
Posts: 372
|
Quote:
Originally Posted by Justin
yeah a native version of that script might be handy...
but also realistically one would group the items before doing a ton of splits, in real world use...
|
Yeah, I honestly can't see how someone can make a ton of edits to multiple items before quickly realizing they forgot to group them.
As for comping, the new behavior is a huge improvement when working with multi-mic sources. For other situations isn't it easy enough to disable grouping temporarily while you comp?
|
|
|
09-06-2016, 09:42 PM
|
#17
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Quote:
Originally Posted by mustgroove
+ Automation: improved point paste edge case behavior [t=180798]
|
More good news! It seems that 5.25 will also feature improvements of the tempo envelope [t=180905 and t=180067], since in 5.25pre1 two tempo points can now be placed at the same time position when copying/pasting envelope points.
However, there is an amusing-looking bug: When I try to run my LFO Tool script on the tempo envelope, I get this:
In previous versions, the tempo envelope has never gone crazy.
Last edited by juliansader; 09-06-2016 at 09:57 PM.
|
|
|
09-06-2016, 09:57 PM
|
#18
|
Human being with feelings
Join Date: Jul 2009
Posts: 7,570
|
Quote:
Originally Posted by esosotericmetal
Yeah, I honestly can't see how someone can make a ton of edits to multiple items before quickly realizing they forgot to group them.
|
actually it's easy. 3 ways that happen to me just this year
- if they were selected at first and never got unselected because split action moves selection to items on the right of the split.
- if ripple edit for all tracks is enabled and you trim start to cursor.
- SWS Region playlist also breaks your grouping after pasting the items.
|
|
|
09-06-2016, 11:38 PM
|
#19
|
Human being with feelings
Join Date: Jan 2012
Posts: 1,180
|
Quote:
Originally Posted by Justin
yeah a native version of that script might be handy...
but also realistically one would group the items before doing a ton of splits, in real world use...
|
I use a script that selects all items in a folder to edit takes. I'd like there to be an option to have take changes follow the selection without having to be grouped.
|
|
|
09-07-2016, 01:04 AM
|
#20
|
Human being with feelings
Join Date: Jul 2011
Posts: 99
|
Quote:
Originally Posted by mustgroove
v5.25pre1 - September 6 2016
+ VST: improve behavior initializing resizeable VST3 UIs [t=181147]
|
Autotune 8.1 VST3 still doesn't reopen at specified window size.
Anyway, now the manual realtime resize is working, I guess resize everytime is still viable.
|
|
|
09-07-2016, 01:14 AM
|
#21
|
Human being with feelings
Join Date: Jan 2015
Posts: 794
|
Quote:
Originally Posted by James HE
It don't think it's working as intended...
|
Looking at your .gif the reason why it works like that is that before choosing the take you select all of the split items. Why you do that?
Anyway Justin said that in pre2 he will eliminate the "take lane move along" for multiple selected items and keep only the move along in Grouped items. This should solve your gif problem
For me this has been a massive improvement in take lane management
g
|
|
|
09-07-2016, 01:19 AM
|
#22
|
Human being with feelings
Join Date: Aug 2007
Location: Near Cambridge UK and Near Questembert, France
Posts: 22,754
|
The whole of my arsenal of Antares software is fuqu`ed since they went VST3 and version 8 on autotune.
Getting fed up with no response from Support but "we are working on it" and still no preset selection in Harmony Engine, for instance.
Avox still has crashes when scanning plugs with reaper and Sonar Pro. Such a pain.
__________________
Ici on parles Franglais
|
|
|
09-07-2016, 01:58 AM
|
#23
|
Human being with feelings
Join Date: Jun 2009
Location: South, UK
Posts: 14,214
|
Quote:
Originally Posted by schwa
No thread reference, just something we noticed in testing. Previously a single selected CC event would draw the shading incorrectly unless the mouse was down.
|
Awesome! This use to drive me crazy with sustain pedal editing as the values are hard to tell if they are 0 or 127
__________________
subproject FRs click here
note: don't search for my pseudonym on the web. The "musicbynumbers" you find is not me or the name I use for my own music.
|
|
|
09-07-2016, 02:38 AM
|
#24
|
Human being with feelings
Join Date: Aug 2006
Location: Berlin
Posts: 11,817
|
Quote:
Originally Posted by Justin
yeah a native version of that script might be handy...
but also realistically one would group the items before doing a ton of splits, in real world use...
|
Or have track group edits that can be turned on/off. Yeah it's a Protools thing, but it's a good idea for simple, effortless edits across tracks. People would have to create edit groups, but nobody seemed to mind in the last 20 years.
|
|
|
09-07-2016, 04:10 AM
|
#25
|
Human being with feelings
Join Date: Oct 2007
Location: Lincoln, UK
Posts: 7,924
|
Quote:
Originally Posted by Justin
yeah a native version of that script might be handy...
but also realistically one would group the items before doing a ton of splits, in real world use...
|
Following-on from Airon's suggestion, may I offer my opinion here about take-linking please?
I still think adding this to Project Bay Item Groups tab (as a group manager) would be the better way forward with this. The user then gets flexibility with the take linking, and can overview the item groups and linked takes within the Project Bay. I'm not saying that you shouldn't be able to marquee-up a group and have auto-linking for coincident takes happen as default without opening a group manager (far from it), but I think we need to allow choices and workflow differences from this fixed default.
Linking coincident takes across (multi)tracks in these groups automatically should be the default or possible as the default, but including linking would allow opting out of this default for if the group wasn't coincident multitracks (eg sequential rhythym and lead guitars, inc harmonies, for layering) or (eg) maybe to except a smattering of drum hits, which could then be replaced by samples/flown hits, manually added into the group ( and possibly back into the linking). To put it succinctly, allow manual removal and addition of items and takes to take-linking, and display linking status within the group.
The biggest headache might be the UI. How to clearly show and edit linked items in Item Groups, how to disable linking in maybe down to just one item or just one take from the auto-linking? I'm afraid I have no useful suggestions for this ATM.
I think this could be made to offer the functionality bemoaned by (ex) PT users missing playlists/edit groups. Conincident take linking and comp recall across a named group. Maybe not having to create an edit group like PT, but having certain take-linking functionality happen in item groups while allowing selective "opting-out" within the Project Bay...
Please consider this for workflow flexibility for your multitrack editing users.
>
Last edited by planetnine; 09-07-2016 at 04:17 AM.
|
|
|
09-07-2016, 04:58 AM
|
#26
|
Human being with feelings
Join Date: Jul 2006
Posts: 12,480
|
Clipmax 1.2.3 x64 is showing grey space rather then white space on resize (so you can't double click anywhere to get it resized down):
Last edited by Dstruct; 09-22-2016 at 09:10 AM.
|
|
|
09-07-2016, 05:04 AM
|
#27
|
Human being with feelings
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,467
|
Quote:
Originally Posted by esosotericmetal
Yeah, I honestly can't see how someone can make a ton of edits to multiple items before quickly realizing they forgot to group them.
|
Hmmm... I dunno - like maybe you port a mix to REAPER that was tracked and partially edited in another DAW?
Since there isn't another way of creating at "edit" group, it's intuitive to just marquee select everything in those tracks and group them.
Also I use groups somewhat fluidly. I have a toolbar icon that toggles the option that selecting one item in a group selects all items in the group. This is handy often in the arrangement stage where I might be moving different sections around within regions - or just to be able to mute or manipulate a bunch of items quickly.
|
|
|
09-07-2016, 05:13 AM
|
#28
|
Human being with feelings
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,467
|
Quote:
Originally Posted by planetnine
Linking coincident takes across (multi)tracks in these groups automatically should be the default or possible as the default, but including linking would allow opting out of this default for if the group wasn't coincident multitracks (eg sequential rhythym and lead guitars, inc harmonies, for layering) or (eg) maybe to except a smattering of drum hits, which could then be replaced by samples/flown hits, manually added into the group (and possibly back into the linking). To put it succinctly, allow manual removal and addition of items and takes to take-linking, and display linking status within the group.
The biggest headache might be the UI. How to clearly show and edit linked items in Item Groups, how to disable linking in maybe down to just one item or just one take from the auto-linking? I'm afraid I have no useful suggestions for this ATM.
>
|
For some of the edits you describe, the user might ungroup the items, make the edit, then regroup them.
That seems the simplest solution, however there would need to be a straightforward way to reestablish the group.
The expectation that the user would always group, then split, and then have no reason to undo this grouping is unrealistic.
|
|
|
09-07-2016, 05:56 AM
|
#29
|
Human being with feelings
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,922
|
Quote:
Originally Posted by James HE
The expectation that the user would always group, then split, and then have no reason to undo this grouping is unrealistic.
|
Agreed, and shit can happen while editing. God knows I've messed up at times and been greatly puzzled about my editing session and grouping.
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
|
|
|
09-07-2016, 07:30 AM
|
#31
|
Human being with feelings
Join Date: Apr 2010
Posts: 27
|
Quote:
Originally Posted by Justin
yeah a native version of that script might be handy...
but also realistically one would group the items before doing a ton of splits, in real world use...
|
For music that is not click based the takes are usually recorded not vertically on top of each other (takes-comps system) but horizontally besides each other. It is very realistic to have many multi-track items that need to be vertically grouped. I have done this manual selection and groupings too many times already until I discovered this script. For my work this is a must have add-on.
A better hack would be a way of telling Reaper to automatically group items that will be recorded.
I'm sure that in classical music field people are doing manual groupings by hundreds every day...
I strongly feel that Reaper should have an additional and more flexible grouping system for multi-track items.
|
|
|
09-07-2016, 07:32 AM
|
#32
|
Human being with feelings
Join Date: Oct 2007
Location: Lincoln, UK
Posts: 7,924
|
Quote:
Originally Posted by James HE
For some of the edits you describe, the user might ungroup the items, make the edit, then regroup them.
That seems the simplest solution, however there would need to be a straightforward way to reestablish the group.
The expectation that the user would always group, then split, and then have no reason to undo this grouping is unrealistic.
|
Point taken. Can the group be saved and then reapplied after the splits? I've written scripts that deal with items and their GUIDs and work out the new items' IDs after a user item split. It might end up going down the fuzzy-logic rabbit-hole though..
Can "un-applying" the group be an alternative to completely un-grouping? Reapplying can then use a little logic to re-establish the group, including splits from existing members with the same source files, timeline position, etc.
You can always add to groups in PB Item Groups using D+D.
Dunno, I'm brainstorming here, nothing is going to be perfect for all workflows I guess...
Definitely need that group consolidation after split action though, or an option not to split the group on item splits.
>
|
|
|
09-07-2016, 08:12 AM
|
#33
|
Human being with feelings
Join Date: Nov 2012
Posts: 372
|
It seems that all that is really needed is a native version of that script mentioned above and maybe some other actions related to grouping. Anything more (short of edit groups) seems unnecessarily fiddly and sort of duct taped on.
With the other scenarios described is the functionality not covered by a) disabling groups b) group and ungroup c) using the x-raym script or d) making a custom action?
|
|
|
09-07-2016, 08:39 AM
|
#34
|
Human being with feelings
Join Date: Jul 2009
Posts: 7,570
|
personally I like how grouping (for edits) works now. It works perfectly for video editing, unlike every video editor I've tried.
|
|
|
09-07-2016, 09:00 AM
|
#35
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,669
|
Quote:
+ MIDI: improve behavior when stopping overdub/replace recording with held notes [t=180453]
|
thanks for looking into this bug. what behavior should be different now? unfortunately, i'm still getting the same "infinite note" results as described in their various manifestations in the report thread.
see gifs:
^ while overdubbing a kick drum. first pass, 2 kicks are recorded. 2nd pass, 1 kick is recorded before the other kicks. infinite note appears as soon as note is recorded. if note is held over the NOTEON of the next note, infinite note is recorded. desired behavior: while in overdub mode, set the note length to last up until the play cursor, not default to infinite note length.
here it is again with a chord being recorded in overdub mode.
next up: when overdubbing in a time selected loop, notes held over the loop point create a new note at loop start, rather than the duration continuing past the loop point.
maybe it's naive of me to think this, but i feel like this all would be resolved if there wasn't this assumption of infinite note length. it looks wrong, it feels wrong, and it causes a lot of issues for recording in Overdub mode.
Last edited by mccrabney; 09-07-2016 at 09:12 AM.
|
|
|
09-07-2016, 09:39 AM
|
#36
|
Human being with feelings
Join Date: May 2009
Location: Brazil
Posts: 323
|
Can I expect a review of this issue...
http://forum.cockos.com/showthread.php?t=179015
Since MIDI is under focus in this cycle? I still believe an ´exclusively activate item´ in both action list and mouse modifiers would be quite useful for many of us.
Thanks.
__________________
Ceanganb
|
|
|
09-07-2016, 09:49 AM
|
#37
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
Quote:
Originally Posted by mccrabney
thanks for looking into this bug. what behavior should be different now? unfortunately, i'm still getting the same "infinite note" results as described in their various manifestations in the report thread.
maybe it's naive of me to think this, but i feel like this all would be resolved if there wasn't this assumption of infinite note length. it looks wrong, it feels wrong, and it causes a lot of issues for recording in Overdub mode.
|
The fix in pre1 is only for when stopping recording with held notes.
Quote:
+ MIDI: improve behavior when stopping overdub/replace recording with held notes [t=180453]
|
I've duplicated some of the bad behavior you mention, which is unrelated, hopefully we can fix that easily enough.
Last edited by Justin; 09-07-2016 at 10:23 AM.
|
|
|
09-07-2016, 09:59 AM
|
#38
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
Quote:
Originally Posted by juliansader
However, there is an amusing-looking bug: When I try to run my LFO Tool script on the tempo envelope, I get this:
In previous versions, the tempo envelope has never gone crazy.
|
It seems to me that the first course of action when a script does something funky should be -- what is my script doing wrong? I'm guessing from that screenshot it's doing something like inserting an envelope point in the wrong place with a noSort=true... so maybe don't do that?
|
|
|
09-07-2016, 10:25 AM
|
#39
|
Human being with feelings
Join Date: Apr 2014
Posts: 151
|
I know autosave was looked at i think 1 pre back - is it possible to have a limit on the number of saves? in my case i dont really need more than 5. I have currently just set the interval a bit longer but generally would want maybe four for the last per session and after that the rest can get overwritten. The option would be great as I have to go deleting GB's of space all the time
|
|
|
09-07-2016, 12:08 PM
|
#40
|
Human being with feelings
Join Date: Mar 2007
Location: I'm in a barn
Posts: 4,467
|
Quote:
Originally Posted by esosotericmetal
It seems that all that is really needed is a native version of that script mentioned above and maybe some other actions related to grouping. Anything more (short of edit groups) seems unnecessarily fiddly and sort of duct taped on.
|
I think there could be some underlying preferences that would define the behavior. Similar to the preference to not split all the items at the edit cursor if nothing is selected - that's something that new users can easily get tripped up on. The interaction of groups and the take switching i feel is very similar in that it creates a situation where users are making edits they don't intend to make. I strongly believe that steps to be taken to prevent that.
Quote:
Originally Posted by esosotericmetal
With the other scenarios described is the functionality not covered by a) disabling groups b) group and ungroup c) using the x-raym script or d) making a custom action?
|
disabling groups pretty much does it, fortunately. So yeah a native way to "fold" a new item or take, logically, into correlating existing groups does pretty much cover it.
Initially my reaction to the way things worked was skewed because I was trying to break it - but I missed the obvious so I didn't really interpret what I was seeing correctly.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 12:27 PM.
|