Igevorse Otonnoleare

JACK Transport: first steps

15 June 2014 | 10:19 pm

Overview of work this week

In short:

  • Working on JACK Transport.
  • New ideas about realtime midi input.

JACK Transport! Implementing this is harder than I thought. Actually, it took a week of work.

Implementing JACK Transport seek/reposition consists of several parts:

  1. Internal seek before playing - clicking on notes and then pressing "play" in MuseScore.
  2. Internal seek while playing - pressing "play" in MuseScore and then clicking on notes.
  3. External seek before playing - seeking via JACK Transport and then pressing "play".
  4. External seek while playing - pressing "play" and seeking via JACK Transport.

Now 3/4 of this is done - the first option (internal seek before playing) is not implemented. Everything else works.

I didn't work on implementing "assigning channels for staves" because of work on JACK Transport, but I look through the code and still think about correct implementation of this feature.

Also there were some new ideas about realtime midi input. For example, make variants, different transcriptions of input, from which user can choose the best one. You can see sketch here. This approach helps to make post-editing faster and decrease number of false positives. I want to say thanks to David Bolton, who pointed me to some important difficulties of implementing realtime midi input. There are more and more barriers for making 100% accurate recognition system. So, I underestimated the problem. By the way, realtime midi input is not in my proposal for GSoC, so I don't need to rush with implementing it.

Key tasks that stalled

Internal seek before playing - implementing it breaks another options. Maybe I use the wrong approach? I have tried many approaches this week, current one is the best, I think.

Why does it hard? When we are seeking from MuseScore, we sending a signal to JACK Transport, JACK Transport sends signal to MuseScore to seek, and... we've got a recursion/cycle that runs forever.

Solution is usually very simple, but it is not just a recursion between two functions, we have an interaction between two applications working in several threads. It was not easy to keep all possible interactions in the head. It was new and interesting for me. Of course I will find a solution, just need more time.

Also, I still can't connect my midi keyboard.

Upcoming tasks this week

Finish working on JACK Transport, publish the code.

Test it hard and write about testing.

As usual, you can find me on IRC #musescore as igevorse.

Also feel free to write me about implementing some JACK-related features that you need and want.

« Realtime midi input: to be or not… · JACK Transport: first steps · Seek from JACK Transport: video demo »

  1. Comments (1):

  2. avatar
    lasconic · 16 June 2014 | 02:15 pm

    About the Jack issue, check if I'm not talking BS with other software using Jack but I think there is a way to define which of the connected piece of software should be the master of Jack transport. That would solve the "loop" issue.

Leave your response!

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