> On 31.03.2015, at 19:51, Tom Breton (Tehom) <[email protected]> wrote: > >> >> 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. > > That will probably be hard. > > The things that stay open until they are closed are editors, like, the > notation editor. > > Getting an editor to talk to another editor is tricky. Editors can work > on the same segment simultaneously, but they do it indirectly: each one > sees and reacts to all the changes, but they typically don't tell each > other to do anything. Co-ordinating two editors sounds tricky. > > It might make more sense to store the parallels in some global object and > dispatch commands that navigate them, like "Next Parallel", in the > notation editor itself. That's probably easier than co-ordinating two > editors, or getting a dialog to stay open across commands without > problems. That's what I'd recommend.
Ok, thought about that, but it seems that the current way the thing is organized works ok, unless I miss something. Generally I do not think about the checker dialog as an editor, for me it's just something that indicates issues in the content of the notation editor. It does not change the music (ok, technically yes, because it sets/resets a property of an event, but it does not really change what is played). Also the parent of the dialog is the notationView, so if the notation editor is closed, the checker dialog is closed as well. The dialog gets the this-pointer of the notationView upon creation, so this pointer is always valid as long as the dialog exists. If the users starts the search, all information is built from that pointer (list of staves, list of segments). So during search the content that the checker uses is the current content of the notation editor. When the search is finished a list is printed in a textBrowser that shows all found parallels with bar and track. The user can click on a line, upon that the pointer in the notation editor is positioned to the current parallel and the user can edit. Movement, insertion and deletion of notes will not interfere with the current list of segments and staves and the absolute time of the not edited notes. So the list in the dialog stays ok, with the exception of the currently edited parallel, but this I consider intended behavior. If the users decides to do a bigger change, like removing or adding segments to the notation editor, this of course may destroy the link between event, segment and stave. However, I consider this tolerable. I think this situation is comparable to do programming in an integrated development environment like eclipse or others. If you compile your project you get a list of error messages in the console. If you click on such an error, you usually get transported in the editor to the corresponding line in the source file. This works as long as you do not insert or delete lines. If you insert or delete a line, clicking on the later error messages will point you to the wrong line. In that case I usually just recompile, then the line numbers are ok again. So, if the user really changes the segments in the notation editor during parallels checking, he/she just has to click on restart to get an updated list of parallels. Again, I think this effort is tolerable. Advantage is that most of the code is encapsulated in the dialog and there not so much interference with the source of notationView (should make maintenance easier) Anyway, if I put the parallels as an object into the notation view it would be hard to decide what to do if the user then changes the segments there, how would we reassign the parallels to the new segment list? In the end I think the search anyway would have to be redone... > Now I can't help thinking, "What about parallels in segments that the > notation editor isn't visiting?" I suspect you have a plan to deal with > those. Actually, this is a point which I thought about from the beginning, when I tried to figure out where to put the menu entry. For me the checker is something that helps me to look in a certain way at the music I'm currently working on by coloring problematic notes. So for me it belongs to the notes I currently want to see/check/work on. This means that it should go to the notation editor. #disclaimer: the next two paragraphs are under the assumption of writing music in the period of baroque and a bit later on where you have those strong issues about parallels in church music... When I work on a piece for organ, I usually have five tracks. One for each voice and one in which I note down the current harmonies in form of basic chords. (remember, I'm a beginner in terms of writing music, so I still often need this kind of notation as a reminder for myself to not get lost). This track is usually muted and goes on only sometimes when, e.g., checking harmonic progression. So usually this should not take part in parallels checking. Easy solution is to open only the four real voices and start the checker. Another piece I'm working on is a mass for SATB, accompanied by four string voices, two trumpets, oboe, bassoon and kettle drums. Here the first point is to get SATB right. So I open only those four voices, check them for parallels and try to get them right. In the next iteration more voices are added and checked. In the end the kettle drums never take part in the checking process as this just makes no sense, so one can just leave them out of the notation editor when doing the check. So the user is responsible to load all the segments into the notation editor in which he/she wants to check and can leave out the others. I hope this all makes sense somehow... Best 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
