nesdev.com

I used MCK/PPMCK's implementation of MML for years and even made C++ programs for it as preprocessors to add features. I got really good/efficient at making music this way, and I was highly resistant to switching to FamiTracker, seeing it as a lot of hassle to switch to an unfamiliar composition method. Then I started doing collaborations with people using FT and slowly started to realize that it was a much better workflow. There's nothing more annoying in MML than having a drum loop that says something like [c8 c4 c8 d4 d8 c8 d8]256 then wanting to add a fill somewhere in there or customize it at all. Gotta count the loops for every iteration...whereas in FamiTracker you just find where you want to edit things and edit them. The only thing I miss from MML is search/replace functionality of text editors.

Anyway there's a program called MuMML that runs scripts every time you save your file. You can edit the scripts to do whatever you want and it has a lot of settings for existing MML formats. When I used it, it ran all my programs, then the compiler, then spit it out to Winamp. So for instance you could do what Rahsennor said, have some kind of symbol that ignores data above that line, then hit CTRL+S in your editor and the song will play from that point.

I sat and thought about it for a while and remembered that Pently has a concept of time signature, encapsulated in a "rhythm context" object (PentlyRhythmContext in pentlyas.py). Patterns use the rhythm context to translate "quarter note" into a number of rows, and the song uses it to wait for a particular measure and beat before emitting pattern start commands. Thus I'd need to ensure that the rhythm context can count the rows emitted by fix_note_duration(). For pickup, I could have a bar check in a pattern's first measure force advancing to the next measure rather than raising a warning.


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.

I have run into such NP-complete problems in past NES projects, such as about a year ago when I was trying to collecting sprite tiles into 1K banks for MMC3, where cels in one bank can share tiles but cels in different banks cannot. I discovered that minimizing the number of banks needed for a particular set of cels is the same as the "VM packing problem", which Wikipedia claims "is hard to even approximate." It's harder than the ordinary bin packing problem where objects do not share portions, such as packing compressed CHR into unused parts of a ROM in Action 53, for which the first fit decreasing approximation is more than good enough.

But if jsr hasn't made a new release of FamiTracker 0.5 beta in years, and HertzDevil doesn't accept pull requests for 0CC-FamiTracker 0.3.x, how would I "export row highlight and 0CC-FamiTracker linear pitch setting"?


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.


Seek back? Hold my beer.

Pently recently gained "seek forward"; "rewind to start and seek forward" is my next task.


I've headed down that path with my roadmap for adding a richer playback GUI to Pently's NES export. I've already got visualization and a rehearsal mark list over the past couple days, and next on my list are seeking to a rehearsal mark, pause and step as suggested by rainwarrior, and track muting. But what's the practical difference between an "export/compile" step (activated using the Run button in your text editor, or by a script watching file modification times) and the play button in a tracker?

The thing that'd matter to me: In famitracker, you can still modify note, effect, instrument data + pattern sequences all while playing back and the changes will take place instantaneously.

_________________
http://www.frankengraphics.com - personal NES blog

In theory it's possible to make the export/compile work, and it sounds like you might be on the right track, but the differences would be:

- instant conversion and playback. It should start playing immediately. If the conversion, launching, and starting of the player takes less than a quarter second, that would work

- interactivity. It sounds like you have some of this underway. I want to be able to press pause on the player, change one line/note/whatever in the score, back the player up one measure, and replay from there. Or play a single line over and over again while tweaking the source until I'm happy with it. Or if I have a channel set to solo or mute, I want it to stay that way after I make a change and press play again. Those aren't insurmountable, but are all important for an interactive feel.

I had another thing, but ran out of time, I'll come back later

_________________
My games: http://www.bitethechili.com

The other bits also apply to the interactivity, and are a bit harder, I think. I'd love to have some sort of UI linkage between the editor and the player. Like if I highlight an area of the editor, I'd like an option to only play that bit, or jump to it. And if I pause the player, I'd like some way to jump to the part of the source that's current in the player.

_________________
My games: http://www.bitethechili.com

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.


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.)


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.

Wouldn't this depend at least a bit what you'd be abandoning Famitracker for? I mean, MML in itself has no interface other than the constraints of the format, so it's hard to compare until there is one. Or do you mean that the tracker model itself is irreplacable for you?

_________________
http://www.frankengraphics.com - personal NES blog

I'm not talking about any hypothetical MML editor, I'm talking about what we have today. The value of Famitracker vs. that is enormous.

The pattern would be to set a temporary rehearsal mark just before what you're working on and set a project-wide option to have the player ROM start at that mark.


NSD.Lib and Pently always operate in linear pitch mode. But 0CC-FamiTracker's text export doesn't include whether a module was authored in linear pitch mode. This means the converter would not know what to do with vibrato depths and portamento rates unless the user passes an explicit command-line option stating whether the module was authored with linear pitch on or off.


In mid-2019, several key U.S. patents related to rhythm games are set to expire. A rhythm game would need to know how many rows make up a "beat" of musical time in order to know how fast to move the arrows. "Burning Heat" and "Butterfly" wouldn't use the same rows-per-beat setting, and "July" switches mid-song.


