Text based Melody Parser to build MIDI Clips

[anytizer]

I am trying to build a parser for converting printer-friendly text format notations into midi clips.
It should understand Western notes, SARGAM notes and few other formats.

In this discussion, I want to achieve:

• More ideas for this parser, and the future of this sub-project.
• Reviewing and improving the current source code, and parser logic.
• Develop accurate documentation on formatting the notations per parser.
• Quicken the process of writing and testing your new melody back to written form.

Inspirations:
Since many melodies come as hand-written or printed format during the teaching learning process; I attempted feeding them directly to the parsers and obtain MIDI Clip data.

[anytizer]

Source Files

• 2026-01-23 - melody-editor-so.lmms (External link, follow readme for instructions on compiling as native LMMS plugin)

[anytizer]

Documentation

TLDR: This section describes how the parser understands melody in text format.

You need to format your notations into human readable form with the following considerations.
Then, correctly choose your input type before replacing the melody in midi clip.

Features	Western notes Parser	SARGAM notes Parser	Virtual Keyboard Parser
Natural notes allowed	C D E F G A B C# D# F# G# A#	S R G m P D N r g M d n	Alpha-Numerals (QWERTY) keyboard
Higher octaves marker	Append octave number eg. C5 D6	Append an asterisk * eg. S*, R**	??
Lower octaves marker	Append octave number eg. C3 D2	Append a dot . eg. S., R..	??
Chord Making	Brace notes within [ and ]	Brace notes within [ and ]	Brace notes within [ and ]
Longer chord lengths	Add a dash - BEFORE ].	Add a dash - before ].	Add a dash - before ].
Time shared / split notes	Comma eg. C#,D#	Comma eg. r,g	??
Silence / Pause marker	Use x wherever needed.	Use x wherever needed.	SPACE character
Longer silence marker	Introduce another x.	Introduce another x.	Introduce PIPE
Continuation mark	Add a dash -	Add a dash -	??
Comments per line	Start a line with hash #.	Start a line with hash #.	??
Sharps / Flats	Only sharps understood. flats	Lower case for komal notes.	??
Example 1 - chords	[ C E G - - - ] A A,B A G	[ S R G - - - ] D D,N D P	[qwe]tyu-iop
Example 2 - long note	G3 A3 E4 D4 - G4,A4 B4 D5 C5 - - -	P. D. G R - P,D N R* S* - - -	??
Example 3 - silence / pause	C x D x E x G -	S x R x G x P -	??
Help Link	here	here	here

Other notes

• Chords must have been terminated with corresponding ].
• Error count: Number of notes that were NOT converted for use in LMMS is returned.
  • Remedy: Look for accidentally joined notations
  • or illegal notes or characters like: E#.

[anytizer]

Latest Screenshot

Explains various parts of the UI.

Demonstration

• Open Melody Editor; Paste or Type your notes
• Or, double click the editor area to load from file.
• Select parser type. (SARGAM and English Notes supported so far, not the scores).
• Point to a midi clip where to update the data,
• Press update midi clip.

[yohannd1]

Oh, this is a really nice idea! I don't think I'd have much use of this plugin in its current state, but I have a potential use case that is similar.
Other than LMMS, I also like to use furnace tracker to compose music, and I find entering melodies in it much faster than what I usually do in LMMS. When copying melodies from furnace to the clipboard, they get converted to plain-text information like this:

org.tildearrow.furnace - Pattern Data (241)
0
C-4........|
...........|
...........|
...........|
D-4........|
...........|
...........|
...........|
E-4........|
...........|
...........|
...........|
F-4........|
...........|
...........|
...........|

A parser for this seems pretty simple, so I might do this in the future.

As for the installation flow, I wonder if there is a way to make this a standalone plugin that does not need to be compiled alongside LMMS (if I understood correctly, CMake needs to be aware of the plugin).

[anytizer]

Thanks for landing here. Letting your CMake know where this plugin is, is essential alike other lmms plguins. Here are some info on the parser. MelodyEditor is ideally for one instrument at once, and is without automation data. I think, when you raise your ChiptuneParser, for example, could bind with MelodyEditor's listing.

this->parsers.append(new ChiptuneParser());

It works like Export MIDI and Import MIDI feature of LMMS, creating an xml in memory. In that case, we can consume volume and panning of each note to the maximum intent. For safety reasons, there is a limit of 15 to 20kb text parsing only, so that parsing won't cause LMMS to crash or delay.

To begin with, you can try converting your pattern data to English Notes written in a horizontal manner. Then use it with MelodyEditor as new a new parser.

[allejok96]

Is the syntax meant to be edited by humans? If not it would make more sense if it could be pasted directly into PianoRoll.

There are probably hundreds of clipboard formats out there so people will argue why hardcode this specific format into piano roll... But LMMS has a system where plugins can register themselves as an ImportFilter to enable import of arbitrary project formats. This is how MIDI and hydrogen file import is handled.

I bet the concept of an ImportFilter could be extended to cover drag and drop and paste of notes in piano roll to enable more cross-application work.

Perhaps there would even be a ImportFilter for furnace tracker projects (whatever those looks like), and then it would be clear to the user that he could import those types of projects. And maybe he would even try to copy/paste between the apps. Or maybe he read in the docs that he could do that.

[anytizer]

It should be editable by a human. But it appears, here, that the notations are built within Furnace Tracker and use a copy/paste of plain text notations to bring into LMMS. @yohannd1 may know the details on how to handle such data format. It appears to come in 2 flavours: clipboard's plain text format, or compressed .fur file. .fur looks like hex-techie.

[yohannd1]

Yeah, I was specifically thinking about the clipboard format, since it's human-readable plain text. Parsing a .fur file would be a very complex task, I believe.

[allejok96]

I see you've made a standalone git repo for the plugin. How do you complie and install it in LMMS? Do you have to compile LMMS at the same time? I didn't know how so I just copied into the lmms source directory and built everything

[anytizer]

Thank you for building it. I hope, the process went well, and you were able to play around with the notations in English or SARGAM. I clone the source code in a separate directory and soft link the MelodyEditor folder and append a line in CMake so that LMMS build system knows and builds them along with other plugins. What you have done is still a valid process, except that MelodyEditor is not yet merged with main LMMS codebase. Somewhere in the long readme, I mentioned how to link with ln -s command; under title: Compile as a native plugin for LMMS; that ultimately results something like copying the codes within LMMS. Also, I have provided some sample notations in the same readme file, to copy/paste.

[ribbon-otter]

perhaps you want to consider supporting abc notation since that is a very established text-based music notation system, particularly for folk music?

[anytizer]

Bookmarking their standards for references. Thank you for a reminder.