On Thursday 06 July 2006 3:59 pm, Michelle Donalies wrote:

> This seems counter-intuitive. Could you give me a synopsis of why?

I suppose the essence of it is that it is cleaner than allowing people to 
insert program changes in the middle of a segment.  Program changes in the 
middle of a track are a fact of life if you don't want to have to do 
ridiculous things, like putting the violin patch part on one track, and the 
pizzicato patch part on another one.

The logical thing to do in those cases is to keep all your music on track, one 
channel, and change programs in MIDI to make it simulate what the real 
performance is supposed to sound like.  This means program changes, but we 
never have had a reasonable or complete facility for doing this.  (And 
everyone but me and William has always thought they were a totally evil idea 
anyway.)

So Pedro came up with the idea of switching this around.  Presumably tracks 
will have default instruments for newly created segments, in the new Track 
Parameters box, but it will be possible to reassign instruments to individual 
segments.  (There's also some business here about getting the instrument 
disentangled from the sequencer too.)

That isn't an entirely satisfactory approach, now that I think on it.

If I have to assign these instruments to segments, that means I'm forced to 
have double barlines separating these sections.  At least as displayed and 
printed with Rosegarden.  (Not sure about LilyPond export.  I don't think it 
does double barlines, and I would argue it shouldn't, now that people can 
produce one on demand anyway with the || -> directive.)

If I were able to insert regular ol' MIDI program change events (as is 
currently only crudely possible), then there would be no need to cut up the 
segment for the only purpose of changing how that bit of the track plays in 
MIDI.  I think that would be better, really.  Splitting segments yields extra 
time signatures that can't be rendered invisible, for one thing.  (I really 
need to file that.  That sucks!)

So I'm not sure I'm convinced by this whole instrument moving to the segment 
idea after all, really.  I don't dislike the idea, but it isn't a wholly 
satisfactory solution to the problem of a part that flips between different 
kinds of muted trumpet patches, for example.  There are really quite a lot of 
legitimate, logical reasons to change patches in the middle of a track.  
That's why Cakewalk lets you change patches in the middle of a track.

> To allow Track 1 (labeled
> gtr1) to change instruments to a trumpet three or four segments into the
> piece seems to me to be a pain in the rear.

Guitar to trumpet would be stupid, but that's kind of like arguing that 
because you'll kill yourself if you hit yourself in the head with a hatchet, 
nobody should ever be allowed to have hatchets, because there is no 
legitimate reason to own one.  Violin or cello to pizz and back, trumpet to 
muted and back, oboe to English horn and back, flute to piccolo and back, 
etc.  This kind of stuff is not uncommon.

> Then, if you're copying from 
> Track 4 (the flute) to Track 1 (gtr), you have to go through the extra step
> of changing the instrument.

You do raise a good point here.  That would indeed be a PITA for nothing.

Pedro?

I don't think I'm nearly as convinced as I just was on this whole instrument 
belonging to segment thing anymore.

-- 
D. Michael 'Silvan' McIntyre  ----   Silvan <[EMAIL PROTECTED]>
Linux fanatic, and certified Geek;  registered Linux user #243621

Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

Reply via email to