> Really, it seems a lot more sensible for Rosegarden to do controllers on
> some
> "conductor track" at the global level, on a per instrument basis.
> Rosegarden
> definitely gives you the rope to hang yourself with in this respect, since
> you
> won't see controllers that are in some other segment, even though they
> definitely affect the MIDI channel you're using. I think some of the
> fundamental design decisions were really questionable in retrospect, but
> we've
> all inherited that legacy, myself included.
Interesting that you should say that; I was thinking along similar lines
recently. It can be confusing to edit controller events and find that
unseen events in another segment are resetting or overruling what you're
doing. It can be tedious to fix.
The model doesn't match the MIDI that it's controlling. Controller events
think that they are contained in one segment along with notes etc and that
segment is contained in one track. But really they pertain to an
instrument. That instrument might be playing multiple segments on
multiple tracks.
At first I also thought that it'd require radical changes. But then it
occurred to me that there's a 90% solution that doesn't require radical
changes. It just uses segments instead of creating new structures,
commands, and functionality. I'll outline it:
* Distinguish three types of MIDI segments, otherwise unchanged.
* Mixed :: Just like MIDI segments are now.
* InstrumentWide :: Contains only controller events and other things
that apply across segments and tracks to an
instrument.
* Isolated :: Contains only relatively isolated events (notes etc)
It isn't philosophically perfect. For instance, notes apply note-offs
across segments and tracks, yet putting notes into InstrumentWide segments
would defeat the purpose. But note-offs are less confusing than hidden
controllers and are a less serious issue.
* Give the user a means to make non-mixed segments. Probably just a
command to split a mixed segment into InstrumentWide and Isolated.
* Make the various functionality respect the type logic. There's a lot
but I suspect it's mostly shallow. Like, "Join Segments" would just set
the new segment's type correctly. Notation and Widget editors would
silently ignore InstrumentWide segments. At this point, event inserters
and rulers would just refuse to operate on the wrong kind of segment.
* Finally, make controller event inserters use InstrumentWide segments
* Rulers other than velocity wouldn't visit Isolated segments. Instead
they'd find, lengthen, or create an InstrumentWide segment for the same
instrument at the same time.
* Similarly, insert pitch bend won't insert into an Isolated segment,
it would find or make a suitable InstrumentWide segment.
That's about as easy a path as I can think of.
I had actually intended to propose and work on that, but making triggered
controllers took precedence.
Tom Breton (Tehom)
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
