On 31 Jul 2005, at 5:43 PM, David W. Fenton wrote:
I *think* I understand what "keyswitch" is, but could you explain it?
Sure.
The full version of GPO is designed primarily to be played back in
real-time (for instance, when recording a track for a sequencer).
Keyswitching is a method to trigger changes playback techniques in
real-time without having to change instruments. Keys below the
playable range of the instrument are defined to trigger these changes.
So, in GPO full, the strings have playable keyswitches for arco, pizz,
short bows, trills, and tremolos; the harp has keyswitches for
harmonics and stopped notes; the brass have keyswitches for mutes; the
flutes have keyswitches for n.v. and fluttertongue, etc.
In GPO Full, these keyswitches are always in the octave immediately
below the lowest playable note on the instrument, so that they can be
triggered in real time. For instance, the lowest note on the GPO Full
KS flute is B3. The keyswitch to trigger ordinary playing is a major
seventh below that (i.e., C3). D3 triggers non vib playing. E3 triggers
fluttertongue playing.
While keyswitched instruments were designed for live playing, they are
also very useful for use in notation programs, because it means you
don't have to load up a bunch of different MIDI channels with arco
violins, pizz violins, muted violins, tremolo violins, etc., all in
separate channels. You can just load the keyswitched violins and
everything is right there in a single patch, taking up a single
channel.
However, it was also somewhat problematic to use the keyswitched
instruments with a notation program. In Finale 2005, we had to
maintain separate "arco,""pizz," etc. expressions for the violins and
violas, cellos, and basses, separate "mute" and "no mute" expressions
for the horns, trumpets, and trombones, etc.
GPO Finale Edition solves that problem by using "unified" keyswitches.
These keyswitches are not playable (at least, not without transposing
your keyboard) because they all start on MIDI note 1 (i.e., C-1, the
note two octaves below the lowest C on the piano). That way, the
keyswitch that triggers "pizz" is exactly the same MIDI note for all
string instruments; the keyswitch that triggers "mute" is exactly the
same MIDI note for all brass instruments, etc. This also prevents the
novice GPO user from accidentally triggering pizz playing during note
entry and being confused about how to get the arco sound back.
GPO Full now contains a "notation" set that uses the same unified
keyswitches as the GPO Finale Edition.
However, in Finale 2006, in addition to the unified keyswitches, Human
Playback is also able to handle the regular, playable keyswitches used
in older versions of GPO Full (and the non-notation set of GPO Full).
But that's a little bit trickier for HP, because with the non-unified
keyswitches, it needs to know which instrument is assigned to which
staff so it can trigger the appropriate keyswitches in the appropriate
octave. It relies on staff names for this -- hence the problem with
"violoncello" as a staff name. Human Playback sees only the first part
of the name -- "violon" -- and assumes that it's dealing with a violin,
not a cello -- so all the keyswitches are triggered in the incorrect
octave. (This will be fixed in the next HP update.)
The thing is, NONE of this is information that a casual Finale should
need to know. If MakeMusic had just omitted all the non-keyswitched
string patches from the GPO Finale Set, everything would be MUCH less
confusing. If you take away the option to load the non-keyswitched
strings, and if you eliminate the confusing non-HP expressions from the
Finale default file, everything would seem much simpler and more
transparent. You would just load up the GPO Violin, enter "pizz", play
back, and you'd get pizz playing.
Unfortunately -- somewhat perversely in my opinion -- Coda has added
all of these potential pitfalls for newbies. If a user doesn't know
what "KS" means, they probably won't load the KS instruments in the
first place. And if they see a "pizz" in the Finale default file that
says "GPO Finale Edition," they will probably use that one instead of
creating their own. I really have no idea who was in charge of these
decisions, but they were VERY VERY VERY bad choices, choices that were
protested by the designer of Human Playback (Robert Piéchaud) in the
strongest possible language at the time. I have no idea why Coda won't
listen to the guy who created Human Playback for them when he warns
them about issues affecting Human Playback, but there you go.
I just wonder why Finale didn't build in functionality to ignore
expressions with playback definitions that duplicate those that are
defined for HP.
I wonder that too, but apparently this was too difficult to pull off.
- Darcy
-----
[EMAIL PROTECTED]
Brooklyn, NY
I just wonder why Finale didn't build in functionality to ignore
expressions with playback definitions that duplicate those that are
defined for HP.
It seems to me that the "law of leaky abstractions" is showing
through here:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
That is, the wires and underpinnings are showing through in the user
interface, in a way that requires you to understand how things work
below the surface in order that you correctly navigate the user
interface that controls those factors.
Perhaps this is a version 1 problem -- i.e., these kinds of things
will get cleaned up in the next Finale release based on user input.
--
David W. Fenton http://www.bway.net/~dfenton
David Fenton Associates http://www.bway.net/~dfassoc
_______________________________________________
Finale mailing list
[email protected]
http://lists.shsu.edu/mailman/listinfo/finale
_______________________________________________
Finale mailing list
[email protected]
http://lists.shsu.edu/mailman/listinfo/finale
