From: D. M. 'S. M. <ros...@gm...> - 2006-03-07 21:20:27
|
On Tuesday 07 March 2006 7:15 am, Vince Negri wrote: > when it is required. Presumably, if we use the built in event property > mechanism, saving > this info will almost code itself :) Just about. Rosegarden is pretty well designed when it comes to stuff like this. > This really comes down to the desired effect in the GUI. I've seen two > main styles for tab: > 1) As a second staff underneath a trad notation staff. In this case, > all the tab shows are the frettings. Rhythm, dynamics etc are all on > the trad staff. > 2) As a self-sufficient staff where the rhythm and dynamics are marked > on the same staff. This style looks like trad notation, but with > numbers instead of blobs for the note heads. > > 1) Is what you typically see on magazines. 2) Is what you would tend > to write yourself on a pad of paper. I think I'd lean toward whatever Lilypond can do, primarily. Just with half an eye toward eventual exportability. There is a lot of variation in tab, but we probably need to pick one style and make that the only choice. My first thought would probably be 1) I imagine. Conventional notation with a toggleable tab add-on below it. (And some fiddly bits to calculate the fret/string automatically using mostly sane defaults, and then let you shuffle through alternatives to tweak from there, rather than forcing people to spell out every fret/string manually. That would suck.) > Suppose we go for 2). Then TabStaff could inherit NotationStaff (be a > "special sort" of NotationStaff) - that seems most fitting. > > If we go for 1), then TabStaff isn't a NotationStaff - it would > inherit LinedStaff. > > The main issue with (1) is that RG, afaik, doesn't have the capacity > for displaying linked staves (think piano score with LH and RH > staves). That makes the "just the numbers" view less useful. So > personally I've prefer (2), but I'm open to persuasion. :) We could solve the problem of not being able to link staves, and/or create a new kind of staff that's a conventional 5-line staff above, and a 4-6-line staff below. (Maybe more than six. I forget how many strings lutes have, but it's a bunch.) Tunings per string should be configurable in assorted ways too. Probably a global default with a per-staff override. Though it's probably enough starting off to restrict this to a 6-string guitar in standard EBGDAE tuning, so long as its designed to facilitate, rather than complicate eventual nth degree tweakability later on. This kind of two in one object might involve solving some of the same problems involved in making a true grand staff, which is something we desperately need to add. I think a true grand staff should be one staff object that displays 10 lines, and does intelligent things in between. I think we should have one, though merely being able to put system brackets (?) between separate staffs might be sufficient. Not sure how Chris will feel about all of that. I'm purely thinking from userland here, with only a vague understanding of how all of that code operates. Notation code is out of my league, except when it comes to being the Accidental Police. I'm encouraged that you're answering a lot of your own questions here, and you still seem enthusiastic after rooting around in the code some. I'll keep a spot on the contributor page warm for you! -- D. Michael 'Silvan' McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ |