Tabs and Menus Fried
Some of my tabs and menus are fried. Those that I remember from before the bug seem to work. I tried removing MuseScore from my computer, downloading a fresh copy, and re-installing, but that did not change anything. (I have not yet tried it on a different computer; that will be the next step unless somebody here has had the same problem and fixed it.)
A screen capture of the export dialog screen is attached. But the problem is widespread throughout the system.
| Attachment | Size |
|---|---|
| Capture.PNG | 140.61 KB |
Comments
Revert to factory settings
In reply to Revert to factory settings by Jojo-Schmitz
Thanks! Factory reset removed the glitch. Of course, there is always the question of how such an event can occur. Doesn't the object oriented programming paradigm prevent all such errors?
In reply to Thanks! Factory reset… by richard1941
Apparently not.
In reply to Apparently not. by Jojo-Schmitz
My career was in military electronics support. Ever notice how, in software development, the managers select the tools that the practitioners are forced to suffer with? Sometimes that happens when the software salesman is a gorgeous young woman who accompanies the manager for two weeks to a Mexico vacation. Or has blackmail information. Or pays a kickback. Etc.
In reply to My career was in military… by richard1941
It is very easy to be cynical. I suggest you take a look here https://github.com/musescore/MuseScore/issues?q=is%3Aissue+is%3Aclosed at all the bugs that have been reported and dealt with. Try reporting this issue there and see what happens.
In reply to My career was in military… by richard1941
@richard1941 • Oct 20, 2024 - 21:57
Maybe you're speaking of your own experience as a manager with a gorgeous young woman so I can't argue with that, but MuseScore is largely developed in C++ using Visual Studio which is a good environment for software development. The programming paradigm cannot prevent humans from including bugs in their code.
In reply to Maybe you're speaking of… by yonah_ag
No, it is not good.
C++ allows you far too easily to use null references which accounts for most of the crashes of MuseScore.
And the graphical library Qt suffers from the impossible problem to emulate a common environment between Linux, MacOs and Windows, which is an extremely challenging task and will in the best case never offer you more than the common demonitor between these 3 os. Granted, Qt is the best tool doing that but that doesn’t make it great.
So MuseScore probably uses what’s the best existing solution for multi-platform heavy application (Qt & C++), but that doesn’t make it great.
In reply to No, it is not good. C++… by frfancha
C++ is geared towards performance applications and requires the programmer to take care of things that other languages do for you. This means that the programmers cannot get away with being lazy.
A common denominator for the graphics library does not seem to be that limiting for the relatively simple requirements of MuseScore. It's not as if it it's some real-time, 3D, action-packed gaming software.
In reply to C++ is geared towards… by yonah_ag
Qt has its own set of quirks and issues as the famous menu appearing on incorrect screen demonstrate in the current MuseScore version.
C++ can be performant, but so can Rust
In reply to Qt has its own set of quirks… by frfancha
But it does have quite a challenging task so a few quirks are not surprising!
I guess that writing a graphics library in C++ specifically for MuseScore would have advantages but would take some effort. Such a library would only need to support graphical objects required by MS and would remove the dependency on a third party library. It could be optimised for MS requirements.
I took such an approach over 30 years ago when graphics libraries were thin on the ground. It was written in Intel x86 machine code and was blisteringly quick. I tried it in compiled Fortran but it was just too slow. C++ hadn't been invented then and C itself was just starting to gain some traction.
In reply to But it does have quite a… by yonah_ag
C++ is 45 years old, C is 54 years old...
In reply to C++ is 45 years old, C 54 is… by Jojo-Schmitz
I know, (invented was the wrong word; I meant adopted), but it takes a while for commercial organisations to move to newer technologies. There has to be a commerical benefit in doing so, (it takes a lot of resource to port software to a different environment), and this has to be weighed against the risk of software regressions and stand-still of actual product enhancement. Universities, (and maybe start-up companies), typically have the luxury of being able to adopt things earlier.
I joined a company that had already been developing software using Fortran 4 and after a couple of years there we made the move to Fortran 77. We also ported the software from DEC mainframes running VAX/VMS to PCs running MSDOS 3, then 5, then 6: the main code in Fortran and the graphics in machine code.
When I left after 8 years they were just starting to use C but this was for an entirely different product range. I don't know whether the earlier software ever moved from Fortran: probably not. "If it ain't broke - don't fix it".
In reply to I know but it takes a while… by yonah_ag
I remember during the Nixonian engineer's holocaust, about 1971, I hung out at the Pasadena City College machine shop. The instructor wanted a punched tape to cut out a particular fancy part. To get that required access to the campus computer. When I went to the computer center, they asked, "Do you program in Fortran 2, or Fortran 4." Like an idiot, I said, "Fortran 4." They said, "Then you are not qualified to work with our Fortran 2 computers." That's how it was. Now the power of those monsters is broken; everybody had several computers. (My favorite is a defunct iPhone 6 running a WP-34s emulator about 20 times faster than the actual platform would. An HP-prime emulator, also on the iPhone 6, has great symbolic calculus, it integrates almost as well as Wolfram, and provides power series for most things I think up, but, alas, no partial fractions.) And the keys are touchscreen, not those sleazy physical keys that get mashed so easily.
Languages? Never discuss languages with a FORTH programmer. We know that anybody who does not program in FORTH or in Assembler is merely an insane closed-minded fool subject to the authority of the bosses.
And don't get old!
In reply to C++ is 45 years old, C 54 is… by Jojo-Schmitz
Looks like the main product (Pipe Stress Analysis 5) is still alive and well in 2024 and has the same name it had way back when I worked on it.
http://www.wcompsys.co.uk/psa5.html
In reply to C++ is 45 years old, C 54 is… by Jojo-Schmitz
And it is still good stuff, and very empowering to the coder.
In reply to But it does have quite a… by yonah_ag
Only 30 years ago? You young guys missed the dark age of computing, when engineers were not allowed to use computers. That barrier started to crumble about 45 years ago with the first programmable HP handheld calculators. I remember taking a computer class at UC Berzerkeley where computer access meant you could stay up until 3:00 AM to get to a keypunch machine that was broken. And if you finally got your deck together, you submitted through a sealed window to a snotty girl who was obviously the computer center manager's GF. You could see all of the privileged people inside, building highly marketable skills for themselves while excluding outsiders.
In reply to Only 30 years ago? You… by richard1941
I still have a copy of McCracken "A Guide to Fortran IV Programming" on my bookshelf. But the first applications that I wrote that were of any use to anyone were written in APL - remember that? I have a great fondness for it and the challenge of getting a single line of code to do as much as possible.
In reply to I still have a copy of… by SteveBlower
I still have a Fortran 77 handbook on the shelf, that was actually the first programming language I learned, in the mid 80s on the university's mainframe. Follow by GFA-Basic and m66k assembler in my Atari ST, then in
'89 C on UNIX, (DG/UX, SGI Irix, Linux)
In reply to I still have a Fortran 77… by Jojo-Schmitz
I still have my first programming language (Pascal) book too. It's like an old friend who intoduced me to amazing new ideas and opened up a whole new world to me.
In reply to I still have a copy of… by SteveBlower
I never worked with APL. Like FORTH and LISP, it was frowned upon by the data processing authorities who sequestered the corporate computing resources. However, I remember a practitioner, Harry Bertucelli (PBUH) who liked to demonstrate to our calculator group how any problem could be solved in APL with only one line of code.
As for the data processing authorities, my engineering group had an Argentine genius who built a PDP-11 out of discarded junk circuit boards. That became a foundation for word processing, modeling and simulation, and all kinds of important activities. Occasionally we would have a brief power outtage, maybe less than a second, after which our secretary would holler a Texas curse because it was late in the afternoon and she had not hit the save button all day. Eventually we were provided with DEC PC's. They must have been the result of my previously described procurement process, or maybe they were selected by the Data Processing managers to intentionally cripple us. Ordinary floppy disks wouldn't work. They had 64k of memory, but 63k was taken by the operating system. The engineers who got them hated them. So we continued with the PDP-11.
In any case, my immediate goal is to teach myself HP Prime programming language. I am still testing random number generators. I found that MWC with 6 digits in the seed generates and incredibly long sequence, but that it has poor statistical quality. But with a 12 digit seed, I have yet to find a test failure. Thank you, George Marsaglia!
In reply to I never worked with APL. … by richard1941
HP Prime!
I had forgotten that actually my first useful application was a cooling tower simulation written on an HP 65. In those days the plant operational data was crunched using cylindrical slide rules. The HP 65 that I was allowed to play with was looked on in awe.
In reply to HP Prime! I had forgotten… by SteveBlower
HP-65 required extraordinary coding skills totally opposite those of "structured programming". There were only 10 memory registers, One of those was reserved for indirect addressing, and another, R8, was blown away if you invoked a trig function. But considerable power was there. When HP-67 and TI-59 came along, we had a lot more breathing room. As for music, I finally got the Rondo in second sonata of Devienne's book to play in the correct order. You need to designate the third section as a coda. I found that multiple codas work OK; somehow MuseScore remembers which coda was last played and goes to the next on when called. Still some problems with musescore. Audio quality isn't very good. Some of the dynamics in Devienne's book do not exist in MuseScore. Some of the MuseScore dynamics sound terrible on playback. But that's OK. MuseScore is an excellent value for the price! And there is a great library of examples.
In reply to My career was in military… by richard1941
I have been through the thing with industrial software. I know how things are done. Remember GOTO was first considered harmful by Niclaus Wirth? When top down structured programming would remove all mistakes. Then strongly typed languages. DoD came in with ADA, when we were developing AI apps in LISP and ATE test program sets in ATLAS. Then the Object people took over. All this stuff comes in waves, and as time goes on, the coders are becoming farther removed from the actual hardware, so they have no idea what is going on inside and what might be a more efficient way to do things.
As for the gorgeous Mexican software rep (the kind Trump would NOT deport) who took me to Cancun for a couple of weeks... Don't tell my wife about that! It never happened.
In reply to I have been through the… by richard1941
We won't tell :-)
My first look at coding was at uni where we were taught (Niclaus Wirth's) Pascal. We didn't find out until the end of the course that the GoTo statement even existed in Pascal so we had been jumping through hoops exiting from loops when an error was detected in a deep level of nesting.
In reply to Revert to factory settings by Jojo-Schmitz
One other problem also fixed, thanks to this forum! Failure of repeats that are in the middle of a measure. That was a big obstacle for me. Just use Tool/Meaures/Split Measure to create a bar line where a repeat can be inserted and honored by the Playback function.