Having Alternate / Selectable Naming Rules for Saving?

MusicBrainz Picard
1

To save with different rules you’ve got to change the contents in the Naming Script option setup as there is no way to use a different script when saving from either Left or Right without code changes/additions to support / store multiple Naming Scripts similar to how the Tagger Scripts can be chosen from the Contextual Menu now?

Except that Naming Scripts would default to the first one. If you want to use any other rules to save against, you’ll need to use the Contextual Menu to select a Naming Script the same way a Tagger Script is selected.

Though I suppose if you want that functionality now it could be set using some hardly used tag to hold a value.

Before saving, select all your stuff that you want saved differently and add/edit some hardly used tag:

$if($eq_any(%bpm%,666,777,888,),
$set(%_saveScriptRules%,%bpm%),$set(%_saveScriptRules%,999)

$if($in(%_saveScriptRules%,666), ... build %_pathNameForSave% ... )
$if($in(%_saveScriptRules%,777), ... build %_pathNameForSave% ... )
$if($in(%_saveScriptRules%,888), ... build %_pathNameForSave% ... )
$if($in(%_saveScriptRules%,999), ... build %_pathNameForSave% ... )

$noop(and then finish up the rest/common stuff next)

$set(_fileNameForSave, %artist% - %title% %_fee%%_fi%%_fo%%_fum% Do As I say Here)
$noop( ...and finish by)

%_pathNameForSave%/%_fileNameForSave%

2

Something like PICARD-9 or its related issues?

3

I should have known to look there… and then poke a thread about it…
9, eh? Yeah. That’s been on the block for a while. :slight_smile:

Yes. That about sums it up.

Or for the time being, use a HackAroundMethod :face_vomiting: like I wrote.

4

I’ll see if I can find the link in the past forum of the discussion, but we put a hack method together that made use of multiple ini files and different desktop shortcuts.

"C:\Program Files\MusicBrainz Picard\picard.exe" -c %APPDATA%\MusicBrainz\ClassicalPicard.ini
"C:\Program Files\MusicBrainz Picard\picard.exe" -c %APPDATA%\MusicBrainz\PopMusicPicard.ini

Here is it:

2 Likes
5

I made a shell script to mv one to the other and back to do kinda the same thing. I figured it Iwas going to have to quit and relaunch I may as well just store scripts in the Tagger Script section, and copy/paste what I want out from there.

But… :wink: An even more sketch hack. More like Dragons -AND- Zombies. Just do NOT go there.

I run two instances of Picard and edit the config with the other one. :wink:
Actually… (yeah, we don’t want to hear this I’m sure ) … I let a couple of them run and get twice as many files sorted.

Kids, Do Not Do This At Home! DO NOT ATTEMPT.
PROFESSIONAL DRIVER on CLOSED COURSE.

2 Likes
6

For Windows users it is going to be very easy by using multiple portable installations of Picard.
(hopefully an official release will be published soon)

1 Like
7

Just spitballing here as I haven’t tried this.

I think you could have a number of tagging scripts like:

$set(_usenamingscript,1)

And others that set it to 2, 3, etc.

Then you can select the appropriate releases, right-click and run one of these scripts. In your naming script you would then have $if statements to check this variable and apply the correct naming scheme.

Thinking about it, if you drop the underscore, then this tag would be saved to your files and you would only need to set it once. Whenever you update after that, it would just choose the correct portion of the naming script automatically.

2 Likes
8

As we found in that thread, there is no need at all for portable installs. Just a set of separate ini files which could be stored anywhere. Easier to stick to one version of the application and use multiple settings files.

It is also a trick that will be the same for all OS versions. Just requires different ways of writing the path, and I’m pretty sure all OS let you change the shortcuts and arguments.

9

Well, not always. Especially when plugins pose problems with certain Picard versions it is great that you can have different versions of Picard on your system.

E.g.:
‘Classical Extras’ currently doesn’t work well with Picard 2.2 and higher.
‘Format Performer Tags’ seems to have a problem with Picard 2.3

With portable installs you can have different versions on your computer so you’re able to keep using problematic plugins.

edit:
also, I am not sure how robust the ‘separate ini’s’ solution is when you are doing something stupid like trying to open a new instance (shortcut) of Picard while another one is already running.
I am not 100% sure of it, but I think I created some problems when I did that accidentally once or twice.
I am guessing separate portable installs will be much more immune to such problems.

2 Likes
10

Ah, yeah, I did kinda expect it may be that. That is a little bit of a concern that now the main App is getting all these updates that plugins are causing the need to go multi-setup.

Anyway - dragons are clearly in charge now. :dragon: working alongside the chaos fairy :fairy:

11

1 Like
12

I just tried my suggestion up above and it works like a charm. I added two scripts to set the variables %usereleasecomment% and %usemediatype% (plus two more scripts to delete those variables in case I change my mind on a specific release).

Then in my naming script, I have the lines:

$if(%usereleasecomment%,$if(%_releasecomment%, \(%_releasecomment%\)))
$if(%usemediatype%,$if(%media%, \(%media%\)))

I right clicked on the releases and chose the appropriate scripts, and folders were named correctly. I then tried again and confirmed the variables were written as tags so they are persistent.

2 Likes