Show score during play

[djangobaer]

I do a lot of testings with ConPianist. That app is using your coding to show the score. Both apps are very good and I have a lot of fun with them. But sometimes, during playing, I can not find next notes quick enough. This happens when page is switching.

So I ask you if it is possible to manage the score in the same way as Smart Pianist(Yamaha) is doing? In the added picture you can see, that the next upcoming lines (60 ff) are shown above the active playline (53 ff).

In that way you can have an eye on the next upcoming notelines before page is switching.

Thanks Harald

[cecilios]

But sometimes, during playing, I can not find next notes quick enough. This happens when page is switching. So I ask you if it is possible to manage the score in the same way as Smart Pianist(Yamaha) is doing?

How lomse displays the score depends on the view type that the application (ConPianist in this case) decides to use. Currently Lomse has only implemented three view types:

• VerticalBookView is for rendering the score in pages, with the pages spread in vertical (e.g. Adobe PDF Reader, MS Word, MuseScore)
• HorizontalBookView is also for rendering the score in pages, but with the pages spread in horizontal (i.e. Finale, Sibelius)
• SingleSystemView is for rendering the score in a single very long system, as if the paper had infinite width.

I think ConPianist is using VerticalBookView, meaning that pages go one after the other in vertical. Therefore, the next system is always displayed below the current one being played. ConPianist can move up the page when playback is approaching the bottom of current page. In this way the next system will be always visible at bottom, but never at top as you are asking.

What you are requesting is to display the systems in a order different of the real order in the score (e.g. systems for measures 60-84 before systems for measures 53-59). Currently, lomse has no provision for selecting the measures to display and its order, it just displays systems in its natural order.

Of course, it would be possible to develop a View behaving as you are requesting but that is out of my current scope and available time. Moreover, that view will have limited applicability. In the image you attach, the displayed score is a piano score and, therefore, system height is small compared to application window height. In these conditions, several systems can be displayed simultaneously in the screen. But, for ensemble or orchestral scores the requested view would not solve the problems as, probably, it would be only possible to display one system in the screen.

Nowadays, tablets are starting to replace traditional printed scores and new solutions have to be devised to avoid turning pages and having always visible what is being played and the coming measures. Lomse still has no provision for views oriented to that end. The view suggested in https://github.com/lenmus/lomse/issues/124 as well as a not paginated vertical view could be the solution. In both, it would be simpe to scroll the score to keep the action centered on the screen, without distracting paper borders and spaces between pages.

In any case, I'm alone developing and maintaining the Lomse library and, unless more people join the project, the development will go slow. Sorry!

Note: Edited to fix a typo

[cecilios]

I come up with a not-too-expensive possibility to solve this in ConPianist. The idea is that ConPianist would be to have two buffers for score images, one for the current screen and another, smaller (half screen) for the piece of score on the next page. And when the program detects that the first bar of the last system is playing, ConPianist will replace the upper half of the screen with the other buffer.

[djangobaer]

It is a good idea. We will think about that option and test also the different views you offer. Thank You.

[hugbug]

I come up with a not-too-expensive possibility to solve this in ConPianist.

I don't even know where to start ;)

Currently I just draw the image generated by Lomse. The whole scrolling (via mouse) and positioning (scroll to current playback position) is controlled by Lomse. In my program I have no idea what is currently displayed in the score window. Neither do I know how to ask Lomse to render a specific page :)

I currently have a number of features to implement in my app. I'd says when I'm done with them I can try to implement that special score view mode using your suggestions. I will sure fire a lot questions at you to that time.

Feel free to close that issue for now. I'll post here again when I'm working on the feature.

Thank you for your assistance.

[cecilios]

Currently, I'm trying to finish with issue #229 that is taking more time than expected and I still have to work on this for a few days.

The whole scrolling (via mouse) and positioning (scroll to current playback position) is controlled by Lomse.

Oh! I though it was your application by using the scroll_to_measure() methods. If it is lomse, then current behaviour is that the playback cursor will advance and when it reaches the bottom right corner, the screen will be updated with the next system(s). Is it?

I'm thinking in another possibility for solving ConPianist issue. It would be to change the playback tracking behaviour in VerticalBookView by smoothly scrolling the page when playback moves to the second system displayed in the page. The idea would be to try to keep the action always at top of screen, to have visible as much coming music as possible. But this will be only feasible when system height is small enough so that at least three systems can be displayed in the window.

