On Friday, December 02, 2011, Tom Breton (Tehom) wrote:

> 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.

No, it isn't quite what I meant.  Putting it that way, and all the discussion 
that ensued finally helped me get a few things to click in my head though.

I've been writing and deleting text for a couple of hours now.  I kind of hate 
to give my answer without showing my work, but I just don't have time to 
continue this.

What I concluded is that when you have controllers in little portable boxes 
that can move anywhere fluidly, you have decided to create the problem of 
being able to create situations where unintended conflicts exist.

You can take steps to make everything within a sphere of influence aware of 
everything else within that sphere (tons and tons of deleted thinking out loud 
here), but since the boundaries of said sphere are extremely fluid and 
malleable (move a segment to a new track, change the instrument on an existing 
track, move a segment in time) and the interconnections between all the 
elements are complex, it is virtually impossible for software to resolve 
anywhere close to 90% of the potential conflicts automatically.

The only real solution to this whole problem, as I see it, is to dump the 
segment model.  Since we're not remotely going to consider that, I just don't 
see anything but to live with this side effect, and deal with it.  It can be 
confusing, without a doubt, but it also works in its own way.  It is what it 
is, and it's not wrong, it's just different from the approach most MIDI 
sequencers take.

I have to go all the way back to saying that I don't think there is any 
fundamental architectural change our founders could have made 10 years ago 
that would have resolved any of this.  It's just how the segment model has to 
work.  Even with the mythical "extra-segmental" context I've been lamenting 
the lack of for years, you've still got gobs of problems resolving who owns 
what, and what goes where when what moves.

Having said all that, feel free to start hacking on your 90% idea in a branch, 
and see if you can make it work.  I'm convinced you can't, but I'll be first 
in line to extol your brilliance if you prove me wrong.

For my part, I'm going to stop thinking about how to solve this problem 
henceforth.  I've contributed what I could, and I'm spent.  I'll be happy to 
support you in any way I can if you want to pursue this, but I'm done having 
any hand in where it goes from here.  I'll be happy to test your work and try 
to pick holes in it though, once I get my grubby hands on it.  There's even a 
remote possibility we might work through all the problems together, and make 
the damned crazy thing work.

Good luck!
-- 
D. Michael McIntyre

------------------------------------------------------------------------------
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

Reply via email to