Comments (9)
I do think that the UI should update immediately when you type, as in that the letters appear and the cursor moves forward; otherwise it feels like it's lagging. But indeed, it might be an idea to re-layout the score only after a certain delay instead of after every character.
But if the re-layout process can be optimised so much that it doesn't introduce freezing, that's even better of course :)
from musescore.
I do think that the UI should update immediately when you type, as in that the letters appear and the cursor moves forward; otherwise it feels like it's lagging. But indeed, it's a good idea to re-layout the score only after a certain delay instead of after every character.
Indeed, thank you Casper, that I think would be a more reasonable option, thank you.
Right now it seems to me at least - I don't have any experitise to understand the code - that the graphical interface tries to render each new element you add to the score immediately after the input. The system is implemented very very well, but as my last project grew bigger it eventually took at least 1.5x the time (I didn't measure it, but I would really say at least this ratio) to compose, because of the graphical rendering.
from musescore.
I would assume this might apply to note input as well as text. FWIW, I did experiment with this sort of thing back during 3.0 development when we were working on the partial relayout feature (only laying out what changed) and it wasn’t very good yet. Also a version where the main score updated but parts did not. It had potential but I never followed through as eventually the partial relayout feature seemed to be working well enough.
from musescore.
Long ago, when computers were slower and mostly character-oriented, there was a text editor that could combine several user actions and display the final result only.
Something like this: cursor is at the beginning of a file (BOF); for a quick sequence - "go to EOF", "go to BOF", two times "down" - no screen redraws, only cursor jumps to the beginning of the third line.
Possibly, if next character or command arrived while screen update was prepared or performed, next updates would be delayed until fast input sequence ends and there is a pause.
from musescore.
General comment, application independent: in many cases, the drawing time might be higher than user new input time. This can come from slow hardware, fast user, heavy loaded system, complex rendering shape...
From my experience, a very efficient way to handle this is:
- on user input event
- push user modification request in the modification queue
- set an alarm with 0 ms delay for the main loop to handle update
- in the update function
- consider all the modifications in the queue
- make a single draw update
With such principle, the interface is as responsive as it can be. When the user make some input, then the update process is started without delay. If the user is making input quicker than the system can manage, then the system will merge some inputs and the display delay will not be more than the refresh time.
Maybe some similar behavior is already implemented for the real-time play rendering and can be applied to user input. Otherwise, the same principle can be applied for playing: the position change is just an event pushing a pending redraw request.
from musescore.
The drawing is indeed handled that way by Qt. The source of latency in the case of MuseScore is the layout calculations, but indeed perhaps a similar mechanism could be applied here. Perhaps we should do these calculations in a background thread, so that the UI thread is not blocked, so that the user can continue triggering events while the calculations for the previous events are being finished. That's difficult to do though, because when a user action modifies the score, that might also influence which next actions are available. So you'd either need to wait for the calculations of the first action to complete before you can determine whether the next action should be available in the UI, or you'd need to predict that.
from musescore.
I guess this can be split in 2 parts:
- when user input modifies the data, the structure has to reflect the change and next available actions are defined from the last state
- the structure result in a layout computing and display. This task is usually time consuming
The first part (handling users inputs) should be computable without layout rendering, hence user inputs are managed quickly while the rendering loop updates the screen at a lower refresh rate, when the layout is ready.
from musescore.
That's difficult to do though, because when a user action modifies the score, that might also influence which next actions are available.
Does it make a difference?
Currently if user types ahead non-available or invalid command, it would be ignored or not executed.
In any case, input should be processed sequentially.
- the structure result in a layout computing and display.
For best results layout computing and actual drawing should be separated.
This way it would be possible to drop partially calculated layout if additional input arrived.
If necessary, drawing could be made on an off-screen canvas, then prepared image to be blitted to screen.
from musescore.
This way it would be possible to drop partially calculated layout if additional input arrived.
This is the wrong way to do. Each time you start computing a layout, you have to run it to the end and update the display accordingly.
If you drop in progress computing each time a new input arrives, then in a situation where the computing time is longer than the user input delay to the next input, you end up with a frozen interface until the user stop. This is very annoying because on such interface you make a bunch of inputs, then stop to let the program refresh, check the result, and start again.
If you fully process and update the display, then your application display is updated at the higher rate that the system can do, you always have the best available state, that is the state that was available when the compute step started. From the user point of view, the program is processing inputs in real time with a constant display update delay.
Just a remark: you have exactly this behavior when you are playing a pipe organ in some big church where the keyboard is away from the pipes. Even at very moderate speed, each time you press a key, you hear the note from the previous key.
from musescore.
Related Issues (20)
- Line component of TextLines ignores Text alignment HOT 3
- Harp pedal dialogue window remains if double clicked HOT 2
- All notes change to the specified dynamics, even if played before the change and held during it HOT 1
- MS Ver 4.4 plug-in compatibility HOT 2
- Subject: Enhancing MuseScore with Advanced Musical Operations HOT 4
- Freezing for a moment with certain actions HOT 3
- GuitarBend color not saved
- We must stop using the "Offset" property to determine the default position of items HOT 1
- Horizontal frames vis à vis instrument names HOT 2
- Tremolo between whole notes collide with noteheads and accidentals
- Some notes are still sound after deleting/replacing during playback HOT 1
- Make "Classic Phrasing" the default phrasing on Musesounds orchestral instruments. HOT 2
- Add preference/action to play all instruments when a range is selected
- Translation of the names of playing techniques in sound flags HOT 1
- [Edit Shortcut Dialog] When navigating to the text input field, screen reader doesn't pronounce the key properly, you need to press twice (Linux)
- First note on playback does not sound HOT 4
- Holding up/down arrow to change pitch, glitches with larger scores HOT 2
- Replace Instrument button in instrument panel does not work HOT 1
- Screen goes blank after tooltip disappears from top menu HOT 4
- "Tubular bells" missing from Select Instrument dialog HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from musescore.