Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On samedi 19 février 2022 21:02:06 CET mark_at_yahoo via Rosegarden-devel wrote: > BTW, while desperately searching yesterday for any clues to solve my > dilemma, I unavoidably ran across the extensive online references to > your historical and continuing position in the Qt world. Even more so > than the last time I mentioned it here, I'm somewhat embarrassed (of > course in addition to being grateful) for your help with my newbie > problems. It's an honor and privilege I'll try not to abuse. No worries. I help because I choose to :) I don't contribute much to rosegarden code itself, but as an occasional user I try to help on this list. > Not sure I'm qualified to be hanging with this crowd, but I still hope > to contribute something that will make your net time expenditure on me > worthwhile. New contributors are always welcome :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
Le 20 février 2022 à 14H32 (+0100) Philip Leishman a écrit : > Should anything go to /usr/share ? > My feeling is that nothing should be installed there. Rosegarden runs > perfectly without a /usr/share/rosegarden directory. Anything there is > only a potential problem! > > I can create a bug report. Should I suggest that nothing should go to > /usr/share or is something useful there ? Nothing in /usr/share/rosegarden, but there should be still some files under /usr/share/icons/, /usr/share/mime/packages/, /usr/share/applications/ and /usr/share/metainfo/. (See install_manifest.txt in the BUILD directory) Yves ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
Should anything go to /usr/share ? My feeling is that nothing should be installed there. Rosegarden runs perfectly without a /usr/share/rosegarden directory. Anything there is only a potential problem! I can create a bug report. Should I suggest that nothing should go to /usr/share or is something useful there ? Philip On 2/20/22 13:17, Ted Felix wrote: On 2/20/22 6:51 AM, Philip Leishman wrote: I can confirm this. I have openSUSE too. Luckily I didn't install the rosegarden package. I downloaded the package (without install) and I can see all the rc files would go to /usr/share/rosegarden/rc/ This is surely not a good idea ? All the translations are there and, well, just about everything. The .rc files do not belong there. The only reason we treat them like resources is so that users can customize them. We don't copy them to ~/.local/share. Consequently, putting them in /usr/share causes trouble when installing/running other versions. I'm not sure whether any of the others would cause similar issues. E.g. the translations are not copied to ~/.local/share. Do the ones in /usr/share cause trouble like the .rc files? I believe the history of this is that some distros didn't do the right thing with our resources. So we put them in the binary and copied them to ~/.local/share. This eliminated the distros as a variable and made Rosegarden more reliable. OpenSUSE's approach makes Rosegarden less reliable. The rule here is... Any resource directories that do not appear in ~/.local/share/rosegarden after a run of Rosegarden should not appear in /usr/share/rosegarden. locale and rc are obvious candidates. pixmaps is a huge waste of space and (assuming they are used) would introduce bugs if we ever change those. And we need to change those. scripts are for developers and should not be installed for users. This would be a great start, but the rest should probably go as well. None of them really serve a purpose since we copy to ~/.local/share on startup. One of you folks actually using OpenSUSE should open a bug report against the Rosegarden package and get this moving in the right direction. Good luck. Ted. ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/20/22 6:51 AM, Philip Leishman wrote: I can confirm this. I have openSUSE too. Luckily I didn't install the rosegarden package. I downloaded the package (without install) and I can see all the rc files would go to /usr/share/rosegarden/rc/ This is surely not a good idea ? All the translations are there and, well, just about everything. The .rc files do not belong there. The only reason we treat them like resources is so that users can customize them. We don't copy them to ~/.local/share. Consequently, putting them in /usr/share causes trouble when installing/running other versions. I'm not sure whether any of the others would cause similar issues. E.g. the translations are not copied to ~/.local/share. Do the ones in /usr/share cause trouble like the .rc files? I believe the history of this is that some distros didn't do the right thing with our resources. So we put them in the binary and copied them to ~/.local/share. This eliminated the distros as a variable and made Rosegarden more reliable. OpenSUSE's approach makes Rosegarden less reliable. The rule here is... Any resource directories that do not appear in ~/.local/share/rosegarden after a run of Rosegarden should not appear in /usr/share/rosegarden. locale and rc are obvious candidates. pixmaps is a huge waste of space and (assuming they are used) would introduce bugs if we ever change those. And we need to change those. scripts are for developers and should not be installed for users. This would be a great start, but the rest should probably go as well. None of them really serve a purpose since we copy to ~/.local/share on startup. One of you folks actually using OpenSUSE should open a bug report against the Rosegarden package and get this moving in the right direction. Good luck. Ted. ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
I can confirm this. I have openSUSE too. Luckily I didn't install the
rosegarden package.
I downloaded the package (without install) and I can see all the rc
files would go to /usr/share/rosegarden/rc/
This is surely not a good idea ?
Philip
On 2/19/22 22:02, mark_at_yahoo via Rosegarden-devel wrote:
On 2/19/22 11:27 AM, Ted Felix wrote:
On 2/19/22 1:55 PM, mark_at_yahoo via Rosegarden-devel wrote:
The problem actually wasn't ~/.local/share/rosegarden/rc (that
directory didn't exist), but rather /usr/share/rosegarden/rc from my
distro's 17.12 installed package.
That seems really wrong. What distro is this?
openSUSE. I've been on it for over 20 years ("SuSE" in the early days
before the split into commercial SUSE Enterprise and openSUSE). I'm
currently stuck on the deprecated Leap 15.1 release (current is 15.3)
because I don't have time to deal with the usual breakages I get when
upgrading. That's also why I resist going to "Thunderbird", which is
their rolling release that most people are using these days -- it
seems to replace major breakage when upgrading the fixed releases with
continuous minor breakages. And for technical reasons which I still
think are somewhat specious, one can't use YaST2 (openSUSE's GUI
system administration tool, the best one I've ever found) with
Thunderbird. Every time I think about switching to a Debian- or Mint-
or Arch-based system with DEB packages I realize how much I've
invested in learning openSUSE/YaST2/zypper/RPM (yes, I've been on the
openSUSE mailing lists and forums and contributed fixes there) and
it's not worth the pain of changing. And CentOS and Fedora are RPM but
don't seem to have any/enough advantages to consider.
Sorry for the digression. Details for the openSUSE Rosegarden package
below. It installs everything into /usr, not /usr/local. I actually
like that for the separation (almost but not perfect) between the
distro's components in /usr and stuff I've built from source in
/usr/local. I realize there's linkages and dependencies that break
that plan -- like those I've just run into with Rosegarden -- but I
still contend that judicious use of
$PATH/rpath/$LD_LIBRARY_PATH/LinuxStandardBase/etc would allow
different versions of software to coexist without going to full-blown
Docker/Appimage/Flatpak/etc or virtual machines running different
distros. But mine is a minority opinion. For example, most RPMs are
non-relocatable, I guess because their creators don't want to deal
with the issues. I'm constantly doing `rpm2cpio foo.rpm | cpio -id
--no-absolute-filenames` to fake them out.
Oops, those were more digressions. Hope the 1% of this that actually
answered your question was helpful.
$ rpm -qil rosegarden | egrep '^/' | wc -l
905
$ rpm -qil rosegarden
Name : rosegarden
Version : 17.12
Release : lp151.3.66
Architecture: x86_64
Install Date: Wed 01 Jan 2020 07:02:48 PM PST
Group : Productivity/Multimedia/Sound/Midi
Size : 38881353
License : GPL-2.0+
Signature : RSA/SHA256, Sat 04 May 2019 01:56:18 AM PDT, Key ID
b88b2fd43dbdc284
Source RPM : rosegarden-17.12-lp151.3.66.src.rpm
Build Date : Sat 04 May 2019 01:52:30 AM PDT
Build Host : lamb54
Relocations : (not relocatable)
Packager : https://bugs.opensuse.org
Vendor : openSUSE
URL : http://www.rosegardenmusic.com/
Summary : Midi, Audio And Notation Editor
Description :
Rosegarden is a well-rounded audio and MIDI sequencer,
score editor, and general-purpose music composition and
editing environment. Rosegarden is an easy-to-learn,
attractive application that runs on Linux, ideal for
composers, musicians, music students, and small studio or
home recording environments.
This is a complete rewrite of the old 1.7.x series of
rosegarden and has many new features and enhancements.
See the changelog for details.
Distribution: openSUSE Leap 15.1
/usr/bin/rosegarden
/usr/share/applications/com.rosegardenmusic.rosegarden.desktop
/usr/share/doc/packages/rosegarden
/usr/share/doc/packages/rosegarden/AUTHORS
/usr/share/doc/packages/rosegarden/COPYING
/usr/share/doc/packages/rosegarden/README
/usr/share/icons/hicolor/128x128
...
/usr/share/man/man1/rosegarden.1.gz
/usr/share/metainfo
/usr/share/metainfo/rosegarden.appdata.xml
/usr/share/mime/packages/rosegarden.xml
/usr/share/pixmaps/rosegarden.xpm
/usr/share/rosegarden
/usr/share/rosegarden/CMakeLists.txt
/usr/share/rosegarden/appdata
/usr/share/rosegarden/appdata/rosegarden.appdata-old.xml
/usr/share/rosegarden/appdata/rosegarden.appdata.xml
/usr/share/rosegarden/autoload
/usr/share/rosegarden/autoload/autoload.rg
/usr/share/rosegarden/chords
/usr/share/rosegarden/chords/chords.xml
/usr/share/rosegarden/data.qrc
/usr/share/rosegarden/examples
/usr/share/rosegarden/examples/Brandenburg_No3-BWV_1048.rg
/usr/share/rosegarden/examples/Chopin-Prelude-in-E-minor-Aere.rg
...
/usr/share/rosegarden/fonts
/usr/share/rosegarden/fonts/LilyPond-feta-design20.pfa
/usr/share/rosegarden/fonts/LilyPond-feta-nummer-
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/19/22 10:55 AM, mark_at_yahoo via Rosegarden-devel wrote: Thanks again. Onward and upward from here. Hopefully not too many more stupid questions from me. I *will* write the feature request but want to experiment a bit more with stub implementations to clarify the details of what I'll be proposing. I've submitted a Feature Request ticket: https://sourceforge.net/p/rosegarden/feature-requests/500/ #500 Matrix Editor grid highlight modes Note that because I'm volunteering to do the implementation I tried to make myself the owner, but SourceForge wouldn't allow it. I guess only maintainers can be owners. I also wasn't sure if numerically higher or lower priority numbers are directly or inversely proportional to importance/priority, so I left that at the default 5. Hope I didn't do anything completely out of line on this, my first ticket. Rosegarden feature request number 500! That's gotta be a good omen, right? ;) ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/19/22 11:27 AM, Ted Felix wrote:
On 2/19/22 1:55 PM, mark_at_yahoo via Rosegarden-devel wrote:
The problem actually wasn't ~/.local/share/rosegarden/rc (that
directory didn't exist), but rather /usr/share/rosegarden/rc from my
distro's 17.12 installed package.
That seems really wrong. What distro is this?
openSUSE. I've been on it for over 20 years ("SuSE" in the early days
before the split into commercial SUSE Enterprise and openSUSE). I'm
currently stuck on the deprecated Leap 15.1 release (current is 15.3)
because I don't have time to deal with the usual breakages I get when
upgrading. That's also why I resist going to "Thunderbird", which is
their rolling release that most people are using these days -- it seems
to replace major breakage when upgrading the fixed releases with
continuous minor breakages. And for technical reasons which I still
think are somewhat specious, one can't use YaST2 (openSUSE's GUI system
administration tool, the best one I've ever found) with Thunderbird.
Every time I think about switching to a Debian- or Mint- or Arch-based
system with DEB packages I realize how much I've invested in learning
openSUSE/YaST2/zypper/RPM (yes, I've been on the openSUSE mailing lists
and forums and contributed fixes there) and it's not worth the pain of
changing. And CentOS and Fedora are RPM but don't seem to have
any/enough advantages to consider.
Sorry for the digression. Details for the openSUSE Rosegarden package
below. It installs everything into /usr, not /usr/local. I actually like
that for the separation (almost but not perfect) between the distro's
components in /usr and stuff I've built from source in /usr/local. I
realize there's linkages and dependencies that break that plan -- like
those I've just run into with Rosegarden -- but I still contend that
judicious use of $PATH/rpath/$LD_LIBRARY_PATH/LinuxStandardBase/etc
would allow different versions of software to coexist without going to
full-blown Docker/Appimage/Flatpak/etc or virtual machines running
different distros. But mine is a minority opinion. For example, most
RPMs are non-relocatable, I guess because their creators don't want to
deal with the issues. I'm constantly doing `rpm2cpio foo.rpm | cpio -id
--no-absolute-filenames` to fake them out.
Oops, those were more digressions. Hope the 1% of this that actually
answered your question was helpful.
$ rpm -qil rosegarden | egrep '^/' | wc -l
905
$ rpm -qil rosegarden
Name: rosegarden
Version : 17.12
Release : lp151.3.66
Architecture: x86_64
Install Date: Wed 01 Jan 2020 07:02:48 PM PST
Group : Productivity/Multimedia/Sound/Midi
Size: 38881353
License : GPL-2.0+
Signature : RSA/SHA256, Sat 04 May 2019 01:56:18 AM PDT, Key ID
b88b2fd43dbdc284
Source RPM : rosegarden-17.12-lp151.3.66.src.rpm
Build Date : Sat 04 May 2019 01:52:30 AM PDT
Build Host : lamb54
Relocations : (not relocatable)
Packager: https://bugs.opensuse.org
Vendor : openSUSE
URL : http://www.rosegardenmusic.com/
Summary : Midi, Audio And Notation Editor
Description :
Rosegarden is a well-rounded audio and MIDI sequencer,
score editor, and general-purpose music composition and
editing environment. Rosegarden is an easy-to-learn,
attractive application that runs on Linux, ideal for
composers, musicians, music students, and small studio or
home recording environments.
This is a complete rewrite of the old 1.7.x series of
rosegarden and has many new features and enhancements.
See the changelog for details.
Distribution: openSUSE Leap 15.1
/usr/bin/rosegarden
/usr/share/applications/com.rosegardenmusic.rosegarden.desktop
/usr/share/doc/packages/rosegarden
/usr/share/doc/packages/rosegarden/AUTHORS
/usr/share/doc/packages/rosegarden/COPYING
/usr/share/doc/packages/rosegarden/README
/usr/share/icons/hicolor/128x128
...
/usr/share/man/man1/rosegarden.1.gz
/usr/share/metainfo
/usr/share/metainfo/rosegarden.appdata.xml
/usr/share/mime/packages/rosegarden.xml
/usr/share/pixmaps/rosegarden.xpm
/usr/share/rosegarden
/usr/share/rosegarden/CMakeLists.txt
/usr/share/rosegarden/appdata
/usr/share/rosegarden/appdata/rosegarden.appdata-old.xml
/usr/share/rosegarden/appdata/rosegarden.appdata.xml
/usr/share/rosegarden/autoload
/usr/share/rosegarden/autoload/autoload.rg
/usr/share/rosegarden/chords
/usr/share/rosegarden/chords/chords.xml
/usr/share/rosegarden/data.qrc
/usr/share/rosegarden/examples
/usr/share/rosegarden/examples/Brandenburg_No3-BWV_1048.rg
/usr/share/rosegarden/examples/Chopin-Prelude-in-E-minor-Aere.rg
...
/usr/share/rosegarden/fonts
/usr/share/rosegarden/fonts/LilyPond-feta-design20.pfa
/usr/share/rosegarden/fonts/LilyPond-feta-nummer-design10.pfa
/usr/share/rosegarden/fonts/LilyPond-parmesan-design20.pfa
/usr/share/rosegarden/fonts/README
/usr/share/rosegarden/fonts/README.regenerated
...
/usr/share/rosegarden/library
/usr/share/rosegarden/library/AccessVirus.rgd
/usr/share/rosegarden/library/Alesis-DM10.r
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/19/22 11:09 AM, David Faure wrote: Yes, XDG_DATA_DIRS. It's the recommended way to hack on KDE apps installed into a different prefix. (I wrote QStandardPaths BTW) Good find, but setting an env var is much simpler, it'll keep your "git diff" clean :) Thanks, David. Will do. BTW, while desperately searching yesterday for any clues to solve my dilemma, I unavoidably ran across the extensive online references to your historical and continuing position in the Qt world. Even more so than the last time I mentioned it here, I'm somewhat embarrassed (of course in addition to being grateful) for your help with my newbie problems. It's an honor and privilege I'll try not to abuse. Somewhat similarly Ted: I started with your Linux MIDI Guide years ago and missed making the connection. And I probably just haven't yet found Philip's accomplishments outside of Rosegarden. Not sure I'm qualified to be hanging with this crowd, but I still hope to contribute something that will make your net time expenditure on me worthwhile. ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/19/22 1:55 PM, mark_at_yahoo via Rosegarden-devel wrote: The problem actually wasn't ~/.local/share/rosegarden/rc (that directory didn't exist), but rather /usr/share/rosegarden/rc from my distro's 17.12 installed package. That seems really wrong. What distro is this? Ted. ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On samedi 19 février 2022 19:55:33 CET mark_at_yahoo via Rosegarden-devel wrote: > On 2/19/22 6:13 AM, Philip Leishman wrote: > > On 2/19/22 15:02, Ted Felix wrote: > >> My guess is that you've got an .rc file in > >> > >> ~/.local/share/rosegarden/rc > >> > >> That will prevent the new one from being picked up. Rename any that > >> are in there to end in ".old" or whatever and then re-run rg. All the > >> correct menu items should reappear. I thought about this but since rosegarden doesn't appear to offer configurable shortcuts or toolbars (which is kind of the whole point of using kxmlgui BTW...), nothing should create a file in ~/.local/share/rosegarden/rc. > The problem actually wasn't ~/.local/share/rosegarden/rc (that directory > didn't exist), but rather /usr/share/rosegarden/rc from my distro's > 17.12 installed package. It only took 5 seconds to figure that out, > mkdir ~/.local/share/rosegarden/rc, and copy my development tree's > matrix.rc into there. Voila! Ah! Well done. > Is there a way to configure something like a compiled-in or > runtime-settable $QT_SEARCH_PATH to keep the RG executable from using > /usr/share? Yes, XDG_DATA_DIRS. Excluding /usr/share from XDG_DATA_DIRS is generally not a good idea, because e.g. mimetype definitions are only found there, so the app would be missing them (e.g. for the file dialog). However you can just set XDG_DATA_DIRS to YOUPREFIX/share:/usr/share and all will be fine. It's the recommended way to hack on KDE apps installed into a different prefix. The rc files installed into your install prefix will have precedence over those installed in /usr. > Wait ... got it! Searched the docs, found QStandardPaths (I wrote QStandardPaths BTW) > searched the code, found ResourceFinder.cpp -- all good now. (I'll > restore the original "prefixes" variable's static initializer in > ResourceFinder::getSystemResourcePrefixList() before submitting any > merge requests.) Good find, but setting an env var is much simpler, it'll keep your "git diff" clean :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/19/22 6:13 AM, Philip Leishman wrote: On 2/19/22 15:02, Ted Felix wrote: My guess is that you've got an .rc file in ~/.local/share/rosegarden/rc That will prevent the new one from being picked up. Rename any that are in there to end in ".old" or whatever and then re-run rg. All the correct menu items should reappear. Ah !!! That will be the problem. Gentlemen, gentlemen ... I cannot thank you enough! I spent 6 hours yesterday trying to figure out why nothing I changed in MatrixView.cpp and/or matrix.rc had any effect whatsoever. Ritual suicide was beginning to look like my best option. The problem actually wasn't ~/.local/share/rosegarden/rc (that directory didn't exist), but rather /usr/share/rosegarden/rc from my distro's 17.12 installed package. It only took 5 seconds to figure that out, mkdir ~/.local/share/rosegarden/rc, and copy my development tree's matrix.rc into there. Voila! Is there a way to configure something like a compiled-in or runtime-settable $QT_SEARCH_PATH to keep the RG executable from using /usr/share? Wait ... got it! Searched the docs, found QStandardPaths, searched the code, found ResourceFinder.cpp -- all good now. (I'll restore the original "prefixes" variable's static initializer in ResourceFinder::getSystemResourcePrefixList() before submitting any merge requests.) Yes I'm a Qt newbie, and yes I probably should learn it before trying to implement my feature request. But I claim I do understand software (see fixes above) and still hope that a lot of what I'm trying to contribute can be done by using code that already exists in RG as examples. I did break down and go through a bunch of Qt tutorials yesterday, but I don't think I would have found the problem you've solved for me without several weeks of intensive training in Qt. Thanks again. Onward and upward from here. Hopefully not too many more stupid questions from me. I *will* write the feature request but want to experiment a bit more with stub implementations to clarify the details of what I'll be proposing. ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/19/22 15:02, Ted Felix wrote: On 2/18/22 1:18 PM, mark_at_yahoo via Rosegarden-devel wrote: Is the intent to add a "triad/black-keys" control to the GUI to allow switching it on the fly (for users who liked it the old way)? Yes. We try to preserve the old behavior in some way that the user can control it. If changes are more extreme, then they do not become the default. The old approach is preserved as the default and the new approach has to be enabled in some way. The highlight mode is switchable in the matrix editor under view->highlight. A new highlight mode should be selectable there. In my builds of both 21.12 and master/HEAD from the SourceForge repository (local tree current as of yesterday) the Matrix Editor's "View" menu just has: View Grid > -- Toolbars > Rulers > My guess is that you've got an .rc file in ~/.local/share/rosegarden/rc That will prevent the new one from being picked up. Rename any that are in there to end in ".old" or whatever and then re-run rg. All the correct menu items should reappear. Ah !!! That will be the problem. Ted. ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/18/22 1:18 PM, mark_at_yahoo via Rosegarden-devel wrote: Is the intent to add a "triad/black-keys" control to the GUI to allow switching it on the fly (for users who liked it the old way)? Yes. We try to preserve the old behavior in some way that the user can control it. If changes are more extreme, then they do not become the default. The old approach is preserved as the default and the new approach has to be enabled in some way. The highlight mode is switchable in the matrix editor under view->highlight. A new highlight mode should be selectable there. In my builds of both 21.12 and master/HEAD from the SourceForge repository (local tree current as of yesterday) the Matrix Editor's "View" menu just has: View Grid > -- Toolbars > Rulers > My guess is that you've got an .rc file in ~/.local/share/rosegarden/rc That will prevent the new one from being picked up. Rename any that are in there to end in ".old" or whatever and then re-run rg. All the correct menu items should reappear. Ted. ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/18/22 2:38 PM, Philip Leishman wrote:
Very mysterious !!!
Yes indeed.
You should see in the code:
in data/rc/matrix.rc - the definition of the menu:
&Highlight
and in src/gui/editors/matrix/MatrixView.cpp - the creation of the actions:
createAction("show_note_names", SLOT(slotShowNames()));
createAction("highlight_black_notes", SLOT(slotHighlight()));
createAction("highlight_triads", SLOT(slotHighlight()));
// add the highlight actions to an ActionGroup
QActionGroup *ag = new QActionGroup(this);
ag->addAction(findAction("highlight_black_notes"));
ag->addAction(findAction("highlight_triads"));
Seems the same in the sources I have.
The only thing a bit unusual is the QActionGroup.
Another place this is used is in the notation editor - Can you see the
note font and size menu items at the top of the view menu ?
Yes. I guess that makes it even worse (why working there and not in
Matrix Editor)?
Something to do with Qt version: 5.9.7 ???
Only thing I found in a quick comparison between:
https://doc.qt.io/qt-5/qactiongroup.html
https://doc.qt.io/archives/qt-5.9/qactiongroup.html
is that the 5.9 docs explicitly state that QActionGroup inherits
objectName from QObject vs current (5.15??) which doesn't mention it.
Must be a change in the documentation style because they both inherit
QObject.
Very strange
Sigh, yes. I'll keep working on it. BTW, I also did the following, but
I'm guessing none of the tests check GUI correctness (very difficult to
do) much less this specific case.
$ make clean
$ cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_TESTING=ON
$ make
$ make test
Running tests...
Test project /usr/local/x/rosegarden/unbacked/21.12/rosegarden-git/build
Start 1: realtime
1/10 Test #1: realtime . Passed0.03 sec
Start 2: accidentals
2/10 Test #2: accidentals .. Passed0.02 sec
Start 3: segmenttransposecommand
3/10 Test #3: segmenttransposecommand .. Passed0.02 sec
Start 4: test_notationview_selection
4/10 Test #4: test_notationview_selection .. Passed1.04 sec
Start 5: transpose
5/10 Test #5: transpose Passed0.02 sec
Start 6: reference_segment
6/10 Test #6: reference_segment Passed0.02 sec
Start 7: utf8
7/10 Test #7: utf8 . Passed0.02 sec
Start 8: testmisc
8/10 Test #8: testmisc . Passed0.91 sec
Start 9: convert
9/10 Test #9: convert .. Passed0.51 sec
Start 10: lilypond_export_test
10/10 Test #10: lilypond_export_test . Passed5.12 sec
100% tests passed, 0 tests failed out of 10
Total Test time (real) = 7.72 sec
___
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/18/22 22:14, mark_at_yahoo via Rosegarden-devel wrote: On 2/18/22 11:54 AM, Philip Leishman wrote: On 2/18/22 19:18, mark_at_yahoo via Rosegarden-devel wrote: The highlight mode menu was in 21.12 ! Make sure you are using the git repository. We used to be on SVN but switched to git some time back. The latest git will also have the highlight menu. It's a complete mystery, Philip. :( Yes, I'm using git. Just to double-check, I did a fresh clone of the SourceForge repository and built 21.12 -- and got the same results (no hilight menu). I also built master and again no joy, although note I had to make a small patch for my Qt5 5.9.7, as per https://sourceforge.net/p/rosegarden/mailman/rosegarden-devel/thread/88726f65-8f9f-0b19-50b0-a1a437a8deea%40tedfelix.com/#msg37612478 and: Activity for Rosegarden: 1 day ago Ted Felix Ted Felix committed [e62e6e] Use QString::endsWith(), even better (It also needs a bunch of startsWith() calls. I'll send Ted a patch. Not his fault because the bug doesn't show up with later Qt5 versions like he uses.) Details of my builds below in case you're interested. I'll keep hacking on it but I'm clueless for right now. May I suggest you create a new feature ticket for this. We can continue the discussion in the ticket. Excellent suggestion. I hadn't done so because SourceForge was telling me I didn't have permissions to create tickets (my bad, I wasn't logged in) and also I'm new here and don't know your policies (some projects like to have mailing list discussions before a user files a ticket). I'll create one, but I'm including my build logs here because they're probably not relevant to the ticket. Again, thanks for your help, and if you have the time and see anything I've done wrong below, please tell me. Build log: $ git clone https://git.code.sf.net/p/rosegarden/git rosegarden-git Cloning into 'rosegarden-git'... remote: Enumerating objects: 159806, done. remote: Counting objects: 100% (159806/159806), done. remote: Compressing objects: 100% (26792/26792), done. remote: Total 159806 (delta 136140), reused 155823 (delta 132695) Receiving objects: 100% (159806/159806), 138.48 MiB | 43.23 MiB/s, done. Resolving deltas: 100% (136140/136140), done. $ ls rosegarden-git/ $ cd rosegarden-git $ git checkout 21.12 Note: switching to '21.12'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at 5f68aeae6 Updates for version 21.12 $ mkdir build $ cd build $ cmake .. -- The C compiler identification is GNU 7.5.0 -- The CXX compiler identification is GNU 7.5.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc - works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ - works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") -- Checking for module 'alsa>=0.9' -- Found alsa, version 1.1.5 -- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11") -- Found X11: /usr/include -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Checking for module 'liblo>=0.7' -- Found liblo, version 0.28 -- Checking for module 'lrdf>=0.2' -- Found lrdf, version 0.5.0 -- Checking for module 'fftw3f>=3.0.0' -- Found fftw3f, version 3.3.6-pl2 -- Checking for module 'samplerate>=0.1.2' -- Found samplerate, version 0.1.9 -- Checking for module 'sndfile>=1.0.16' -- Found sndfile, version 1.0.28 -- Checking for module 'jack' -- Found jack, version 1.9.12 -- The following features have been enabled: * ALSA, Alsa library (Advanced Linux Sound Architecture), used for MIDI support * SNDFILE, Better support for WAV files * JACK, Library for accessing the JACK server (http://jackaudio.org). * LIRCCLIENT, The LIRC client library, for remote control support -- The following REQUIRED packages have been found: * Qt5Core *
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/18/22 11:54 AM, Philip Leishman wrote: On 2/18/22 19:18, mark_at_yahoo via Rosegarden-devel wrote: The highlight mode menu was in 21.12 ! Make sure you are using the git repository. We used to be on SVN but switched to git some time back. The latest git will also have the highlight menu. It's a complete mystery, Philip. :( Yes, I'm using git. Just to double-check, I did a fresh clone of the SourceForge repository and built 21.12 -- and got the same results (no hilight menu). I also built master and again no joy, although note I had to make a small patch for my Qt5 5.9.7, as per https://sourceforge.net/p/rosegarden/mailman/rosegarden-devel/thread/88726f65-8f9f-0b19-50b0-a1a437a8deea%40tedfelix.com/#msg37612478 and: Activity for Rosegarden: 1 day ago Ted Felix Ted Felix committed [e62e6e] Use QString::endsWith(), even better (It also needs a bunch of startsWith() calls. I'll send Ted a patch. Not his fault because the bug doesn't show up with later Qt5 versions like he uses.) Details of my builds below in case you're interested. I'll keep hacking on it but I'm clueless for right now. May I suggest you create a new feature ticket for this. We can continue the discussion in the ticket. Excellent suggestion. I hadn't done so because SourceForge was telling me I didn't have permissions to create tickets (my bad, I wasn't logged in) and also I'm new here and don't know your policies (some projects like to have mailing list discussions before a user files a ticket). I'll create one, but I'm including my build logs here because they're probably not relevant to the ticket. Again, thanks for your help, and if you have the time and see anything I've done wrong below, please tell me. Build log: $ git clone https://git.code.sf.net/p/rosegarden/git rosegarden-git Cloning into 'rosegarden-git'... remote: Enumerating objects: 159806, done. remote: Counting objects: 100% (159806/159806), done. remote: Compressing objects: 100% (26792/26792), done. remote: Total 159806 (delta 136140), reused 155823 (delta 132695) Receiving objects: 100% (159806/159806), 138.48 MiB | 43.23 MiB/s, done. Resolving deltas: 100% (136140/136140), done. $ ls rosegarden-git/ $ cd rosegarden-git $ git checkout 21.12 Note: switching to '21.12'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at 5f68aeae6 Updates for version 21.12 $ mkdir build $ cd build $ cmake .. -- The C compiler identification is GNU 7.5.0 -- The CXX compiler identification is GNU 7.5.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc - works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ - works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") -- Checking for module 'alsa>=0.9' -- Found alsa, version 1.1.5 -- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11") -- Found X11: /usr/include -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Checking for module 'liblo>=0.7' -- Found liblo, version 0.28 -- Checking for module 'lrdf>=0.2' -- Found lrdf, version 0.5.0 -- Checking for module 'fftw3f>=3.0.0' -- Found fftw3f, version 3.3.6-pl2 -- Checking for module 'samplerate>=0.1.2' -- Found samplerate, version 0.1.9 -- Checking for module 'sndfile>=1.0.16' -- Found sndfile, version 1.0.28 -- Checking for module 'jack' -- Found jack, version 1.9.12 -- The following features have been enabled: * ALSA, Alsa library (Advanced Linux Sound Architecture), used for MIDI support * SNDFILE, Better support for WAV files * JACK, Library for accessing the JACK server (http://jackaudio.org). * LIRCCLIENT, The LIRC client library, for remote control support -- The following REQUIRED packages have been found: * Qt5Core * Qt5Gui * Qt5Widgets * Qt5Xml * Qt5Net
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/18/22 19:18, mark_at_yahoo via Rosegarden-devel wrote: On 2/18/22 3:14 AM, Philip Leishman wrote: On 2/18/22 10:00, mark_at_yahoo via Rosegarden-devel wrote: The old triad version respected key changes and also major-vs-minor, re-aligning the tonic triad's root to the new key and switching the third between natural and flat. The black key mode really relates to the black keys on the piano keyboard which is, of course, independent of the key of the composition. I think you are talking about a new feature - "highlight scale". I'm confused because it looked to me that black key mode completely replaced the old key-dependent root/third/fifth hilighting, so I felt I was proposing restoring an old feature rather than adding a new one. But I understand it being key-independent if instead if it's intended solely as a visual aid, expanding the piano keyboard graphic on the left of the ME across the whole grid. Piano players practice everything (scales, chords, compositions) in all 12 keys so they're used to implicitly conceptualizing how a given key/scale/mode falls across the white and black keys. That's why beginners like me have a hard time playing piano and why I'd like a "highlight scale" feature to help. I also think it might aid users composing for other and/or multiple instruments, but any real composer is 99% certain to also be an at least competent pianist, so maybe it's a specious use-case. I'll explain the reason for my confusion below, in the part about hilight mode being switchable. This would be identical to the black key mode if we are in C major. Yes, absolutely. If we were in, for example, A major a "highlight scale" mode would highlight the notes of that scale - A, B, C#, D, E, F#, G# with a special highlight for the A. Yes, with the rationale for the special hilight I explained. Is the intent to add a "triad/black-keys" control to the GUI to allow switching it on the fly (for users who liked it the old way)? The highlight mode is switchable in the matrix editor under view->highlight. A new highlight mode should be selectable there. My confusion ... In my builds of both 21.12 and master/HEAD from the SourceForge repository (local tree current as of yesterday) the Matrix Editor's "View" menu just has: View Grid > -- Toolbars > Rulers > I can't find a "highlight mode" option in any sub-menus there, nor anyplace else I've searched in RG's interface. Is there some cmake/make build option I'm missing to enable it? Could the feature not have made it into the master branch? The highlight mode menu was in 21.12 ! Make sure you are using the git repository. We used to be on SVN but switched to git some time back. The latest git will also have the highlight menu. Regarding dynamically switching the hilight scheme in general, I realized after my last post that adding a pseudo-scale of "Tonic triad" (if I succeed with the scale/mode enhanced design) would eliminate the need for a separate "Old triad hilight" option. (There could also be "Tonic seventh" for completeness.) Then also an "Absolute" vs "Key relative" switch so that users who want can have the black keys stay locked to the piano keyboard instead of moving when in a key/tonic other than C. So Setting the key to, say harmonic minor would not affect the key signature but would be visible in the new "highlight scale" mode. Correct. Are there any other places where this would have an effect ? Possibly, and I thought about that but left it out because my post was already too long -- like this new one's becoming. ;) I haven't searched the codebase for it, but is the key+major/minor, as set in this "Segment -> Add Key Change..." dialog that we're talking about, locked one-to-one with an internal code object that contains just that data? Or is it abstracted a bit more, with the chance to add some translation in between? There must be some further metadata somewhere because just knowing, for instance, that there's an F# in the current key doesn't tell you that it should be placed in the key signature on the top line of the treble staff instead of the lowest space. Of course this doesn't affect the Matrix Editor but does the Notation one. Adding arbitrary scales presents a little more difficulty although I don't think it's insurmountable. What is the key signature of a piece that's in the Eb Minor Pentatonic? I think that one's easy (it's the same as normal Eb Minor), but what about Eb Blues, or Eb Whole Tone? There's no standard major or minor key signature that has the correct sharps or flats for those, and I don't know enough music theory to give an answer. But I think it could be worked around, either by semi-arbitrarily assigning "major-like" vs "minor-like" to the "weird" scales and going with the standard key signatures for them, or just punting the whole problem and rendering them as C Major with no flats or sharps, with accidentals in any measure th
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
On 2/18/22 3:14 AM, Philip Leishman wrote: On 2/18/22 10:00, mark_at_yahoo via Rosegarden-devel wrote: The old triad version respected key changes and also major-vs-minor, re-aligning the tonic triad's root to the new key and switching the third between natural and flat. The black key mode really relates to the black keys on the piano keyboard which is, of course, independent of the key of the composition. I think you are talking about a new feature - "highlight scale". I'm confused because it looked to me that black key mode completely replaced the old key-dependent root/third/fifth hilighting, so I felt I was proposing restoring an old feature rather than adding a new one. But I understand it being key-independent if instead if it's intended solely as a visual aid, expanding the piano keyboard graphic on the left of the ME across the whole grid. Piano players practice everything (scales, chords, compositions) in all 12 keys so they're used to implicitly conceptualizing how a given key/scale/mode falls across the white and black keys. That's why beginners like me have a hard time playing piano and why I'd like a "highlight scale" feature to help. I also think it might aid users composing for other and/or multiple instruments, but any real composer is 99% certain to also be an at least competent pianist, so maybe it's a specious use-case. I'll explain the reason for my confusion below, in the part about hilight mode being switchable. This would be identical to the black key mode if we are in C major. Yes, absolutely. If we were in, for example, A major a "highlight scale" mode would highlight the notes of that scale - A, B, C#, D, E, F#, G# with a special highlight for the A. Yes, with the rationale for the special hilight I explained. Is the intent to add a "triad/black-keys" control to the GUI to allow switching it on the fly (for users who liked it the old way)? The highlight mode is switchable in the matrix editor under view->highlight. A new highlight mode should be selectable there. My confusion ... In my builds of both 21.12 and master/HEAD from the SourceForge repository (local tree current as of yesterday) the Matrix Editor's "View" menu just has: View Grid > -- Toolbars > Rulers > I can't find a "highlight mode" option in any sub-menus there, nor anyplace else I've searched in RG's interface. Is there some cmake/make build option I'm missing to enable it? Could the feature not have made it into the master branch? Regarding dynamically switching the hilight scheme in general, I realized after my last post that adding a pseudo-scale of "Tonic triad" (if I succeed with the scale/mode enhanced design) would eliminate the need for a separate "Old triad hilight" option. (There could also be "Tonic seventh" for completeness.) Then also an "Absolute" vs "Key relative" switch so that users who want can have the black keys stay locked to the piano keyboard instead of moving when in a key/tonic other than C. So Setting the key to, say harmonic minor would not affect the key signature but would be visible in the new "highlight scale" mode. Correct. Are there any other places where this would have an effect ? Possibly, and I thought about that but left it out because my post was already too long -- like this new one's becoming. ;) I haven't searched the codebase for it, but is the key+major/minor, as set in this "Segment -> Add Key Change..." dialog that we're talking about, locked one-to-one with an internal code object that contains just that data? Or is it abstracted a bit more, with the chance to add some translation in between? There must be some further metadata somewhere because just knowing, for instance, that there's an F# in the current key doesn't tell you that it should be placed in the key signature on the top line of the treble staff instead of the lowest space. Of course this doesn't affect the Matrix Editor but does the Notation one. Adding arbitrary scales presents a little more difficulty although I don't think it's insurmountable. What is the key signature of a piece that's in the Eb Minor Pentatonic? I think that one's easy (it's the same as normal Eb Minor), but what about Eb Blues, or Eb Whole Tone? There's no standard major or minor key signature that has the correct sharps or flats for those, and I don't know enough music theory to give an answer. But I think it could be worked around, either by semi-arbitrarily assigning "major-like" vs "minor-like" to the "weird" scales and going with the standard key signatures for them, or just punting the whole problem and rendering them as C Major with no flats or sharps, with accidentals in any measure that needs them. There's likely some other solutions, but again, it might require a separation of the scale/mode used for hilighting vs that for notation rendering. Certainly not a stupid feature. In
Re: [Rosegarden-devel] Bug and/or feature request for new Matrix Editor black key highlights
Hi, On 2/18/22 10:00, mark_at_yahoo via Rosegarden-devel wrote: The new (in 21.12??) black key highlighting in the Matrix Editor is awesome! Wanting something like this instead of the old triad highlights was one of the two missing features in 17.12 that prompted me to look into the source code, so imagine my surprise when I found it had already been implemented. Not that I can imagine anyone being interested my motivations. ;) What might be of interest is that IMO there's a bug (or missing feature) in the new highlighting. The old triad version respected key changes and also major-vs-minor, re-aligning the tonic triad's root to the new key and switching the third between natural and flat. I think the new black key highlighting should do something similar, both aligning to the tonic of the current key, and highlighting "black keys" that are the accidentals in that key depending on if it's major or minor. I'm sure that's clear, but just to beat a dead horse I'm saying tonic plus 1,3,6,8,10 semitones in major keys, and tonic plus 1,4,6,9,11 semitones for minor keys. The black key mode really relates to the black keys on the piano keyboard which is, of course, independent of the key of the composition. I think you are talking about a new feature - "highlight scale". This would be identical to the black key mode if we are in C major. I also think that the tonic needs to be highlighted differently than the other non-black/non-tonic keys. It was fine to have it the same with the triad highlighting because the gap between the fifth and the next tonic made it obvious, but with all the non-accidental scale notes the same it's too cluttered and not immediately apparent. If we were in, for example, A major a "highlight scale" mode would highlight the notes of that scale - A, B, C#, D, E, F#, G# with a special highlight for the A. I have a partly working implementation of the all the above, and will submit a merge request for review, hopefully in a day or two. It's a fairly easy change, but I'd also like to be presumptuous and do a little cleanup in MatrixScene.cpp at the same time. On that subject, it seems like the current black key highlighting code is a bit preliminary. For instance, the triad highlighting is still in there, settable in the user's configuration (I think. I'm not familiar with that subsystem). Is the intent to add a "triad/black-keys" control to the GUI to allow switching it on the fly (for users who liked it the old way)? The highlight mode is switchable in the matrix editor under view->highlight. A new highlight mode should be selectable there. As a pure feature request, I'd also like to add user selectable scales and modes to the Segment -> Add Key Change... dialog that (I assume) is shared between the Matrix and Notation Editors. Instead of the current "Major,Minor" pulldown menu. I'd like to see two: One for scales with Major, Natural Minor, Harmonic Minor, Melodic Minor, Minor Pentatonic, Major Pentatonic, Blues, Whole Tone, Whole/Half Tone ... the list can go on forever, see sites like https://allthescales.org/. Or maybe have a "Custom" entry with additional buttons to select any subset of the 12TET notes. (Yes, melodic minor is weird. Just the ascending version because descending is same as natural and I can't figure out how it could be dynamically switched between the two.) So Setting the key to, say harmonic minor would not affect the key signature but would be visible in the new "highlight scale" mode. Are there any other places where this would have an effect ? And then also a Mode menu: Ionian (default), Dorian, Phrygian, Lydian, Mixolydian, Aeolian, and Locrian. Yes, Major+Aeolian is the same as Minor+Ionian, but I don't think the redundancy is a problem, and despite being an extremely unskilled/amateur musician my understanding is that is does make sense to talk about modes of other-than-major scales. Also yes, there's things like Aeolian and Locrian not making sense for the pentatonic scales because there's not enough notes in them, but that could be handled by forcing the offset back within range or just wrapping around modulo scale size, with or without a warning message in either case. Unless I get a response of "This is the stupidest feature request we've ever heard", I'll try to implement it and submit for review and possible approval. That will take a bit longer as my Qt-fu (adding menus and rearranging dialogs) is pretty weak, but the actual algorithmic code for computing in-vs-out notes of scales+modes is trivial (and something I've done many times before in simple ad-hoc MIDI utilities that I've written over the past few years for my own use). Certainly not a stupid feature. In my opinion you can go ahead with this. Philip ___ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel _
