Making MML editing more practical

One possibility for quicker feedback is to bind a key combo in your editor (such as F5 or Ctrl+R) to a script that does the following:

1. Stop the running player, if any.
2. Compile your MML score into an NSF, GBS, SPC, etc. that plays and loops the first song in a score. This could be a song containing only the part you're working on.
3. Play it in a background thread.

Would inclusion of such a script with an MML-driven tool make MML editing more practical? Or is it that important to hear each single note as you key it into the pattern in a tracker? In particular, is it important enough to overcome the limits of FamiTracker's data model?

• Inability to reuse patterns across channels
• Inability to reuse patterns at different transpositions
• Inability to reuse patterns with different instruments
• Inability to loop a pattern, such as a drum loop, that is shorter than the module's pattern length
• Inability to interrupt a single playing pattern, such as to interrupt a drum loop with a drum fill
• Inability to export row highlight and 0CC-FamiTracker linear pitch setting

It's a very good idea. It'd help a lot with the most siginificant issue for sure. Two important thing are missing though:
-the ability to play from a point.
-the ability to play a loop.

without having to edit the text. Possible remedy:
-ctrl-shift command to export from the edit line and onwards
-if anything is marked, export that only, as to create a loop.

Next step (leaning towards conveniences rather than necessities, imo) would be to have a text editor where:

-any syntax errors are colour marked differently (trivial to do that in np++ if notes are separated by comma or space)
-a ctrl command toggles the keyboard from plain text to note keyboard, similar to how trackers operate - each key autowrites the code for that note.
-ctrl commands to transpose note keyboard in octaves
-visual reference of above two features.



pros with a plain text editor:
you can label and comment your parts freely - makes it easier to organize and come back to.

cons with a plain text editor:
-hard to measure beats. maybe a measure could be set which highlights even beats - although beats are highly contextual and freeform in MML.
-transport line is imaginary; not visual - makes analysis of playback a bit harder.
-hard to quickly reorganize your composition by dragging patterns around instead of a single draggable object, you must take care to mark the whole label before dragging/cutpasting.


Another thing that might be really good:
-Being able to compose in a unified MML syntax and have modular export tools. Good for porting soundtracks between platforms, even though there's no escape from manual adjustments.

My MML format has a 'cut' command, a line consisting of a single '!' character, which causes the MML compiler to discard all song (but not instrument) data up to that point. If used a second time, it causes the compiler to dump the song so far and exit immediately. I use this to isolate the portion I'm working on for listening.

Keeping the beat is the hardest thing I've found with MML. I've so far been using layout to track it manually, like so:

...but I've been thinking of adding a '|' command that makes the compiler actually check that the elapsed time is a multiple of the length of a bar, and that the Nth bar of each channel occurs at the same point. I got the idea from ABC notation, which might be a useful format all by itself.

When transcribing music, I've tried to keep one measure per line. See, for example, song canon in the Pently demo score.

Where common MML syntax is lacking, I tend to take inspiration from LilyPond. From its page on bar checks and rehearsal marks:

• | causes LilyPond to emit a diagnostic if the elapsed musical time at that point isn't a multiple of one measure as defined in a song's time signature.
• \mark #8 marks this measure with the rehearsal label "H", the 8th letter of the alphabet. \mark \default marks this measure using the following letter. More complicated \mark commands draw other rehearsal labels.

LilyPond's bar check behavior appears to match the behavior you describe. But does your MML dialect let a score set a time signature other than 1 measure = 1 whole note? And how do you plan to handle pickup beats?

A more musically inclined cut command might let you leave several rehearsal labels in your score. Then you choose a label to play and loop by adding a command at the top of the score.

I haven't implemented the bar command yet, due to lack of solutions to the issues you listed. In the meantime, my MML compiler currently throws an error if the channels are unsynchronized on any blank line. I chose a blank line to match/enforce the formatting I had decided on, in which music is written in paragraphs like the one above. That's the only check it has right now.

