[ks002]

For me , MS has made huge steps forward in the last 3 years since I started to use it on windows. Sometimes I think there are almost too many features in there, but then its good to know there are there. Some features could benefit from small UI changes and let me take the audio player as an example. Lately I started to use the audio player more and more. The audio quality with respect to speed and pitch changes is excellent imho. Sometimes I even create a fake song in MS just to practice with a particular audio track! There is this dialog box to change speed or pitch. One can enter a number or press the +/- buttons to change the value. This is fine. However to apply the setting one has to press OK in addition and the box closes afterwards. For me it makes much more sense to apply the new value right away and then have the user decide if he wants to keep the setting with the OK, Cancel buttons. Also some means of resetting the value to default (1) would be useful. Another thing is the rewind button (|<). It works as a 'start of playlist' . I rarely have more than 1 track for a song so it does nothing for me. Now I have to press stop and playback again to restart the track.  Why not making it a 'go to beginning of track' in this case? Or make an option so that the function can be set? 

I would appreciate if the development of MS is focussed even more on such small usability things 
Klaus

[Zubersoft]

Thanks for the feedback. I'm always open to improving the usability of the app. I have plenty of ideas for changes to the Windows 10 version as well. It just comes down to time. Right now, users have made it very clear that changing the annotations functionality is the most important thing (by far). So I'm going to focus most of my attention on that so I can get it done faster. After that, there are very compelling reasons to get the iOS version done as fast as possible, and I'm getting a huge amount of feedback and desire for that. After the iOS version is finished, I have a list of high priority feature requests that have been waiting for awhile that I get feedback on regularly. So those will come next. While working those high priority feature requests, I will slip in small usability enhancements as I can (this is true for any update as long as the usability changes are small). The priority that any change is given depends upon a combination of the complexity involved, the number of users that request it and the number of users that benefit from it. 

When I get a chance to modify the code for the pitch/tempo adjustment so that it can be changed without having to exit the dialog, I will do that. This involves having to ensure changes aren't triggered too quickly (when changing the tempo speed, the values can change extremely fast and I don't want to crash the audio player as I'm not sure what that library is capable of when it comes to being hammered like that), that the value is reset properly if the dialog is canceled and adding the necessary code to watch for changes on that dialog in the calling code (right now it doesn't process changes until the dialog is closed). That dialog is used all over the application, so any changes I make could impact other areas, so there may be a lot of other code that needs to be updated depending upon the nature of the changes. I've also been considering changing the dialog based approach with the number entry to something more like a popup window without OK/Cancel that just lets you change the value quickly with arrows and a slider (similar to the existing dialog layout) as it's less jarring on Windows 10. Microsoft's framework only lets you display a single dialog at a time, so if a dialog needs to pop up another dialog, you have to close the first, trigger the second, then when the second closes, trigger the first to show again. It's incredibly annoying and not great from a user standpoint either. So one of my goals is to see if I can switch to popups in various parts of the application where dialogs are being used at the moment. 

So as you can see, any change is going to require focus to ensure its done right, and even when it seems small, it can impact a lot of areas of the application. So I can't just work these as I receive them - they will have to be scheduled appropriately. I really do appreciate the feedback, and the changes will be made, but it will require some patience.

As a side note, if you want to restart the track, just press play a second time. That is how the track can be restarted. There is no need to stop and then play again.

Mike

[ks002]

Mike, thanks for all the insights into the programming issues. I am fully aware that there is a bunch of items on the todo list. Beside my special request I just wanted to emphasize how important also the small things are. We fans of the app want it to be the polished Mercedes! I hope (and think) that I am no alone with this. In case you havent seen it: There is a very funny video where a guy takes on the UI of the Musescore app. He is now part of the Musescore team. Give it try: https://www.youtube.com/watch?v=4hZxo96x48A

[BRX]

I know that and the one he made for the current Sibelius version, too. I doubt he will get onto their team. :-)