tepples wrote:
But I fear that some of these, such as patterns with effective loops of different lengths, might not be exactly trivial for an exporter to detect automatically. I guess I ought to sit down and define the loop recognition problem more precisely and present the definition in a new topic, in order to see if it's isomorphic to some problem known to be either tractable or NP-complete.
Well, detection of loops and repeated substrings within a single pattern is actually pretty easy, and patterns are "short" in the scheme of things. NP isn't a necessarily a problem when you're dealing with a small enough set. Detecting shared pattern data globally is harder but there's a lot of pretty useful detections you can do without breaking your back. We only need "good enough" here, not "optimal".
Stepping back from this, though, the whole point of the complex repeat features is
compression, right? The goal should be "how do I make the smallest output data" before it should be "how do I let the user play tetris with their own data". If finding the optimal way to loop something really is a hard computational problem, the user will also have a high probability of failing to solve it well, and also likely it will take a human more time and effort, which is also a waste.
From another angle: generic compression algorithms manage to do a pretty good job of things like this already, so I am certain there are practical methods already available.
4klang does a pretty good job of compressing music data, and might have useful techniques.
tepples wrote:
how would I "export row highlight and 0CC-FamiTracker linear pitch setting"?
I thought linear pitch was just a global option you can choose? I don't really understand how this is an export problem? (Supporting it at all is a problem, but that doesn't seem to be your question?)
Does "row highlight" mean something I'm unaware of? I assumed this meant the visual appearance of highlights on every Nth row while editing in the tracker. Why would it be exported, isn't it only visual?
(I don't use 0CC so the terms might be used to mean something I don't expect.)
tepples wrote:
rainwarrior wrote:
Just because Famitracker doesn't have a variety of "mirror this but with ~~~ transformation applied" modes as a built in feature doesn't mean you can't apply it after the fact.
In my experience, composers want to make changes to a piece even after I've hand-optimized the converter's output, and it would be labor-inefficient for the tools people to have to hand-reoptimize the data after each tweak.
Yes, having mirror functions in the tool would be great and more convenient. The only mirror Famitracker has currently is just through the order being able to reuse a pattern on the same channel.
The optimization problem wasn't that big a deal for me, though. The main reason is just that you don't need to "hand-reoptimize" all the time, only once you're finished working on the piece. It's a finishing pass, not ongoing labour. The other way I mitigated it was having my my exporter output some diagnostic statistics to a text file that I can use to understand what duplicates were found, etc. and of course the total size is a very useful metric. During that finishing pass I could go over the tune and spot my copy paste failures (which weren't many, TBH). It was a very small problem to solve and took only minutes to go over the whole soundtrack.
Actually, this is getting a little bit away from what I think is the actual advantage of complex mirroring/repeat functionality (which MML has a distinct advantage for). Mirroring is just a useful composing tool; you'll find it in notation packages like
Finale too, where there's no export size concern at all. I think it's
primary function for the user should be for that.
Making smaller output is a good side effect of mirroring, but the
exporter can and should find mirroring whether or not the user remembered or knew to specify it (or did a suboptimal job). The user does
not have to be the compressor. Giving the user power to compress something themselves in the absence of an automated one is worthwhile, but it's certainly not the best use of their time if it can be easily automated.
And finally, even if MML has good mirroring tools, like I said before I wouldn't trade the tracker workflow for it. Too much is lost for that gain. The ideal solution for the me would be better mirroring
within Famitracker, not abandoning Famitracker for MML.
...but overall it's something I can live without; the repercussions of not having it are only a minor inconvenience. If it was a bigger problem I'd have modified Famitracker myself.