Meta events are exported to midi but not imported from midi

[mqnc]

Hi!

I wanted to write lyrics and chords into the midi file. In general it's possible with muse but it's very cumbersome so I wanted to do it in another editor. If I export the project as midi, all meta events from the .med file are still present (as I see them in the other editor). But if I import the midi file back to muse, the meta events are gone. I've had a look at the code.

In importmidi.cpp, it says

// if we split the track, SYSEX and META events go into
// the first target track

Then meta and sysex are specifically excluded

if (ev->type() != MusECore::ME_SYSEX && ev->type() != MusECore::ME_META)

and then later it says

if (first) {
                  //
                  // track does only contain non-channel messages
                  // (SYSEX or META)
                  //
                  MusECore::MidiTrack* track = new MusECore::MidiTrack();
                  track->setOutChannel(0);
                  track->setOutPort(0);
                  buildMidiEventList(&track->events, el, track, division, true, false); // Do SysexMeta. Don't do loops.
                  processTrack(track);
                  MusEGlobal::song->insertTrack0(track, -1);
                  }
            }

Does that mean muse can store meta and sysex in any track but only imports it when it's in the first track? Can one just delete the "if not meta and not sysex" condition and everything's fine or will that shoot into some other knee?

[terminator356]

Observed. Thank you. Checking...

[terminator356]

Fixed in git master. Try 'er out. Lyrics and a few other metas were ignored in midi.cpp:buildMidiEventList(). For example we don't specifically have support for 'cue point' metas (we need a cue point list, exactly like our marker list) so instead I allowed them through anywhere on any track for now so at least they are preserved, although they are only supposed to appear on the first track.

I would have loved to embellish the above fix with much better lyric support, but... I've had a few ideas, and some new ones now, about supporting and displaying lyrics and other text metas directly in the Arranger and Pianoroll editors. It is challenging. Displaying movable pieces of text in a row, all on a line without them running-on or overlapping, all while respecting the horizontal zoom control, is... virtually impossible. Best would be that the user zooms in until all text can be seen, or we could try to do it automatically. But... If vertical space permits, I had some ideas about 'stacking' or 'shimmying' the texts above or below each each other so that they don't blend or smear together or overlap. This technique I was considering as well for displaying program names in the midi controller graphs, instead of just an actual graph of program values. It might be a little weird, maybe hard to get used to the texts automatically 'jockying' for vertical position as you zoom out. Lyrics might look strange having words on different vertical levels.

[mqnc]

Thanks! I will test when I'm home. I see, it's tricky to make this beautiful. For now I am just using this guy: https://www.midieditor.org/ It puts markers where the events are and you have to click em to see the text in a little edit window, one at a time. But displaying all content would be much cooler of course. Audacity has label tracks. They start a new row for the next label if it would otherwise overlap. But it can look messy as you can see here: https://silshack.github.io/inls161fall2016/assets/ref-images/audacity/label-track2.png Maybe rather rotate the labels by 45° upwards or downwards or have them overlap and display the clicked one somewhere else also. And if the user wants to have it all readable, she has to zoom in enough.

[terminator356]

Hey thanks for that shot of Audacity, never knew it had that feature. Yeah, that's pretty much exactly like I envisioned, complete with those 'stems' or as I imagined like 'flags' poles. But yeah I see it can get kinda ugly.

After some brainstorming last night I have... a plan... (oh oh, look out!)... to dominate the world with my... Oops sorry wrong plan.

Showing lyrics in the Score Editor, Pianoroll Editor and Drum Editor would be the main goal but that would be quite complex, but I believe there should also be a separate dedicated Lyric-only Editor window where text can be enlarged and scrolled like a Karaoke player. For this 'Lyric Editor' I was thinking about arranging it in a page instead of all horizontally. I think this may be possible - we might be able to place several of our TimeScale widgets (the bar,beat,tick timescale at the top of each editor) on one screen interspersed with lines of text. In other words a timescale then a line of text then another timescale then another line of text and so on vertically down the page. As the song plays, the red play head cursor would move through each of these timescales, each of which is biased forward from the previous timescale, of course. (This would mark the first time we ever tried to place things vertically on a canvas instead of all horizontally, and could lead to some better things especially for the Score Editor.)

