Is it possible to use AUTOMATIC1111's Alternating Words in a dynamic prompt?

[masslevel]

Maybe I'm doing something wrong, but I'm trying to use AUTOMATIC1111's Alternating Words feature within the dynamic prompt syntax. It's an extremely helpful tool to create new styles and mixings.

{[token1]|[token1|token2]} doesn't work.

I think the | delimiter isn't escaped within [ ]. I end up with parsed prompts including [token1 or token2].

Prompt editing works as expected {token1|[token1:token2:0.5]}. Since it doesn't use the pipe delimiter, I suppose that's the reason why it works.

[adieyal]

It's difficult avoiding stepping on toes. Auto1111 uses custom syntax to edit prompts, as does the Unprompted extension. I'm going to create an issue to try to escape a | when it is inside square brackets [...]

[ThereforeGames]

Hey @adieyal,

This is the author of Unprompted. Feel free to let me know if I can make any adjustments on my side that would help with syntax compatibility problems. I know some folks like prompting with both of our extensions simultaneously, so I am happy to collaborate with you whenever the situation arises. You can reach me via DM or discussion board at any time.

Merry Christmas, by the way!

[adieyal]

Hi @ThereforeGames - Merry Christmas to you too. Thanks for reaching out. I'll let you know if anything comes up.

[masslevel]

Thank you for looking into this! Your extensions are essential to explore the latent space. Happy holidays!

[adieyal]

@masslevel - could you please have a look at 1.5.0 - i've re-written the parser to be more flexible. Hopefully it should be able to handle your use case - note - there might be some teething issues, let me know if anything doesn't work as it should.

[masslevel]

Thank you for your work, @adieyal!

I just updated Dynamic Prompts and I can't 100% rule out that it has something to do with Automatic1111's updates from today, but something isn't working correctly.

Example 1
When I run a prompt and Dynamic Prompts is enabled it stops processing the prompt like this:

(token1:0.5) results in (token1
so no :, weight and closing bracket.

Example 2 (more complex)
<embedding1> [(<embedding2>:1.0):(<embedding3>:1.0):0.5] results in just <embedding1>

This syntax worked perfectly with Dynamic Prompts before today's (yours and Automatic's) update. I know that syntax is a bit excessive but it helps getting a tiny bit more control how tokens or embeddings are mixed - or to create totally new things.

If I disable Dynamic Prompts the prompt is processed as expected.

And I'm sorry if I caused any trouble with that change for you.

If you need any more information, please let me know.

[adieyal]

I expected there to be some issues as the change was pretty extensive.

Example 1 - I'm aware of this, currently working on it
Example 2 - I think this is the same issue as above.

I know that syntax is a bit excessive but it helps getting a tiny bit more control how tokens or embeddings are mixed - or to create totally new things.

I'm all for complexity. The new parser should be able to handle some intricate prompts, for example, apart from the :weight bug you mentioned, you can do something like

# Prompt editing with nested sub-prompts
# [from:to:when]
[
    A sub-prompt with __colours__ and {__colours__|__colours__}  # [from...]
    :
    Another sub-prompt with __colours__                          # [...:to:...]
   : 0.5                                                         # [...:when]
]

You might be interested in this issue which is being used to document any issues related to the new parser upgrade

[masslevel]

Thanks for the information and that you are looking into it! I will check out the issue.

Looking forward to do ;-)

[{(<embedding1>:1.0)|(__embedding-list__):1.0}:{(<embedding2>:1.0)|[{(__styles1__):1.0|(__styles2__):1.0}|(<embedding4>:1.0)]}:0.5]

edit: more readable

[
    {(<embedding1>:1.0)|(__embedding-list__):1.0}
    :
    {(<embedding2>:1.0)|[(<embedding3>:1.0)|(<embedding4>:1.0)]}
    : 0.5
]

not sure if it is possible to alternate the alternation