Dragging audio to the Timeline with the "Drag Audio Only" button should override Source Patching!

[Pierre Louis B.]

When dragging audio to the Timeline from a clip in the source monitor with the "Drag Audio Only" button, that audio should get dragged to the Timeline regardless of whether or not the Timeline's source patching for audio is turned on or off!

What's the sense of preventing a user from using the "Drag Audio Only" function when audio source patching is turned off, when it's clear that what they want is to drag&drop their audio?!  This is counter intuitive and illogical from a USER'S point of view.  It might make sense from a programmer's POV, but who cares if it provides absolutely zero benefits to the user and only makes the interface more tedious to deal with?

Adobe, please make Pr more FLEXIBLE and INTELLIGENT! 

Thank you!

[RobShultz]

I can think of multiple users where the main editor turned off audio track patching to a channel so that a clipped wouldn't be dragged into that track. There may be good reasons why the feature you're mentioning is working as it was designed to work.

[Pierre Louis B.]

@RobShultz, if an editor uses the "Drag Audio Only" button, it's because they WANT to drag a clip's audio to the Timeline.  Period.  That's why that specific button should override Source track targeting.  Isn't that an easy enough concept to understand?  Now... If an editor drags the CLIP from the Source Monitor, then YES, it should respect Source track targeting.  But that is NOT what I'm talking about here.  Please at least try to understand the Feature Request before responding with a pointless response.

[R Neil Haugen]

I don't think Rob's comment was at all unthinking. I thought he has a pretty good point.

For many colloborative uses, a senior/lead editor will set the sequences or oversee their setup. Which will often include very detailed audio tracks, as in some place b-cast specs require a TON of specific tracks in specific order.

In those situations, you would not want to allow a simple override by drag/drop. Especially, as it's quite possible with 'small' track heights, to accidentally drop on the wrong track. I've done that many times myself.

But ... allowing this as a user toggle choice, I can see.

I would not agree with this as a total override.

Neil

[Pierre Louis B.]

You completely miss the point Neil.  Using the "Drag Audio Only" button in the Source Monitor is an EXTREMELY SPECIFIC action.  The chances of someone using that button by mistake instead of using a keyboard shortcut to Insert/Overwrite or instead of Drag & Droping a clip from the Source Monitor is next to ZERO.  THAT'S why that command should be respected every time a user uses it.  Period!  IF a user wants to drag just the AUDIO from the Source Monitor to their Timeline, why are they forced to turn on Audio Source Patching first if they want it OFF for all of the other clips they're sending to their Timeline using the other 3 methods mentioned?

As I said and repeat, the current way it works may seem logical from a programming standpoint, but it is 100% certifiably ILLOGICAL from a workflow standpoint.

Can't you see that?

You wrote as a defense of the current workflow: ...often include very detailed audio tracks, as in some place b-cast specs require a TON of specific tracks in specific order."  The point of my FR is that the "Drag Only Audio" button DOES work if ANY audio track is patched, but it DOESN'T work if they're all turned off.  So that comment is irrelevant.

You also wrote: "you would not want to allow a simple override by drag/drop. Especially, as it's quite possible with 'small' track heights, to accidentally drop on the wrong track."  Except that that is exactly the way dragging audio from the Source Monitor currently works.  Even if A1 is patched, the user is allowed to drag the audio to ANY audio track, whether it is enabled or not.  I have zero issues with that part of the workflow.  That makes this argument equally irrelevant.

As you can hopefully see now, your response is misguided, just as Rob's is.

My FR is to remove a tiny yet annoying bit of friction in Pr's workflow.  This would benefit every editor that encounters the same situation I come across from time to time, while also providing zero disadvantages to all other users.

[R Neil Haugen]

What is a path or workflow you might like, is not necessarily something  someone else might like.

You are most welcome to post your ideas, please do so ... but also, you should expect others to comment on what they might like or not like. That's how a group process works.

I find the diversity of how humans do things always fascinating. But I don't get disagreeable with anyone simply because we disagree. I never expect anyone to agree to begin with.

Neil

[RobShultz]

You've posted your request in the right place. If the Adobe engineers agree they will take it up. Now may be a good time to sit back and have a decaf cup of coffee.

[Pierre Louis B.]

What's worrysome is that both you and RobShultz are "Community Expert"s, and yet here you are both, unable to understand an extremely easy editing concept.

Part of avoiding being "disagreeable", as you say, is not posting nonsense before even understanding the concept at hand.  It's not that I disagree with you Neil, it's that your statements were flat out incorrect.

You wrote: "What is a path or workflow you might like, is not necessarily something someone else might like."  Please enlighten me... what is there that anyone could possibly not like about the Pr team fixing the workflow inconvenience I'd like them to fix?  If you can come up with a single valid argument, I'm all ears.  But as I wrote already, there are simply no downfalls to this workflow quirk being fixed.... unless the editor is a masochist who enjoys extra unnecessary steps in their workflow just because...

