> Are you referring to your Tile Tool as an example?
I'm not especially talking about Tile Tool.. Just Tools in general.. But since I spent a lot of time on Tile Tool, I'm sure some of the ideas come from there..

I don't think I completely understand what you mean by 'But I'm not saying the bounds should be the restrictive process...'. What do you mean by restrictive process?

If I take my Text Pencil tool as an example, I first thought it would allow me to go wild with drawing text, but when I was making a poster using the Tool I found out that I had to use it slowly and with precision to make legible texts. Of course these restrictive bounds had a huge impact on the resulting work - this slowness of working also gave me time to think of how and where I would place the texts. Because undoing was a hassle, I would think once or twice before drawing.

It's so easy to undo something, sometimes I wonder how much effect this has on our work.. Every step of the way can be questioned, undone, redone.. You don't have to choose anymore, just try every possible combination.

Breaking rules.. Yes.. And maybe also resurrecting rules?

I'll agree with Simon, and say the use of a tool rests soley on the artist, not implicitly in the tool itself.

We have the benifit here, however, to change not only our techniques, but the mechanism as well. If an artist feels a given function is too 'loose', he/she's able to account for this in code. Random elements can be constrained, or ignored, and wanted code can be harvested for a specialized purpose.

I feel the development process itself is most valuable. As with any tool, the execution is left to the individual. But we're not creating visual art here, just the means.

For example, I'm a great fan of Hiroyuki's new cube/cylinder tool. Some very elegant code that provides a new dimension to similar tools we've had in Illustrator for some time (symbols, etc.) In both, he chose to require an amount of "jitter" that must be greater than zero (though may be rounded down from .001) thereby requiring a random process in the two. Should he have been more worried about keeping a SG user from being sloppy, or on creating a script which adds to our arsenal and performs well?

Thanks :) > Simon
But I don't think all the tools should be strictly "interactive".
In fact, I use Math.random() in my scripts so often.
One reason why I use it is for the purpose of productivity rather than creativity. A productive script saves my time and helps me to be able to spend more time for the creative phase of the work.

This may be a passive usage of a tool. But even when I aim for this purpose, I try to adjust the frequency of the raw random value by applying various Math functions, in order to get better results. I think this is in the creative phase of the development.

I recognize Sg as a plugin that has potential to create an innovative tool, and I wish to create it sometime. But for now, I feel I need a script most when I want to avoid complicated routines.