Making MML editing more practical

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Making MML editing more practical

Post by rainwarrior »

FrankenGraphics wrote:mirroring = reuse of patterns?
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.
tepples wrote:How critical is it that the music sound exactly the same through the game-oriented driver as it does inside the tracker?
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.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Making MML editing more practical

Post by tepples »

gauauu wrote:
tepples wrote: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?
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
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.
gauauu wrote:- 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.
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.
raygrote
Posts: 18
Joined: Mon Oct 05, 2009 4:32 pm

Re: Making MML editing more practical

Post by raygrote »

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
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Making MML editing more practical

Post by FrankenGraphics »

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.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Making MML editing more practical

Post by tepples »

FrankenGraphics wrote: Mon Apr 16, 2018 11:21 am could be converted by a script to a famitracker-friendly text format and imported for aural feedback
A flow that relies on import is inadequate. It is not immediate enough.

I recently (two years after the OP) discussed music tooling with Banshaku and rainwarrior on the NESdev Discord server, and it turns out that the MML workflow is missing a lot of features that musicians have since come to expect:
  • Ability to hear a note through the speakers as it is being keyed into the score in the text editor
  • Ability to loop a few measures of a piece
  • Ability to set the playback point at the cursor and step-play one row or other time unit at a time, controlled by the speed of keypresses, mouse clicks, or touch screen taps
  • Ability to record using an external MIDI keyboard if connected
Musicians are so insistent on the immediate feedback of a tracker user interface and having the music sound exactly the same in the game as it does in the tracker that they are willing to make their soundtracks shorter and more repetitive to fit a ROM space budget rather than use a driver designed to fit more music into a given amount of ROM space.

Another workflow option is that the musician provides a tracker file and then a music tool programmer adapts the score to meet the limits of the driver and add optimizations that the automated converter missed. This, for example, is the ft2pently flow. But in my experience, it tends to lead to disputes of the following form:

"When is it going to sound tick-for-tick like how I want it?"
"I thought musical equivalence, not tick-for-tick transparency, was the idea."
"Screw it; we're cutting half the songs and switching drivers."
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Making MML editing more practical

Post by tepples »

Generic compression methods that work well with megabytes of RAM, particularly the LZ family, don't work as well when the sound driver state has to share a 2048-byte work RAM with the rest of the game state. 4klang lacks a format doc analogous to bytecode.md of Pently, and I haven't had time to reverse engineer 4klang's pattern data format from its source code. (Nor am I aware of which programs are suitable VSTi hosts.) As for recognizing loops in the exporter, what should I learn before attempting to solve what you call "not a terribly difficult engineering problem" myself?
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Making MML editing more practical

Post by rainwarrior »

It probably would have helped to quote me, especially since the thing you're referring to is back a page (and several years) but by some luck I got curious and searched the other pages and also can remember what I meant.

Basically I was referring to finding repeating substrings. There are many ways to look for these but there are standard useful algorithms for it. Rabin-Karp is the one that most readily comes to mind.

I think I might also have been obliquely referring to how Famitone seemed to subdivide patterns to find repetitions as well, but I can't remember how it does this, or whether it even really does it.
Post Reply