I would hope we could allow the user to enter the complete lyrics quickly at once, like a normal text editor, into a small separate panel, and then 'drag and drop' the various words into place in the actual Lyric Editor canvas beside this text panel.

[mqnc]

I feel ya, I feel ya. Can you post a link to a video of a Karaoke player that shows what you mean by "like a Karaoke player"?

How would you resolve the length discrepancy between text and the linear TimeScale? Have variably large gaps between syllables or the spaces between beats in the TimeScale adapt to syllable length?

And do you envision any visual connection between the music and the lyrics? Like depicting little notes or lines (like the preview of a midi track) along with the TimeScales? Or does one have to play the track in order to match the timing of syllables and notes or just work with the bar count?

Also, in my particular case: I don't want syllables, I want to feed the midi file into my own python script that shows the lyrics on a screen. And I want the display to be line by line, not word by word. So one text/lyrics event contains a long text, then nothing for some bars, then the next long text event. But I'm not complaining if Muse is not tailored to my personal use case. But maybe that's a common use case.

[terminator356]

I meant just a big display of the text as in a player for Karaoke fans to read from a distance, like a tele-prompter, which could also help bands read lyrics from a distance. I suppose there would still be the issue of words overlapping so I guess 'zoom' would still be needed.

It occurred to me that since each word is typically associated with a note, that there should be an optional link of some kind between the two so that if a note is moved, the word will move too, and if a word is moved the note will move. For that reason it also occurred to me that there typically should be no more than ONE word per lyric meta event. I downloaded some midi files with lyrics and that seems to be the case. Is it your experience that you would like to put several words per lyric event? It seems that would not be recommended.

[mqnc]

I want this for my band. Due to several reasons.

Right now we have lyrics and chords on A4 paper. But it doesn't fit comfortably without having tiny text or abbreviating the 2nd and 3rd chorus by just writing "chorus". But then you have to jump through the page in action which sucks. Having to flip the page also sucks and having multiple pieces of paper also sucks. Also, my undisciplined guitarist often loses his note sheets.

Long story short: I want to display the current and the next chord and the current line of lyrics on the phone.

The thing is, we don't need a detailed match between words and notes, we know how the syllables match the bars. We just need memory support. And I don't want the phone to display

"Like" then "baby" then "baby" then "baby" then "oh"

I want it to display

"And she's buying a stairway to heaven"

without the need of showing when to sing which syllable. And the easiest way to implement it is when there's a new lyrics event, replace the current lyrics on the phone.

But the thing is, I think you can implement it the way you described and I can just work with it, I don't mind if the text labels overlap. I want to click somewhere and edit the text that is shown when that moment is reached. :) (and even that is not necessary as I can just betray you with another editor :D if import and export works) (oh by the way I downloaded the new master and compiled it. Compiled fine but crashed. Does it not work alongside MusE 2.1?)

[terminator356]

Good stuff. Thanks. Can't promise anything soon as I'm deep into other branches, but I will try to make it as friendly as possible since I write lyrics too.

Sorry to hear about the crash with master. 2.1 is very old by now. We get reports of 2.1 or master crashes, as seen in the issue tracker, and it is usually caused by bad plugins during MusE startup and plugin discovery.

If you run MusE in a terminal with the -D option and report the results back I'll try to help.

There are some command-line options which disable loading of various plugin architectures, (see muse3 -h for help) it is a good place to start. We have an issue request to create a 'sandbox' and blacklist such plugins, hopefully it would eliminate these problems.

[mqnc]

Seems to be the same here. muse3 -D revealed:

loadPluginLib: adding ladspa plugin:/usr/lib64/ladspa/cs_phaser.so name:Phaser1 with LFO label:Phaser1+LFO required features:0
Segmentation fault (core dumped)

muse3 -p works fine.

And it works now, lyrics events stay. Text events (FF 01) are still dropped tho, but I'll just use lyrics for chords as well.

I really appreciate your fast response to this!! Open source is awesome!

[terminator356]

Thanks mqnc. MusE reserves text meta events FF 01 for track comments. Right-click a track name in the Arranger and you'll see a 'Track comment' entry.