Composer to tools guy: "I thought I was finished working on this piece, but I was mistaken." It may be hard to estimate the different cost of propagating asset changes in different subsystems: "Your build process automatically recompresses level backgrounds when changed, so why not music?"

Why is that a problem? I would kind of expect the exporter to have a bunch of options like that. (OK maybe it would be slightly nice to have but it seems super trivial to work around? I presume you've already submitted a report to 0CC devs about it?)


LOL. I don't think there is anyone besides you in all of NESDevdom that would currently be holding back a rhythm game because of whatever patent you are referring to.


I think a rhythm game has a lot more specialized needs than that. TBH if you're making a rhythm game and you don't have some custom solution going on for the music you're probably doing it wrong?


Well, it's all about magnitudes. Like I said, in my case it took minutes to review an entire game soundtrack. If you think it's a significant problem then go ahead and solve it.

Done.


True, but probably only because the NES scene is small enough that only one person wants to develop a Power Pad-controlled rhythm game. The patents in suit in Konami v. Roxor are why StepMania is not in Fedora.

But time signature/row highlight issues aside, and assuming the advantages of the tracker model:

How critical is it that the music sound exactly the same through the game-oriented driver as it does inside the tracker? If, for example, the drum representation doesn't match that of FT, would it be acceptable to include surrogate drum samples in FT's DPCM channel along with commands in the describing how the converter should render them as PSG drums? You'd still be able to tell what the drums are supposed to be during composition, even though you'd have to play them after conversion in order to fine-tune their mixing.

I understand this sentiment; what we have is what we have. There is a precursor you might or might've not experienced? 3MLE.

It's a (for its niche purposes) full featured, interactive-during-playback MML editor featuring a text editor, piano roll editor, and a tracker-like param viewer on the side. It's just not suitable for NES composition as

1)its interface and output is tied to a soundfont-like interpreter
2)it adopts the standard midi-editor-like linear score, rather than that of a pattern sequencer.

_________________
http://www.frankengraphics.com - personal NES blog

Well I have seen graphical editors that use an MML sort of format underneath, but not specifically for PPMCK/MML, and I'm not familiar with 3MLE either but that's all aside what I was talking about.

Like, in a trivial sense you could adapt the current Famitracker to save PPMCK/MML instead of FTM, but that doesn't create any new editing capabilities for Famitracker. Similar story with MML editors: the ones I've seen that can load "handmade" files are really hamstrung in terms of how they can present information to you for editing just because the user could have organized it any way they want. (This trivial Famitracker MML would only be able to load MML created in Famitracker, or is otherwise parseable as the FT subset of MML features, not arbitrary hand-edited MML... this gets pretty tricky IMO.)

So in this context, I was talking about being able to use the mirroring abilities of MML effectively. A text editor gives you full access, but no other support. A hypothetical Famitracker with MML save gives you no access to that feature, but all the other support of Famitracker.

The bottom line is, if you want mirroring in an editing tool, that's a separate feature it has to have written into it. That's got little to do with the format: if FT grew such a feature the FTM format would grow along with it. So... I don't think the format itself is the problem here.


My point was that mirroring is a very nice composing feature, but not essential, and its value for compression is only a side effect. Valuable only if you've got nothing else, because I have a belief that can be done much better automatically (and that doing so is not a terribly difficult engineering problem).

Yeah, to me MML support within a FamiTracker branch would be of no use except for porting work already as good as done from Famitracker to another (MML based) driver (not bad at all in itself, definitely useful). But you'd still lose a lot of the benefits with using a MML based driver unless you plan to hand edit those post-port.

mirroring = reuse of patterns?

this is just a personal preference, but i wouldn't want to write computer music without pattern sequencing, be it basic or advanced. I'd prioritize that over:
-score modifying interaction during playback.
-hearing notes as i play/write them (can be substituted with a physical instrument on the side).

I think interface is more important than differences in file format between pently and famitracker. But MML holds the promise of portability - it could be a relative breeze to move a soundtrack between Pently, DevSound and Rahsennors' project once you have instrument definitions set up, and there'd be strength in numbers.

_________________
http://www.frankengraphics.com - personal NES blog

I have used both tracker interfaces and MML; I find the MML much easier and more convenient to work with. (This is why I wrote AmigaMML.)

Still, you could make up a multi-view editor, to get the benefits of all of them, especially if MIDI input is also possible.

Also another file format is the Csound numeric score format, which is a somewhat tracker like format but more generalized. (I have found it more useful to write a MML compiler to target it, although some people do use the Csoud numeric score format directly. There are also various GUIs for Csound.)

Batch editing operations would still be possible even with tracker based interfaces; one way could be to use SQL statements. You can enter the SQL commands to read or alter the pattern data, to do such thing as transpose, copy and transpose, stretch, etc, and save the ones you use into a user menu so that you need not type them in every time.

_________________
.