My cut command was intended as a quick-and-dirty "what does this sound like" mode. I wanted to be able to type a single character before and maybe after a section and hit F9/whatever I happened to have set up for a compile-and-play cycle, then erase it once I'm done editing. I specifically wanted to avoid extra typing and scrolling, to make feedback as quick as possible.

Programs such as ppMCK and AmigaMML will output the total time per channel, so that you can more easily find synchronization errors. AmigaMML has a @" command, which outputs the current song position to stderr; a hypothetical IDE program could presumably inject this code at the cursor and then compile it if you wanted to implement play from cursor, or to check for the time positions for different notes so that you can more easily find such discrepancies (or you can just use it without any other programs, with @" in several channels at once, to look for missynchronizations). Presumably you could implement stuff like this in other MML compilers too.

Bar checks and rehearsal marks (like tepples mentions) would also be helpful though. Maybe in future I might add such function into AmigaMML, possibly.

(Note that in AmigaMML you cannot have global loops of different lengths or positions (although you are allowed to have local loops of different lengths/positions), due to a limitation of the output format; ppMCK does not have this limitation, and you can set global loops of whatever length and position you want to. MML compilers should probably be designed to allow global loops of different lengths/positions if the output format supports that, but like ppMCK can display the timing diagnostics so that you can find the errors more easily.)

If you are good at music, you should not need to hear each note as you enter it (although listening to it after you write it, to check for errors, is still helpful); even some composers could write music even if deaf; it didn't stop them! It most certainly is possible to compose using MML without all of the fancy stuff mentioned above to help with it, although I find the total time per channel to be a useful diagnostic, at least (I myself have never needed that other stuff; the programs I used don't support it anyways).

I wonder if a spread sheet-like mode of input would be better than free form text, sort of like excel. You could have one spread sheet on a tab for sequences, and another one on another tab for pattern sequencing. rows and column rulers would make a great way to measure beats.



I think this would be a terrible principle to design a musical interface around, though. A bit simplified, it's a bit like designing a counter for really tall people. As good as every musician and songwriter take hearing notes for granted when writing; usually on piano, guitar, song or synth. They rely on it and would perform worse without aural feedback. You'd end up with Ludwig van Beethoven as your sole ideal user, and even then

-He had lots and lots and lots of training and was a professional composer hired by magnates to do one thing only. We're talking about hobbyists doing things in their spare time.
-While used as a fascinating curiosity today, he did so out of harsh necessity, not because he wanted to. A gameboy composer might just use LSDj.
-He had years of gradual degradation of hearing under which he was forced/allowed to build up this skill. An intimidatingly difficult interface would just turn people away for other options unless they have to use it.
-He wasn't completely deaf in the sense popularly envisioned until quite a bit later on in his career.
-Despite being well trained and a professional, his diminished hearing can be traced in his music. Gradually, he started to avoid using bright notes, until the time he got completely deaf. At that point none of it mattered, so the brights were included in his work again.

In his own writing:


And even if someone is that good at music (unlikely), the interface is still impacting the songwriting. Playback helps a long way to remedy that in lieu of instant feedback, of course.

All of these things are something that an exporter can detect and apply, if desired.

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. It's still generally pretty easy to copy and paste stuff. It can also help a lot to spit out detailed diagnostic statistics when exporting (e.g. how many bytes does each pattern take, which are detected duplicates, etc.).

But FWIW, even if it could do none of those things, the interactive feedback beats the "compile and run" model of iteration a hundred times over.

...and as a programmer I'm quite used to compile and run workflow, and have written plenty of music that way too. I do consider that kind of thing usable, but compared to a Famitracker workflow? Forget about it.

I think it would help a lot to be able to hear a single line within a file, for example with a key combination. Possibly with seek back for correct parameters (instrument and octave), but that'd be luxurious. You have to regularly listen to the whole song to be sure you're not messing up anyway.

I'm leaning towards saying being able to solo and mute channels for playback is next to essential. You can live without these features, but they're just too useful to ignore. Both when writing music and when mixing (whith chip music, you kind of have to do both at the same time).

