Is it possible to use a script engine in next version?

[Sam]

I know even now, there are many discoverable features in SA, But for generative art maybe users want to use some script, I don't know, Is it possible to use processing.js as internal/external engine? or even add some simple features for controlling SA by external processing script?

thank you

[Sam]

with some processing script it will be easier to generate math shapes for filling

[Synthetik]

We did think about adding scripting at one point in studio artist history where the cross platform framework we used was going to provide it as a part of their framework. They ended up killing off that particular feature in the framework later on, so it was good in hindsight we didn't take advantage of it at the time.

We have thought about it. I don't know that it would be javascript or anything like that.

People that want to use processing are free to do so, it's a fun environment for art coding. But it's not something we would directly integrate in studio artist, it's kind of it's own thing.

I also get the sense that while some of our power users might be into programable scripting, the typical Studio Artist user would be totally confused and uninterested in it. It takes a certain type of brain and way of thinking to code, and that way of thinking is not necessarily the way many visual artist's brains work.

What i really like about Studio Artist as an environment is that you can start creating art immediately. Just by pressing a button or working with a stylus all kinds of things magically just happen. So you can very quickly create finished works of art without a lot of left brain thinking.  Same goes for things like Evolution Editor or Gallery Show, you can make interesting visual effects without understanding what is going on under the hood. That's not really true with other programs, you have to do a lot of directed work in them to get anything interesting. That's even more true in a 'programming' environment for creating visual art like processing.

We have thought about internal scripting that would be amenable to directed evolution, mutation, etc. This is something i'm very interested in. So people could be using directed evolution to build visual effects, and what might be happening under the hood is that programming scripts that generate the procedural art would be evolving. But it would be hidden from the user. Unless they really wanted to observe and interact with it directly.

The discussion associated with the zentangle approach to building up images did get me thinking that having some way of embedding custom graphics code for fill patterns for the vectorizer or vector paint effects might be useful. So it's on the long list of things to think about for the future. Again, if it was easily self-evolvable it would be way more useful and interesting in my opinion.

[Ryan DigiArt]

I'm very much a fan of the Node based approach. 
I could imagine a nice node interface to SAs different features.

But I also like to code... so maybe a little of both for me.

[Sam]

I think maybe it is better if SA try to use an existing engines like Javascript (sample: https://codepen.io/tholman/pen/ifDak) or even better that, Processing (sample: https://www.openprocessing.org/sketch/128167/) or Nodebox (https://nodebox.live/) Because It will open a gate to a huge community of codes in the world.
But SA developers know it better.

[Ryan DigiArt]

I am assuming SA is written in C++.
If thats the case, embedding Processing (java) or a web canvas/gl option (like the other 2) would likely be a real chore. 
Adding a scripting engine like V8 (javasscript) or Python can be done much more easily, but then there needs to be a SA api to control (big job, but could start small).
Out of those 2 I prefer Python, since its not sandboxed, so you can interact with the web or file system.. and have access to tonnes of extensions.

dreaming a bit now, but python scripting + a nice SA api + Spout/Syphon support would make SA a powerful real-time graphics tool/competitor to Processing (and other creative-coding environments)

or.. if making a SA c++ api is easier.... a comprehensive OpenFrameWorks addon would be amazing, and would open SA to the whole Openframeworks user base.

[Sam]

Yes, it is my fantasy too and I agree with you about Openframeworks, I think SA v5 was Qt

[Synthetik]

We are interested in Syphon support in the future. It didn't really make sense in the 32 bit app, but is more compatible for future developments.

One issue with Syphon is that it is mac osx only. Ever since we went cross-platform we've been trying to support features that work on windows as well as macs.

[Synthetik]

If people want to provide some specific examples of how they would like to use this proposed feature, that would help us.

[Ryan DigiArt]

Well... ok
It there was a Openframeworks api/addon...
I might create a kiosk app that collects images continuously, uses OpenCV to detect if faces in each and rate the image based on the size and position of the face.... after a given time, use the image with the highest face rating at the basis for SA to create a Mosaic of that image using all the other images.... and playback the Mosaic to the environment (if it could be the rendered creation sequence of the mosaic... even better)

[Synthetik]

Devil's advocate here:

Couldn't you do this art installation already. Write your openframeworks code to dump images into 2 folders, one for source, one for image brush. Setup gallery show in Studio Artist to work off of your dynamic source folder, using a set of paint synth presets in a favorites category for the technique that work with the brush folder. 

The 2 programs would work independently. No need for turning studio artist into an openframeworks library.