[Submission] /for console slash-command [SUBMITTED]

[tberakis]

With inspiration from this thread viewtopic.php?f=16&t=1877, I thought I would create an atom that uses the new slash-command functionality to make this kind of thing easier. It only supports a couple of sub-commands so far, but I can see a few more things that would be nice to add in future versions.

-----

The /for slash-command is used to quickly and easily apply changes across a number of tools.
Usage
/for (selected|visible|all) [tooltype[,tooltype...]] [where <condition>] <command> [ & <command>...]

Supported commands:
animate <input> [(with <modifier>|remove)] [force]
color [tile <color>] [text <color>] [fill <color>]
select [(add|remove)]
set <input> ([at <time>] to <value>|expression <exp>)

Examples:
Set the Size of all selected tools to 1.0:
/for selected set Size to 1.0
Set the SeetheRate of all FastNoise tools in the comp to 1.0:
/for all FastNoise set SeetheRate to 1.0
Double the current size of each Merge or Transform currently selected:
/for selected Merge,Transform set Size to value*2.0
Animate Size of all selected tools with default modifier (BezierSpline):
/for selected animate Size
Animate Size of all visible tools (ie not modifiers) with CubicSpline
/for visible animate Size with CubicSpline
Animate Size of all selected tools, replacing any already animated ones:
/for selected animate Size force
Animate Seethe of all FastNoise tools, creating a ramp from 1.0 to 5.0 over 100 frames:
/for all FastNoise animate Seethe & set Seethe at 0 to 1.0 & set Seethe at 100 to 5.0
Remove animation from Size of all selected tools:
/for selected animate Size remove
Set a Seethe expression on selected FastNoise tools:
/for selected FastNoise set Seethe expression time/10.0
Select all FastNoise tools:
/for all FastNoise select
Add all tools where Size > 1 to the selection:
/for all where Size > 1.0 select add
Remove all Merge tools where Angle < 0 from the selection:
/for all Merge where Angle < 0 select remove
Set the tile color to red for selected tools:
/for selected color tile 1,0,0
Set the text color to green for selected FastNoise tools with a non-zero SeetheRate:
/for selected FastNoise where SeetheRate ~= 0 color text 0,1,0

[SecondMan]

[SecondMan]

I just tested this. It's absolutely brilliant - thanks so much for sharing!

It will take me a while to decipher that (astonishingly short) piece of code, there is so much to learn in there

In the meantime, let's get this into Reactor asap

[Dunn]

Totally amazing !
...we could make a custom UI to hold those functions right ?!

Nice one!

[tberakis]

Now updated (in first post) with v1.1

New for this update:

/for can now be limited to a subset of tools using where <expression>:

Set the Size of all selected tools to 1.0, if it's already > 1.0:
/for selected where Size > 1 set Size to 1.0

* set can now set expressions:

Set a Seethe expression on selected FastNoise tools:
/for selected FastNoise set Seethe expression time/10.0

* Added a 'select' command:

Select all FastNoise tools:
/for all FastNoise select
Add all tools where Size > 1 to the selection:
/for all where Size > 1.0 select add
Remove all Merge tools where Angle < 0 from the selection:
/for all Merge where Angle < 0 select remove

Added a 'color' command:

Set the tile color to red for selected tools:
/for selected color tile 1,0,0
Set the text color to green for selected FastNoise tools with a non-zero SeetheRate:
/for selected FastNoise where SeetheRate ~= 0 color text 0,1,0

[SirEdric]

Wow. Period.

[SecondMan]

fantastic!

So - not able to test this right now - I'm guessing 'where' could even be used with custom Info content? Maybe we could even make the code do (with some adjustments) something like:

/for all where Info contains "heavy tool" passthrough

[tberakis]

What would 'info' be? The comments on the tool, or some custom data?

[Chad]

CustomData and Comments would cover most use cases.

[SecondMan]

Comments was what I had in mind. Though CustomData would be great, too. Hmmm... I always forget about that one. Should really leverage that at some point.

[tberakis]

Oh I just looked in Reactor and saw my v1 script already included. Nice!

I see you've changed the id - Should I go with that for submissions going forward?

I went with the wesuckless one as that's what my Temporal Filter fuse is. I'm not sure if that ought be changed too.

[Midgardsormr]

Comments would be easiest for the end user. CustomData is comparatively difficult to access on the fly.

[SecondMan]

Oh I just looked in Reactor and saw my v1 script already included. Nice!

I see you've changed the id - Should I go with that for submissions going forward?

I went with the wesuckless one as that's what my Temporal Filter fuse is. I'm not sure if that ought be changed too.

Err, yes! Submitted!

Sorry for the notification delay - I got distracted and messed up a little - thanks again for sharing!

You're right - your Temporal Filter was one of the first packaged with a host of other tools that we added from scavenging the WSL archives. It was also part of a larger topic where multiple people contributed. So I guess partly for that reason we kept it under that umbrella, while crediting you as the author in the Atom itself. We'll look into this. For the future, by all means use your own name.

[tberakis]

Comments would be easiest for the end user. CustomData is comparatively difficult to access on the fly.

Yes I agree with this.. custom data is a bit obscure for most people - anyone who understands that can probably use real scripts rather than /for

But still, I'm thinking of two paths for additions. Firstly a simple way to query comments, using 'where info contains' ... or whatever.

But secondly, a more complex data interface. So 'where' supporting data, but also a 'setdata' command maybe, to allow setting custom data?

/for all BrightnessContrast where Gamma ~= 1.0 setdata GammaAdjust to true

Or something like that?

I'm open to ideas on this one, as it's getting in to workflow and pipeline ideas that might require a range of solutions.

[Chad]

Comments would be easiest for the end user. CustomData is comparatively difficult to access on the fly.

That's the point.
CustomData isn't visible in the GUI, but is guaranteed to be available for any tool/comp. So for someone making an idiot-proof(ish) pipeline, CustomData is "safer" than Comments.