Edit:
In a personal summary and in answer to the original question, i think a lot can be done with a generic text- or table/spreadsheet editor to popularize an MML based driver such as pently or DevSound, but it'll never come close enough to the creative versatility and effortlessness of a pattern sequencer or tracker to be able to compete on equal terms.

In the best of worlds, i think a dedicated but general MML pattern sequencer with chip audio drivers/players as modular plugins would be able to "win" over famitracker and nerdtracker, not accounting for path dependency, as it could incorporate the benefits from both worlds. LSDj would still hold a solid place in live performance, but such a sequencer would be able to outperform it for game music production.

The pattern sequencer would be responsible for the score and "program change"/instrument pointer, control deck and channel muting/soloing, while the plugin would be responsible for instruments/patches, potential audio samples, interpretation, data export and playback.

This would however be a huge undertaking. At least the modular approach would mean different people could focus on different projects once the protocol has been laid down.

I'm envisioning a tool, somewhat like openscad for 3d design, where a text-based editor lives right beside some sort of GUI tools for previewing and interacting with the output.

I'm not much of a composer, but for something like famitracker, it's not the input format that I find to be that useful (being relatively inexperienced, I find the input system on famitracker to be every bit as cumbersome as text), but instead the advantage is the ability to instantly preview what I did. Like others are saying, it's all about things like muting/soloing, replaying small bits or a single line, etc. If you gave me a text interface to compose, but with full-featured gui tools for listening to it in lots of different ways (integrated in such a way that there wasn't a separate export/compile step to slow things down), I'd be happy.

That's an interesting approach! It's not quite the same, but it reminds me of Adobe AfterEffects where you can edit parameters by hand along the time track, or just enter a formula expressed like javascript in a text box. Both has its benefits.

The benefit with a GUI in the case of this hypothetical mml pattern sequencer is that you could add in as many views as your ambition goes. In the channel view i suppose you'd see the commands positioned along a 1-dimensional timeline, but you could also have a 2-dimensional piano roll editor tab; dragging, extending, erasing, splitting and joining notes. Or a plain text editor tab if you prefer that (probably, this would be implented first). All working on the same ram file.

I imagine the basic window layout to be free floating cascade, but you can anchor windows as tabs in the main program window (much like a web browser).

Some problems i see with the traditional tracker formula:
-rigidity of looped playback (at least famitracker) since there's no transport bar/control deck, you can't input a precise selection to loop. Also (at least in the case of the trackers i know), the loop seam produces artifacts like unintentional instrument changes and stuck notes, but that's a behaviour which could've been avoided. The playback doesn't distinguish what the loop would sound like if exported as a song and what the composer wants to hear when creating a loop for feedback purposes. I resolve this by entering temporary note offs and instrument changes, but that's a workaround rather than a solution.
-learning curve on the mode of input (though i think a lot of people have acquired this skill what with all the compos).
-All the things tepples mentioned in the first post.

This is the reason i'm proposing a pattern sequencer instead of a new tracker, where you can be free to have arbitrary lengths of patterns and interrupt one pattern with another at any measure and transpose a pattern at will. We'd "just" need a midi-like standard for MML commands that has to do with pattern selection, transpositions, tempo changes, effects, instrument changes, and so on.

One of my favourite features of Famitracker is sort of the equivalent of step debugging. Ctrl + Enter plays one row, so you can walk through the piece row by row at any pace you need while editing. I use this more than any other kind of preview.

It's also pretty nice that typing in a note also involves playing and hearing it, and only takes a single keypress.


Inline annotations are a very nice feature of ext formats that have comments, though I would say that I frequently take notes when composing and actually sometimes keep them in a nearby text document. Not all your data needs to be in the same file or same editor. The other thing I often do in Famitracker is put markings and irrelevant effects in an unused channel (usually DMC) for notes and guides.

I've done that too, + used DMC channel as a clipboard for notes. Else, i have tons of separate song files in a project file which serve as stored clipboards and scrap books.

