asagi4
commented
4 months ago I think doing something like this is a bit outside the scope of my nodes. If you want to do this, you might as well work with cond objects directly rather than generating strings.
Though of course, by integrating something like this with prompt schedules you'd get the LoRA shuffling functionality for free.
If you'd like to write a set of nodes that build PROMPT_SCHEDULE objects, I'm open to agreeing on a stable(ish) interface for you to use. The current interface is pretty ad-hoc and while I don't think it currently needs changes, I don't guarantee stability either.
ghostsquad
Describe what's missing I'd like to extend these nodes and provide alternative methods that aren't as complex/error prone as writing a string with special syntax to do all the various features like scheduling, alternating, sequences etc. At first I thought about generating the string providing the user input of tokens, but then realized that I'd likely run into similar issues with syntax getting messed up. This isn't as much of a feature request as it is a dialogue for how might I contribute to this in a more programmatic way, and avoid "special strings" and string parsing? Thanks for your time!
A very simple example is a node that takes 2 strings, and either a slider or a number, and either emits
[cat|dog:0.05]or rather, if I contributed directly to this repo, a way to take that information, and "build up" the prompt/conditioning, before eventually "finalizing" it. (The Builder Pattern).