With languages like lua, it's rather easy to implement scripting into programs these days. I have been playing with the thought for a very long time now, but I have not made up any usable specifications so far. So I'm asking you, what functionality would you need? I thought about providing scripting functionalities for the pattern editor. Now the question is of course what should be possible, i.e. what kind of pre-made functions should exist?
I've come up with:
- A "for each"-style command, which applies a custom lua function on every mod command
- Retrieving and changing the order list (+ sequences)
- Retrieving and changing a pattern command using given coordinates
It would be possible to call exisiting OpenMPT functionality from these scripts, but that cannot be done automatically - every function would have to be bound to a lua identificator manually first. That's why I would like to know which functions really should be usable from within lua (f.e. something like AddChannel() or RemoveChannels()).
I doubt that scripting would work inside a song, but I can see it a bit useful as macro functionality to make a tedious task easier by doing it scripted.
For instance, do a copy/paste between songs, transpose the song in a specific way not possible by the replace dialog (can't think of one but I'm sure there must be one)
Would it be inside the song, then the only thing I can think of is, a simple script that would be; if xxx is true, then yyy.
This could be useful for jumping to a specific pattern or perhaps using automation.
I said pattern editor. Of course that doesn't mean "song scripting".
Quote from: "Jojo"I said pattern editor. Of course that doesn't mean "song scripting".
Since you program the song in the pattern editor, I wasn't sure. Don't blame me for the fact that both answers are possible.
Since Renoise is getting the LUA-scripting I would like to see what it brings before I can say how it would be useful. (Just have to wait for the beta release to show up).
Could better automation be one of the functions that could be done?
But generally LUA is way easier to program than c++, so I reckon we would have more users contributing to the project. So I am all for it, just don't how it would be useful. And is LUA the only alternative, how about Python or Erlang?
Quote from: "Rakib"And is LUA the only alternative, how about Python or Erlang?
How simple is it to implement those languages in a C++ project then? Lua is not without reason the most wide-spread scripting language that can be found in many well-known programs.
QuoteSince Renoise is getting the LUA-scripting I would like to see what it brings before I can say how it would be useful. (Just have to wait for the beta release to show up).
Well, it would making editing patterns a lot easier, and people would not have to bug the developers to implement each and every pattern edit function into OpenMPT which probably noone else needs (f.e. a special transpose function which only transposes certain instruments on certain channels or whatever).
http://code.google.com/p/epi/
http://www.language-binding.net/
But it was just an question, LUA sounds nice.
But I know in many scientific areas c or fortran is used to do the calculation and python for the non-speed related stuff.
hmm, interesting thought, i can definitely see it being useful!
i would also like to see instrument/sample modification possible, like making a script to iterate through all the samples and disable panning (ugh, i hate doing that).
the question i have is: would these scripts only be macros (like i can see the 'cleanup' command becoming a script, or the interpolate volume/effect column), or could they be an always-running thing that would modify the way mpt behaves (such as keyboard split becoming a script, or making mpt display .xm effects as .it style instead, or even creating custom dialogs...)?
i would put in my vote for python tho, simply because its the scripting in another of my favorite programs (blender) and im trying to learn some of it, but hey, whatever works.
I thought more of macro-like actions, but it is probably possible to let them run in the background - I don't know yet.
How scripting compares to allowing people to write plugins?
I'd say it's the same amount for integrating it, but the advantage of scripting would be that the user can directly write scripts in/for OpenMPT without having to use a separate compiler. And a script is practically platform-independent and no plugin interface has to be designed carefully (of course there is still a scripting interface to be designed, but this is easier to fix than a plugin interface IMO).
By looking at the renoise forum and all the tools they are building their, I very much want to something similar in modplug. But if implemented, I'd like a in-built script-editor and maybe a debugger and if it's not to much work a form builder.
http://www.renoise.com/board/index.php?showtopic=27164&pid=213885&st=0&#entry213885
A debugger is extremely unlikely to happen, and neither is a fully fletched script editor planned. Of course it is possible to display errors in scripts, but not much more than that. And there are enough good Lua editors out there.
At the moment, I'd rather prefer a C implementation like picoc (http://code.google.com/p/picoc/) instead of LUA. Though I'm not sure how useful picoc will be, since there's a chance that it won't work with Visual Studio, at least not out of the box.
As LPChip has been asking about the status of this, here are some concept I have been writing up over the last few months. Feel free to discuss and add remarks. It is very much possible that I've forgot about important functions that should be available to the scripts.
Concept: Running scripts
Obviously there would be some kind of button / shortcut: Run Script
This would open the "Scripts" dialog, which offers a list of existing scripts (most recently used script would be preselected).
Frequently used scripts could be assigned to freely configurable shortcuts (maybe 10 of them?).
Concept: Actual Scripting
Things that the scripts should have access to:
- Patterns
- Order list
- Sequences
- Samples
- Instruments
- Plugins?
Actual interface functions
- Read / write playback/edit position
- Read / write access to Order list
- Read / write / create / delete / switch sequences
- 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
- Read / write access to sample data, create samples
- UI access: Get and set selection boundaries (pattern data / order items / sample data)
- Dialogs: GetInteger / GetFloat / GetString input boxes (all with optional min/max parameters), Message Boxes
- Callback functions that are called on every tick / row / pattern change.
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.
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." ;D 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.... ;)
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
Update: Squirrel (http://www.squirrel-lang.org/) 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?
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.
QuoteI 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).
Quote
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.
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
Con: It's JavsScript? :P
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)...
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 :-)
Hi all!
Quote from: Saga Musix on April 06, 2011, 20:34:52
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... :-[
Quote from: arseniiv on December 25, 2014, 19:52:54Could 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 (https://wiki.openmpt.org/Manual:_Hidden_Settings#.5BPaths.5D)).
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.
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 (https://forum.openmpt.org/index.php?topic=5708.0) 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. ;)
Oh, interesting. :)
I currently can't think of more examples, but I will give it some thought and come back to this.
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.
Scripts will
not be a part of a module or able to modify the behaviour of module playback (in particular, scripting will not be part of libopenmpt). Scripts will also
not be able to modify the drawing behaviour (or any other part) of the UI. This would be beyond the scope of a scripting API. To quote Renoise's scripting readme:
QuoteChange Renoise's existing behaviour. Like, you can't make all C-4s in the pattern editor yellow instead of white. You can write your own pattern editor, but not change the existing one.
The same will be true for OpenMPT, probably for the same reasons as the Renoise developers found.
Being able to create your own windows would be nice in the long run, but I doubt it would be part of the initial API, since that's a rather complex thing.
Okay then.
To be more precise, the scripting API will mostly focus around reading and altering module data - patterns, samples, instruments, plugins, everything. It will be able to run in various contexts, like automatic background scripts that do something anytime a pattern inserted, or it can be called explicitely by the user. Some MIDI I/O manipulation (like MIDI filters) will probably also be possible. The focus, however, is not on modifying the GUI.
So: I want to hear your ideas of fancy things you want to do with the module data. Maybe running some FFT on sample data? Morphing patterns? Give me ideas! ;)
You can also post any other ideas that are not related to manipulating song data, since I do not want to exclude those. But as said, it's unlikely that things that do something with the program's UI would get into the API.
And I don't want another song to be able to modify how my OpenMPT looks like. I don't get it why some programs allow that. The only exception where I understand it, is with Rebirth, where the skin is part of the sound module, and the song itself uses that sound module. Its like bundling your song with a VSTi and that VSTi happens to have that skin.
Quote from: Saga Musix on July 05, 2017, 11:53:07
Maybe running some FFT on sample data? ;)
Wow this would be very cool!! what kinds of fft operations you could add ? ::)
its been 10 years still havnt seen anything powerfull about FFT on vst than http://rekkerd.org/dtblkfx/
Quoteits been 10 years still havnt seen anything powerfull about FFT on vst than http://rekkerd.org/dtblkfx/
I didn't mean this as an online processing effect (though that could in theory be possible if I add a scriptable Lua Plugin to the list of built-in plugins), but rather offline, like transforming some sample data to FFT, then doing some operation on the FFT (e.g. removing a specific frequency), and then transforming the FFT data back to a normal sample.
yes i understand about offline.
removing specific freq is interesting and helpfull!
what i've been using a lot is an exageration operation(like anarchy effects Convoluter - free version http://www.anarchy-rhythms.com ) - that is like blending/morphing your sound from sine tones to noise. from very circle to very random.
another thing is a spectral compression that can delete frequencies below selected volume, for example -50db(things only closest to silent will be deleted) - this is very usefull for extracting specific instruments from a mixed tracks. or give it a range like "keep frequencies from -20db to -30db, all other frequencies must be deleted"... there is a tutorial on this particular plugin for max for live on youtube, but i guess it wont help you ???
this fft technology is all exclusive :)
Yeah, I think all of that should be doable. ;) I've been working on a lot of stuff related to this during the last week, and I think we should be able to have at least a basic scripting API in OpenMPT 1.28. Some simple operations are already possible, like converting all samples to 8-bit with a single line of code.
LOL maybe I'm simplistic in my thinking, but I would like the ability to bind scripts to keyboard shortcuts for the purpose of triggering playback of specific patterns, samples, and so on for live performances.
Yes, as mentioned, scripts can be run in different contexts, e.g. at startup, or when a key is pressed. Play/Pause is already a planned but not implemented part of the API, playing a specific note of a sample/instrument might also be sensible.
Probably going to happen, but it would be nice if it could fire up all commands available through the menu. In my case I'd want to load the most recent song. Maybe even the most recent two.
It's not been in the API wishlist yet but it has been added now. :) The difficult part is how to make it work smoothly and easily, since e.g. command IDs and positions may change. Having access to the MRU list even without the menus might be more sensible.
Yeah. I guess the MRU doesn't actually have to be tied to File->1-0. But other commands in the menu might be nice. For example having a script that performs a few actions and then opening the setup screen for you, or switching to a different song in memory.
Sure, the intention is that most, if not all things that can already be called manually would be available in the API as well. If I overlook some of them, they can of course always be added later, but having ideas of what people want to do with the API will minimize the risk that something important is missing. :)
Current Status: After a week of work on the scripting integration, I already made good progress in implementing various things that already make it possible to run a script "with a purpose", for example I can already run a script that would convert all samples to 8-bit mono. Switching between songs and getting a list of loaded songs is also possible.
Can it open a textfile, read its content, parse it, and perform actions based on that?
Can it also get information FROM the tracker instead of performing an action? For example, get the maximum length of the current song, know when the song is about to end, perform an action when the song ended and the tracker is no longer playing (can happen if looping is disabled), etc.
One could create a playlist engine this way which could be benefitial for one who wants to perform on stage.
Oh, and if possible, can the script generate a dialog with buttons and perform actions based on custom button presses?
For example, the script loads preprogrammed songs and waits for a button press to advance in the script.
Quote from: LPChip on July 09, 2017, 10:32:24
Can it open a textfile, read its content, parse it, and perform actions based on that?
Lua has a file I/O package, yes, and I will enable all the default Lua packages.
Quote from: LPChip on July 09, 2017, 10:32:24Can it also get information FROM the tracker?
Yes, that is the entire point of the API. ;)
Quote from: LPChip on July 09, 2017, 10:32:24Oh, and if possible, can the script generate a dialog with buttons and perform actions based on custom button presses?
Oh come on, it's even being discussed in the first post on this page...
Okay, I admit, that last one I got carried away in enthusiasm and it was a bit of teasing on my end. :P
I like how my post is now referring to itself recursively due to the page break.
Quote from: Saga Musix on July 09, 2017, 10:43:58
I like how my post is now referring to itself recursively due to the page break.
Hahahaha I hadn't noticed. I read first post of this topic, not page...
I am very sorry to revive an old thread, but any update on this? I cannot find references to scripting in the doc/version history. I would like to export pattern data from OpenMPT to json.
I work on this every now and then, but there's not so much progress. It's a huge and difficult task. The current state can be tried at https://github.com/sagamusix/openmpt but I don't remember if accessing pattern data currently works. libopenmpt might currently be an easier / more stable way to get pattern data out of module files, or maybe copying all patterns to the clipboard and then transforming the text data to json with an external tool.
Thank you for the reply and the effort! I'll look into the alternatives you suggested.
For me the ideal simple scripting interface for modplug would work like Inkscape plugins.
Inkscape is an SVG editor and when you run a plugin what happens is the entire SVG data is simply passed to the plugin via stdin, which makes its changes, and then returns the SVG data back again. Inkscape replaces its own buffer with whatever the script passed back via stdout (and you can undo of course).
For modplug it could be just this simple. You click a button called "run pattern script" and then choose an executable, or scripting file which is associated with an interpreter by the OS already. The entire pattern data is passed to the script you choose via stdin, which could even be in the same format as modplug copy-paste data (JSON could be nice but it's probably more work). The stdout from the executable/script is then parsed as paste data and pasted over existing pattern data.
In this way the user can use whatever language they like. If .py files are associated with the Python interpreter they can select a Python script. Same for Lua, Nodejs, native exe, etc. All they need to do is parse the pattern data in their language and return the modified data by printing to stdout.
Openmpt could remember previous scripts in a pull-down menu for convenient access.
Stderr could be logged and simply displayed to the user for errors and debugging.
For me an important difference from just manual copy-paste is being able to get the entire song of data not just one pattern.
Perhaps it would be nice to be able to only pass some channels and somehow tell the executable this, but that's not essential.
It could be done in an async way so the script can e.g. launch a UI with options/config for the user if needed.