The rather strange behavior of the 'Insert Silence' function…

Hi, all

Not a big deal (at least for me, as I don’t use it often), but the Insert Silence function behaves rather strangely, IMO, when there is no range selection done :

Before :

After :

Actually, what is happening is that the whole existing material has been moved beyond the right locator (which was at 33.1.1.0). I saw this immediatly, thanks to the Overview line and ctlr+Z is our friend, in this kind of situation.

Naively, having an audio event selected without any range selection done, I thought that the Insert Silence would then move the existing material with an amount of the size of it : it’s not the case, obviously.

So, I do not want to start a endless debate, but I’m truely wondering if there is an actual use case where throwing everything on the right according to the right locator position instead of a previously done selection length could be useful : after all, a range one is also… a selection, and the current behavior isn’t documented, AFAIK.

At the end, I wouldn’t qualify this as a bug, but it seems rather strange to me, unless some of you can make me think twice about it. Thanks…

Sounds to me it’s doing exactly as expected.

In this case, the “Range” selection is the left and right locator.

I hope my memory doesn’t fool me, but I think inserting silence was already working like this before there even was a “Range” selection tool.

From which my inquiry : why not an eventual previous selection done at first ? I would see this rather more logical and useful (i.e. rythmic context…). I know that the locators are essential in Cycle mode, but still… It seems more easy to me to do a selection on the material already existing before inserting silence.

Any use case that could contradict my POV ?

Could be, but I’m unable to confirm : as I stated previously, I’m not used to the feature. Thanks for chiming in, by the way… :slightly_smiling_face:

1 Like

My best guess is that Steinberg generally try to keep things backwards compatible as much and long as possible to avoid breaking workflows, macros and scripts.

That leads to historical oddities and inconsistencies, when new features and workflows get introduced.

And that’s rather common in systems that stick around for a long time.

I empathize with software developers, because they are in a can’t win situation: Breaking backwards compatibility pisses off upsets lots of users. And inconsistencies due to that approach also does.

1 Like