Need a generic way of splitting a song into multiple patterns

[Malvineous]

It is currently not possible to convert an unpatterned song like MIDI, IMF or RAW into a patterned format like S3M.

Rather than simply start a new pattern when the end of the current one is reached, it would be nice to analyse the song and try to find repeating sections, so those can be used as the pattern boundaries. But a run-on pattern conversion might still be needed in case those patterns end up being larger than the format supports (S3M has a max of 64 ticks per pattern.)

This would also require reducing the tick speed and rewriting the song with fewer ticks, since formats like RAW typically run at hundreds of ticks per second, while S3M is usually less than 10 ticks per second. It might also require expanding the ticks as well, so that a pattern being written to S3M can be expanded to 64 ticks exactly.

[ildar]

A tiny hint: https://github.com/uyjulian/spc2it/ splits into configurable amount of rows per pattern.

[Malvineous]

That would work if there was only one input and output format (like SPC and IT) but unfortunately once you start introducing other formats it complicates matters somewhat due to the various format limitations you need to work with.

S3M and TBSA for instance are both fixed at 64 rows per pattern, so to write in these formats you have to adjust the song itself to fit into 64 rows per pattern (or fewer, with pattern break events.) If you get input patterns larger than 64 rows, you have to decide whether to write one S3M pattern for each input pattern, possibly altering the timing or losing notes, or whether you spread each incoming pattern over two or more S3M patterns to keep the timing right and preserve all the notes. The correct decision likely depends on the source song, so you'd need both options available.

Then .raw files can have thousands of rows (DRO is 1000 rows per second) so you don't really want to write an IT with 1000 rows per pattern, you want to try to reduce this to the smallest number of rows possible. But again how far do you approximate the timing in order to reduce the row count? If there are events on rows 0, 500, 1000 then you can easily slow down the tempo and reduce that to rows 0, 1, 2, but what do you do if you get events at 0, 500, 1001? What about 0, 500, 1020?

It's all doable, the trick is just in figuring out how to make it as flexible as possible while minimising the tradeoffs.

[ildar]

Mmm, leave quantization on user's choice?

[Malvineous]

You'd still have to provide some sort of guide to point the user in the right direction, otherwise they'll quickly get frustrated as they change values but they are repeatedly told "sorry you can't write to an .s3m file because there are too many rows per pattern".