Hello All,
> > Maybe you don't, maybe you make a rule that
> transformations are applied to
> > links only. If you want to apply a transposition to
> the underlying segment,
> > you have to open it up in an editor and move the
> notes. If you want to
> > stretch/squash the underlying segment, you have to
> open up the editor and
> > rewrite the segment with notes of different lengths. I
> think this is
> > defensible.
>
> Having to open the source to make changes at the source
> sounds very
> defensible. Otherwise apply transformations only to
> local copies.
I agree as well. Make changes to the source.
>
> > What about note edits when a segment is linked? Say
> you have a linked
> > segment which has been transposed and stretched. You
> open it up in the
> > notation editor, I think you should see the notes
> after the
> > transformations have been applied. Can you edit the
> notes directly in the
> > transformed view and expect the underlying segment to
> be adjusted
> > appropriately? Possible, but perhaps fiddly.
>
> Transformations of duration and pitch are one thing, but
> the linked copies of
> these things would *have* to be read-only. Anything
> else really pushes the
> line beyond merely being fiddly.
I know triggered segments can be transformed in this way. But that doesn't
mean we have to apply the transformations to symlinks.
I suggest for simplicity a symlink should not be transormable in duration or
pitch, or velocity. However, they may appears in other tracks so the
instrument can change, but the events otherwise stay the same.
I think this model is much more comprehensible. Yes, the other things are neat
but this this feature is a really just a add on provided by the trigger segment
mechanism and wasn't a part of the initial idea. I think sym-links that do not
transform in pitch or duration would be very valuable on its own.
I admit having the transformation would be really cool. Just complex.
>
> Being able to represent the local, read-only view of a
> manipulated segment in
> a conventional edit view seems like it could get quite
> complicated too. I get
> what you're saying about you apply stretch and transpose to
> the local linked
> copy of some read only master, but while the technology to
> interpret these
> manipulations definitely exists at the sequencer level, I'm
> doubtful this is
> so cut and dried at the edit view level. It would
> probably need some quite
> complex code to take the transformations into account in
> order to change the
> on-screen representation of the master data, which is
> probably another reason
> why we never did provide a proper on-screen representation
> of these segments.
> This one sounds plausible, but a headache of such magnitude
> I'd like to avoid
> even thinking about how to work it conceptually, let alone
> implementing
> anything in practice.
>
> > How about for linked segments
> > which have transformations applied you split the edit
> view to show the
> > transformed and untransformed views simultaneously?
Again if we did not apply transformations, this process is simplified. I
suggest that if a user wants to edit a sym-link. The user must specifically
call a command to convert the sym-link into a deep copy of the source segment.
We do this with repeating segments already. So there is precident for this
action sequence in the UI.
>
> I'm in danger of breaking into manic laughter at this
> one. The notation
> layout code is already so brittle and buggy after all these
> years and all this
> work. Just taking that thought at a surface level, it
> sounds almost
> impossible to achieve, given our demonstrated level of
> (in)competence in this
> area.
> --
> D. Michael McIntyre
>
>
No comment.
Sincerely,
Julie S.
------------------------------------------------------------------------------
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
