Saving patterns the other way... (MPTM)

[Saga Musix]

In his articles about his softsynth, kb/farbrausch pointed out that saving patterns row by row is just "stupid" and that saving them "channel by channel" (first downwards, then left to right) is better, e.g. for compression - redundant data can be compressed easily. So I thought that we could do that in the MPTM format as well...?

[bvanoudtshoorn]

You know, I like the idea, but I have to ask... Nowadays, is a difference of, say, 300KB really that significant, especially given the amount of work that will go into this?

Personally, I think that a far more logical organisational structure would be by instrument; theoretically, this would then flow through into the pattern's organisation. Something like what was discussed in this post...

[Saga Musix]

Nowadays, is a difference of, say, 300KB really that significant

I'm always optimizing for size, no matter how much it improves the size. Just because we have the resources, doesn't mean we have to waste them. And there are f.e. also compos that depend on size (32kb compos and other stuff) where you'd love to have this reduction in size.

[bvanoudtshoorn]

Hmm, I see your point.

In that case, I think that you could have even *more* optimised storage by grouping instruments together, rather than channels.

[Harbinger]

If i understand you correctly, this would mean a pattern would consist of one track/channel. This sounds closer to sequencing, which is how i cut my teeth. Tracking (as opposed to sequencing) seems somewhat primitive to me, and since i now use .mptm exclusively, i'm all for it. (Should we use a different extension for backward compatibility?)

Oh yeah and optimization is good too

See what you can do!!

[Saga Musix]

it doesn't change anything with patterns, it's just a different method of storing data in files which leads to better compression. modules were stored "row by row" in the past because it was faster on the amiga and for no other reason.

[Harbinger]

I see what you mean.

But if we store it this way, wouldn't it be a short leap to ascribe one pattern per track? This would allow patterns A and B of track 1 to be played twice each while track 2 played Patterns C,D, E, and F, for example.

Of course we'd need a new pattern GUI....

[älskling]

I think this is a good idea when creating 4kB demos, but in general, isn't there also a good reason for many new file formats to be xml-based?

[Relabsoluness]

In his articles about his softsynth, kb/farbrausch pointed out that saving patterns row by row is just "stupid" and that saving them "channel by channel" (first downwards, then left to right) is better, e.g. for compression - redundant data can be compressed easily. So I thought that we could do that in the MPTM format as well...?

In IT-files pattern data is saved so that there are channel-specific flags used to control what gets written; for example if there is a channel with identical rows, it doesn't save the same row multiple times in the file.

But some new way to write pattern data seems needed at some point, for example the special (control) notes introduced in the devBranch_1_17_03 can't be saved with IT pattern data if I recall correctly.

I'm always optimizing for size, no matter how much it improves the size.

Even at the cost of performance and wasting time on something completely irrelevant?

Just because we have the resources, doesn't mean we have to waste them.

Totally agree.

[Saga Musix]

Even at the cost of performance and wasting time on something completely irrelevant?

Well, of course I don't go that far But some things are easy to do and not very resource-demanding. I was maybe exaggerating a bit.