So much for the 'Expert' designation.  But I digress.  By all means guys, keep posting irrelevant arguments rather than contributing anything of value to the conversation.

[R Neil Haugen]

I simply don't understand the angst.

I've already said this would be fine in my opinion with a toggle to permit it or not.

[Pierre Louis B.]

It's just that it's annoying when people respond to a FR raising non-issues that don't apply or don't even make any sense, simply because they didn't understand the post before responding.

What would be the purpose of a toggle to permit it or not?  This would require a lot more programming effort on Adobe's part for zero benefits.  Would having a toggle to make the Spacebar serve as a play/stop shortcut or not be of any benefit to users?  It clearly wouldn't.  Nor would a toggle be of any benefit whatsoever in this case.

Bottom line, when raising issues with a FR, make sure you actually understand the FR first.  Otherwise the issues raised will most likely be incorrect, as was the case here.  I find it baffling since this FR is really simple to understand.  You can try it out for yourself!  Set Source Mapping to Video only, and add a bunch of clips from the Source Monitor to the Timeline, one by one, using drag-drop, or shortcuts for Insert or Overwrite.  Now, on the 10th clip, try dragging that clip's audio to your Timeline using the "Drag Only Audio" button.  Doesn't work, does it?  Why not?  Because that button wasn't programmed to work intelligently, that's why!  Why limit that button's use with Source Mapping when there is simply no advantage whatsoever in doing so?  All I'm asking is for the Pr team to make it intelligent.  You seem to be asking for a toggle so users can choose between:

1. Intelligent way (what I suggest)

2. Stupid way (the limited way it currently works, providing zero benefits to anyone)

Now why on Earth should Adobe fix something only to give users a toggle so that they can revert back to the old, stupid way it worked before?

BTW, before responding, please test it out for yourself so that you ACTUALLY understand the issue at hand first.  Only then is it possible to have an intelligent, productive conversation.

[R Neil Haugen]

I have tested it. And used this for years.

Why you insist anyone who even accepts your suggestion, though with an added user option,  is basically an idiot, and can't possibly have tested this ... that I don't get.

Neil

[Pierre Louis B.]

And why do you insist that users would need an option to revert to the current behaviour when it offers zero benefits and only disadvantages compared to what I suggest, giving much more work for the Pr team to program and adding complexity to Pr?

I challenged you to come up with a single benefit of the current way vs the fix I suggest.  You've failed to provide any.  Rather you seem to get a kick out of arguing for argument's sake.  As I said, the fix I'm suggesting isn't rocket science.  It's extremely simple to understand and self explanatory.

Tell me Neil, what do you get out of trolling on this site?

[R Neil Haugen]

I'm not insisting on anything, nor challenging anyone else's thoughts or ideas. Nor demanding others merely submit passively to my ... thoughts.

I merely added what to me, is a sensible alternative, one that would make this more amenable to more users. And wouldn't hurt your proposal in any way. I see no basis nor logic for your assumption that your process would be 'easy' in code and any mod to it would be difficult. None whatsoever.

We are all welcome to assumptions. We also need allow others the same grace.

Your open hostility is ... unfortunate. Misplaced. And puzzling.

Neil

[Rag and Bone]

Just one vote so far...just saying.

[R Neil Haugen]

And that was me, of course ... 😉

[Pierre Louis B.]

What's puzzling to me is your refusal to recognize how your arguments don't make any sense.  The current way it works is illogical.  I've explained why at length.  You, nor anyone else, has provided a single valid argument in favour of the way it currently works.  Why defend an illogical workflow by insisting users would need a way to revert to it after it is fixed?

What could possibly be the benefit of preventing users from using the "Drag Audio Only" button when Source Patching for audio is turned off?  If an editor uses that button, isn't it because they WANT to drag the clip's audio to the Timleine?  Every single time?  Whether they remembered to turn on Source Patching for Audio first or not?  If you don't want to drag your clip's audio to the Timeline, simply don't use that button.  Simple!

Limiting the use of the "Drag Audio Only" button to when source patching is turned on is nothing more than a silly stumbling block in an editor's workflow, one that could easily be fixed without any downsides whatsoever to anyone.

@Rag and Bone, as they say, if you don't have anything of value to contribute, why bother writing in the first place? 😉

[R Neil Haugen]

You've made it clear that according to you, only what's logical to you is actually logical.

You use hostility throughout your responses.

So past your initial post, I do not find any of your posts of any additional interest or value.

And after several days, I am still the only person who has voted for your idea. I don't think your comments are helping to advance your suggestion.

Neil

[Pierre Louis B.]

I've tried again and again to explain the workflow issue at hand with provable facts and your response is that I'm being hostile and that none of my responses are of any value?  Why don't you give it a rest Neil?

[R Neil Haugen]

Sure thing.