Hotcode Code Generator for the same variable in more than one namespace

[ejhutch]

Hi,
Is it possible to have a hot code code generator for the same variable in more than one namespace?

I'd like to be able to do something like [volume.root]/[volume.prefix][workflow.preingestfolder]

However, if I have "local" in usercustom3, [volume.prefix] seems to evaluate to what I would expect [workflow.preingestfolder] to evaluate to "To Ingest1"... and [workflow.preingestfolder] also seems to evaluate to  "To Ingest1". What seems to be going on?  Thanks!

Example Hotcodes definition:

//$$   volume
//##   prefix   volume   root   backuproot   
//==   {usercustom3:0:lc}
//==   {clientcustom3:0:lc}
//??   local      Pictures   PicturesBackups
local   Local_   /Users/edhutchison   Pictures   PicturesBackups
mobile   PB_   /Volumes/SSD   SSDPictures   SSDPicturesBackups
server   Server_   /Volumes/sharedPictures   ServerPictures   ServerPicturesBackups

//$$   workflow
//##   preingestfolder   ingestfolder   originalsfolder   selectsfolder   outputfolder   outtakesfolder   trashfolder
//==   {usercustom3:0:lc}
//==   {clientcustom3:0:lc}
//??   To Ingest   Ingest   Original   Select   Output   Outtake   Trash
local   To Ingest1      Ingest   Original   Select   Output   Outtake   Trash
mobile
server

[alexmacnaughton]

Hi, could you give me more information about what you're trying to achieve with the hot codes?

[ejhutch]

Hi,
Oh, a number of different things, but with this example it's providing different locations for me to ingest or move photos to based on if I'm working locally on my laptop with just it's internal drive, locally with an external SSD, or connected to a server.  There are a few different ways to solve this particular case, including with the dialog snapshot feature, and this possible use case for hotcodes is just one possibility.  And storing the volume path is simply for my reference since you have to manually pick the volume path in the ingest and copy/move destination and backup folder roots and can't use variables for it.  I'm also planning automated repository segregation by path depending on whether photos are created by/for clients, family members, youth sports teams, friends, personal photos, or other types of photo creators or clients.

I realize that I could (and may have to) just extend the column list in one namespace to support all of the columns, but organizing them into different namespaces and hot code files is easier for me to keep track of where I need to make changes or additions.

If I have to just use one namespace for those particular code generators I'd do something like what's below.  Or I may try to find a different approach.  Either way it's helpful to know the constraints of the hotcodes feature.

//$$   path
//==   {usercustom3:0:lc}
//==   {clientcustom3:0:lc}
//??   local      Pictures   PicturesBackups To Ingest   Ingest   Original   Select   Output   Outtake   Trash
//##   prefix   volume   root   backuproot   preingestfolder   ingestfolder   originalsfolder   selectsfolder   outputfolder   outtakesfolder   trashfolder

local   Local_   /Users/edhutchison   Pictures   PicturesBackups To Ingest1      Ingest   Original   Select   Output   Outtake   Trash
mobile   PB_   /Volumes/SSD   SSDPictures   SSDPicturesBackups
server   Server_   /Volumes/sharedPictures   ServerPictures   ServerPicturesBackups

