Scripting in OpenMPT

[LPChip]

I think it would be a great idea if the script can actually load/save one or more songs.

Not sure if you have to program mathematical functions, but a random with min and max would be nice.
Perhaps even commands to mute/unmute channels, so scripts can be used to easier perform on stage?

I have given plugins some thought but I doubt that plugins really need scripting. Perhaps the ability to add a plugin, load and save its preset, so you can write a script to move stuff from one song to another.

Also, there should be something like: next free instrument number, next free sample number, next free pattern number I think if you want to mass/copy/move from one song to another.

[Harbinger]

While i'm sure i can make full use of scripting within MPT, and have a variety of requested capabilities for the outset, i am actually more curious about how scripting is to be integrated within the code, now that i understand how tight the processes are. I equate it to grafting rose bushes into a thicket of briars and ivy.

If you can somehow pull this off, Jojo, i will be amazed at the level of your programming skill and will begin referring to you as "our resident wizard." But i would like to keep up with YOUR thought processes and how you're able to pull it off, as you go along over the next several months. I know you can foresee the challenges, and i guess i want to to be an intern spectating over your surgery....

[Rakib]

People may have heard about Max/msp and pure data, it for programming music. Now it has come as an library, so it can be implemented easily.

This can work as both scripting language and also as sample and effect generator.

http://bugs.openmpt.org/view.php?id=50
http://en.wikipedia.org/wiki/Pure_Data

The library:
http://gitorious.org/pdlib

[Saga Musix]

Update: Squirrel looks nice. Similar API to Lua (yet a bit better to use), and it looks more like C++/Java/etc., but is just as dynamic as Lua. A nice combination in my opinion, and so far it was much nicer to work with on the implementation side.

There are still some tough decisions to make. For example how scripts should be run. One big difference to Renoise is that OpenMPT can load multiple modules at once. Thus, should a script only be aware of one module (its "owner"), or all modules?

[Harbinger]

I use GIMP and they use scripting to get a LOT of their features implemented, esp. in applying filters or effects. These scripts are integrated into the main program, and i wonder if you plan to do the same. I would hate having to run it from a separate console, but with MPT's tight code, there may be no choice, at least at the outset.

I'm not sure what your question is referring to, but i would think we should be able to run any script at any time, even combining where possible.

Also consider time needed. I for one would much rather have capabilties right away and establish better GUI later, and if it's gonna take a LOT longer to integrate scripting in order to get everything you want now, let's go ahead and enter the new construction with all the 2x4s showing rather than wait for a perfect mansion with all the amenities you've been planning on.

[Saga Musix]

I would hate having to run it from a separate console, but with MPT's tight code, there may be no choice, at least at the outset.

There will most likely be a (debugging) console and the possibility to run scripts from some kind of dialog, and scripts could probably even be persistent (always running in the background).

I'm not sure what your question is referring to, but i would think we should be able to run any script at any time, even combining where possible.

There was a typo in the question, now it should be clearer. The problem is that I'm not sure if scripts should be aware of all modules loaded, because that could make things complicated, but may also open up some interesting possibilities (copying between different modules, for instance.).

GUI and stuff is not a problem concerning time, designing a proper API is. The scripting API should be straight-forward to use and be consistent. Designing this API will be very demanding, as I've never done something like that before.

[enkore]

You'll maybe want to take a look at QtScript (it does not require using any other component of Qt!), which is a ECMAScript implementation with very good C++ binding (put in another way, QtScript is the binding).

Pro: JS is well-known, simple to use + powerful
Pro: Makes integration with a Qt-based GUI somewhere in the future much easier
Pro: Well-tested implementation

[Saga Musix]

Con: It's JavsScript?

I've been fiddling around with Squirrel quite a bit and I like it a lot so far, Only problem is that there's no standardized tool for automatically creating bindings (might want to look into SWIG, flex or write a custom parser)...

[enkore]

That's done mostly automa(ti|magi)cally with QtScript... for stuff inheriting QObject.

JS/ECMAScript is actually quite nice, most ppl don't like it b/c they only know it from the JavaScript environment, which is (imho) botchered up in many ways.

