Nova NamePath Manager 🧭

A delivery graph repeats itself. The database path is typed on four nodes, the batch folder on two, the report and audio output roots on three, and the filenames have to agree or the validation step at the end fails for reasons that have nothing to do with audio. Change album and you're editing all of it, in six places, hoping you didn't miss one.

Nova NamePath Manager 🧭 owns those paths once and feeds them out. Then it goes one better and stores the whole set as a named profile, so switching project is one dropdown instead of six edits.

Inputs

The path values themselves are the boring half: database_path, table_name, folder_string, file_filter (default *.flac), input_filename, report_path, audio_path.

Two of them carry the actual thinking:

• existing_database - on, database_path points at a database that already exists. Off, it describes one to create, and the path gets split into new_database_folder and new_database_name for Nova SQLite Reader. That's how a fresh album's database gets built without anyone hand-rolling a path.
• concatenate_filename - on, report_path and audio_path each get input_filename joined on with a /. Off, both pass through untouched. This is what keeps the master, the report and the archive named consistently all the way down the chain, which is exactly the thing you stop doing manually once you're on your fourth album.

Then the profile machinery: profile, profile_action (use the widgets below, apply selected profile, save to selected profile, save as new profile) and new_profile_name. Profiles are plain JSON files under profiles/namepath/ - readable, editable, diffable, and not hidden in a database somewhere.

Outputs

Everything comes back out individually - database_path, new_database_folder, new_database_name, table_name, existing_database, folder_string, file_filter, input_filename, report_path, audio_path - plus settings_json, which is every resolved value in one blob for Nova Console or a report.

existing_database is emitted as a boolean output on purpose: a downstream node can branch on which of the two database paths is the live one, rather than guessing.

What it deliberately doesn't do

It never touches the filesystem. No directory creation, no existence checks. That's a considered choice with a good reason: a path manager that silently created directories would scatter empty folders across your disk on every graph edit, and the nodes downstream already report a missing path with proper context. This node composes strings and shuts up.

Saving happens on execute, through normal ComfyUI data flow - not over HTTP. The optional browser widget only reads. Which means the node behaves identically in API mode and in headless runs where no frontend exists. That's unusually careful for this class of node, and it's the right call: a workflow that behaves differently when you queue it from a script than when you click the button is a workflow you can't trust.

One practical note: the profile list refreshes when the browser reloads. Save a profile and don't see it in the dropdown? Reload the page. Its own dropdown, its own caching, one known wrinkle.

Install

ComfyUI Manager → Nova Audio Player → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/NovaFemme/ComfyUI-NovaAudioPlayer.git

Under ▶️ Nova Audio → 🛠️ Utility & IO, no dependencies, no models. The profiles/ folder is created on first run - the pack deliberately writes real files you can edit by hand rather than keeping configuration in memory.

Where it fits

Nova NamePath Manager 🧭 ──▶ Nova SQLite Reader 🗃️ ──▶ Nova Tag Writer 🏷️
        │ folder_string, file_filter
        ├──▶ Nova Batch Load Audio 🎼
        │ report_path / audio_path / input_filename
        └──▶ Nova Audio Master 🧾 ──▶ Save / Identity / Validator

If you build one delivery graph and run it once, you don't need this node. If you're going to run it on an album a week for a year, it's the difference between a workflow and a chore.