I could also achieve similar organization with keywords and / or multiple catalogs (which I'm also using), but this approach so far seems like it will meet most of my needs to keep my photo repositories organized in such a way that each repository can be easily moved or shared in bulk depending on working storage capacity. Plus it's easier for me to keep track of where photos are stored as they're moved among local, SSD, and server storage.

Thanks for your question.

[alexmacnaughton]

Hi, thanks for the extra information. I may be completely misunderstanding what you are trying to achieve with hot codes. Please feel free to correct me. If I understand correctly, creating snapshots of the paths you want for ingest, copy and move is the best approach rather than using hot codes.
It's possible to create a folder path using hot codes, but it's a complicated way to do it. Personally, I think hot codes work best when, for example, you're using a folder name to trigger the completion of multiple IPTC fields.

[ejhutch]

I think you understand correctly.  However I'd suggest that creating snapshots seems to be best if you want to easily change Destination Folder ROOT paths for the Primary and Secondary Ingest Destination Folders.  Hotcodes may be better for automatically populating the Folder Name field under Copy Photos: when "into folder with name" is selected. It seems to really depend on what you want to do.

Still, I think it would make sense if code generators for a single variable could be different in more than one namespace.  Though I'm not sure if the fact that they seem not to be able to be different across namespaces is a bug, an intentional design decision, or some other reason.

Does anyone know if this is intentional behavior for code generators?

Thanks!

[ejhutch]

Hi,
Bumping because my original question about having the same variable as a hot code generator in more than one namespace with different hot code tables in each namespace never really got answered.  In my experience with Photo Mechanic Plus version 2025.10, build 8858 on macOS Sequoia 15.7.2: if I have {usercustom3} as the hot code generator in two different namespaces, the codes looked up and used are always from the last namespace that was loaded that that variable was used in.  And it does the same thing whether the namespaces are in the same file or different files. In my mind, this partially defeats the purpose of having separate namespaces.  Is this supposed to be the expected behavior?

Thanks!

Hi,
Is it possible to have a hot code code generator for the same variable in more than one namespace?

I'd like to be able to do something like [volume.root]/[volume.prefix][workflow.preingestfolder]

However, if I have "local" in usercustom3, [volume.prefix] seems to evaluate to what I would expect [workflow.preingestfolder] to evaluate to "To Ingest1"... and [workflow.preingestfolder] also seems to evaluate to  "To Ingest1". What seems to be going on?  Thanks!

Example Hotcodes definition:

//$$   volume
//##   prefix   volume   root   backuproot   
//==   {usercustom3:0:lc}
//==   {clientcustom3:0:lc}
//??   local      Pictures   PicturesBackups
local   Local_   /Users/edhutchison   Pictures   PicturesBackups
mobile   PB_   /Volumes/SSD   SSDPictures   SSDPicturesBackups
server   Server_   /Volumes/sharedPictures   ServerPictures   ServerPicturesBackups

//$$   workflow
//##   preingestfolder   ingestfolder   originalsfolder   selectsfolder   outputfolder   outtakesfolder   trashfolder
//==   {usercustom3:0:lc}
//==   {clientcustom3:0:lc}
//??   To Ingest   Ingest   Original   Select   Output   Outtake   Trash
local   To Ingest1      Ingest   Original   Select   Output   Outtake   Trash
mobile
server

[dennis]

Hi,

Can you post your original code replacement file as an attachment? The text you pasted I don't think will work. PM expects tab characters, not a sequence of spaces, to separate fields etc.

--dennis

[dennis]

... if I have {usercustom3} as the hot code generator in two different namespaces, the codes looked up and used are always from the last namespace that was loaded that that variable was used in.  And it does the same thing whether the namespaces are in the same file or different files. In my mind, this partially defeats the purpose of having separate namespaces.

This isn't what namespaces does. Namespaces is to separate hot code definitions for Hot Code Names, Code Generators, and Defaults ONLY. There can only be one definition for a given code replacement. So your original definition of:

local   Local_   /Users/edhutchison   Pictures   PicturesBackups

is loaded but then overwritten again on the second definition. There can only be one set of replacements for "local".

HTH...

--dennis

[dennis]

From our help page: "Keep in mind that all the actual code replacement definitions (codes followed by multiple replacements) are present in all Namespaces. Therefore you may need to be careful about how you generate your codes."

Think of the various namespace definitions as "alternate headers", separate from all the actual codes replacements.  These various "namespace views" share the same set of code replacements.

The original goal of hot codes (which I was going to call haught codes) was to handle situations where you have workflows for metadata templates and file routing (ingest) that trigger off of a key piece of metadata (for example camera serial number) but then a camera is introduced to the workflow and we can't get the serial number.  This happened in the early days of Sony before they added the option for the camera owner to write out the serial number in the Exif.  This missing serial number broke some workflows that had things like ={serial}#3= (with various column numbers used in different dialogs).  Hot codes solves this problem by providing different code generators, and it simplifies the syntax by allowing you to have column headers (the actual "codes").

--dennis


HTH...