[DUPE] Revised IT Project (.ITP) functionality

[bvanoudtshoorn]

Nice idea -- could prevent 'code copy'. Related to this, I've been pondering about possibility of having sort of 'background pattern data'. The idea is roughly that if one has for example drum channels in pattern 1 and the same drum part would be used in multiple patterns, then instead of copying it to every pattern, one could have the channels in other patterns as 'background channels': the channels would effectively have the pattern data just as in pattern 1, but background data could be edited only in pattern 1, and the modifications done there would be effective on all background instances. Compared to the somewhat arbitrarily chosable clips, this might be considerably easier to implement.

I really like this idea. It'd make the whole continuous scroll paradigm more uniform. Just to clarify, is it
1. Data in pattern X is repeated in patterns Y and Z unless you say not to?
2. Data in pattern X is assigned to some sort of ID thing, which you can then ref and include in patterns W, Z, and B?
I definitely prefer option 2...

Just to throw up problems before you even start to think about coding this -- what would happen if the patterns that you reuse the data in are of different sizes?

[LPChip]

Maybe it should be done like it has been done in Goat Tracker.

It was a bit different at first but now I really love it.

Basically a pattern consists out of 1 channel (could be made 4, which probably is better) and then for the amount of channels (if 4 per pattern, then divide by 4) you have that amount of sequences.

Although I prefer the instance one over this. I do think the user should create instances themselves by means of copy/paste. I would also like to see to convert an instance back to normal notes, and if you copy an entire channel, it creates an instance of that entire channel. Say you duplicate an entire pattern, it makes instances of each channel unless there are already instances present in the current channel. Then it'll copy the channel as is.

Basically you make one pattern, then you duplicate it, all channels become instances, you revert the channels you're working on and done.

[Relabsoluness]

I really like this idea. It'd make the whole continuous scroll paradigm more uniform. Just to clarify, is it
1. Data in pattern X is repeated in patterns Y and Z unless you say not to?
2. Data in pattern X is assigned to some sort of ID thing, which you can then ref and include in patterns W, Z, and B?
I definitely prefer option 2...

I haven't planned this throughly, but the first idea was something like that menu from right-clicking channel header would bring options such as:
(When no background channel enabled:)
"Use channel from pattern x on background."
(When background channel enabled:)
"Disable background leaving background commands as copy"
"Disable background without leaving background commands as copy"

And when duplicating patterns, there could be "Background duplicate"-option, then one could 'finetune' the background on channel level. Some finetuning could also be done simply be adding commands on top of background commands.

Just to throw up problems before you even start to think about coding this

Well it's good to think about possible problems beforehand.

what would happen if the patterns that you reuse the data in are of different sizes?

Either all background commands doesn't fit to destination or it fills destination only partly. More refined ways to do this could of course be invented, but in first approximation, I think this would be fine.

[Saga Musix]

I didn't read the whole conversation, I just stopped at this point:

That sounds interesting, but it also sounds like it would make things a bit complicated? I wonder how BASS.DLL or FMOD would handle these, they would also need to be updated to support this.

I wonder what kind of subtunes Relabs was referring to, but I guess even you, Skaven, have made use of subtunes in the past, the tricky kind of way (subtunes divided by "---"). Actually, I've asked how to detect subtunes in modules using BASS.DLL, look here.

[Skaven]

Perhaps, but there would be just one sequence to work with at any given time. So instead of having the songs one after another in sequence, there would be own sequence for all songs; when one would like to work with some particular sequence, it could be chosen simply by, say, right-clicking on sequence and choosing the given sequence from the context menu. The same patterns, samples, instruments etc. would be available for all sequences.

Yep, sounds good. The main reason why I've been looking for something like this, is that I've had to implement multiple songs (or sequences) within one tracker file to be able to share the sample set, yet have multiple different tunes for one game title for different game states (main menu, gameplay1, gameplay2, game over fanfare, win fanfare, etc).

Like Jojo posted just above, these had to be separated with "+++" markers (just for visual clarity - I'll welcome Sequence Markers any day ), and whenever any song gets any shorter or longer, all the consequent songs will shift in the sequence, thus all the Bxx loop commands and the game's song offset locations need to be updated. This is tedious and error prone: Bxx commands must be in hex in the patterns even when "Display rows in Hex" checkbox is unchecked in the preferences), while some games refer to the offsets in base 10, need to fiddle with Calculator.

Multiple sequences within one tracker song would make this very easy. But I don't know how many people really need this feature for other purposes than just including many songs within one file. For downloadable games this would be teh win. Perhaps some demoscene demos could benefit from this too, although it seems that most demos just use MP3s and Oggs these days.

Additional idea for the multi-sequences: each sequence could be set with its individual highlight interval. So that you could use 3:4 or 3:3 in some sequences and 4:4 in others. Er... on second thought, maybe this should be pattern specific (like pattern name) rather than sequence specific... and it's very low priority anyway.

I've been pondering about possibility of having sort of 'background pattern data'. The idea is roughly that if one has for example drum channels in pattern 1 and the same drum part would be used in multiple patterns, then instead of copying it to every pattern, one could have the channels in other patterns as 'background channels'

Sounds like an interesting idea, but it would restrict the instancing to the length of the pattern. Many drum beats et al have a much shorter repeat interval (for example, 16 rows, where a pattern can be 128 rows long). So like LPChip, I would prefer instances.

To keep things simple, duplicating an entire pattern would just duplicate the note data unless there are instances in it, then the instances would get duplicated as instances. Otherwise oMPT may instantiate data the user doesn't want to instantiate. I wouldn't want to instance an entire pattern, because I just as might just repeat its number in the Sequence editor.

Also, some of my instances may more than one columns wide (such as 3-channel chords with fade commands) - should these be possible?

However, I suppose nobody needs instances that go beyond the boundaries of a pattern? Should be prevented, the user shouldn't be able to drag an instance partly outside a pattern. That, or the part outside is just ignored.

[Relabsoluness]

But I don't know how many people really need this feature for other purposes than just including many songs within one file.

I think it's quite sufficient for the feature to justify its usefulness if people need it for that particular purpose.

Sounds like an interesting idea, but it would restrict the instancing to the length of the pattern. Many drum beats et al have a much shorter repeat interval (for example, 16 rows, where a pattern can be 128 rows long). So like LPChip, I would prefer instances.

I do agree that instances could be more powerful and user friendly, but there's also the question how difficult it is to implement. Background channels, as subset of instance-functionality, could be a good starting point. It's also worth noting that by creating 'instance patterns', i.e. patterns with instances that can be mapped to actual patterns through background channels, one could tackle problems like the different sized patterns.

[Skaven]

But I don't know how many people really need this feature for other purposes than just including many songs within one file.

I think it's quite sufficient for the feature to justify its usefulness if people need it for that particular purpose.

All right, I'll make it an official Feature Creep Request then.

[Saga Musix]

I read "future crew request".

[Saga Musix]

I'll move this one to the archive; any discussion on this idea should be continued in http://bugs.openmpt.org/view.php?id=368