A "control bridge" node from Impact-pack resets counting from "number counter", even if the option to stop_at_stop is on.

[diodiogod]

Control bridge is useful to mute or bypass on queue. It will stop the workflow automatically and queue again. I think this behavior resets the counter. Here it's a simple example to test it: https://jsoneditoronline.org/#left=cloud.de8d15a7a0c84818ad61bb8ef5f6ece3

Thanks!

[chaosaiart]

( Oh, I misread it at first. ) You want the node to be no reset by the "Control bridge" node. I have no influence over "Control bridge". This is a different custom node, and especially because I don’t know how this mute is programmed, it might be reset all save parameters entirely.

Additionally, I don’t know the purpose of your mute or what you’re aiming to achieve. Depending on what you’re trying to do, it might be possible to achieve your goal with a switch.

[diodiogod]

Thanks for the response. My workflow is rather big and complex and would probably bring more confusion to post it here.

Basically, I my purpose is to create a bunch of images using different prompts and ksamplers, changing a lora on each queue. It's basically a XY plot to test loras epoch but with different prompts. So each queue saves a part of this XY plot that in the final queue I concatenate the images together. I know there are nodes to do XY plots, but I could not make them work with multiple prompts in the way I wanted.

My idea was to automate all of this in "one go". I set the number of how many loras I want to test, and do that many queues + 1. The last one will mute/bypass all the ksampler (to not generate again) and concatenate all the saved images. It is working right now...

I just thought I could use your node to never go above a specific number, "stop_at_stop", so the workflow could always stop at the correct number of queues. But the bridge node (that I use to bypass the ksamplers at the last queque) rests the counts... Anyway. Maybe it's not something you can do anything about it because, as you explain, is probably some kind of reset the bridge node does. But thanks anyway!

[chaosaiart]

Have you ever tried something like that?

Of course, it won't be muted, which is absolutely not a problem with text... I've already tested that. With Loras, it works in principle, the only question is whether it will eventually lead to VRAM issues.

[diodiogod]

That looks interesting. Each queue change the "active_frame" and that changes the prompt in one ksampler only right? If I have 5 prompts for each lora, I think I would need to manipulate the LoRa name to be the same up until frame 6. Then change the lora name on the "lora +add_lora node based on this number... Then have a part of the workflow with an integer evaluation to activate the grid save. I'll check this in the future. Thanks for the idea!

[chaosaiart]

active_frame is the frame counter, each new image +1. When a prompt starts depends on what "start_frame" you enter in the "Frame Prompt" node. Only one "Frame Prompt" node is active at a time, regardless of whether you attach 2 to 9 or use multiple "Prompt mixer by Frame." The main thing is that the last one forwards the "FRAME_PROMPT."

Loras are the active ones that are connected to your active "Frame Prompt" node (+ those that are connected to the "Main Prompt," which is always active.)

You can also connect a lora to more than one "Frame Prompt."

So you can rearrange it as you need, you could also manipulate the KSampler with counter and active_frame, etc.

Oh, I was also mistaken about the VRAM, I remember that I load the Loras only in the "Frame Prompt Clip Encoder," and only the ones that are active... I totally forgot.