From: Chris C. <ca...@al...> - 2002-06-27 09:09:31
|
Hans Kieserman <hki...@ma...> writes: > > I HATE the geocrawler mail archive interface argh - haven't > been able to find the old grace notes discussion Well, you don't have to use the geocrawler interface -- there's a SourceForge archive too, which is also pretty bad but at least has a search function. But I think your basic problem is that there hasn't actually ever _been_ a very informative discussion about grace notes. > Admittedly high-level, how about > 1) add grace note boolean flag on note Events I'm certainly happy to flag grace notes with some sort of property; I don't particularly feel the need to make them "groups" in the way that beamed groups are. This does mean in principle it wouldn't be possible to have more than one set of grace notes happening at once on a single staff; in theory you can have two beamed groups going on at once (one with stems up, the other with stems down) but our renderer doesn't actually deal with those correctly yet anyway. > 2) add menu item to convert selected notes to grace notes > [...] > 3) for playback/matrix view, treat as "normal" notes but subtract > length of grace note from subsequent (tied) note I think parts 2 and 3 are not all that simple. But for the moment let's ignore part 2 (how to make grace notes using the GUI) and concentrate on how to represent them sensibly. Remember, notes don't just "follow" one another, they have individual start times and durations and can overlap. Also we generally prefer to store values that make immediate sense for performance rather than do complex conversions at performance time; for grace notes there's a complication in that we might ultimately want to allow the option of performing them in more than one way, but I feel that we should aim to make sure performance was "not too bad" even if the performance code knew nothing about grace notes. I can think of quite a few possibilities. For descriptive purposes let's imagine a note of duration 960 (crotchet) preceded by two short grace notes of duration 240 each (semiquavers). This series of notes starts at time zero. (a) The "main" note has its normal start time and duration (0 and 960). The grace notes start at 0 and 240, each with duration 240. (They also have a small negative subordering value, to ensure the first one appears before the main note.) The grace notes are marked with a boolean grace property. Rendering and performance become rather complicated because the second grace note (rendered and performed before the main note) appears after it in the segment. Hence I don't like this option. (b) The grace notes are at 0 and 240 with duration 240, and the main note is at 480 with duration 960. The grace notes are marked with a boolean grace property. (This appears to be what you're suggesting?) Performance is a slightly complicated by having to manipulate the duration of the main note. Editing and rendering might be slightly complicated by the way the main note now overlaps the note that follows it, appearing to be in some kind of arpeggiated chord. The practical difficulties are probably fairly small, but I don't quite like the feel of this one -- I feel it's more important to keep the duration of the main note "correct" in the context of the surrounding notes than to make it only make sense when you take the grace notes into account. (c) The grace notes are at 0 and 240 with duration 240, and the main note is at 480 with duration 480. The grace notes are marked with a boolean grace property. Performance is trivial if the representation happens to coincide with how you like to play your grace notes. Rendering and editing are weird because you have to manipulate the duration of the main note constantly taking into account the grace notes. (d) The notes are all at 0; the grace notes have duration 240, with some other property to indicate the order in which they're played. The main note has duration 960. Kind of weird; not sure if there are any real advantages to this. (e) The notes are all at 0; the grace notes have duration 0, with some other properties (perhaps we can be clever with subordering) to indicate the order in which they're played, and a property for the visual duration of the notes. The main note has duration 960. The advantage of this is that there's no presumption about how the grace notes are performed, which may make it easier to vary the performance (if more difficult to get a default performance), and the performance durations are at least consistent with the idea of grace notes as ornaments. The disadvantage is that we need to mess around quite extensively with both times and durations in playback, as in (a) and (d), and this may even reorder notes (by moving the main note to a later time than some other note that nominally starts later), something I'm not sure we can cope very well with. (f) Any of the above, but with grace notes having their own event type rather than just being notes with different properties. This would make most sense for configurations like (e) in which they don't behave quite like other notes. I possibly like the (f) version of (e) best, despite its apparent weirdness. I think it's got both consistency and flexibility for performance, and editing grace notes strictly "as ornaments" might be easier than editing them as notes that then are made into grace notes somehow (which could be quite a difficult thing to do in the GUI, although I said I was going to disregard that for the moment). If I was to do it in the (e) way, I'd probably also avoid "having a menu item to convert selected notes to grace notes" -- instead I'd probably have a grace note toggle for the standard note tools. Of the others, I probably like (c) best because it's the only one that could (with suitable use of properties) allow the user to specify precisely when they want their notes played as well as how they should look, without making the duration of the main note appear inconsistent with the one following it as (b) does. Thoughts, anyone? (Jeez, who'd have thought you could write so much about grace notes without even going into _how_ to perform, edit and notate them?) Chris |
From: Hans K. <hki...@ma...> - 2002-07-02 16:57:12
|
Chris- Grace note plan sounds good. You had convinced me that (f) was the way to go, only because I'm pro-notation, but for ease of use and speed of coding, (c) definitely seems to be The Way. This means that a crotchet with two semiquaver grace-notes will automatically become a quaver, correct? In general, you will probably hear me whining more about the notation manipulations that currently go on in order to make playback easier (for example, a quaver and a crotchet that occur at the same time are converted into a quaver-chord tied to another quaver, F-flat is always represented as E-natural, etc), but until I find a magically easy solution that coexists nicely with the current code, I'll try to be quiet. Hans -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup 1 cent a minute calls anywhere in the U.S.! http://www.getpennytalk.com/cgi-bin/adforward.cgi?p_key=RG9853KJ&url=http://www.getpennytalk.com |
From: Chris C. <ca...@al...> - 2002-07-02 17:12:08
|
Hans Kieserman wrote: > This means > that a crotchet with two semiquaver grace-notes will automatically > become a quaver, correct? Internally yes, and it'll take a bit more calculation at display time to make sure it appears as a crotchet. Downside: you probably won't be able to have grace notes whose total notational value exceeds that of the note they're attached to, because grace notes will always, pending some cleverer way of manipulating their properties using the GUI, be stored with their notational durations and the main note will be stored with whatever's left over (and its duration must be at least zero). > F-flat is always represented as E-natural That's one we should be able to do something about -- we do store the accidental and it's used in NotationDisplayPitch:: rawPitchToDisplayPitch when deciding (for example) whether pitch 58 means A# or Bb. But it's not quite clever enough for the Fb/E case. Chris |
From: Hans K. <hki...@ma...> - 2002-10-21 15:29:55
|
Thanks for the explanation- > a crotchet but for it to be followed by a new quaver rest that > wasn't there before? That would be easy to do, but again may > seem a little strange in certain circumstances. What circumstances? I think that moving the note is probably a better thing to do (where "moving" = adding a rest) than changing what the user has entered. The real problem, as I see it, is that I think of grace-notes as an afterthought, so the current entry method requires a bit more planning than I'm used to. That is, I tend to add them after I add the note to which they attach, which doesn't really work with this paradigm. Maybe this could be chalked up to user-education? Another input method that could work is to not allow grace-ifying notes- simply require a grace note entry mode (a la tuplet mode), which enters grace notes notated as usual. Since they have zero duration always, they wouldn't require alteration of any existing notation. Hans -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup |
From: Chris C. <ca...@al...> - 2002-10-21 16:04:52
|
Hans Kieserman wrote: > simply require a grace note entry mode (a la tuplet mode), > which enters grace notes notated as usual. Problem with this is we're running out of keys... Still, it's probably the best idea. We didn't have any of these modes when I started doing the grace note stuff and I wasn't very keen on the idea, but I decided I might as well give in and use modes for keyboard entry and now they're everywhere. So what the hell. Chris |
From: Richard B. <bo...@bo...> - 2002-06-27 11:48:53
|
No-one's mentioned this on the list yet have they? Anyhoo, we are on the cover disk of July's Linux Format (out now). I'm sure they won't mind me reproducing this: http://www.masticate.com/rosegarden/rg-linux-format.jpg Stunning eh? I'm actually trying to get a job from them as we speak so I should be nice really.. B |
From: Richard B. <bo...@bo...> - 2002-06-27 11:59:13
|
Richard Bown wrote: > Anyhoo, we are on the cover disk of July's Linux Format (out now). It appears we're not on the cover CD, we're on the cover DVD - so if you buy the cheaper version of the mag you don't get us. I don't know quite what this says - either we're too good for the cheap version of the mag or too average a piece of software for the limited space on a CD. Either way we get the text but disappointingly no link. B |
From: Chris C. <ca...@al...> - 2002-06-27 12:41:13
|
Richard Bown wrote: > It appears we're not on the cover CD, we're on the cover DVD - so if > you buy the cheaper version of the mag you don't get us. Ooh. I know the CD version costs like six quid, which I always thought was a bit excessive -- how much is the DVD one? (I'd generally rather more pages and no CD, but I'm probably alone in that.) Chris |
From: Richard B. <bo...@bo...> - 2002-06-27 17:31:33
|
Chris Cannam wrote: > Ooh. I know the CD version costs like six quid, which I > always thought was a bit excessive -- how much is the DVD one? I've no idea. > (I'd generally rather more pages and no CD, but I'm probably > alone in that.) I'd agree with you - purely so that I could have a chance to do some writing for them though. I got in touch with LF about doing some writing for them too and they seem to respond quite positively - more importantly I'm involved in a chat about Bath pubs with the Production Editor. Makes me feel all wistful and sneezy. Bath is a lovely place but a killer for hayfever. B |
From: Richard B. <bo...@bo...> - 2002-06-28 08:12:26
|
I've got a class that'll generate peak data for an audio file. While it's doing this I want it to send back status on it's progress so I can pop up a dialog. Now I don't really want to to make everything from the peak file generator (sound lib) up to the gui a Q_OBJECT just so I can throw signals from it - is there an alternative I could use "with some form" of exceptions? How does Qt do its signals? Any ideas? B |
From: Chris C. <ca...@al...> - 2002-06-28 09:05:58
|
Richard Bown wrote: > I've got a class that'll generate peak data for an audio file. > While it's doing this I want it to send back status on it's > progress so I can pop up a dialog. Now I don't really want to > to make everything from the peak file generator (sound lib) up > to the gui a Q_OBJECT just so I can throw signals from it - is > there an alternative I could use "with some form" of exceptions? An exception is never likely to work, because when you throw an exception the stack gets unwound: you can't go back to the point where the exception was thrown after you've caught it. Potentially you could include information in the exception about how far the peak-data generation had managed to get, and then restart generation from that point -- but that would be a very twisted way to manage control flow. Why not just call a function? Make your activity function take a pointer or reference to some abstract class that's empty except for a given callback method prototype, and call that each time you have status to report. Then make your status-reporting thing subclass that. An Observer pattern, except that you probably don't even need to have the capability to have more than one callback object attached to a given activity. What's the purpose of this, anyway? Is it to provide status activity (like a progress bar or something)? If so, we could probably do with something like it for a few other operations as well -- opening large files, opening notation windows on long segments etc. Maybe that's a distraction. > How does Qt do its signals? I don't know exactly how, but I imagine they just have a collection of function pointers associated with each signal and they all get called when the signal's invoked. The slot declaration just allows it to bind a function pointer to a name; the connect call just adds a function to the signal's collection. Chris |
From: Richard B. <bo...@bo...> - 2002-06-28 09:21:15
|
Chris Cannam wrote: > Why not just call a function? A what? That's a bit lo-tech isn't it? > An Observer pattern, except that you probably don't > even need to have the capability to have more than one callback > object attached to a given activity. Oh yes, that would work. Ta. > What's the purpose of this, anyway? Is it to provide status > activity (like a progress bar or something)? If so, we could > probably do with something like it for a few other operations as > well -- opening large files, opening notation windows on long > segments etc. Maybe that's a distraction. No I don't think it is - I'll see what I can hack together. Like you say there's definitely a need for some non-Qt mechanism like this. B |