> On 29.03.2015, at 03:09, Tom Breton (Tehom) <[email protected]> wrote:
>
>>
>
> When it returns, we check whether it succeeded or was aborted. If it
> succeeded, we're still not done. In fact, we haven't *done* anything at
> that point.
>
> Now we extract the values from the dialog and pass them to a command,
> which is another object. That has to be executed too, but then you're
> done.
>
> There are all sorts of exceptions and variant cases around, so don't take
> this as an absolute rule of how RG always does things.
Ok, thanks for the info. I will have to think about that, as the checker stays
open all the time until the users closes it.
This reflects the intended workflow as I would like it.
The idea is:
write music
then, at some point, start checking for parallels by opening the dialog and
clicking start
click through the resulting list & edit notes according to mood&frustration
level
restart search
The last two steps repeat until the user decides to stop and closes the dialog.
For me the advantage of keeping the dialog open is the point that you do not
have to restart the search after editing each parallel as you can edit your
music while the dialog is open. So you can take care of a bunch of parallels in
a row while the list is still clickable. How to integrate this into the
settings concept I will think about a bit later as I found a more pressing
issue:
I'm a real beginner in writing music, so I frequently take lessons from a local
church musician. During that we go through my music and he gives me all kinds
of hints and tips and theory. After the lesson I will work on the stuff and
usually, before the next lesson, I'll mail him a pdf created through lilypond,
so that he can have a look in advance to make the lesson hours more effective,
as working full time unfortunately does not go well with music making in terms
of lifetime 8-(((
Also my working style is pretty much 'paper affine'. So I like to print out my
stuff and have a look at it not on screen but in a real paper (yes, I know, I'm
a dinosaur, but that's the way it is... (and you can always use something as
flexible as a pencil...))
So, I'd like to be able to include the color of the parallel notes into the
lilypond source file. It seems that rosegarden does not export note colors at
the moment, unless I overlooked it somehow.
I've looked around in the lilypond exporter. I do not really understand all the
issues, but it seems that LilyPondExporter::writePitch writes out the lilypond
representation of the current note to the current stream. I added a check
whether the note is member of a parallel to this. If yes, it prints out the
string "\tweak color #magenta" just before the note. This works for me in the
files that I checked. However, as I do not fully understand the logic, the
crucial question is, whether this may break something.
Code looks like this (for the moment I marked all my changes with "// AL"):
void
LilyPondExporter::writePitch(const Event *note,
const Rosegarden::Key &key,
std::ofstream &str)
{
// Note pitch (need name as well as octave)
// It is also possible to have "relative" pitches,
// but for simplicity we always use absolute pitch
// 60 is middle C, one unit is a half-step
long pitch = 60;
note->get
<Int>(PITCH, pitch);
Accidental accidental = Accidentals::NoAccidental;
note->get
<String>(ACCIDENTAL, accidental);
// format of LilyPond note is:
// name + octave + (duration) + text markup
// calculate note name and write note
std::string lilyNote;
lilyNote = convertPitchToLilyNote(pitch, accidental, key);
// AL
//
// handle parallel color
if (note->has(BaseProperties::MEMBER_OF_PARALLEL)) {
bool memberOfParallel;
note->get<Bool>(BaseProperties::MEMBER_OF_PARALLEL, memberOfParallel);
if (memberOfParallel) {
str << "\\tweak color #magenta ";
}
}
str << lilyNote;
}
So, would this be the correct way of marking the parallels in color? Or should
I go for something else?
Thanks in advance
Armin
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
