Editing GrandOrgue MIDI files?

MusE is a DAW for Linux with both MIDI and Audio editing. https://muse-sequencer.github.io

Moderators: MattKingUSA, khz, spamatica

Post Reply
ramendik
Established Member
Posts: 15
Joined: Sat Jan 26, 2019 2:23 am

Editing GrandOrgue MIDI files?

Post by ramendik »

Hello,

I would like to edit MIDI files produced by GrandOrgue, in order to correct any minor playing mistakes. The files are to be consumed by GrandOrgue again for final rendering into WAV. I am quite new to MIDI editing, and frankly chose MusE because I could install it from Flatpak.

I am facing two issues:

(1) When I open a GrandOrgue-produced MIDI file, I get something that is only a few seconds long. On the piano roll I see all the notes but they are fractions-of-a-second long each, with the entire track apparently squeezed into one measure. This happens consistently on all MIDI files sourced from GrandOrgue.

(2) I'd like to play the notes for editing purposes. But even though I do enable FluidSynth I can't seem to find a way to set the instrument and play the notes on FluidSynth.

How do I fix these issues? Thanks!
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Editing GrandOrgue MIDI files?

Post by Tim E. Real »

Hello. I am having difficulty getting GrandOrgue to work.
Can you please post an example midi file?
Just a guess: I suspect that your midi file's 'ticks per quarter note' value does match MusE's default of 384.
You can adjust that in MusE's Global Settings > Midi > Midi Resolution (and Displayed Resolution).
I do not see any such setting in GrandOrgue, so far...

Second question: Did you use MusE's own built-in MESS FluidSynth, or an external instance of FluidSynth?
If you are using our own MESS FluidSynth, you should see a track in MusE name 'fluidsynth-0' or similar. Check the following:
a) In the Arranger, your MusE midi track's 'Port' column points to that synth 'fluidsynth-0'.
b) You right-click the MESS FluidSynth track's 'Port' column and click 'Show native gui'. From there the gui will open and you should
load a suitable SoundFont and choose a suitable channel for it (typically channel 0 for melodic sounds, or channel 10 for drum sounds).
c) The MESS FluidSynth track should be routed to an Audio Output Track, which in turn should be routed to desired Jack Audio ports.
You can do such routing with MusE's green diagonal arrows found on each mixer strip, or with QJackctl if desired.

After that, playing the MusE midi track should output sound on the MESS FluidSynth track, you should see its meters moving.
ramendik
Established Member
Posts: 15
Joined: Sat Jan 26, 2019 2:23 am

Re: Editing GrandOrgue MIDI files?

Post by ramendik »

Here is an example MIDI file from GrandOrgue: https://drive.google.com/file/d/1hv2Qoj ... sp=sharing

I would really appreciate of you could look as to what I can modify to edit this file.

As for the second question: I am trying to use the internal MESS FluidSynth. I do not have (and don't plan to have) JACK, as I don't really do real time audio (PulseAudio latency is more than sufficient for organ playing). I can install JACK if necessary, but would like to avoid it if possible, because of the impact on "daily" audio use; MIDI editing is just an occasional task.

I was able to select a sound font as you recommend, thanks! Now when I click Play, the indicator to the left of the arranger moves. But there is still no sound, and I'm failing to get anywhere with the green diagonal arrows that I see above the indicator. The arrow gets me into the Routing window, and I see that all tracks are routed to FluidSynth-0. But how do I make FluidSynth-0 output to PulseAudio/ALSA? (Or I can use any other soft synthesizer if that would be beasier. This is simply for verification of edits, so I don't care which way the notes are played).

I can make screenshots if necessary.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Editing GrandOrgue MIDI files?

Post by Tim E. Real »

Initial findings:

First, sorry I misspoke when I implied that MusE would behave different if the 'division' (a.k.a. tick per quarter note)
value in a midi file is different than MusE's default 384.
In fact, MusE will open virtually any 'normal' regular midi file and play at the correct speed by adapting to the specified division value.
For example if a midi file's division says 192, MusE will use that value and play at the correct speed.
The value shown in our Settings is the value when saving a midi file from MusE.
It is not necessary to adjust it for opening a midi file.