Using QtScript is just the obvious thing to do when one already peers after Qt for a while :-)

[arseniiv]

Hi all!

Actual interface functions

<...>

- Read / write access to patterns: GetNote(chn, row), GetInstrument(chn, row), ..., SetNote(chn, row)..., ForEachModCommand style callback functions (with row, channel, order parameters), AddChannel, RemoveChannel, MoveChannel, ResizePattern, ShrinkPattern, GrowPattern
- CreatePattern (concept: returns new pattern number, -1 if failed), DeletePattern, DuplicatePattern

Could you also then add a function for creation of one pre-filled pattern? Maybe it could be faster for 'generator' scripts making whole patterns of autogenerated notes etc.. I know it is premature optimisation, and there isn't any scripting yet, but one more idea is no bad.

And another idea: not only functions GetString and GetNumber but GetSampleIndex, GetInstrumentIndex, GetPluginIndex and such (from active module) — to query a user of generatior script what things to use in composition.

I hope this late posting isn't something bad in this topic...

[Saga Musix]

Could you also then add a function for creation of one pre-filled pattern?

Ignoring the fact that this would already be possible with the planned interface (using a callback that is run whenever a new song is initialized), you can already do this without scripting by using template songs (and possibly specifying a default template).

[arseniiv]

Ah, sorry, I've said it inaccurately. I meant merely random patterns, not 'static' ones. Thank you anyway for default template setting, didn't know about it.

[Saga Musix]

For the first time in a long while I am having a look at scripting integration again. I have finally decided to stick to the Lua scripting language, since it has the best ecosystem compared to other embedded scripting languages I had a look at, such as Squirrel. And thanks to a great number of older compilers no longer being supported in OpenMPT 1.27 and later, I can finally use Lua bindings for C++ that are actually easy to use and thus increase my motivation to actually work on this feature. (This is by a way a great counter-example for "we're just dropping compiler support because it's easier for us" - if we had to support anything older than Visual Studio 2015, I would not bother with integrating scripting support in OpenMPT because it would be a lot more work to write). If we're lucky, basic scripting support should be present in OpenMPT 1.28.

I'm still looking for more ideas how you would be using the scripting functionality, i.e. what kind of tasks would you wish to automate if it was possible? The more ideas you post, the more ideas I get for the scripting implementation.

[LPChip]

Oh, interesting.

I currently can't think of more examples, but I will give it some thought and come back to this.

[the]

How about adding the ability to "bundle" the scripts with MPTM format modules, or a separate format for doing so, or adding the ability to load a compressed file with the module and the script included in it, with a unique file extension?

The reason I am asking for this is because it will be possible for a module to tweak the settings of OpenMPT to enable some features inbuilt in the program like changing the theme of the patterns and the user interface (though that may not be very useful, aside from "changing the mood", probably). If a facility for "dynamically" colouring the patterns, that is, the ability to change the colour of each individual cell each row, or tick (which may be resource intensive), and/or changing the pattern theme at each position may make way for some interesting visualizations for a song and make the bundling of a script and a module much more useful.

The scripts may be automatically executed by the program when the script-module bundle is loaded or when the module is played, although problems due to malicious scripts may arise such as crashing OpenMPT or acting as malware (if the script is allowed system access, although I don't think that is going to happen).

In addition to this, facilities such as creating dialogue boxes or canvases can also be created, which also may dock to the space which is usually empty on the general tab of a module, or to the bottom left or right corners in the pattern view which may be made translucent (no information will be obstructed as the pattern scrolls upto halfway through the viewport, provided that the boxes are small enough). The dialogue boxes may be used to show the song comments as a popup box (like Renoise). The canvases may be used to create visualizations for the song or act as a "splash screen" logo for the module, when it is loaded.

Also, how about allowing the patterns to be viewed in a separate window to make the visualizations (mentioned in paragraph 1) more immersive?
I do realize that these ideas are mostly cosmetic additions, would make the scripting API very "featuristic", and are more suitable for an appropriate module player rather than a tracker, but OpenMPT can be used to make such visualizations for the module players.