π BV Named LoRA Stack
Give your LORA_STACK a name so regional LoRAs know where to go
- lora_stack
- registry
- registry
Regional prompting has a LoRA-shaped problem. The community-standard LORA_STACK type - that list of [path, model_strength, clip_strength] tuples that ComfyUI-Lora-Manager and friends emit - is anonymous. It's a stack of LoRAs, but nothing says what it's for. When a BV Node Pack regional conditioning node wants to apply "one LoRA to the left character and a different one to the right character," it needs to tell the stacks apart.
BV Named LoRA Stack is the naming layer. It wraps an incoming LORA_STACK, stamps it with a workflow-local name and a stable stack_id, and appends it to a chainable registry - a BV_LORA_STACK_REGISTRY - that the regional conditioning nodes read to assign stacks to Global, Background, and per-region scopes.
How it works
The mechanics are deliberately simple because the contract is the value. The pack documents a public, JSON-compatible registry format (v1) where each entry is a stable id, a display name, and the unchanged stack entries - so other node packs can emit that type without depending on BV's sender node. Looking at the source, this node's whole job is one call: add_named_stack(registry, stack_id, name, lora_stack). Feed it nothing, and it starts a fresh registry; chain a second one into its optional registry input and it appends to that.
The three inputs:
- lora_stack (LORA_STACK, required) - plug in your Lora-Manager stack (or any compatible producer).
- name - the human-readable label, default
LoRA Stack. This is what the Regional Editor shows when you assign a stack to a region. - stack_id - the stable identity, and it's required: the source rejects a blank one with an explicit
stack_id is requirederror, and it also rejects duplicate stack IDs and duplicate names. That strictness is the point - a stable id means downstream references survive a rename, which is why the pack treats ids as authoritative and names as presentation.
Output is a single registry wire into your conditioning node's lora_registry input (the BV Regional Native Conditioning, Anima, and experimental Krea attention paths take it). The matching lora_bindings sidecar output from the regional prompt node is what actually maps stacks to regions - the editor then lets you assign one unchanged stack globally plus one additional stack per region.
Where people get caught
Performance. This is the one everyone discovers the hard way. In the default multipass_legacy mode, every distinct effective regional model stack costs an extra full model pass - one regional stack normally doubles sampling time, two different stacks triple it. Empty stacks and stacks whose model and CLIP strengths are both zero are valid no-ops, which is your escape hatch: don't disconnect the wire, just zero the strengths.
The producer matters more than the node. The README's example workflows load cleanly only if you have ComfyUI-Lora-Manager installed - not because BV needs it at runtime, but because those graphs use it as the LORA_STACK source. Any compatible producer works; the README tests paired two Anima character LoRAs from the same series and a skin-tone slider isolated to one side, and the results are genuinely impressive - but they're also a favorable, carefully-controlled pairing. Don't generalize "two random Civitai LoRAs mix cleanly" from that.
Installing
It's one node in a pack - search BV Node Pack in ComfyUI Manager or:
cd ComfyUI/custom_nodes
git clone https://github.com/BlackVortexAI/bv_nodepack.git
Restart and hard-refresh (Ctrl + F5) after install. No extra Python dependencies; the optional Lora-Manager is only needed to reproduce the pack's example graphs.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| lora_stack | LORA_STACK | β | |
| name | STRING | LoRA Stack | β |
| stack_id | STRING | β | |
| registryopt | BV_LORA_STACK_REGISTRY | β |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| registry | BV_LORA_STACK_REGISTRY | β |