Second, I note that the application QTractor also opens the file incorrectly.
So we are in 'good' company. MusE is not the only one having trouble with this file ;-)

Third, the reason this file causes trouble is because while virtually all midi files' division value is specified in
musical time (ticks per quarter note), there is allowed another type of division specification:
SMPTE / MIDI Time Code (a.k.a. linear time, in seconds).
This file uses such a specification for the division.

I see that we have code to attempt to deal with these types of division values, but it looks somewhat suspicious.
It may or may not be correct.
This means it is possible MusE is doing something wrong, but it also could mean that MusE is correct and GrandOrgue
is not saving the correct division value. (The fact that both MusE and QTractor show identical results suggests the latter.)

I will need to study the situation more and see what's going on...

About no sound:
So no Jack, eh? OK, open Global Settings > Audio tab. What is the 'Audio Backend' selected there?
If it says 'Jack Audio', change it to 'RTAudio Pulse Audio' if you have Pulse Audio, or change it to 'RTAudio ALSA' if you
do not have Pulse Audio. Try that. A restart is required to take effect.

What may be happening there is that with the 'Jack Audio' setting, since there is no Jack, MusE will fall back to a
dummy audio driver which produces no sound.

Good luck, HTH.
Tim.
ramendik
Established Member
Posts: 15
Joined: Sat Jan 26, 2019 2:23 am

Re: Editing GrandOrgue MIDI files?

Post by ramendik »

Thanks! I really would appreciate if you could look into this. Yes, by the nature of GrandOrgue it is normal that linear time would be used, because the software knows nothing about musical time.

It also uses nonstandard MIDI signals for stops.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Editing GrandOrgue MIDI files?

Post by Tim E. Real »

Yeah, it's a 'recorder'. No concept of ticks, bars, beats.

I must have read the midi file spec a hundred times but I don't think I ever noticed this feature :oops:
This is soooo ironic and funny for me. Here's why:
I have a branch, basically long abandoned, where among many other changes the time-lines could be switched
from ticks (musical time) to frames (linear time).
My goal was to make MusE the ultimate editor, suitable for linear time based broadcasting, studio etc.
You'll notice a normally hidden column in the Arranger named 'Lock'. It has remained unused.
Whoever put it there I think was heading in this direction. My code centered around using that column to switch from ticks to frames display.

But recently I explained privately that since the branch is long forgotten, my philosophy (erm, justification for doing the easier thing?)
changed to that of "MusE is a musical editor so I'll concentrate on that". Too bad I didn't finish the branch.

So the irony comes from that fact that also, here I am trying to make our wave based tracks and parts behave like our midi based parts,
that is, instead of being frame based they'll be tick based and won't move around when tempo is changed.
But now it seems we'll need to make an MusE 'uber-editor'. Both midi and wave tracks, parts, and events will need to be switchable.


A bit of tech talk, thinking out loud, may not get to changes tonight or tomorrow, just to let you know and if you have feedback:

So... Yes indeed that code I mentioned that we have is flawed. MusE is wrong.
A line attempts to use a full integer to negate the extracted short integer division value from the file. The value ends up incorrect.
Great. That gets me to the correct division value, which in this file's case is: 1000 ie. 1 ms.

But now... At this point for MusE in its current form (a musical editor) a conversion of the division must take place: From ms to ticks.
At 1000 (1ms), left as such, the song appeared to be exactly half as long as required.
Tempo must be considered, and a conversion against a standard tempo value must be done. This standard value is 120bpm
which is the default for a midi file, and in MusE.
At 120 bpm there are 2 beats per second. In MusE by default there are 384 ticks per quarter note and the
default time signature says quarter note gets a beat.
Thus I discovered that I simply needed to multiply the value 1000 by 2, to arrive at a tick based division of 2000.

The very last event in your song has a 'time' value of 112626. With a division of 1ms that means the song is 112.626 seconds long
or just under 2 minutes, correct? The conversion I described does that.


But now here are some concerns, and you may want to provide feedback here:
If your song has only one tempo - the default 120bpm, then great, we are good.
But what happens if you have one tempo different than 120bpm or several tempos, in an existing song (see our tempo map editor),
and then you import this particular midi file by choosing 'Add to song' instead of 'Replace'?

