On Thursday 22 Sep 2005 09:15, Peter Mogensen wrote: > I'm currently trying to come up with the best template for a more > structured Lilypond export. > > I think considering to change the current mapping, which is: > // Lilypond Voice = Rosegarden Segment > // Lilypond Staff = Rosegarden Track > > To: > Rosegarden segment = Lilypond notes > Rosegarden Track = Lilypond Voice > > ...and then keep the score/staff definition seperate.
That sounds reasonable to me. > It would be nice to have some reference material of what Rosegarden > is expected to be able to export to Lilypond and how the result > should look visually. That might actually be more a question for the users list. I know the arrangement has changed in the past before -- for example I think there used to be a raw Rosegarden Instrument -> Lilypond staff mapping that seemed like a neat idea at the time but turned out to be fairly inappropriate for most uses (although probably a good thing to be able to call up as an option). [...] > I was thinking that it could be relative simple to add primitive > understanding of repeats to RG Well, we _do_ have _very_ primitive understanding of repeats -- in that they appear on segments that are marked and shown as repeating. Not that I'm arguing. There's nothing particularly tough about putting the same segment in more than one place, especially if only one of the instances is actually editable (as is the case for repeating segments now). When we play something, we actually expand out the repeats at the start of playback when writing the segments into our memory-mapped area for the sequencer to read, so if we get the display code and this expansion right, playback just follows. > I was thinking somthing in the line of: > > * There's already a repeat flag. This could be expanded to include a > repeat count. Technically straightforward (apart from the problem of making it obvious in the GUI). > * A "voltarepeat" flag could be added, which causes the segment to be > repeated only after the next (volta) segment. Or, a repeating segment could be marked as (I'm not sure what terminology would really work for this) only being "suspended" by the next segment, instead of being ended by it. At the moment a repeating segment repeats up to the start of the following segment; one marked as only being suspended by the next segment would repeat up to the start of the next one, then would start again as soon as the next segment or its repeats had ended. So e.g. you could mark one segment as repeating twice (plus the original copy) and being suspended by the following segment, and then drop in a segment after the first repeat, to get AABA. Would it be possible to map this sensibly into notation automatically? It might all be a bit mind-bending, particularly since it would be hard to show the difference between repeat sorts in the canvas. Another alternative for producing this kind of effect _in playback_, but that we don't support at all currently is aliased segments, i.e. just segments that are non-editable copies of another segment but can be dropped in anywhere (rather than having their positions determined by the repeat flag etc). Mapping repeat structures generated this way on to notation could be hard, though. > * You could actually also support D[SC] al (Fine|CODA) in that way by > setting attributes on segments and allowing for placing "Fine" and > CODA. I _think_ most uses of these could also be mapped into the structure described above, if the segment was subdivided at segno etc. But I'd have to see some actual examples. It could just prove limiting and frustratingly obscure. Any more thoughts? Chris ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
