[enhancement]: Generate Forever or Infinite Iterations feature

[Jonseed]

Is there an existing issue for this?

• [X] I have searched the existing issues

Contact Details

No response

What should this feature add?

Provide a "generate forever" functionality like in Auto1111/Forge, or maybe call it "infinite iterations." In Auto1111/Forge you can right-click the generate button and choose "generate forever," and it will continue to generate new images (random seed each time, which also changes the dynamic prompt used) until the generate forever process is cancelled by right-clicking the button again and choosing cancel. Something similar in Invoke would be great, which is useful to set it to generate a few hundred/thousand images overnight, for example.

Alternatives

Invoke does have Dynamic Prompting, but that will only output up to the Max Prompts setting per iteration.

And if you're not using dynamic prompting, then you just have the iterations number to work with, which looks like it maxes out at 999?

It would be nice if there was a way to simply set it to continue invoking until the user stops it or cancels it, without setting a specific number of iterations, maybe add an infinity button ♾️ next to the number of iterations, basically making the iterations infinite. Or the infinity button ♾️ could be added above the up button, stacking the three 🔽🔼 ♾️ buttons, making the UI a little less cluttered keeping the empty negative space between the number of iterations and the send to gallery button, which is nice from a UI design standpoint.

As far as queuing these jobs, perhaps it just auto-adds another invokation to the queue once the current one is finished? The cancel button could stop the current generation and the auto-adding of new jobs, or the infinity button ♾️ could change to a cancel button ❌ after clicking it to start generating, so clicking again would stop the auto-adding feature but not cancel the current generation, and the cancel button functionality would remain the same (cancel the current item).

Additional Content

No response

[psychedelicious]

The easiest way to do this would be a feature on the frontend. An event listener for the queue item completed event would immediately enqueue the same graph w/ a new seed. However, this would rely on the client (web browser) to be connected the whole time, which feels awkward.

Ideally it'd be a backend feature, like a flag on the queue item. There are some complications w/ the linear UI (i.e. Canvas) graphs that make this pretty tricky to do. Those graphs don't actually use a random seed node. Seeds are determined as you click the invoke button. So we'd need to figure out how to tell the backend how to re-queue with a new seed, or change the graphs substantially.

What if we just increase the max value of the iterations input? There's a max_queue_size config that we can access from the UI - could use that for the max of the input. Would that serve the need?

[Jonseed]

The way it is implemented in Auto/Forge is frontend, and it does seem a bit awkward, and doesn't work all the time (if the tab sleeps it stops working, and in Forge it is kind of broken, etc.). I agree it would be better as a backend feature. Allowing greater max values of iterations could work, but also seems awkward when all you want is it to continue generating indefinitely until you stop it.

[psychedelicious]

Thinking through a potential backend implementation, I don't think it would happen any time soon due to the effort required for implementation.

A purely frontend implementation, though it has some issues, is much easier to implement. Also, it enables a flow not easily possible with a backend implementation. Each generation could use the current settings, so as you tweak settings, your generations kinda evolve with them. I'm guessing this is how A1111/Forge work.

Notes/outline for a frontend implementation:

• Add a setting to track if infinite mode is enabled, probably in the system slice.
• Expose that setting in the UI, probably in the <QueueControls /> component.
• When the user enables infinite mode, we may want to enable the randomized seed setting else you'll get infinite samesies. Or, in the graph builders, we override the user's random seed setting when infinite mode is enabled.
• In the socket.io event listener for queue_item_status_changed, if it is complete/failed/canceled and infinite mode is enabled, dispatch enqueueRequested.
• If the user explicitly queues a generation while infinitely generating, the queue will grow by 1 (1 in progress, 1 pending) until the infinite mode is disabled. If you click Invoke 5x while infinitely generating, the queue will grow by 5 (1 in progress, 5 pending). While not exactly a problem, this feels wrong. One simple and flexible way to prevent this situation is to add a condition in the event listener to trigger the next enqueue only if the queue is empty. Maybe it's a non-issue.