View Issue Details

IDProjectCategoryView StatusLast Update
0000147OpenMPTFeature Requestpublic2011-07-01 18:19
Reporterharbinger Assigned To 
Status newResolutionopen 
Platformx86OSWindowsOS VersionXP
Summary0000147: Pattern Aliases

I posted this right before Issue Tracker became available, so i wanted to bring this in for possible implementation. Here is the original post:

Not sure how difficult it would be, but knowing a bit about the code, i want to enter this request for the future. If done right, it could be a feature that most other trackers don't have.

I'm envisioning a Pattern Alias, a special note in a pattern row that forces a channel to play the data from another pattern, even while playback continues in the current pattern. The Pattern Alias would look a bit like a PC event, but instead the user can enter an alias to row Z of pattern Y belonging to the sequence X, something like:

PAT 01 012 000

which means the playback pointer would play the note data starting at row 0 of Order 12 of Sequence 01. (This of course limits the aliasing for the first 1000 rows of the first 1000 patterns of the first 100 sequences).

I'm thinking it can be implemented by simply extracting the note from the given source row (or tick) in the same way it extracts the note from the current tick of the current pattern. That is, the playback pointer keeps up with where it's at for each channel, and when an alias is called, the channel's pointer finds the data from the same place in the source pattern. Then, if a note or other event is called from the current channel, the data and perhaps the sound from the aliased channel is stopped (with options to loop or fade).

An alternate version would be a channel pointer rather than a row pointer. Instead of playing row X it could play the same row (as that of the pattern alias) but at channel X. I could use both methods.

I'm not sure what's the best way of handling pointer desyncing, such as when the current pattern is, say, 32 rows but the referenced pattern might be, like, 36. Theoretically, it should continue with playing back the source pattern until THAT ends, but the playback pointer for each channel would be in different rows, which might be able to be overcome by assigning a variable or an array to keep up with where each channel's pointer is supposed to be calling. Hmm,
CHANNEL pRow pChn pPat pSeq
000 031 000 001 001
001 031 001 001 001
002 000 006 050 002
which shows that when the "global" playback pointer is at row 31 for the current Pattern 1 in Sequence 1, the playback pointer for Channel 2 has encountered an alias, and its playback pointer is in the first row of channel 6 of the given pattern 50 of Sequence 2. So, even if the source pattern (50) has more or less rows than the current pattern, the pointers should stay in sync as long as every channel's row pointer is incremented properly. But what if the tick count is different? Or the tempo? Perhaps those of the source pattern are ignored, and those attributes of the current pattern are used.
There might also be problems with some of the other pattern FX like Pattern Break or Pattern Loop. Some limitations to their use would have to be introduced.

The result of all this would be similar to a sequencing trick of interchanging instruments using the same pattern of notes -- altho here we're not using different instruments, but it might be possible: patterns could serve as templates for note playback. By leaving the instrument designations in the source pattern blank (notes without instruments), you could call the instrument in your main channel, then call the alias to the "uninstrumented" pattern. You could do the same with volume levels and pan settings. It might also work for differing tempos and other global settings.
It would also save HD space (even though this is nowadays not a huge problem), and could make assembling and transcribing tracks a helluva lot quicker...

Sound doable?

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


There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2011-07-01 18:17 harbinger New Issue
2011-07-01 18:19 harbinger Description Updated