2009/10/12 Mathias Gyllengahm <firstname.lastname@example.org>
It was a long time since I did any MusE coding, but being on paternity leave has given me a bit of coding abstinence... So while Jr takes his daytime nap (usually they are far too short! ;-) I've been doing some happy MusE-hacking. Since his naps are short and he doesn't sleep well at nights I can't stay up long to code, so it has been necessary for me to keep my work short and precise - it's simply not possible to build up very long chains of thought...
Anyway, me and Robert have discussed the possibility of launching external scripts within MusE that as input are given data about the song (midi events). The scripts manipulate that data and MusE parses the data and updates accordingly. More precisely as follows:
1. The user uses a menu from within the pianoroll to launch an external program (probably a script)
2. MusE dumps the data of the selected part to a temporary file. The data looks like the xml from the project files, but it only contains a <part>....</part> tag.
3. MusE launches a script which as argument is given the path to the temporary file. The script modifies the data
4. MusE parses the data back to a new Part object and updates the song to reflect the new structure of the part, as given by the script
I've made the above scenary work, but it needs some thinking. Here's where you guys can give input!
The above scenario makes it possible to quickly implement features that as of today are a bit cumbersome. F.ex. deletion of overlaps functionality or fixed length could have been made this way. This could be used to do scripts for generation of data as well, but as of today it doesn't really fit into the concept, since it's tied to the pianoroll, and a generator script doesn't need any input. Anyway, that could be changed in the future.
Just ignoring the input, as would be done with a generator, seems fine to me :-)
What I'm thinking of is how to do the connection between the external scripts and the editor. The easiest thing (I like easy things) is to simply scan two directories for executable files. One directory coming with the MusE installation (this way we can distribute nice scripts with the application) and a directory under the users home directory, f.ex. ~/.muse/midiscripts or something like that. The Pianoroll is equipped with a new menu, named script-fu or something like that, and in that one goes all the filenames of the executable files in these directories. Perhaps a separator between them to distinguish between delivered or personal scripts. No fancy file with lots of descriptions of each script, what it does etc. That could be done later on.
Just two dirs with executable files (e.g: staticlength.py, swing) looks like a good start.
What do you guys think? I'm already thinking fancy Python QT-gui apps with lots of knobs and stuff.
Yes yes yes yes yes :)
As you can see this can quickly lead to dependencies to lots of obscure libraries since everyone can extend MusE with their own favourite app. I think the benefits outweighs the backsides by far though. On the other hand, we should probably restrict the delivered scripts to f.ex. Python + Qt3/Gtk or something like that. It might also be easy to crash MusE with badly coded scripts.
In theory the isolation should be quite sound (no pun intended) if the file import can be done in a safe way...
Which brings me to my only concern. I didn't look at what is available in the Part tags but I wonder if there aren't a bunch of data that should be good to have that isn't available. ...
- number of samples in part
- number of measures contained (in float i suppose)
- bpm (a bit harder if there are tempo changes)
And the parsing/creation of xml is imho a little much to handle in a script (but perhaps I'm just old and backwards)