FWIW, a lot of things have already been discussed in the development section: https://forum.openmpt.org/index.php?topic=4078.0 Now that we will start targeting C++11 with OpenMPT 1.27, implementing scripting will become a little bit easier (as in, less cumbersome), but there are still a lot of internal things that need to be refactored to be able to implement scripting properly.

Okay, but still looking forward to it even if it takes some time.

Bumping this as a "I really want to make and contribute scripts" vote.

Thanks for your interest. If you have any specific ideas of what you would like to be able to do with the scripting API, please post them here, as this will help shaping up the API and deciding what's needed and what isn't.

Sure. Ideas I have about what I would do with a scripting system and how I'd expect it to work:

Pattern shortcut keys to do these things

• Shuffle and adjust existing pattern data(e.g. humanize or quantize rhythm)
• Fill in pattern data from a menu of presets (with submenus for note column, effects column, mixtures, etc.), with some presets responding to and modifying the existing data(i.e. potential for chaotic effects by pushing the button multiple times).

Scripts that fill in instrument data.

• Pick "piano_c4.wav" and it automatically looks for "piano_b#3.wav", "piano_c#4.wav" etc. and sets the trigger ranges.
• Auto-fill default loop points, note-cut behavior, envelopes, fade, etc.
• (more ambitious) Program the entire front-end of the sampler, e.g. it reads the note-on, volume and effects columns and interprets those to one or more output voices, adjusting sample, loop point, filter cutoff, etc.

Scripts to help prepare a track for export or make it more fluid to downgrade formats(e.g. I am writing for a webgame and plan to use .XM, but initially write in MPTM for convenience)

• Batch downgrade sample quality to a certain specification (e.g. 33khz, mono, 16-bit)
• Convert single-track, long-release note-offs that rely on MPTM voice allocation to 2 or 3 monophonic XM tracks
• Batch render plugin chains to sampler instruments(Renoise has a builtin function for this)

For the API model of most of these I would expect to be working from within a input data->output data callback that lets me do "CRUD" operations on the native data structures, with UI limited to a pre-action menu, maybe with some buttons, sliders, or lists of presets; for numeric entries the UI should be able to remap ranges, e.g. dB power to % amplitude. For the scripts that are more like shortcuts, they might rely on a separate configuration step, i.e. there is some kind of data persistence they're relying on, with the config taking place in a different script. Scripts might want to declare up front what parts of the persistent store they use(and if they are read, write, or both), so that the UI can expose dependencies, conflicts or maintenance issues to the user.UI gets trickier when I consider more elaborate UI situations such as a "wizard" style system where it cycles between user prompts and batch processing, or a concurrent UI that is synchronized as the user scrolls through the pattern view or makes other edits. I don't have specific ideas about that.I am not very particular about the programming language syntax or runtime; it's more important that the API be flexible and have good examples, and that the language have a type system appropriate for the context(e.g. a unified numeric type like JS may be inappropriate), and good tooling(errors, debugging features, etc). Neither do I expect the scripting to have the throughput or real-time requirements needed to perform DSP; the most latency-dependent situation I outlined above was for the sampler front-end. For DSP code I would be referencing the many audio programming languages that are out there(e.g. Pure Data, Supercollider, Faust, CSound), while my interest here is in scripting OpenMPT's existing data model.