Jump to content
You must now use your email address to sign in [click for more info] ×

Recommended Posts

i don't understand the usefulness of this demo. where are the scripts that can control properties of the tools that are already in the programs. like accessing gradient, lines, color values, layers, etc. i'm looking forward to scripts that can automate a lot of the repetitiveness, rather then image generation to some 80's looking fractals. this is not looking good or hopeful.

however after seeing how layers can be renamed in a later post, i'll just wait and see what the team will showcase what scripting can do in some future update. is scripting coming to version 2?

Windows 11 Pro x64 | 2700X 8 Cores CPU | AMD RX Vega 64 GPU | 32 GB RAM | NVMe M.2 PCIe 3.0 x4 • 970 EVO SSD | Affinity Photo • Designer • Publisher

Link to comment
Share on other sites

23 minutes ago, symbiont said:

i'm looking forward to scripts that can automate a lot of the repetitiveness, rather then image generation to some 80's looking fractals.

I would respectfully suggest to read (again) page 17 of this thread before jumping into any conclusions.

 

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

Hi
Will there be ways to do even more simple things, like for example: launching Affinity Photos with a list of images and triggering the HDR Merge with options ?

Will scripting support these scenarios (launching the app, saving a file, exporting a JPEG,...)

@Tim Franceyou mention discussing options such as a Gui-less execution. Would that mean that exporting an image version of a document without launching the app could be envisioned ?

Thanks

Link to comment
Share on other sites

  • 2 weeks later...
On 3/24/2023 at 2:05 PM, Tim France said:

We now have a scripting core that we're reasonably happy with and have put together a little test area where we can run Javascript code, so I thought I'd show you some of that.

This is stupendous news!

Scripting and plugins are the most important thing this suite needs. The ability to expand the functionality of the software by the users is an absolute must. Thank you very much for your work on this.

Link to comment
Share on other sites

27 minutes ago, LCamachoDesign said:

Scripting and plugins are the most important thing this suite needs. The ability to expand the functionality of the software by the users is an absolute must. Thank you very much for your work on this.

I totally agree. Back in the day with Illustrator I really enjoyed some of the "off standard" options for design brought into the game by interesting scripts and plugins. Not having any of these in the Affinity apps has had me looking back more often than I really wanted... So lets see what will be coming of this!

Link to comment
Share on other sites

Will the various scripts eventually also be exposed to the keyboard shortcuts of the software? That would make it very versatile if you can call each and every possible function that can be made through scripts from a shortcut (without arbitrary requirements of using Function keys or holding one or two particular modifiers).

Link to comment
Share on other sites

  • Staff
On 4/12/2023 at 2:50 PM, Intuos5 said:

Will the various scripts eventually also be exposed to the keyboard shortcuts of the software? That would make it very versatile if you can call each and every possible function that can be made through scripts from a shortcut (without arbitrary requirements of using Function keys or holding one or two particular modifiers).

Hi Intuos5,

Yes that's correct -  the plan is that commands exposed by scripts/plugins will appear in the Shortcuts settings page, alongside native commands. 

Link to comment
Share on other sites

  • Staff
On 4/14/2023 at 1:29 PM, Ezbaze said:

Will there eventually be support for Python and not just Javascript?

Hi Ezbaze, 

We'll have our hands full with JavaScript for the foreseeable future, but we aren't ruling out other languages eventually. 

In addition, the JavaScript engine is itself implemented using our plugin SDK, to which we plan to add support for alternative scripting engines (i.e. you could in theory write your own plugin to support Python or any other language).

Link to comment
Share on other sites

1 hour ago, Jon W said:

Hi Ezbaze, 

We'll have our hands full with JavaScript for the foreseeable future, but we aren't ruling out other languages eventually. 

In addition, the JavaScript engine is itself implemented using our plugin SDK, to which we plan to add support for alternative scripting engines (i.e. you could in theory write your own plugin to support Python or any other language).

Very understandable considering how many things there are, that would be perfect :)

Link to comment
Share on other sites

Another thing to consider: a coded/scripted brush engine.

Here is how I see that working:

A script registers a brush definition, with its name, icon/representation, a set of parameters the user can configure for it, etc., and a subroutine that implements the brush itself.

When the user has that brush selected and starts dragging across the canvas, two threads run in parallel:

* One thread updates a path object tracking the movement of the mouse, and if the other thread is generally lagging, displays a thin version of the path between the last point that the path was at when the other thread last provided data and the point where the brush is dragging through.

* The other thread takes whatever is in the path object and calls the scripted/API-coded subroutine with that path and any parameter values that were set for the brush.  The subroutine applies the path to the underlying image data and generates the image (or vector shape) which is temporarily rendered onto the canvas when the subroutine completes.  It then waits for the path to be updated or the brush application operation to complete.

 

When the operation is complete and the final path has been processed:

* If the brush is being applied as a raster/pixel brush and it generated a raster image, it is applied to the pixel layer; if it generated a vector shape, the shape is rasterized and applied to the pixel layer.

