Hi all,
I'd like to propose a new pattern command that combines note delay (SDx) and note cut (SCx) into one command. I'll call it :xy for now[1].
":xy" means the note begins at tick x and cuts at tick x+y (so plays from tick x for y ticks).
The concept and implementation are both very simple, and the benefit is fine-grained control over the slice of time in which the note plays - extremely useful (& fun) when tracking at high tick resolutions in modern tempo mode (e.g. 16 ticks per row). This is also particularly handy for VSTis, where tick-resolution control of the note's timing cannot be achieved with envelopes or by adding silence before a sample.
Here's a prototype patch: http://gist.github.com/371612
Let me know what you think - if there are no objections I'll tidy it up and check it in. I've had this in my working copy for years and find it very valuable (I use it pretty much every time I fire up OpenMPT), but I was reluctant to commit it because adding pattern effects can be a bit controversial. Of course, we'd add it only for .mptm.
[1] In the current codebase, command ':' is associated with something called "velocity" (CMD_VELOCITY and VOLCMD_VELOCITY). This is nothing to do with MIDI velocity. When used as a volume command, :0x results in some half-finished algorithm I implemented based on a chat with LPChip in 2004, combining sample offset and volume. I don't think anyone uses it. When used as a normal command, it does nothing at all. In fact, it doesn't even load properly (hence the change to Load_s3m.cpp in the patch above: chars < 0x40 don't load as pattern commands - not sure if it this is a bug or an aspect of IT pattern packing). Therefore, I think it would be pretty safe to use ':xy' for something else. If we pick this character I'll clean up the code to remove the references to "velocity".
The idea sounds great - as long as it's only implemented for the MPTM format (I hope that the XM/IT hacking times are now finally OVER). I would also be very glad about the removal of the velocity command, I always found it rather useless to be honest, and it makes the whole code just so much more confusing.
You have my approval to remove the effect. I was looking for a way to give sounds a more natural feeling by being able to use this velocity command to give the impression that expression was used.
Since this effect is only useful on samples, and I use VSTi's nowadays, I don't find myself using it.
Excellent suggestion! I'm sure i could use it! 8)
Hmm. I wonder if the "note cut at x+y" thing is not a bit too confusing. Especially because you always have to keep the current ticks/row in mind. And especially if the cut value is 0, the cutoff won't happen at all - is that wanted? If the cut value was absolute like the delay value, one could also cut "before" the actual note, which sounds like a nice feature to me.
I did consider using y as the absolute cut tick value - in fact I had originally implemented it that way. As you say it is a little more intuitive, and you can cut the previous note before the current delayed note begins (nb: you can always achieve that by using an extra channel anyway, so this is pure "syntactic sugar").
On the other hand, the benefits of using x+y are:
1. A larger range of ticks can be covered. Your cut can be as late as tick 0x0F+0x0F - nice if you have over16 ticks/row.
2. While tracking, I noticed that often you want to keep the duration of note constant and just change the delay value. If you use absolute values, you have to change both numbers to keep a constant duration. This is the main reason I decided on x+y, such that y represents the absolute duration of the note (except when y=0 as you correctly point out, or when (x+y)>ticks/row, because cuts don't carry beyond the current row).
That being said, I don't have strong feelings either way - I'm happy to change it if you prefer. :)
Regarding what happens if y=0 (i.e the cut tick is the same as the delay tick), there are two choices: either the note doesn't play at all, or it doesn't cut at all. I think the latter is more useful. Sometimes you're experimenting with different delay (or cut) values, and come to the conclusion you don't want a delay (or cut) at all. In this context, being able to just replace one of the values with 0 is handy. In other words, having :x0 behave like SDx and :0y behave like SCy is quite nice imho.