This leads me to say: You will want (have) to know beforehand any 'implied' tempo and key signature changes
in your recorded performance and enter them into MusE before actually importing the file.
That's because editing the tempos and key changes after importing will alter the song.

An important (no pun intended) consideration: I can provide one new possible import dialog option - a checkbox:
True: "Do you want the importation to adapt all the events' times to the existing MusE tempo map?"
(This means immediately after importing, the song's various passages will play faster or slower depending on the existing tempo map.)
False: "Do you want the importation to be unaffected by the existing MusE tempo map?"
(This means immediately after importing, the song plays at the original speed throughout, regardless of existing tempo map.)
Again note that in both cases further editing of tempos will alter the song.

All for now. Cheers.
Sir talk-a-lot.
User avatar
oscillator
Established Member
Posts: 1127
Joined: Sat Jan 17, 2015 6:07 pm
Location: SWEDEN
Has thanked: 725 times
Been thanked: 296 times
Contact:

Re: Editing GrandOrgue MIDI files?

Post by oscillator »

This is an interesting discussion to follow! :)

I only have a tiny suggestion: Could this not be solved, quickly and roughly, by the Python script TempoHalf? Just to get something useful?

I like the idea that MusE concentrates on one thing, and does it good, instead of trying to be a jack of all trades. I also like the notion that wave parts are treated as midi parts, because that is what *I* want! :) A DAW such as MusE is quite monolithic anyway.

There is that open source philosophy of doing one thing and doing it good, else use another tool. In this case to "fix" the GrandOrgue midi file. QTractor works the same as MusE, but what does for example Ardour do? Or Midi Editor? (https://www.midieditor.org/).

Just some humble thoughts! :)

MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik

spamatica
Established Member
Posts: 573
Joined: Mon Feb 08, 2010 10:38 am
Has thanked: 80 times
Been thanked: 97 times

Re: Editing GrandOrgue MIDI files?

Post by spamatica »

@oscillator. If I understand Tim correctly there is actually data lost in the import, so just stretching the midi out won't work (but I didn't actually try).
Otherwise I'm mostly with you, if it can be solved with other or simpler means, let's explore that first. (Though MusE does strive to be jack of all trades, but we really should start cutting down on that for our own sanity... ;) )

Regarding handling tempo changes, this seems to get very complex after a while, and it will probably never be right, as the original might have deviations. I vote against even trying.
If the fix in MusE is as simple as adding a set tick length (or whatever) to be able to read these files, that is of course fine. But more than that, it seems very complex for a rather narrow feature.

But enough ranting and more solutions. I was thinking there might be some command line tools for midi that does a better job?
I tried two: timidity (a sound player) and aplaymidi, ALSAs tool for playing midi files.
These both handle the file more correctly but interestingly produce files which have different tempo, so there might not be a clear answer how fast it should be.

I found a process using the command line to convert one such midi file to one that MusE can handle.
1. run 'arecordmidi -l' to find out the identity of the Midi Through port (for me it was 14:0 so I will use that)
2. start 'arecordmidi -p 14:0 output.mid'
3. start 'aplaymidi -p 14:0 nameofmidifilefromgrandorgue'
4. when aplaymidi has completed, Ctrl-C out of the arecordmidi instance and you should now have a converted file named output.mid

The drawback of this procedure is that it runs in realtime so it takes a few minutes to process this file. If you have lots of files in this format it might be a bit tedious.
MusE DAW
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Editing GrandOrgue MIDI files?

Post by Tim E. Real »

Actually no data is lost.
My explanation was complex, but not the code.
It is really a simple matter of correcting the existing code we have.
A few more lines added here and there, and the new option mentioned, and the song will import just fine.

The only drawback I mentioned is the user may want to supply an implied tempo map.
But that will be the case no matter what tools are used.
That's unavoidable when going from linear time to musical time. It's up to the user to create that map if desired.
ramendik
Established Member
Posts: 15
Joined: Sat Jan 26, 2019 2:23 am

Re: Editing GrandOrgue MIDI files?

Post by ramendik »

Thanks for all the very interesting discussion!

