yes, but musescore offered a very powerful method of having it all in SVG.. there is no comparison with native OS type that only take a normal picture. So... not the same, I hope Musescore doesnt take a turn towards hidding and changing things that were already proved to be useful and superior next to other software.
Good point about SVG! Anyhow, if you check out the various posts about this, you'll see this wasn't a decision to remove functionality, just an unfortunate and temporary side effect of the change to an entirely new UI system - the old code for the old image capture simply didn't work with the new system and there was no simple way to adapt it. So rather than delay the entire MuseScore 4 project while this is implemented, the decision was made to release 4.0 without this (and the very small handful of other features that had to be temporarily dropped for similar reasons, like the score comparison tool), and then redesign and reintroduce new versions of these tools in an update later.
"Meanwhile, as far I know all OS's come with built-in screen capture facilities that work well."
Right, but OS level screenshot facilities don't have the "size to fit" functionality MuseScore's image capture has.
As Marc has mentioned, this was most certainly not an intentional move to lift out useful functionality. In particular the SVG output was a nice touch. The problem we faced was that the older solution for it was technically incompatible with our new system. This simply means that it would have taken a large amount of time to rebuild and test. We felt it was much safer (and would speed up our release) to bump it to a smaller release. Apologies about this.
what about JACK, today I discovered that v 4 is out and to my surprise it does not support JACK anymore... this is exactly what I was fearing. I am not saying I use musescore as a sequencer, but the fact that I use Linux allows me to be customisable and modular with my work flow. The fact that musescore removed the ability to use the software in an open and free way is definitely troublesome for me. Is this feature coming back? will musescroe allow their users to configure and work on their own systems as they please or are you moving to a more closed and centralized way of doing things... this really got me upset.
true... but as Marc said, some features are gone are planned to come back later... where can I know which are these features. How can I find out what functionalities is musescore dropping? I will open a feature request if possible.
It's difficult to predict the future. Right now I don't think there are imminent plans to reimplement JACK, but that doesn't mean it won't happen, especially considering this open-source software so anyone really could decide to take up the task at any time.
Better to start a new forum discussing your usage of JACK. My sense is, the vast majority of people would prefer not to have to deal with JACK, but some of the things that JACK formerly made possible could still be of interest to many. So seeing those implemented more directly. That's already happened with VST of course - not yet on Linux, but that's definitely planned.
In https://github.com/musescore/MuseScore/issues/12775 Tantacrul said:
"I'm moving Jack issues to 4.x, which is when we will begin to address them."
So just maybe there is still hope (just like there is hope for Linux vst's ...)
That would depend on your OS, I guess - you’d have to consult the documentation for its capture facility to learn what options it provides. But if white background won’t work for your purpose, pretty much any image editor should be able to convert that to a transparent image.
As a teacher who uses this software to create warm-up sheets for my students, this feature was the best tool that MuseScore had above other software. I downloaded MuseScore 4 for the awesome playback sounds, and I am really disappointed to see this feature go. I hope to see it roll out soon.
I'd like to say that, although I really understand the fact of the technical incompatibility of the old capture tool with the new UI system, I don't agree with Marc Sabatella's argument that the OS's built-in screen capture facilities are a suitable workaround to the original feature. JRSV already mentioned the ability to export to SVG, but not only this, also the ability to export in high resolution is critical to anyone who needs to put music fragments into other apps. As a university professor I always prepare exams and music theory texts using SVGs exported from MuseScore. Also I always criticize students who present assignments with low-quality or low-resolution musical examples (which is what you get with standard OS screen capture). I my music publishing class I teach them to export music fragments as SVG files, and even use them to create some tricky things in MuseScore itself (see for example Bartok's Mikrokosmos where there is small staves showing the pitch range). The lack of this feature simply makes MuseScore 4 unsuitable for a large part of my job. So, I think bringing back this feature should be a high-priority task for MuseScore 4.
For the record, I'm not saying a third party capture completely replaces the builtin tool forever and thus it will never be reimplemented. I'm just saying, it's a workaround for now. Which it is. Slightly more effort on some systems - might need to zoom in to get the same resolution, might not support the same formats or might require editing to get the transparent background if that's important, but still, it's an option we can be using today while we wait for the new facility.
That may well be, but I don't think they are using the issue tracker to make the development plans. It's definitely known as a feature to be designed & developed even without an issue, though. And in any case, having the issue remain open here where the developers are not looking isn't useful, so no point in keeping this open. Wouldn't hurt to open an issue on GitHub of course.
@Marc That is not what github says! There is explicitly requested to register feature requests here!
See:
This issue tracker is used only for tracking development events.
If you want to create bug reports or feature requests, please go to the forums or the issue tracker on https://musescore.org/.
Oh, that's a shame. I was looking for the capture icon but couldn't find it. I like to catalogue main motives and themes, especially for large-scale works, so I can reference or develop them. It's nice to have them all inhabit a document for reference.
The message you refer to is not what it says on the main issue reporting page.
But, it is true that in order to avoid deluging GitHub with low-quality reports (eg, bad title, bad description, no clear steps to reproduce, etc) the development team has stated they don't want users turning there first. They want musescore.org to be the initial triage center. Once something is confirmed as a real bug and not a duplicate and with a clear description that allows people to reproduce the problem, then they want the issue reported on GitHub.
In order to make this process work, it's pretty important that we don't allow this issue tracker here to be cluttered with open issues that don't need to be, either. The triage process involves marking an issue needs info if ity, like the majority of issues here, are not yet sufficiently clear and reproducible. Or if it's known to already be on the radar, issues here should be closed so we don't waste further time on them.
What's missing is a new status that would mean "confirmed here but not yet reported n GitHub or otherwise made known to the development team".
Anyhow - getting back tot he issue at hand - every OS comes with a built-in image capture facility, and there are many free third-party tools available as well. So even though the native feature within MuseScore is not yet implemented in the new design, you can still create the same sort of theme catalogs as always.
I'm not sure I'm following you.
Are you saying that feature requests must be marked as duplicates just because you happen to know that somebody is aware of it even when that feature request isn't registered in any system or at least any system users can access?
I'm saying there is no point in having an issue "active" here if it is already being tracked by the developers elsewhere. And yes, whether users can access that or not. With the current workflow, this triage station isn't for the benefit of curious users wanting to look things up - it's for the benefit of the people doing the triage, and by extension, for the benefit of the developers, by allowing GitHub to focus on only clearly stated reproducible non-duplicate issues. Ideally, there would be zero open issues issues here, because we'd be triaging them as fast as they come in. AEveryopen issue here stands in the way of effective triage work, which is why I think it important to the treaige and move on as quickly as possible, so things don't get more out of hand than they already are.
So, whether the developers happen to be tracking an issue on GitHub or in their own internal design documents is pretty immaterial. There is nothing anyone here needs to do to make sure the developers have it on their radar, so there is no point in keeping this open. All it does is clutter there tracker and make it more difficult to find the issues that have not yet been triaged. There should be a bare minimum of "active" issues - only issues not yet confirmed, or confirmed here but not yet confirmed to be already logged somewhere the development team is aware of.
Like I said, it certainly doesn't hurt to also add a GitHub issue for this, but I assure you, it is already known, so there is zero point in having it open here either way.
So issues are also in a place that nobody except "developpers" can access.
Interesting.
This seems to confirm that development is now restricted to the internal team only and not open at all anymore.
Design documents have never been public. Bug reports are. GitHub is for bug reports and is completely public. Nothing new here..
Anyhow, I still say, it's counterproductive to keep issues open when every single one of us knows with absolutely certainty that the developers already know full well about this - it's mentioned the release announcement, after all. Hweoeve,r in the interest of just letting this issue be closed and movingon, I've gone ahead and opened a GitUb issue anyhow - https://github.com/musescore/MuseScore/issues/15912. Took less effort than continuing to argue about it.
But please can we try to remember the purpose of this tracker here? Having issues left open indefinitely is not good. We want to get issues closed as quickly as possible so the actual bugs that have not yet made it to the attention of developers can be reported.
This is unfortunate indeed, although of course hardly anyone searches for duplicates before posting, so keeping the duplicate open wouldn't help with that either.
What we really need then is at least two more statuses: one for confirmed but not yet reported to GitHub, another for issues now reported on GitHub, both of which would appear in a list of "open" issues and thus in a default search. But those of us merely wishing to find the issues not yet moved into one of these states would have a way of excluding them. And of course we would really need a button to forward an issue to GitHub.
Meanwhile, we can continue to do the best we can with a less-than-ideal situation!
Ir return to usingh the Missue tracker here for released version and dropping the GitHub tracker, or at least use it only for issues of in-development versions
Having 2 system is just bad
I loved MuseScore 3's image capture tool because it hides the notes that are supposedly invisible. If I use my os's capture tool, I still see the gray-colored notes. Is there a way to keep the notes invisible but not show up in the OS's image capture tool?
You can turn off the visibility of hidden notes and other categories of things in the View menu under the submenu - Show. Just untick everything in that sub menu.
I'm going to add my comment to the other comments here and voice my support for the Image Capture tool. The Image Capture tool in MuseScore 3 is an excellent tool that allows music educators to create graphics and easily pop them into Powerpoint or Word to make presentations, assignments, tests, etc. It really was a life-saver for me as we went into the pandemic and I continue to use it to enhance my online teaching. In addition, I use it frequently for lecture materials and exercises now that we're (about halfway) back in person. I hope it will be coming back in MuseScore 4. Until then, I’ll be sticking with MuseScore 3.
I also hope to see it return. But just so you know, your OS already provides an equally easy-to-use image capture facility; you don't need to rely on MuseScore to provide another. For instance, on Windows, pressing WIndows+Shift+S allows you to capture a region just as easily.
There are indeed special use cases where the built-in tool was indeed an improvement, which is the reason I hope it comes back. But for basic things like creating educational worksheets etc, PNG or whatever format is used by your OS's native screen capture should be more than sufficient. My point isn't to argue against seeing the built-in image capture return, it's just to help people do their jobs today using the tools as they exist, which actually work extremely well for 99% of use cases. No reason students should be forced to look at examples with the lesser quality engraving of MU3 when you can easily add examples using the much improved engraving of MU4.
I'm also sorely disappointed to see this feature gone. As a guitar instructor, there are MANY times where a chord chart with lyrics is best, but intros/riffs/fills need sheet music or TABs embedded in the word doc. Image capture was, without a doubt, the best and quickest way to add 1-5 measures of music into a text document.
Is there a specific reason the image capture built into your OS isn’t working for you? As noted, there are some limitations, but for the bats majorly of use cases, it should be completely sufficient. I use this a lot in my work too and frankly haven’t missed it since the OS facility is so convenient.
Yes, as I said, there are limitations - and yet the vast majority of use cases don't need either of those. So I want to make sure people understand that almost certainly they can still do what they are doing - eg, creating documents in other programs and pasting in musical examples. There are very few real world use cases where a PNG capture by an OS-level screen capture tool isn't completely sufficient. Some yes, but I think many people are simply not aware there is a simple alternative.
The screen capture hasn't the quality of the old "image capture". For me is very useful since I need to create a lot of documents for my students. I also use it to create collections of single parts on A4 pages for printing.
I think this is a very useful function that saves a lot of time
It’s useful indeed and wi hopefully return . But do note that if have reasonably high resolution display, and/or a large enough one to display your examples zoomed in a bit, you can still get 300 DPI captures that would be indistinguishable from what you were getting in MU3.
Today I worked on a score created with musescore 4, so I cannot open it on ms3. I had to export a PNG, open with an image editor, crop the part I need, save and the import in the pdf editor.
Image capture is a VERY useful feature that only Musescore has (had). I hope that will be reintroduced soon.
If you say which OS you are on, we can help you use its built-in image capture facility more effectively, if you are interested. You might be surprised to learn how powerful it is - many people are unaware.
If you're not interested, no need to respond further - it's already known this is a feature that many users want to see come back and this is not the place to track issues anymore anyhow.
As for transferring files from MuseScore 4 to 3, certainly don't resort to images - simply export to MusicXML, which MuseScore 3 can import directly. For questions about that process - or questions about anything having to do with MuseScore - please use the Supprot forum.
I use ubuntu linux. It isn't a problem to use the system image capture, but it keeps in the screenshot also page break, "a capo" , background colors and all hidden elements that shouldn't be in the exported image.
So, no, the system screenshot isn't a valid substitute of the previous native function of musescore 3.
And no, if I have to export from ms4 to musicxml, import in ms3, fix the impagination ... it's faster to work directly in ms3 :)
You can easily turn off display of breaks etc - those controls are in the View menu. You can also do it from the Properties pane if nothing is selected. or, you can make your screen captures from the Publish tab, which automatically hides all that. You can also set the paper color to pure white instead of the slightly off-white it is by default. It really does work extremely well!
BTW, I think I misunderstood what you were saying when you wrote "I cannot open it on ms3. I had to export a PNG" I thought you meant, you export the PNG file from MuseScore 4, then used an image editor to convert it to PDF, then used the PDF import feature to get it into MuseScore 3. Now I see, you just meant, you used the PNG export instead of screen shot from within MuseScore 4 and cropped that directly. This if course works, but is nowhere near as efficient as the OS screenshot tool.
Comments
It is supposed to come back in 4.x with x > 0
Meanwhile, as far I know all OS's come with built-in screen capture facilities that work well.
In reply to Meanwhile, as far I know all… by Marc Sabatella
yes, but musescore offered a very powerful method of having it all in SVG.. there is no comparison with native OS type that only take a normal picture. So... not the same, I hope Musescore doesnt take a turn towards hidding and changing things that were already proved to be useful and superior next to other software.
Good point about SVG! Anyhow, if you check out the various posts about this, you'll see this wasn't a decision to remove functionality, just an unfortunate and temporary side effect of the change to an entirely new UI system - the old code for the old image capture simply didn't work with the new system and there was no simple way to adapt it. So rather than delay the entire MuseScore 4 project while this is implemented, the decision was made to release 4.0 without this (and the very small handful of other features that had to be temporarily dropped for similar reasons, like the score comparison tool), and then redesign and reintroduce new versions of these tools in an update later.
In reply to Meanwhile, as far I know all… by Marc Sabatella
"Meanwhile, as far I know all OS's come with built-in screen capture facilities that work well."
Right, but OS level screenshot facilities don't have the "size to fit" functionality MuseScore's image capture has.
That too, but unfortunately that feature has been broken for a pretty long time, as you reported in #314437: Image capture: "Auto-resize to page" misbehaves - and another related issue in #305451: Image capture selection moves out of sight.
In reply to yes, but musescore offered a… by JRSV
As Marc has mentioned, this was most certainly not an intentional move to lift out useful functionality. In particular the SVG output was a nice touch. The problem we faced was that the older solution for it was technically incompatible with our new system. This simply means that it would have taken a large amount of time to rebuild and test. We felt it was much safer (and would speed up our release) to bump it to a smaller release. Apologies about this.
In reply to As Marc has mentioned, this… by Tantacrul
what about JACK, today I discovered that v 4 is out and to my surprise it does not support JACK anymore... this is exactly what I was fearing. I am not saying I use musescore as a sequencer, but the fact that I use Linux allows me to be customisable and modular with my work flow. The fact that musescore removed the ability to use the software in an open and free way is definitely troublesome for me. Is this feature coming back? will musescroe allow their users to configure and work on their own systems as they please or are you moving to a more closed and centralized way of doing things... this really got me upset.
Entirely unelated to the issue at hand.
In reply to Entirly unraleted to the… by Jojo-Schmitz
true... but as Marc said, some features are gone are planned to come back later... where can I know which are these features. How can I find out what functionalities is musescore dropping? I will open a feature request if possible.
See https://musescore.org/en/node/334701
In reply to See https://musescore.org/en… by Jojo-Schmitz
thank you, this is what I am looking for... would be useful to know which features are not coming back.
It's difficult to predict the future. Right now I don't think there are imminent plans to reimplement JACK, but that doesn't mean it won't happen, especially considering this open-source software so anyone really could decide to take up the task at any time.
Better to start a new forum discussing your usage of JACK. My sense is, the vast majority of people would prefer not to have to deal with JACK, but some of the things that JACK formerly made possible could still be of interest to many. So seeing those implemented more directly. That's already happened with VST of course - not yet on Linux, but that's definitely planned.
In reply to It's difficult to predict… by Marc Sabatella
In https://github.com/musescore/MuseScore/issues/12775 Tantacrul said:
"I'm moving Jack issues to 4.x, which is when we will begin to address them."
So just maybe there is still hope (just like there is hope for Linux vst's ...)
In reply to Right, but OS level… by RobFog
Does OS level screenshot have the 'transparent background' feature? I need the MuseScore's image capture with transparent background.
In reply to Does OS level screenshot… by Goldenray
That would depend on your OS, I guess - you’d have to consult the documentation for its capture facility to learn what options it provides. But if white background won’t work for your purpose, pretty much any image editor should be able to convert that to a transparent image.
As a teacher who uses this software to create warm-up sheets for my students, this feature was the best tool that MuseScore had above other software. I downloaded MuseScore 4 for the awesome playback sounds, and I am really disappointed to see this feature go. I hope to see it roll out soon.
In reply to Meanwhile, as far I know all… by Marc Sabatella
I'd like to say that, although I really understand the fact of the technical incompatibility of the old capture tool with the new UI system, I don't agree with Marc Sabatella's argument that the OS's built-in screen capture facilities are a suitable workaround to the original feature. JRSV already mentioned the ability to export to SVG, but not only this, also the ability to export in high resolution is critical to anyone who needs to put music fragments into other apps. As a university professor I always prepare exams and music theory texts using SVGs exported from MuseScore. Also I always criticize students who present assignments with low-quality or low-resolution musical examples (which is what you get with standard OS screen capture). I my music publishing class I teach them to export music fragments as SVG files, and even use them to create some tricky things in MuseScore itself (see for example Bartok's Mikrokosmos where there is small staves showing the pitch range). The lack of this feature simply makes MuseScore 4 unsuitable for a large part of my job. So, I think bringing back this feature should be a high-priority task for MuseScore 4.
For the record, I'm not saying a third party capture completely replaces the builtin tool forever and thus it will never be reimplemented. I'm just saying, it's a workaround for now. Which it is. Slightly more effort on some systems - might need to zoom in to get the same resolution, might not support the same formats or might require editing to get the transparent background if that's important, but still, it's an option we can be using today while we wait for the new facility.
Came up multiple times in the forum
In reply to It is supposed to come back… by Jojo-Schmitz
aaahhhhhrggll LOL
This is a known limitation of the current design, so no need to have this issue open in addition.
I don't see in on GitHub though
That may well be, but I don't think they are using the issue tracker to make the development plans. It's definitely known as a feature to be designed & developed even without an issue, though. And in any case, having the issue remain open here where the developers are not looking isn't useful, so no point in keeping this open. Wouldn't hurt to open an issue on GitHub of course.
In reply to That may well be, but I don… by Marc Sabatella
@Marc That is not what github says! There is explicitly requested to register feature requests here!
See:
This issue tracker is used only for tracking development events.
If you want to create bug reports or feature requests, please go to the forums or the issue tracker on https://musescore.org/.
Oh, that's a shame. I was looking for the capture icon but couldn't find it. I like to catalogue main motives and themes, especially for large-scale works, so I can reference or develop them. It's nice to have them all inhabit a document for reference.
The message you refer to is not what it says on the main issue reporting page.
But, it is true that in order to avoid deluging GitHub with low-quality reports (eg, bad title, bad description, no clear steps to reproduce, etc) the development team has stated they don't want users turning there first. They want musescore.org to be the initial triage center. Once something is confirmed as a real bug and not a duplicate and with a clear description that allows people to reproduce the problem, then they want the issue reported on GitHub.
In order to make this process work, it's pretty important that we don't allow this issue tracker here to be cluttered with open issues that don't need to be, either. The triage process involves marking an issue needs info if ity, like the majority of issues here, are not yet sufficiently clear and reproducible. Or if it's known to already be on the radar, issues here should be closed so we don't waste further time on them.
What's missing is a new status that would mean "confirmed here but not yet reported n GitHub or otherwise made known to the development team".
Anyhow - getting back tot he issue at hand - every OS comes with a built-in image capture facility, and there are many free third-party tools available as well. So even though the native feature within MuseScore is not yet implemented in the new design, you can still create the same sort of theme catalogs as always.
In reply to Yes, in order to avoid… by Marc Sabatella
I'm not sure I'm following you.
Are you saying that feature requests must be marked as duplicates just because you happen to know that somebody is aware of it even when that feature request isn't registered in any system or at least any system users can access?
As long as there isn't an issue for this elsewhere, or isn't a duplicate
I'm saying there is no point in having an issue "active" here if it is already being tracked by the developers elsewhere. And yes, whether users can access that or not. With the current workflow, this triage station isn't for the benefit of curious users wanting to look things up - it's for the benefit of the people doing the triage, and by extension, for the benefit of the developers, by allowing GitHub to focus on only clearly stated reproducible non-duplicate issues. Ideally, there would be zero open issues issues here, because we'd be triaging them as fast as they come in. AEveryopen issue here stands in the way of effective triage work, which is why I think it important to the treaige and move on as quickly as possible, so things don't get more out of hand than they already are.
So, whether the developers happen to be tracking an issue on GitHub or in their own internal design documents is pretty immaterial. There is nothing anyone here needs to do to make sure the developers have it on their radar, so there is no point in keeping this open. All it does is clutter there tracker and make it more difficult to find the issues that have not yet been triaged. There should be a bare minimum of "active" issues - only issues not yet confirmed, or confirmed here but not yet confirmed to be already logged somewhere the development team is aware of.
Like I said, it certainly doesn't hurt to also add a GitHub issue for this, but I assure you, it is already known, so there is zero point in having it open here either way.
As long as it is not visibly tracked elsewhere this issue here is not a duplicate
In reply to I'm saying there is no point… by Marc Sabatella
So issues are also in a place that nobody except "developpers" can access.
Interesting.
This seems to confirm that development is now restricted to the internal team only and not open at all anymore.
In reply to So issues are also in a… by frfancha
Design documents have never been public. Bug reports are. GitHub is for bug reports and is completely public. Nothing new here..
Anyhow, I still say, it's counterproductive to keep issues open when every single one of us knows with absolutely certainty that the developers already know full well about this - it's mentioned the release announcement, after all. Hweoeve,r in the interest of just letting this issue be closed and movingon, I've gone ahead and opened a GitUb issue anyhow - https://github.com/musescore/MuseScore/issues/15912. Took less effort than continuing to argue about it.
But please can we try to remember the purpose of this tracker here? Having issues left open indefinitely is not good. We want to get issues closed as quickly as possible so the actual bugs that have not yet made it to the attention of developers can be reported.
The lack of Image capture is a regression. And as such a bug... even if by design
Closing issues here basically resultes in new and duplicate issues comming up.
Duplicate are much worse than open issues IMHO
Anyway, thanks for opening the GitHub issue
This is unfortunate indeed, although of course hardly anyone searches for duplicates before posting, so keeping the duplicate open wouldn't help with that either.
What we really need then is at least two more statuses: one for confirmed but not yet reported to GitHub, another for issues now reported on GitHub, both of which would appear in a list of "open" issues and thus in a default search. But those of us merely wishing to find the issues not yet moved into one of these states would have a way of excluding them. And of course we would really need a button to forward an issue to GitHub.
Meanwhile, we can continue to do the best we can with a less-than-ideal situation!
Ir return to usingh the Missue tracker here for released version and dropping the GitHub tracker, or at least use it only for issues of in-development versions
Having 2 system is just bad
I loved MuseScore 3's image capture tool because it hides the notes that are supposedly invisible. If I use my os's capture tool, I still see the gray-colored notes. Is there a way to keep the notes invisible but not show up in the OS's image capture tool?
In reply to I loved MuseScore 3's image… by joonpark
You can turn off the visibility of hidden notes and other categories of things in the View menu under the submenu - Show. Just untick everything in that sub menu.
In reply to For the record, I'm not… by Marc Sabatella
I think the real workaround is to still run MuseScore 3. You don't have to delete it to run MuseScore 4.
I'm going to add my comment to the other comments here and voice my support for the Image Capture tool. The Image Capture tool in MuseScore 3 is an excellent tool that allows music educators to create graphics and easily pop them into Powerpoint or Word to make presentations, assignments, tests, etc. It really was a life-saver for me as we went into the pandemic and I continue to use it to enhance my online teaching. In addition, I use it frequently for lecture materials and exercises now that we're (about halfway) back in person. I hope it will be coming back in MuseScore 4. Until then, I’ll be sticking with MuseScore 3.
I also hope to see it return. But just so you know, your OS already provides an equally easy-to-use image capture facility; you don't need to rely on MuseScore to provide another. For instance, on Windows, pressing WIndows+Shift+S allows you to capture a region just as easily.
In reply to I also hope to see it return… by Marc Sabatella
An SVG "just as easily"?
There are indeed special use cases where the built-in tool was indeed an improvement, which is the reason I hope it comes back. But for basic things like creating educational worksheets etc, PNG or whatever format is used by your OS's native screen capture should be more than sufficient. My point isn't to argue against seeing the built-in image capture return, it's just to help people do their jobs today using the tools as they exist, which actually work extremely well for 99% of use cases. No reason students should be forced to look at examples with the lesser quality engraving of MU3 when you can easily add examples using the much improved engraving of MU4.
Still waiting for this feature.
I'm also sorely disappointed to see this feature gone. As a guitar instructor, there are MANY times where a chord chart with lyrics is best, but intros/riffs/fills need sheet music or TABs embedded in the word doc. Image capture was, without a doubt, the best and quickest way to add 1-5 measures of music into a text document.
I'm still on musescore 3 also for this missing feature. I use it a lot in my work.
In reply to I'm still on musescore 3… by zorba
Is there a specific reason the image capture built into your OS isn’t working for you? As noted, there are some limitations, but for the bats majorly of use cases, it should be completely sufficient. I use this a lot in my work too and frankly haven’t missed it since the OS facility is so convenient.
Transparency is one, svg another.
Ease of use a third.
Yes, as I said, there are limitations - and yet the vast majority of use cases don't need either of those. So I want to make sure people understand that almost certainly they can still do what they are doing - eg, creating documents in other programs and pasting in musical examples. There are very few real world use cases where a PNG capture by an OS-level screen capture tool isn't completely sufficient. Some yes, but I think many people are simply not aware there is a simple alternative.
The screen capture hasn't the quality of the old "image capture". For me is very useful since I need to create a lot of documents for my students. I also use it to create collections of single parts on A4 pages for printing.
I think this is a very useful function that saves a lot of time
In reply to The screen capture hasn't… by zorba
It’s useful indeed and wi hopefully return . But do note that if have reasonably high resolution display, and/or a large enough one to display your examples zoomed in a bit, you can still get 300 DPI captures that would be indistinguishable from what you were getting in MU3.
Sorry, I work faster and better with the old Image Capture
Today I worked on a score created with musescore 4, so I cannot open it on ms3. I had to export a PNG, open with an image editor, crop the part I need, save and the import in the pdf editor.
Image capture is a VERY useful feature that only Musescore has (had). I hope that will be reintroduced soon.
If you say which OS you are on, we can help you use its built-in image capture facility more effectively, if you are interested. You might be surprised to learn how powerful it is - many people are unaware.
If you're not interested, no need to respond further - it's already known this is a feature that many users want to see come back and this is not the place to track issues anymore anyhow.
As for transferring files from MuseScore 4 to 3, certainly don't resort to images - simply export to MusicXML, which MuseScore 3 can import directly. For questions about that process - or questions about anything having to do with MuseScore - please use the Supprot forum.
I use ubuntu linux. It isn't a problem to use the system image capture, but it keeps in the screenshot also page break, "a capo" , background colors and all hidden elements that shouldn't be in the exported image.
So, no, the system screenshot isn't a valid substitute of the previous native function of musescore 3.
And no, if I have to export from ms4 to musicxml, import in ms3, fix the impagination ... it's faster to work directly in ms3 :)
You can easily turn off display of breaks etc - those controls are in the View menu. You can also do it from the Properties pane if nothing is selected. or, you can make your screen captures from the Publish tab, which automatically hides all that. You can also set the paper color to pure white instead of the slightly off-white it is by default. It really does work extremely well!
BTW, I think I misunderstood what you were saying when you wrote "I cannot open it on ms3. I had to export a PNG" I thought you meant, you export the PNG file from MuseScore 4, then used an image editor to convert it to PDF, then used the PDF import feature to get it into MuseScore 3. Now I see, you just meant, you used the PNG export instead of screen shot from within MuseScore 4 and cropped that directly. This if course works, but is nowhere near as efficient as the OS screenshot tool.