Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Feature Request

Audio ghost copies Issue Tools
issueid=52 06-14-2009 06:19 AM
stk stk is offline
Human being with feelings
Audio ghost copies
Ability to paste 'ghost' copies, which reflect any and all changes made to their 'parent' event.

Ability to paste 'ghost' copies of an event, which reflect any and all changes made to the original ('parent') event.
Likewise, changes made to a ghost copy should update its parent.

Ghost copies, and ghosted events (ie parents) should be visually distinct (colour tint or outline?).

Should include a one-step command to make a particular ghost copy 'unique'.
Issue Details
Issue Type Feature Request
Project Deprecated REAPER issue tracker
Category Editing behavior
Status Suggested
Priority 4
Suggested Version 3.03
Implemented Version (none)
Users who would use this feature 27
Users who would not use this feature 1
Assigned Users (none)
Tags (none)

06-14-2009 08:30 AM
Human being with feelings
 
Nice idea. That could work to many peoples advantage, as they regulate minute changes of a drum groove that is made up of grouped audio items for example, to control each element across the entire session from one spot.

I'd like to add some ideas on how this may work.

The quickest ways may be to declare an item a ghost parent with an action, another button in the top of the item itself, an action tied to an icon or the right-click menu.

The way that works could then be that any copy made of that item(s) becomes a ghost item of it, in other words a ghost child. This ghost child could be indicated again by a button at the top of it, which gives the user the chance to just switch it off locally.

Another way to get rid of the ghost child status would be to use the action that makes the ghost parent.

If that action detects that the selected item is a ghost child, it will turn off that status. Perform that action again and the item will become a ghost parent. So the 'make this item a ghost parent' action would also serve as a way to remove any ghost parent/child status form the selected item(s) as well.

One thing to consider is, what happens to ghost child items you edit ? Should you be able to ? If not, then there's no problem. However if you permit editing of ghost child items, it is probably best to remove the ghost status entirely. A more complex solution is to have the ghost child status be separate for each of the items properties in this regard, at least as much as possible.

As soon as an edit is done to the item gain on a ghost child item for example, it will either no longer respond to changes in the item gain for the original ghost parent item, or to become even more complex, it will simply be added together. That way you'd have relative control over a whole range of ghost copies of your items, while still being able to make individual changes.

The next problem is item-fx and item automation. Doing a static ghost parent/child relationship is probably not hard. Ghost child items simply reflect the ghost parent item in every way, including the item fx.

When you permit changes to the item fx of any ghost child items, you automatically need to instantiate the item fx plugins again, because their settings are different. In terms of performance it could be the best interest of the user to at least keep that non-editable in the ghost child items. The item-fx would need to lose their relationship to the ghost parent item completley, and thus the user will not be able to control that particular item-fx in a ghost child item from the ghost parent item.

The item automation of the ghost child items and the ghost parent item could be combined.

As the user creates ghost child items by either copying the ghost parent item or any of the ghost child items, it will become necessary to have the edit of a ghost child item be reflected in both the other ghost child items and the ghost parent item. In other words, it would become necessary for one of the ghost child items to become the ghost parent, and the ghost parent to become a ghost child item.

One of the methods this could be achieved with is making the ghost status of the item (parent,child,none) be a cycle that alternates between parent and child status with a left-click, and removes any ghost status with an ALT+left-click, as we do when we delete insert effects.

Did I miss anything ?
Reply
06-14-2009 09:24 AM
Human being with feelings
 
Sounds good but different.

Audio ghost copies (in my current host) apply to editing changes made to the source audio, not to envelopes (fades, volume envelopes, etc) as those things are already covered in edit grouping. So for instance if there are shared audio clips in a project and I notice a flaw, an off beat kick drum hit in a drum loop for example, I go the audio editor and highlight that hit and slide it back a little, all of the shared copies get that edit.

How this would work under Reaper's editing paradigm I don't know. What happens if you split a shared/ghosted part, do they all split? If you split a shared part into 3 sections and move the middle section do they all split and do all of the middle sections move? It's a little different from non-destructively editing the virtual source of audio for multiple clips and having the clips reflect those changes.

In Cubase all copies of audio clips are always shared until you tell it otherwise. It's up to you - when you make a change to one - to decide if you want the change to happen to all, or to create a new clip with the edit.

Or you can set a preference...

Quote:
Open Options Dialog
An Options dialog appears, allowing you to select whether you want to create a new version of the clip or apply the processing to the existing clip.

Assume New Versions
A new editing version of the clip is automatically created, and the processing is applied to that version (leaving the original clip unaffected).

Assume Skipping
The processing is applied to the existing clip (which means that all events playing that clip will be affected).
Anyway, the "ghosting" in this case is for the behavior of the raw audio and any edits to the raw audio, not for things that are covered in edit groups. It may end up something different in Reaper.
Reply
06-14-2009 05:19 PM
stk stk is offline
Human being with feelings
 
Thanks for extending the ideas, folks. I know there's a lot of support for this one, and I'm far from the first to suggest it.

Obviously there's some difference of opinion regarding exactly what is shared by the children/siblings.
My preference is with sharing edits / fades etc but not automation, but in true Rpr fashion it'd be lovely to have it all as preferences.
Reply
06-16-2009 06:46 AM
Mobile
 
Surely this is just as relevant to MIDI? The current way really isn't up to the job - .MID file based working prevents recording into the items etc, so I'd love to see a unified paradigm for Audio and MIDI.

+1 for allowing any "ghost"/"clone" item to be parent or child - with multiple parents allowed.. just as with the track grouping "master/slave" options.
Reply
06-16-2009 08:41 AM
Human being with feelings
 
That might be interesting. I've not used shared copies in that manner.

Currently the way they behave (audio or midi) in the hosts I use that have them is that they are "shared" and there is no parent/child relationship. They're all multiple instances of the exact same clip (source data).

Make a change to any one of the many and they all change... any that are "shared". You don't have to edit the "parent" to change them all, you can edit any of them. If you need an independent one make one that's not shared.

Reply
06-16-2009 01:02 PM
Human being with feelings
 
I like the shared content but unshared container idea.
Reply
08-20-2009 04:37 AM
Human being with feelings
 
It's possibly worth noting the "parts" discussion here: http://forum.cockos.com/showthread.php?t=17664

In lieu of complex parts, though, I'd love to see Cubendo-style, "light" parts ASAP. This really is a must-have for me. Let's hope that this FR gets into the elevated section. :-)
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 10:50 AM.


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