View Issue Details

IDProjectCategoryView StatusLast Update
0000875OpenMPTFeature Requestpublic2017-01-03 23:35
ReporterRapture Assigned To 
Status newResolutionopen 
Platformx64OSWindowsOS Version7
Summary0000875: Simple script system implemented in OpenMPT

As Saga Musix suggested in issue 0000064, a simple script system in OpenMPT would rock! "Welcome to OpenMPT script." thumbs up

Imagine what you can do with such a feature! For example:

  • rem exact instrument changes in certain patterns
  • change instrument 1,2 to 3,4 in patterns: 1,2,4,8,12-15
  • only from row 1-32 in patterns: 4,8, otherwise: rows 33-64
  • do it in open songs (tabs) in song: 1,2 and 4
  • end script

And LOTS of other funny and usable things!

So instead of implementing all sorts of special window pop up screens for every single tiny user wish, you could concentrate all these special wishes in a simple script system, where no special coding abilities are needed.

How the script language works would have to be explained in the OpenMPT manual, for sure.

I give it a big thumbs up!

Has the bug occurred in previous versions?
Tested code revision (in case you know it)


Saga Musix

Saga Musix

2016-09-14 10:30

administrator   ~0002662

FWIW, a lot of things have already been discussed in the development section: 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.



2016-09-14 12:52

reporter   ~0002667

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



2017-01-03 22:00

reporter   ~0002822

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

Saga Musix

Saga Musix

2017-01-03 22:23

administrator   ~0002826

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.



2017-01-03 23:35

reporter   ~0002827

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.

Issue History

Date Modified Username Field Change
2016-09-13 23:35 Rapture New Issue
2016-09-14 10:30 Saga Musix Note Added: 0002662
2016-09-14 10:30 Saga Musix Tag Attached: scripting
2016-09-14 12:52 Rapture Note Added: 0002667
2017-01-03 22:00 triplefox Note Added: 0002822
2017-01-03 22:23 Saga Musix Note Added: 0002826
2017-01-03 23:35 triplefox Note Added: 0002827