* If the brush is being used as a stroke for a vector shape, the output of the subroutine becomes the intermediate representation of the brushed path, whether it is pixel data to be drawn along the path or a vector path to be drawn as a shape; it would become an object of it own if the user chooses "Expand Stroke", etc.  If the path changes, or if the user adjusts the brush parameters while the object using it is selected, then the subroutine is simply called again with the new path and parameters to generate a new representation.

Link to comment
Share on other sites

  • Staff
On 4/21/2023 at 3:58 PM, fde101 said:

Another thing to consider: a coded/scripted brush engine.

Hi fde101, 

Thanks for your suggestion. Custom brush engines is an interesting idea and we've added it to our list. 

 

Quote

* One thread updates a path object tracking the movement of the mouse, and if the other thread is generally lagging, displays a thin version of the path between the last point that the path was at when the other thread last provided data and the point where the brush is dragging through.

* The other thread takes whatever is in the path object and calls the scripted/API-coded subroutine with that path and any parameter values that were set for the brush.  The subroutine applies the path to the underlying image data and generates the image (or vector shape) which is temporarily rendered onto the canvas when the subroutine completes.  It then waits for the path to be updated or the brush application operation to complete.

When the operation is complete and the final path has been processed:

* If the brush is being applied as a raster/pixel brush and it generated a raster image, it is applied to the pixel layer; if it generated a vector shape, the shape is rasterized and applied to the pixel layer.

* If the brush is being used as a stroke for a vector shape, the output of the subroutine becomes the intermediate representation of the brushed path, whether it is pixel data to be drawn along the path or a vector path to be drawn as a shape; it would become an object of it own if the user chooses "Expand Stroke", etc. 

Pretty much how the existing brush engine works, unless I'm missing something?

 

Quote

If the path changes, or if the user adjusts the brush parameters while the object using it is selected, then the subroutine is simply called again with the new path and parameters to generate a new representation.

This sounds like a general feature request for parametric brushes, which would be equally applicable to the existing vector brush engine and not really specific to scripting. 

Link to comment
Share on other sites

On 4/18/2023 at 11:06 AM, Jon W said:

you could in theory write your own plugin to support Python or any other language

So, you won't support it directly as you will support JavaScript?

All the latest releases of Designer, Photo and Publisher (retail and beta) on MacOS and Windows.
15” Dell Inspiron 7559 i7 Windows 10 x64 Pro Intel Core i7-6700HQ (3.50 GHz, 6M) 16 GB Dual Channel DDR3L 1600 MHz (8GBx2) NVIDIA GeForce GTX 960M 4 GB GDDR5 500 GB SSD + 1 TB HDD UHD (3840 x 2160) Truelife LED - Backlit Touch Display
32” LG 32UN650-W display 3840 x 2160 UHD, IPS, HDR10 Color Gamut: DCI-P3 95%, Color Calibrated 2 x HDMI, 1 x DisplayPort
13.3” MacBook Pro (2017) Ventura 13.6 Intel Core i7 (3.50 GHz Dual Core) 16 GB 2133 MHz LPDDR3 Intel Iris Plus Graphics 650 1536 MB 500 GB SSD Retina Display (3360 x 2100)

Link to comment
Share on other sites

2 hours ago, Jon W said:

we've added it to our list. 

Nice!

 

2 hours ago, Jon W said:

Pretty much how the existing brush engine works, unless I'm missing something?

I was referring more to how I perceived the scripts interfacing with the engine, but if the existing brush engine is already working in that same manner behind the scenes, then that should make it even easier to implement since you would be hooking it into the existing logic.

 

2 hours ago, Jon W said:

equally applicable to the existing vector brush engine and not really specific to scripting. 

Brushes are already parametric in some sense: if you double-click on a brush in the Brushes panel you get a set of parameters that are being fed into your existing brush engine, for things like brush width, size variance, etc.

When a scripted brush is in use, those parameters would need to be fed into the script so it can determine how to render the brush, but different scripts will want different parameters, so there would be a need to let the script customize the set of parameters that the user can choose from within that editor, replacing the standard ones that are used with the integrated engine.  That much would be an essential addition to make this worthwhile.

The lack of ability to change the parameters of the brush after the fact would become a particularly strange omission in light of scripting, so the other piece that would be good to have would be the ability to re-open the brush editor for strokes already on the canvas to adjust the parameters after the fact.  This could indeed be done for the existing brush engine just as easily, but in my opinion the concept of scripted brushes adds emphasis to its desirability.

 

13 minutes ago, NNN said:

you won't support it directly as you will support JavaScript?

What they are saying is that they themselves will not do so, but they are instead providing a means by which a 3rd party could provide that support through a plugin, which when installed would allow arbitrary languages to be "added" to the software in a manner equivalent to the ECMAScript support they are providing themselves.