As in #122 and #124, this issue again raises the need to think about the need to create View types oriented to interactive applications for score playback and music reading (current View types are mainly oriented to printing scores) as well as to review the existing API methods for controlling what is displayed. So, I'm going to keep this issue open as a remainder and to think about all this.

I will sure fire a lot questions at you to that time.

Fell free to do it. You are welcome!

[kolewu]

The Android app MobileSheets has a view mode that is called Half-Page Turns, maybe that is what you are looking for.

[djangobaer]

Hi Uwe!  

Thankyou for the information about MobileSheets. It is a nice program, but not realy that we are searching for.

 

Our idea is to set a scorescreen like a scoresheet, based on a midi- or musicxml-file, where we can change the shown channels.

A further idea ist to see, after reaching the button of the side, the next line coming up on top of the page.

 

 

Best regards

Harald www.weha-keys.com

 

Gesendet: Mittwoch, 20. Mai 2020 um 23:29 Uhr Von: "Uwe Koloska" notifications@github.com An: "lenmus/lomse" lomse@noreply.github.com Cc: "Harald Weninger" weha@gmx.at, "Author" author@noreply.github.com Betreff: Re: [lenmus/lomse] Show score during play (#233)

 

The Android app MobileSheets has a view mode that is called Half-Page Turns, maybe that is what you are looking for.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[cecilios]

@kolewu Thanks for the link and the ideas.

Just to keep you informed on the situation with this issue: I'm currently quite busy and can not work on this. Hope I could start working on this by end of June. But I've been thinking on possible solutions. For now my conclusions are that lomse should offer three additional Views:

SinglePageView

• As VerticalBookView but a single page with infinite height. Only paper width is meaningful
• If at least three systems are displayed it will use smooth scroll during playback, trying to keep the action centered on top. Otherwise, current behavior in VerticalBookView is the only feasible approach, IMO. In any case, there is a problem with with repetition marks as it is not possible to display the 'go to' point.

FreeFlowView

• Similar to SinglePageView but with page width always equal to window width.
• It will display the document in a single page, and will reflow / reformat it to always adapt to available page width. It will behave in a similar way way to a HTML browser.
• Same scrolling behaviour than SinglePageView.

SplitSingleSystemView

• It would be similar to SingleSystemView (that is, the score is displayed in a unique very long system) and the scroll is in horizontal. But improves SingleSystemView by displaying the "score prefix" (the clef, time signature and key signature, as well as instruments/groups braces/brackets and their names) pinned to the left edge of the paper and do not move on scroll. This pinned left part will only be updated when any of its elements, clef, key time signature, change.
• During playback it will use smooth scroll to try to keep the action on the first half of the window.
• As with all previous views, there is a problem with with repetition marks as it is not possible to display the 'go to' point.

My plans are to start with SinglePageView and FreeFlowView (both are practically the same) and I expect they could be ready in two-three weeks. And then code SplitSingleSystemView; at first it looked difficult to do but after thinking more in depth I hope it could be simpler to do than I thought.

Feedbak and ideas are always welcome!

[kolewu]

Thankyou for the information about MobileSheets. It is a nice program, but not realy that we are searching for.

It's not the app itself but the view mode Half Page Turns that I intended to share, but because the app has a lite version, it's easy to test this view mode for yourself. For sure it's only helpful, if one system fills not more than half of the page.

[cecilios]

The Half-Page turns view would also solve the problem when repetion marks, coda, DC, etc.

Another approach to solve the problem with repetition marks and jumps could be to display the score not in print format but in a 'linearized' format in which the repeated measures/blocks would be inserted in the score and all repetion marks and jums would be removed. I have not yet though in how to implements this.

[cecilios]

The most I think on this the more convinced I am that the solution is what @djangobaer proposed in the first post and that, to my undersdanding, it is also the idea behind the Half-Page pointed by @kolewu .

This is my understanding of the required View:

SplitVerticalView

• The bitmap to be rendered in the application window is split horizontally in two halfs, originating two virtual vertical windows, one at top and the other at bottom. In top window it is displayed the first score chunk and the second chunk is displayed in the bottom windows. When playback enters in the bottom window the top windows is updated with the third chunk. Next, when the playback enters again in top window, the bottom window is updated with the next chunk, and so on.

• It allows to solve the problem of repetition marks and jumps: when the window being played has a jump, the other window is updated with the next logical system positioned at right measure instead of with the next chunk. The behaviour for the user is simple: when the user finds a jump he/she will know that it is necessary to jump to the other half window, unless the repetition is over and the music should continue from that point.

• But, as other solutions, it is only useful when system height is not big, in this case when it is smaller than half window.

• In principle, I see it not difficult to implement and also there is no need to implement smooth scroll (it could cause inacceptable delays for refreshing the screen).

[djangobaer]

Hi! Sorry for my late answer. I think there are different ways to help a musican reading notes. The standard way on a scoresheet is from top left to right and line per line. This is such old as notes were writen down on paper.

I am not a pianoplayer, but I prefer the endless roll(SplitSingleSystemView) left to right where the actual scene is in the middle of the page.

A "SinglePageView" has the problem on the end of each page. You can't see the next notes befor turning. So here would it be nice to scroll like pdf-Viewers. the pages turn vertical and showing the bourder of pages. Looks nice and it is like the pianist knows it.

The "SplitVerticalView" is nearly that what SmartPianist is doing and would be also very nice. But I think it is the longest way for programing.

I have another question to that theme: Is it possible to touch into the scorescreen to switch to a defined position in the score and play along from there?

Best regards Harald

[cecilios]

@djangobaer Thanks for the feedback

Is it possible to touch into the scorescreen to switch to a defined position in the score and play along from there?

Yes, that's simple. Your app has to request to play from a certain measure by using method ScorePlayer::play_from_measure(int nMeasure, ...). See https://lenmus.github.io/lomse/classScorePlayer.html

Also detecting a mouse click on the score and identifying the clicked note or the nearest beat position is already implemented. If really interested on doing this I could prepare some instructions about how to do it.

A "SinglePageView" has the problem on the end of each page.

Current " VerticalBookView" has that problem because the score is splitted in pages. But in "SinglePageView" there will be only one page and, thus, there is only one end of page: when the score finishes. And by implementing smooth scroll we can ensure that the action is at top and the coming measures are always visible. But, anyway, it has the problem of repetitions and jumps.

The "SplitVerticalView" is nearly that what SmartPianist is doing and would be also very nice. But I think it is the longest way for programming.

Probably I'm too optimistic, but it is only to maintain two pointers for current position (top and bottom windows) instead of one pointer. And to modify the rendering method to render two chunks instead of one. Also some additional methods for updating the two pointers and detecting jumps. Jumps detection is easy as they are already detected and compiled in the midi events table contained in the Sound Player. So, I'm optimistic about this and I hope not finding big problems to implement this solution.

[djangobaer]

Hello!

 

Sorry again for my late answer, but I need more hours a day!

 

That looks all very great for me and I am happy about that future looks.

I am not a programmer, that is Andrey's part and he does it very well.

 

I am a tester and user for ConPianist and also a helping hand for ideas and I try to make several inputs for optimizing the program.

But it is very interesting to see that program growing and it will overtake the Yamaha-App soon.

 

So thank you for your infos, I will discuss that with Andrey next time.    

Best regards

Harald www.weha-keys.com +43(0)676-9776633

   

Gesendet: Donnerstag, 21. Mai 2020 um 20:11 Uhr Von: "Cecilio Salmeron" notifications@github.com An: "lenmus/lomse" lomse@noreply.github.com Cc: "Harald Weninger" weha@gmx.at, "Mention" mention@noreply.github.com Betreff: Re: [lenmus/lomse] Show score during play (#233)

 

@djangobaer Thanks for the feedback

Is it possible to touch into the scorescreen to switch to a defined position in the score and play along from there?

Yes, that's simple. Your app has to request to play from a certain measure by using method ScorePlayer::play_from_measure(int nMeasure, ...). See https://lenmus.github.io/lomse/classScorePlayer.html

Also detecting a mouse click on the score and identifying the clicked note or the nearest beat position is already implemented. If really interested on doing this I could prepare some instructions about how to do it.

A "SinglePageView" has the problem on the end of each page.

Current " VerticalBookView" has that problem because the score is splitted in pages. But in "SinglePageView" there will be only one page and, thus, there is only one end of page: when the score finishes. And by implementing smooth scroll we can ensure that the action is at top and the coming measures are always visible. But, anyway, it has the problem of repetitions and jumps.

The "SplitVerticalView" is nearly that what SmartPianist is doing and would be also very nice. But I think it is the longest way for programming.

Probably I'm too optimistic, but it is only to maintain two pointers for current position (top and bottom windows) instead of one pointer. And to modify the rendering method to render two chunks instead of one. Also some additional methods for updating the two pointers and detecting jumps. Jumps detection is easy as they are already detected and compiled in the midi events table contained in the Sound Player. So, I'm optimistic about this and I hope not finding big problems to implement this solution.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.