[I'll answer this part out of order; the thread seems clearer this way]
> In that kind of world, how does this controller problem look different?
Could
> moving the instrument to the segment allow us to deal with the controller
> issue in a more elegant manner than your proposal, which you admitted was
> "philosophically" awkward?
It deals with the controller problem perfectly, assuming that it would
"clone" instruments as needed. Like, if two segments have the same MIDI
instrument at the same time, they each get one playing on its own MIDI
channel. You didn't say, but I think that's what you meant.
As you say, it seems painful to implement. Your proposal seems to be a
100% but radical solution to which I was proposing a 90% but non-radical
alternative.
* Pro: It's purer; it doesn't leave any nagging little
inconsistencies
* Pro: It's easier on the user
* Con: It'd be much more work.
* Con: Its intermediate stages seem more difficult.
Maybe there is a less radical path from here to the 100% solution. I
can't think of it right now.
> I'm just starting to see the edges of this idea, but what if segments,
rather
> than tracks, owned the instrument? A segment would take a default
instrument
> from the track in the same way it takes a default "create segments with"
> color, highest and lowest playable notes, transposition, clef, etc., but
once
> it existed, it would maintain its instrument independently of whatever
track
> it landed on, in the same way it owns its other properties.
If I may add on some ramifications:
Seems like we'd need a user command to re-assign an instrument to selected
segments. That implies a new widget to select an instrument, and a set of
instruments to select from.
What is the set of instruments? Right now, exactly the instruments that
are visited by some track. But any instruments that any segment is using
needs to be kept around, and it'd probably make sense to jump right to
keeping a set of instruments. Pretty soon we'd want an interface to
manage them.
How to edit an instrument? Maybe at first, only via a track visiting that
instrument, like now. Eventually we'd want something better.
That would require support in our save format. Backward compatibility
becomes an issue.
Cloning instruments as needed creates some scarcity of MIDI channels. So
then we might want to reassign instruments to any channel that's free.
Doing that allocation is itself easy: keep a free-list. ISTM the problem
is that the way we do MIDI playing now doesn't support "late" logic about
instrument channels. IIUC, we dump linearized segments that already know
everything they're going to do and we basically stop and start them. But
I've only seen that code a little bit, so please correct me if my
knowledge here is wrong.
Are there any user setups that require a particular mapping of instrument
to channel? I don't know of any. If so, either we can't freely assign
instruments to channels or doing so becomes more complex.
There are surely many places where the code "knows" obsolete assumptions
about instruments, tracks, and channels. I've seen a few and I'm sure
there are many more. Like, everything using Track::getInstrument().
MIDI and softsynth tracks become little more than default settings for
segments and means to select multiple segments. There seems little reason
for a Segment to remember its track id.
Linked segments presumably have non-shared instruments that default to the
original instrument.
Presumably every segment would initialize play with its instrument's
default settings. No more concern about how a previous segment left the
controllers. That's another nice thing that comes from a 100% solution.
It disables some "Stupid Segment Tricks" that make controllers a little
easier to manage, such as putting the volume controllers for a tutti
crescendo into their own dedicated segment and linking or copying that
segment everywhere it needs to go. But that might be provided by
triggered segments that hold controllers (which I should be working on
instead of writing email).
How do triggered segments fit in? I assume they don't hold an instrument,
so they inherit it from a parent?
Its purity probably makes further extension easier.
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