No matter what they want to misname it, they are not implementing a web browser, so it is not appropriate to call it JavaScript - what they are actually providing is a flavor of ECMAScript, which JavaScript itself is based on (it is only JavaScript when it is used in a web browser as it is tied to the DOM used for web pages).

Link to comment
Share on other sites

  • Staff
41 minutes ago, NNN said:

So, you won't support it directly as you will support JavaScript?

As I said last week: we aren't ruling out built-in support other languages eventually, but we have no current plans to. 

However, any third-party "interpreter" plugins will have access to all the same capabilities as the built-in ones. 

 

 

Link to comment
Share on other sites

  • Staff
32 minutes ago, fde101 said:

Brushes are already parametric in some sense: if you double-click on a brush in the Brushes panel you get a set of parameters that are being fed into your existing brush engine, for things like brush width, size variance, etc.

In some sense yes, but the term "parametric" in the context of editing usually implies that parameters can be changed after the fact (e.g. live filters).

31 minutes ago, fde101 said:

When a scripted brush is in use, those parameters would need to be fed into the script so it can determine how to render the brush, but different scripts will want different parameters, so there would be a need to let the script customize the set of parameters that the user can choose from within that editor, replacing the standard ones that are used with the integrated engine.  That much would be an essential addition to make this worthwhile.

Agreed. 

40 minutes ago, fde101 said:

The lack of ability to change the parameters of the brush after the fact would become a particularly strange omission in light of scripting, so the other piece that would be good to have would be the ability to re-open the brush editor for strokes already on the canvas to adjust the parameters after the fact.  This could indeed be done for the existing brush engine just as easily, but in my opinion the concept of scripted brushes adds emphasis to its desirability.

I agree that such a feature would be a good match for custom brush plugins, but still independent.  You might like to raise it on the Feedback and Suggestions forum. 

Link to comment
Share on other sites

Please only focus on one scripting language, so that it gets done, and done well. There's never been a case where the time spent making multiple scripting language support work hasn't significantly reduced the rate of production of the features that scripting support can provide, because being generic becomes too important. Theoretically good, but very limiting for a domain specific use of scripting.

Link to comment
Share on other sites

On 4/18/2023 at 11:06 AM, Jon W said:

We'll have our hands full with JavaScript for the foreseeable future, but we aren't ruling out other languages eventually. 

In addition, the JavaScript engine is itself implemented using our plugin SDK, to which we plan to add support for alternative scripting engines (i.e. you could in theory write your own plugin to support Python or any other language).

As far as you also document the plugin SDK accordingly and in a well reusable manner, otherwise it will be useless!

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

1 hour ago, Jon W said:

The SDK will be fully documented. In fact we expect it to share documentation with our Javascript library, which is largely a wrapper for the SDK. 

 I hope that means that the part will be Javascript independent documented then, so more all the plugin SDK C/C++ mappings one has to hook/wrap to on, without having first to go through a bunch of Javascript based code in order to find out. - For example, let's say I want to hook on with Lua or Py etc. to the SDK, then I'm not that much interested in all the Javascipt language/syntax garbage at all here.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

6 minutes ago, v_kyr said:

then I'm not that much interested in all the Javascipt language/syntax garbage at all here

Hello @v_kyr,

You are getting slightly unreasonable here. The team has stated, in numerous posts, that because the APIs are going to be the same for both C and JavaScript that they will keep the documentation in one place. There will be a lot of people for whom JavaScript will be the most important part and they will not regard this as garbage. They will concentrate on the JavaScript part and you can concentrate on the C based APIs. And they lived happily ever after. 🙂

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

4 minutes ago, Seneca said:

the same for both C and JavaScript

In other words, for two languages with "garbage" syntax 🙂

For an example of how this might be done, consider the way Apple's documentation for many of their APIs is set up.  They have a page with a description, but there is a toggle at the top to show the headers and examples in either Objective C or Swift format (as those are the two languages they are supporting).  I would expect something like this to be reasonably straightforward for Serif to provide.

If a third party writes a plugin for some other language, they would need to be able to at least explain the mapping from one of the Serif-supported languages.  Perhaps Serif could allow the documentation to be retrieved in some source format from which individual language documentation could be easily generated, in support of such languages, then use that same format themselves to generate the documentation for the two they are providing?

Link to comment
Share on other sites

1 hour ago, Seneca said:

They will concentrate on the JavaScript part and you can concentrate on the C based APIs.

That is/was my documentation related question & demand, that the C/C++ API itself is hopefully then documented in a common C/C++ manner here and not just via JS wrapper code examples etc. - Further since I also know that the documentation process here for the Affinity products is often somehow a weak point, I wanted to remind and ask about it explicitly.

Quote

There will be a lot of people for whom JavaScript will be the most important part and they will not regard this as garbage.

Other people might not and they can of course freely do & treat it as they want and like, but hey I do in terms of the language's syntax specifics here. So I expressed freely my own personal opnion about the JS language's specific syntax here. And why should I sugarcoat something that I consider personally as being a syntactical relative bad one?

"Freedom for Muff Potter"  😉

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.