Igevorse Otonnoleare

'Assigning midi channels' feature is ready for testing

17 August 2014 | 11:57 pm

Overview of work this week

In short:

  • Implemented improved InstrumentChange element.
  • Implemented import midi ports/channels from Guitar Pro and Overture files.
  • Fixed bugs with assigning midi channels to instruments.
  • Fixed other bugs.

This week I finished improving InstrumentChange element. If you remember, the goal was to show only one item in mixer for the several same InstrumentChange elements. Now it's implemented completely. You can see an example score on the screenshot: we have several InstrumentChanges for Flute, but only one item in mixer. InstrumentChanges are synced, so if you change volume for "Flute" it would affect all Flute InstrumentChanges within the staff (within the Part, if we talk about code).

Also I was working on assigning midi channels to instruments. The first implementation was buggy, so I had to fix more than 10 quite serious bugs: each of them could break the feature. It works now, but solution is complex and affects a lot of processes (loading/saving file, adding/removing new elements, working with sequencer, etc.), so I am afraid I could broke something. There is only one way to be sure: test it hard.

Users was waiting for this feature for years, so if you're reading this post and you can help with testing - you're welcome! My pull request is here. Feel free to clone and test it!

As I said, current implementation is complex: partially because I added an ability to "fill the holes" in midi mapping. Suppose you have several instruments with midi channels 1, 3, 4, 5, 13 and the ports equal to 1. Now if you add a new instrument, it's channel would be mapped to midi channel 2. In previous implementation it would be mapped to channel 14.

Some information for the developers:

I mentioned in previous post that instruments could have the same midi port and channel, but could not have same indexes in midi mapping array. Now they could. It is the simplest approach to "join" all InstrumentChange elements to one item in mixer. All InstrumentChanges with the same midi program just mapped to one channel. Unfortunately, this solution has it's own drawbacks. So, a few InstrumentChanges with different instruments could be showed as one instrument in mixer. If they have the same midi programs, of course. For example, "Flute", "Soprano flute" and other related to flute instruments have the same midi program. This is probably a limitation in a GM soundfont standart. Or I just need to use not only midi program, but instrument->trackName() too for identifying an instrument. I am sure there's a user that needs to make an InstrumentChange from Flute to Soprano flute, so sooner or later I'll have to deal with this. If you have any suggestions - please contact me at any time.

Since now we support assigning midi ports and channels, we can extend our possibilities in import. I implemented import ports/channels from Guitar Pro 3, 4, 5, 6 (*.gtp*) and import channels from Overture format (*.ove). The last one does not support assigning midi ports to staves, as I understand, but supports assigning midi channels. Also, I have no information about *.mgu and *.sgu formats - there is no trial version of Band-in-the-Box application for the research. If I am wrong, feel free to write me.

Also this week I fixed two bugs: issues #29776 and # 29841.

Get ready for the final report!

Key tasks that stalled

It's ok.

Upcoming tasks this week

GSoC is almost over, but I promised to implement MIDI Actions, so I'll find the time for implementing. However, it may take a long time because of beginning of the study in university.

You can find me on IRC #musescore as igevorse or write a comment under the post.

« Fixing bugs is also important · 'Assigning midi channels' feature is ready for testing · Project summary »

  1. Comments (3):

  2. avatar
    pedroseq · 19 August 2014 | 11:24 am

    Hi Maxim,

    In my opinion, the best choice would be to identify an instrument by using instrument->trackName(), since MuseScore now allows to use multiple .sf2/.sfz, not necessarily GM compatible, and the user may have available other instrument sounds not found in the standard GM soundfonts (for instance, the Sonatina Symphony Orchestra [SSO], in sf2 and sfz formats, which provides most of the instruments used in a regular orchestra). This would also facilitate the use of external sample libraries, that, like SSO, may provide more instruments than those found on GM soundbanks.

    Therefore, using your own example, given the instrumentChange elements present in the score, the mixer should provide the following instrument tracks: Flute, Piccolo, Soprano Flute, Piano, Guitar, Voice.

    And one last thing, regarding the mixer settings, if a user wants to use an external sampler with a dedicated sample library, and not the internal synthesizers with soundfonts, what option should the user apply to the "Sound" field? Also, are the MIDI ports/channels in the "Port"/"Channel" fields accessible by external programs, right now?

    Best regards

  3. avatar
    igevorse · Site · 19 August 2014 | 12:34 pm

    Hi, pedroseq,

    I'll think more about instrument->trackName(). Really, I started from that and moved to using midi programs. As I wrote in the post, I think I should use both midi program and trackName(). Let's consider user has a piano staff and a soundfont with different piano programs. He wouldn't have an ability to switch from one program to another if we will use trackName() only (Not all users know about editing instruments.xml).

    With this approach we'll see a Soprano Flute in this example, right. Actually I just used Flute with wrong range Smile.

    If you use an external sequencer (QSynth), select "Sound" you need: piano, flute... If you use an external synthesizers, I think, "Sound" field doesn't matter.

    Yes, midi port and channel are accessible by external programs via JACK, it was one of the main purposes of this feature.

  4. avatar
    pedroseq · 19 August 2014 | 03:29 pm

    Yes, I see that it might be useful to implement both midi program and trackname(), to account for all usage possibilities, such as the piano staff case you presented.

    I thank you for your remaining answers to my questions. As I replied in MuseScore's dev-list, I'm on vacation rigth now and until the end of this month, so I'll only be able to test your new features when I get back. Until then, I hope that others might be able to alpha-test your new features before Musescore's beta release.

    Nonetheless, I must say that you've done a great job in developing these features for MuseScore and I hpoe you can continue to contribute to it, as long as you're able to in your spare time! Also, I wish you good luck to your return to the university!

    Best regards

Leave your response!

Style `onWall HashCode` by Lited & Sayori
Get your own blog immediately for free with Lited!