I do think that there should be a check box as to whether one wants to adapt the MIDI to the existing tempo or to sun it exactly unchanged, as there can be use cases for both approaches.

I was not aware of MIDI Editor, which seems to be built specifically for the task I am trying to do, while I am trying to use MuSE outside of its core use case. I'll try to build MIDI Editor, and if I succeed, I'll report what I got ut f GrandOrgue files.

I am trying to avoid conversions because, after I am done editing, I want to use the resulting file in GrandOrgue again. If the stops (in nonstandard signals) are lost that's acceptable, but tempo should remain the same.
ramendik
Established Member
Posts: 15
Joined: Sat Jan 26, 2019 2:23 am

Re: Editing GrandOrgue MIDI files?

Post by ramendik »

MidiEditor unfortunately has the same problem.

I can not check with Ardour as I have no idea how to deploy it without JACK.

I'll try to use compilers from Midi to text/csv.

EDIT. Good old midicomp https://github.com/markc/midicomp parses the file perfectly, the timing for each line is in milliseconds. An edit and parse back seems to work too. Of course this is a rather limited mode of editing but it is far better than nothing. I would be very happy to have a proper graphical editor.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Editing GrandOrgue MIDI files?

Post by Tim E. Real »

In git master now:

- Midi import: Fixed importation of SMPTE/MTC division midi files.
Converts linear time to ticks. Ignores existing MusE tempo map so that
it plays at original speed - this allows the tempo map to be set up beforehand
without actually affecting the song.

Note that even the tempo 'percent' box and corresponding quick 50/100/200 % buttons also do not affect the importation.
This means if you import at 200% and then switch to 100% it will be half speed.
(I actually didn't want percent to not affect it but I had to do it this way for technical reasons.)

Please note that some precision may be lost because ticks generally have less resolution than time frames.
You can change the 'ticks per quarter note' resolution in Settings before importing.
That should get you some better accuracy... but... the display will have more divisions per bar :!:
Something about that to me seemed... incorrect or broken. I felt why should there be more visual divisions.
A bar is a bar, a quarter note is a quarter note and so on... being played at a certain tempo. Why visually changing?

If by chance someone actually added a tempo value or even a complete tempo map inside the midi file (for the sake of transport-ability?),
they will also be imported, but just like normal midi files, these tempos will affect the playback speed upon importation,
as it is desirable.

Also, well, let's face it, if you recorded a performance even with a metronome, the tempo value(s) you supply to MusE before importing
might have to be fractional and take some experimentation - unless you supply them for us inside the midi file.
I find it again ironic and funny that 'beat /matching extraction' software may be required here, just exactly like we're
trying to do with the wave files - reconstructing a tempo map if there is none to be found somewhere !
I recon beat matching might be easier with midi, especially if you tell the software which midi note is the bass drum, which is the snare etc.

At least it is guaranteed to open and play nice even if the tempos and bars don't line up exactly with the original times.

I must point out that had our 'lock' column been working, you might have been able to edit tempos after importing -
ie. lock a track's events to their current frames, then edit tempos, then unlock the tracks.

But I believe you may edit time signatures after importing without affecting the song. :)

Giver 'er a try if you don't mind building from source. Hey it's just the first change since release too.
ramendik
Established Member
Posts: 15
Joined: Sat Jan 26, 2019 2:23 am

Re: Editing GrandOrgue MIDI files?

Post by ramendik »

Thanks a lot!

I'll try building from source - seems to require some libraries RHEL does not have, such as LADSPA, I'll rebuild them from Fedora, so this might take some time.

In the meantime, exactly the same issue happens with importation in Audacity, even though *that* should be using linear timestamps to start with.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Editing GrandOrgue MIDI files?

Post by Tim E. Real »

You can change the 'ticks per quarter note' resolution in Settings before importing.
That should get you some better accuracy... but... the display will have more divisions per bar :!:
Something about that to me seemed... incorrect or broken. I felt why should there be more visual divisions.
A bar is a bar, a quarter note is a quarter note and so on... being played at a certain tempo. Why visually changing?
Still with us?
Some major fixes applied!
Very high resolution importing and editing is now possible. Please see here for details:
viewtopic.php?f=61&t=22016

Tim.
Post Reply