One thing which had been nice if famitracker had would be if there was a "comment channel" where you could simply write monospaced things, maybe up to 32 characters per row?
There's certainly a lot of space for it with modern screen resolutions.

That's really neat! Thanks for the tip. Would certainly help when "debugging" harmonics. I suppose it might prove a problem with envelopes stretching over more than one rows' worth of time and ending on a 0, but still - very useful feature.


Agreed. Often, i turn off recording, try out the phrase freely like i was playing on a piano keyboard, then turn on recording again, and step sequence the phrase in place.

It is true, although this is independent of the program used to write the music, since it can be done as part of the playback (whether it is a part of the same program or is separate). (Even if it does not, the ! command of ppMCK can still be used.)

Yes, I have thought of such thing too. You could have multiple windows, and can hide the windows you do not want. For example, you can have:

• MML text editor view
• Piano roll view
• Tracker view
• Wave form view
• Register view
• Scratch pad view

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.

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

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.

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?

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.

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.

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.

Mirroring as any ability to edit something in one place and have those changes appear in multiple places. For Famitracker the only built-in mirroring is for patterns through the order, yes.

There are a lot more things that could be done, though, that could be very useful. Mirror partial patterns. Mirror across channels. Mirror and transpose. Mirror and instrument change. Mirror and volume change. Etc.


How much is a pretty situational question. I frequently compose at a piano before I move the material to NES. It's a question of what things do you need to iterate on, and how often. The more things that you can't get immediate feedback on, the more time you spend in that iteration loop.

Though, nothing being discussed is "critical", IMO. PPMCK/MML works. So does Famitracker. One of them works a lot better for my needs, but I can manage with the other.

It'd mostly depend on how fast your computer can start the emulator. If it needs to start a framework that takes a while to start, such as .NET/Mono used by Mesen or Wine used by FCEUX (debugging version), it might not be that quick. But on a decade-old Core 2 Duo L7500, changing the score and rebuilding the Pently ROM (but not starting an emulator) takes 0m0.332s of real time. The time is dominated by 0m0.271s for the Python program that translates the score into assembly language for ca65; I haven't tried PyPy to see if that speeds it up.


The way it works now is that you place a resume command in the song where you want it to start when the ROM starts, and place a mute or solo command anywhere in the score listing the tracks you want to not play (or only play). Then you can slow down or pause-and-step playback or change muting during playback, though I can't think of a good way for the ROM to propagate this back to the editor.

Hi all, sorry for bumping this topic. It's been a while since I was on this forum! But something sparked me to come back to the forums, I don't know what. Hopefully I won't disappear again. Sorry for the long post! I used to use MML quite a lot so this topic peaked my interest.

I used PPMCK often but lately I have been drawn to AddmusicK. The main reason for this is that I love primitively sampled sound and I also love the SPC700's qwirks. Don't get me wrong, I aspire to do awesome things with the Famicom and its expansions, but unfortunately I feel a lot is setting me back at the moment. Mainly, the fact that I can't really get to grips with trackers for multiple reasons, yet so many awesome things have been done with Famitracker that I really wish I could do.

The main reason I can't get into trackers is that I am totally blind, which I feel puts me at a real disadvantage. To use a computer, I have to use a piece of software often called a screen reader (the one I use is NVDA). Trackers obviously can't convey the grid information in ways that screen readers can interpret. While it is certainly possible to get stuff down as a blind person given the extensive keyboard navigation in a lot of trackers, the tracking process itself is... difficult.

Once you're in the tracking grid, you're pretty much on your own. Going through rows with keystrokes and aural feedback is pretty much all I can do, which is doable if I personally put everything down and I remember what I did, but that only takes me so far. I know that with enough determination I'm sure I could do a lot more than I believe I can now, but I sadly don't possess the patience required and it would still leave me dealing with almost impossible problems like quickly knowing what's already in a module. What is most tormenting is that I can set the instruments up the way I want. It's just getting the sequence down that's painful.

