What's happened to the Advanced Comparison controls such as...

[chrisjj]

... Ignore file extensions? I can't find this anywhere.

[Zoë]

It's been replaced by the "Alignment overrides" option on the "Misc" tab. It supports specific overrides like lining up *.txt to *.bak, rather than globally ignoring all extensions.

[chrisjj]

> It's been replaced by the "Alignment overrides" option on the "Misc" tab.

I cannot see how that provides "Ignore file extensions". Please tell me how.

[Zoë]

It doesn't. All of the tech support questions we've gotten about it have been for specific instances of lining up one type of file with another, and we feel that this better supports that than the checkbox to ignore extensions did.

[chrisjj]

> It doesn't.

Ah. Thanks anyway.

> All of the tech support questions we've gotten about it have been
> for specific instances of lining up one type of file with another,

Perhaps because those support questions requesting line up of all files (like mine in 2005) ceased when BC added this feature in V2.4.

Meanwhile, is there any particular reason why BC3 doesn't act upon:

Align left file (or folder):
.*
with right file (or folder):
.*

??

[Zoë]

Perhaps because those support questions requesting line up of all files (like mine in 2005) ceased when BC added this feature in V2.4.

The vast majority of support requests both before and after "Ignore extensions" was added have been in the form "I need to line up all my .bmp files to their .jpg equivalents". The current functionality provides that in a more general case as well as allowing manual alignments.

I wasn't able to find anything from you regarding this in 2005. You've sent quite a few emails and forum posts though, so I can't say I checked every one. What are you trying to do that the old behavior worked for and the new behavior doesn't?

Meanwhile, is there any particular reason why BC3 doesn't act upon:

Align left file (or folder):
.*
with right file (or folder):
.*

The BC3 behavior works by transforming a filename on the left through the two masks to a specific filename on the right. So if the masks are "*.bmp" and "*.jpg", then it can tell it needs to try aligning "ABC.bmp" with "ABC.jpg". Using "*.*" as the "with right file" option doesn't give it an unambiguous target filename to look for.

[Michael Bulgrien]

Using "*.*" as the "with right file" option doesn't give it an unambiguous target filename to look for.

Just an idea... If the user specifies a wildcard for the extension, perhaps BC3 could "transform" the filenames on both sides to one without an extension.

[chrisjj]

> I wasn't able to find anything from you regarding this in 2005.

*From:* [email protected] (Chris John Jordan)
*Date:* Sun, 30 Oct 2005 16:59 +0000 (GMT Standard Time)
PS It would be nice to have Comparison Control "[] Ignore filename
extension".

*From:* Scooter Support <[email protected]>
*Date:* Mon, 31 Oct 2005 10:23:20 -0600
...
Also, ignoring file extensions is on our todo list for a future release
of BC.

Regards,
Chris Kennedy
Scooter Software

I don't think it was smart to remove this BC2 feaature in BC3.

> What are you trying to do that the old behavior worked for and the new behavior doesn't?

Find matches between e.g. .WAVs on one side and any type on the other, inc. any audio types.

> Using "*.*" as the "with right file" option doesn't give it an unambiguous target filename to look for.

Sure, but my question was about ".*".

[Zoë]

It would be nice to have Comparison Control "[] Ignore filename extension"

For BC2 we were more willing to add "Ignore filename extensions" without asking for context because it was in BC1. For BC3 we're taking the opportunity to step back and look at various features with a more critical eye. In our opinion, the cases where users gave us background information were better served by the current implementation.

I don't think it was smart to remove this BC2 feaature in BC3.

Noted, but we don't agree. If we hear any user cases that can be solved with "Ignore file extensions" and can't using the current feature, we may change our minds.

Find matches between e.g. .WAVs on one side and any type on the other, inc. any audio types.

Put the .wav files on the right, then put "*.*" in the "Align left file" edit and "*.wav" in the "with right file" edit.

Sure, but my question was about ".*".

Michael's suggestion was regarding "*.*", but it applies to your case as well. As I said previously, the two masks are used in combination with each left file to produce a single, unambiguous filename to look for on the right. It's a 1-to-1 mapping.

[chrisjj]

> For BC3 we're taking the opportunity to step back

Evidently.

>> I don't think it was smart to remove this BC2 feaature in BC3.
> Noted, but we don't agree.

Fair enough, though I still don't see why you cannot allow ".*".

And thanks for letting me know about the undocumented "*.*" option.

[Zoë]

I'm not sure what exactly what you're suggesting ".*" would do or how it would be different than "*.*".

[chrisjj]

Put the .wav files on the right, then put "*.*" in the "Align left file" edit and "*.wav" in the "with right file" edit.

It is really intended that Swap Sides changes the alignement upon a Full Refresh?

[Zoë]

Yes. The manual alignment strings can be regular expressions, which we couldn't swap automatically even if we wanted to. I don't seriously think anyone is going to swap sides after setting up a bunch of manual alignnments, so it shouldn't be a problem.

I've already told you that if you want us to change the behavior you're going to have to come up with a real use case that can be solved with the previous behavior and can't be with the new one. Picking apart specific interactions like this is not going to cut it.

[chrisjj]

> The manual alignment strings can be regular expressions, which we couldn't swap automatically even if we wanted to.

What's the problem with swapping "Align left file (or folder):" and "with right file (or folder):" values?

> I don't seriously think anyone is going to swap sides after setting
> up a bunch of manual alignnments

Sorry - wrong already. And I was aided and abetted by the Swap Sides button, which I note did not change to read "Swap Side and mess up comparison"

Loss of BC's comparison commutativity is a bad idea.

> I've already told you that if you want us to change the behavior you're
> going to have to come up with a real use case that can be solved with
> the previous behavior and can't be with the new one.

Impossible, because when I e.g. compare two mixed-format audio libraries, the Alignment Override Apologist can always require me to enter a stack of extensions manually.

Whereas the BC Usability Champion already knows the advantage of Ignore Extensions.

[Aaron]

Screenshots of your specific files and task will help us understand why the manual alignments are having trouble meeting your needs. We've been using them in house awhile and they are generally more powerful than the Ignore Extensions option was.