(About 130 lines)
Michael once described me as a crazy visionary - which I like - and what
I'm about to propose is either crazy or visionary: I think I know how we
could have a truly layered, foreground/background editor, and the best
part is, it wouldn't require any real structural change and surprisingly
little code change overall.
The vision has been expressed before, in the "layer" feature as inspired
by graphics editors (GIMP, etc). I like the idea that it was envisioning,
but ISTM the feature itself actually just gives you more leverage
selecting which segment has the focus. In contrast, GIMP et al can put
some stuff in the background and let part of it "show thru" to the
foreground while other parts don't show. That seems really useful.
The use case that this addresses is using Rosegarden to edit a composition
that has fine-grained repitition. Ie when your repeated stuff doesn't
come in neat, large blocks of (say) 4 to 8 bars each with a crisp
beginning/end, which linked segments handle so well. Instead different
repititions disagree on a couple of notes while keeping most of the
repitition, or they glide into different endings, or they're the same but
panned differently, or share the same expression controller sequence on
different notes, etc. Repetitive but messy. No neat blocks to simply
repeat.
The problem:
Any way you edit that sort of thing, you do manual work that the software
could potentially do for you.
1. If you do nothing special to manage it, then you frequently have to
find and edit everything that repeats a given thing, even though
it's the same change.
2. You can try to manage all the repitition with linked segments -
which were a very helpful addition, thank you Ian. But linked
segments ISTM want to be shared identical segments. You can vary
them a bit with transposing and truncating them, but they're
really not meant for fine-grained control.
So if you try this method, you often have to slice them quite
finely. I've had many links as short as a bar. So it becomes
difficult to work with. Even slicing them finely can't capture
all the repitition - for instance, segments that have different
panning but the same notes.
3. If you use the strategy (as I have lately) of starting out with
linked segments and converting them to normal as they
differentiate, you save some work but late changes put you back
into case #1. So that's still a lot of extra work.
Ornaments *almost* to the rescue:
Imagine for a moment something that won't quite work. Suppose that you
tried to do layering with ornaments, using them like a background layer.
You put your repeated-but-slightly-varied material into an ornament, and
put the varying stuff and the triggering note into a segment (that's your
foreground)
Change your mind about where your alternate ending starts? Just change
the duration of the trigger note - you can change it independently for
each repeat, without recutting linked segments, and if you change your
mind, you can change it back trivially.
It brings some nice things to the table: making shared brackground in a
point-and-shoot style, naming your background stuff, selecting it from a
menu, etc. But there are big obstacles that keep it from being usable:
1. You can't see what you're doing! If you want to (say) pick up
exactly where the background leaves off, finding where that is is
a chore.
2. Can't easily edit the background either - you can use the
eventlist editor but that's painful.
3. You can't nest them. You can only have two layers.
4. Your control of where the background "shows through" is limited.
You can cut off the end or the beginning, that's it.
Making it work:
IMO these flaws are all fixable without serious rewriting, and in ways
that don't seem like they'd break anything.
A lot of the functionality is already in place. We already have code that
puts a triggered segment's expansion into a segment (In
InternalSegmentMapper). Notation already can allow "fake" segments
(repeated segments' clones) and can treat them as uneditable, though they
do need to "lie" about track number. Notation already can redo layout on
the fly (eg if a segment it watches disappears). By experiment, you can
edit triggers thru linked segments now (though you cannot create them).
Linked segments already give us the ability to edit at different times and
pitches (though not squashed - that'd be asking for too much)
1. To see what you're doing: On command, Notation would "adopt" a
temporary segment containing the ornament's expansion (as by
InternalSegmentMapper's mergeTriggerSegment). Like repeat clones,
this would be a dummy that wouldn't itself play.
2. To edit background: Almost the same as above. On command, add a
local link of the triggered segment to the editor. (But can't do
this for squashed ornaments)
3. Wrt nesting ornaments, that needs the most new code, but it's
basically a queue and a loop around mergeTriggerSegment, which I
know pretty well from InternalSegmentMapper. I imagine there'd be
a recursion depth controlled by user option, defaulting to 10.
4. "Masking" ornaments:
Initially I had some idea involving events that mask/unmask a
given trigger expansion and a new ruler to display and edit them,
and there'd have to be unique IDs for trigger notes, etc, etc.
Then I realized there's something much simpler: A trigger note can
be a stream of tied notes. So let each note correspond to the
respective time-interval of the ornament, and if it has the
property TRIGGER_EXPAND as false, don't expand that time-interval.
* To make that play right, add another loop around
mergeTriggerSegment and a little decoding logic.
* Display "masked out" tied trigger notes in another color.
* And change the collapseNotesAggressively logic to not collapse
different masks together.
And that's about it. Plus of course gluing it together with menu entries,
slots, FooCommand, etc but that stuff's well known.
What do you think? Obviously I wouldn't do this on trunk because it's
experimental.
Tom Breton (Tehom)
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