In an already niche area, accessibility for needs like mine is a topic that's addressed rarely if at all. I've heard of very little discussion on this regarding Famitracker but I haven't dug too deeply either. If there's any interest that I'm not aware of, I would love to participate!

With MML the concentration goes the other way. I'm in a common text editor which screen readers feel right at home in, so I have to focus on making the sound I want, and then when I want to try something, I compile and play. My MML chops aren't scary by any means but I am getting better, and I know that at least some of the pain I feel at the arduous process is shared among MML enthusiasts. I really need to talk to more of them, because I could use a few tips for making the workflow easier.

In MML I am still disadvantaged mainly because visual devices are less effective on me so I find it easier to get lost or that my MMLs are hard to read. While screen readers can announce formatting information, it is only for an informational purpose and doesn't serve a visual/spacial benefit. It's just more words to me so I turn the announcements off. I'm better off with just comments and line breaks.

While I don't format my MMLs very well, I am fairly pedantic about using spaces to separate things I feel are important. Notes often have spaces between them as sort of event separators so I can use keystrokes like control+left and control+right in my text editor to move by word. I don't often put spaces in modifiers like brackets/braces, octave commands, sharps and flats, and some effect commands, because I don't consider them as separate events. Different text editors do use different word separators so it doesn't completely do what I want, but spacing stuff out the way I do helps me read in any case. I'm a very aural musical learner so it takes me a while to translate language to notes. I have a really hard time reading MML, even my own. I can write it considerably better than I can read it. So if I could remove the note names from my reading and hear the notes instead along with whatever effects I've put on them, I would probably die of gratitude lol. If not that, then the ability to instantly play my sequence from a certain point and seek and mute and solo channels would be just as useful to me.

For complex projects, I've made midi files and used separate tracks for the sound chip's channels. FYI The sequencer I use is QWS which was made by a blind programmer and musician, and fortunately the developer and I seem to think similarly when it comes to midi editing so I feel at home in it. When I'm sequencing I spend time making painful decisions about channel allocation, voicings etc. with realtime feedback, which means I' can actually finish an arrangement. When doing the MML, it's just a matter of either converting the midi with tools and manually adjusting, or more often than not I'll just transcribe it by hand, and surprisingly that's easy. I guess it helps that I go out of my way to make the midi sound authentic so I pretty much just transcribe, check, and tweak until they are close enough. Only problem with that approach is I essentially have to write the thing down twice which is a turn-off for me, so I really don't do a lot of the big projects I want to take on.

I saw a number of really good suggestions in this thread about how to make MML easier to work with. What would rock my world is if Famitracker had an alternative text editor mode. You'd set your instruments up the way you normally would, since that's screen reader friendly, but for the rest you could use the text editor. Of course doing instruments in the MML is certainly plausible too but I wouldn't need that as much. I know Famitracker already has txt export, but that's not very writeable.

It would be awesome if good 'ol MML was used, where you can do whatever you want without caring about rows, but even if it were still a tracker, I could work well with that if notes and effects and the like were commands. Perhaps some way to convert a Famitracker text file or ftm module to and from an MML syntax would be the best shot at that?

Again, sorry for the long post. IF you're still reading, then congratulations you've made it through lol

Famitracker does actually have a text import action under the file menu. I have never used it, but it is definitely conceivable that an mml text file that is somewhat strictly formatted to adhere to the trackers' limitations could be converted by a script to a famitracker-friendly text format and imported for aural feedback this way.

There are a lot of more or less hidden tricks to famitracker which i think could be beneficial to someone who don't have much use of the visual feedback of the program. For instance, the control key plus left or right arrows will jump an exact pattern length, as specified by the song information as rows per pattern. But unfortunately in this scenario, most of the interface is still hand/eye coordination oriented via screen and mouse. Some features seem difficult to reach via keyboard. The main line of famitracker has stalled in development, unfortunately... there is a popular fork called 0cc famitracker though. You might want to check with the community there to see if they have any tips or if someone is willing to address the accessibility points you've made. If i recall correctly, 0cc famitracker has more key bindings than the vanilla version.