Making MML editing more practical

[tepples]

I think MML sequencing would be a bit of a jail sentence for the driver, dramatically put. I can only speak for myself, but i could come nowhere close to what sort of music i'd like to make if i had to write, compile, listen, write, compile, listen; all while constrained by the interface for inputting MML code in np++. Haven't done that since qBasic and i'm glad i haven't returned. :S I think a lot of other hobbyist composers like me without years of dedicated studies and training in music theory need direct aural feedback and be able to edit during playback in order to do their best.

I personally dislike MML because it's not a "direct" means of composing. I prefer trackers because you can actually hear the music as you're writing it.

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

[FrankenGraphics]

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.

[Rahsennor]

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:

Code: Select all

1 hR4G5D# qDR hR4G5D# qDR  hR4G5D# qDR hR h.4G5D#
2 hR4D#G  qRF hR4D#G  qRF  hR4D#G  qRF hR h.D#G
T h.4CC   hD  h.4CC   qG#D h.4CC   hD  h.4CC qDD

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

[tepples]

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.

Code: Select all

rehearse Paper_Man::bridge

# ...

song Paper_Man
! verse
blahblahblah
! bridge
blahblahblah
! chorus
blahblahblah

[Rahsennor]

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.

[zzo38]

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

[FrankenGraphics]

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.

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!

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:

"... Of course, I am resolved to rise above every obstacle, but how will it be possible? ..."

"... My hearing has grown steadily worse over the last three years, which was said to be caused by the condition of my belly..."

" ... Often I can scarcely hear someone speaking softly, the tones yes, but not the words. However, as soon as anyone shouts it becomes intolerable..."

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.

[rainwarrior]

• 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

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.

[Bregalad]

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.

[FrankenGraphics]

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.

[gauauu]

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.

[FrankenGraphics]

I'm envisioning a tool, somewhat like openscad for 3d design,

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.

[rainwarrior]

-the ability to play from a point.
-the ability to play a loop.

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.

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

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.

[FrankenGraphics]

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.

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.

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.

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

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.

[zzo38]

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

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

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.

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