MusE 'intercepts' certain metas and if it recognizes them it will absorb them and not pass them on to the track. Anything it doesn't recognize it passes on to the track to be recorded as an event in the track. If you look in midi.cpp at line 498 (case ME_META) you can see the ones that are accepted by the track. Certain other very important metas such as 'instrument name' or 'device change' are handled further ahead in the midi importing code where it is decided whether to absorb the event or pass it on to the track.

That's a bummer about those plugins. But something doesn't make sense, I'm perplexed: Do they crash in Ardour or QTractor? Please test. I have all those plugins mentioned, and they seem fine in MusE. But I'm starting to wonder if MusE has a problem during discovery though...

A nice thing about LV2 is that during plugin discovery, an app does not load an actual library, rather it loads some info about the plugin before the app decides to open the library. This should mean LV2 plugins should be immune from crashing during startup and discovery, although once the library is opened anything can happen next.

Many LADSPA plugins have already been converted to LV2. Virtually anything those ancient LADSPA plugins can do, LV2 can do now.

[terminator356]

Just a follow up: Yeah I know the FF 01 thing may seem weird (I didn't write that). It's really the only one we 'hijack' like that, and it's a bit odd, FF01 is "recommended but not required to be placed near the start of a track" so technically it should be allowed anywhere.

I want to say that regarding the plugins, it might be MusE's fault after all. I forgot there's an old issue, perhaps not the right place to mention it but I should, it concerns C++ 'namespaces' and how loading a library can sometimes 'pollute' your app's namespace. Before one developer added our namespaces several years ago, we had far more trouble even simply discovering plugins. They would crash MusE a lot for that reason. But I believe the fix didn't make MusE completely immune from the problem since we still have some 'global' variables that are not protected by namespaces. I really should look closer at that issue and see if needs solving before pinning it down to plugins.

[mqnc]

I see I see. The tribunal will consider your confession in this sentence. We see that you promise improvement so we shall temper justice with mercy.

I will test in Ardour this evening.

[terminator356]

Can you tell me what Linux distro you're running? 32-bit or 64-bit? Anything unusual to report such as do you build some of the source codes instead of packages? Plenty of memory to spare? That could be an issue - simply running out of memory.

Also, do you have things like Carla or Catia installed or running?

Thanks. Tim.

[mqnc]

I'm running Ubuntu Studio 17.10 64 bit. I built MusE3 and Fluidsynth from source to get the latest fixes, didn't modify anything. 16GB of ram.

Ardour does not crash, the reported plugin works fine there. If I move the .so out of the folder, Muse crashes at another plugin, always around the same location, somewhere in the middle of the libs starting with c (as I see it moves chronologically). Always segmentation fault.

[mqnc]

Rebuilt with debug information. First, this happened during configuration:

** WARNING: rtaudio (>= 4.0) was enabled, but development files were not found. 
** WARNING: lash (>= 0.2) was enabled, but development files were not found. 
** HINT: Don't have LASH? Try installing the LADISH LASH compatibility package instead.
** WARNING: System LV2 support libraries were chosen, but development files were not found or too old:
   Requires lv2 >= 1.12.0, lilv-0 >= 0.22.0, sord-0 >= 0.14.0
   Building supplied internal versions instead.

Here is the DDD output:

GNU DDD 3.3.12 (x86_64-pc-linux-gnu), by Dorothea LReading symbols from muse3...done.
(gdb) run
Starting program: /home/mirko/development/muse/muse3/dbg_build/muse/muse3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Config File </home/mirko/.config/MusE/MusE.cfg>
[New Thread 0x7fffdf4e5700 (LWP 22736)]
QApplication: invalid style override passed, ignoring it.
LOCALE en_US
[New Thread 0x7fffd4721700 (LWP 22737)]
Denormal protection enabled.
Select audio device from configuration : 0
User JackAudio backend - backend selected through configuration
MusE:initJackAudio: jack_get_version() returned zeros. Setting version major to 1.
[New Thread 0x7fffd5ec6700 (LWP 22738)]
[New Thread 0x7fffd5e45700 (LWP 22739)]
Using Jack
Continuing.
Continuing.
Continuing.
*** Error in `/home/mirko/development/muse/muse3/dbg_build/muse/muse3': free(): invalid pointer: 0x00005555557d504c ***

Thread 1 "muse3" received signal SIGABRT, Aborted.

and here is the stack trace:

Unfortunately this doesn't get as far as when the other error happens. Also, there seem to be no debug symbols in the so files. I'm a bit new to building on linux, also I usually use SCons since I am somehow not really cmake compatible. I just replaced "release" with "debug" in your compile muse.sh and then ran the built thing with ddd. Lemme know if I can do something else!

EDIT: Sorry, it actually is the same error as before. I just didn't run with the -D flag so I got less output and I thought it didn't get as far. So good luck! :D (I'd still be curious how to step into the so files...)

[terminator356]

Great detective work! Thanks, this helps. Checking, will report back...

The .so files would probably have to be built with debugging symbols enabled to step through them.

One thing that could be tried is to uninstall the cs ladspa plugins package(s) in your package manager and see if the problem goes away. Should be harmless to try and then re-install later. Hopefully you'd have no other packages which depend on it. (None should, really.)

[mqnc]

Look what we have here... https://github.com/csound/csladspa/issues/1

[mqnc]

Renamed csladspa.so to csladspa.so_ and boom, it worked :P However, it throws a godzillion errors because it finds duplicate libraries in usr/lib and usr/lib64

[mqnc]

The .so files would probably have to be built with debugging symbols enabled to step through them.

I thought so. But as some of them are part of the muse project (like libmuse_core.so), do they not get built with debug information when I replace "release" with "debug" in the compile_muse.sh? :P

[terminator356]

Whoa! Awesome tracking! Praise the Great Pumpkin! Seriously that's totally cool of you to do that. So now we know, eh?

Ahh, the plot becomes clearer: Blush: Turns out I don't have csladspa installed after all! I have cs_chorus and cs_phaser but no csladspa. Looks like that's part of the complete CSound package here on my distro, and I never install CSound. No wonder I never saw the bug. I confused cs with the other cs...

MusE's own .so files are fully debuggable. I do it every day seamlessly stepping in and out of all our modules. I think what you did wrong was modifying the compile_muse.sh file. Try configuring with cmake, read our README carefully for best results. You would pass the debug flag to cmake (can't remember exactly right now.)

Again, thank you very very much for solving this headache. Three cheers. Tim.

[mqnc]

Sure thang bruh!

Let me elaborate on what I meant by replacing release by debug in the sh file:

cmake -DCMAKE_BUILD_TYPE=release -> cmake -DCMAKE_BUILD_TYPE=debug

Should that not do the trick?

[terminator356]

Yes it occurred to me that it should have worked. Possibly wipe out the 'build' directory, or even pull a whole new clone and start from scratch? But I suspect you've tried that. Can you try again and post the text output of configuration? The messages may reveal something.

[terminator356]

Also just to mention if you'd like to delve a bit deeper into the code with full view of everything and cmake options and so on, I highly recommend the most awesome KDevelop IDE, my fave every day for many years.

[terminator356]

OK Enough! That does it. I'm making a safe plugin scanner so that this never hap...

DONE! Please see: https://linuxmusicians.com/viewtopic.php?f=61&t=19082

Please test (say, with 'bad' csladspa.so) and report back:

Cheers. Tim.

[mqnc]

That was quick. I will be busy the next weeks, I'll get back to this asap. Meaning as soon as pleasant :)

[mqnc]

Finally found the Muße (get it?) to get to try this. Works :) How is the lyrics editor coming along? :P

[terminator356]

Yes much has happened in the git master since we last spoke. Be sure to get it.

Lyrics editor is mostly on back-burner although I have some ideas for basic expanded meta display support on the time lines, since I am repairing some marker stuff. Most intensive effort is directed at my latency fixes branch at the moment. But I have paused briefly for some housekeeping and bug fixes.

[mqnc]

I have already downloaded it. Thanks for the status update. I'll be here if you need brain-storming for the lyrics editor ;)

[github-actions[bot]]

This issue is stale because it has been inactive for two years. Remove Stale label or write a comment, otherwise it will be closed in 30 days.

[github-actions[bot]]

Issue has been closed automatically after two years of inactivity. Feel free to reopen if the issue is still relevant for current MusE version.