[gsharp-devel] Initial thoughts

[Robert STRANDH]

Hello, 

Christophe Rhodes writes:
 > 
 > My first initial thought, after fixing the remaining sbcl-related
 > buglets, was "wow, this is a lot faster!"  I presume this is because
 > of the change to the redisplay code -- is it not redisplaying some
 > pane or other in certain cases?  Anyway, that's much appreciated.

I suspect it is because Tim made som improvements to the handling of
output records in McCLIM.  There is still a slight pause when
displaying the entire page from "rapsoden-sjunger.gsh" that I would
like to improve on at some point. 

 > My personal interest is in being able to engrave and "perform"
 > Renaissance and Baroque music, usually but not exclusively including
 > vocal lines.  There are various obvious missing things that spring to
 > mind that are necessary to deal with this repertoire: lyrics, figures
 > (for figured bass and for time-signature changes), various ornaments
 > and other glyphs, 

Right.  There are literally hundreds of minor things and dozens of
major things that need to be added.  It is mostly just a matter of
doing one at a time.  Some of these things might require some
discussion with regard to design, i.e. how and where to do it. 

 > and of course beamed semiquavers...  

Right.  

 > I thought a
 > simple first project that I might look at is some way of dealing with
 > triplets, which would hopefully be extensible to septemdecaplets and
 > the like should our contemporary brethren find the need.

These are useful (and somewhat hard) things to handle.  It will not
be too hard to make Gsharp understand triplets and the like, but
getting the display code to show them with the right spacing might be
tricky.  The people who developed the Lime score editor wrote
something about that in an article that I can no longer find. 

 > I have also been spending some time recently in a computational music
 > department (at City University in London), where I showed the 0.2
 > release to a couple of people.  

How embarrassing.  I have not dared showing it to a musician or a
composer yet.  Somehow, they appreciate only features and not basic
design principles.  

 > The response was promising; 

What a nice surprise. 

 > I think
 > they appreciate the possibilities both of the dynamic environment and
 > of the UI framework.  One thing that came up was that it would be very
 > nice to have something analogous to emacs' keyboard macros.

Should be fairly easy to put in. 

 > As a simple example of why this would be nice: consider entering a
 > part consisting of repeated dotted-quaver/semiquaver figures like:
 >     _____    _____    _____    _____
 >    |   _|   |   _|   |   _|   |   _|
 >    |    |   |    |   |    |   |    |
 >    |    |   |    |   |    |   |    |
 >   @ .  @   @ .  @   @ .  @   @ .  @ 
 > 
 > This is an absolute pain to enter in current state-of-the-art (and
 > also not state-of-the-art but more academically-inclined) notation
 > packages: after each note, the input state needs to change.  

Well, in Gsharp, it is slightly better.  I would type this as:

      f.]f[[f.]f[[

with the input state on a quarter note (I am sorry, I can't remember
the British English equivalents of "half note", "quarter note",
etc).

 > One
 > viable method for doing this with less pain would be to enter the part
 > in straight quavers, and then record and repeat a keyboard macro to
 > alter the elements in sequence.  In case this isn't clear, try (in
 > emacs, in a sacrificial buffer with stuff in it) the effect of 
 >   C-x ( C-a ( C-e ) C-f C-x ) C-x e C-x e C-x e 100 C-x e
 > to see the analogy.  

Right!  In Gsharp, it would be something like

  C-x ( C-f ] . C-f [ [ C-x )

and then

  C-u 100 C-x e

 > Whether this keyboard macro facility wants to
 > record gestures (keystrokes) or commands, I don't know -- does anyone
 > know what emacs does?  Probably both in various circumstances. :-)

I don't think it matters really.  The only situation where one could
see the difference would be if keyboard bindings change between the
definition and the invocation of a keyboard macro.  

 > Speaking of keystrokes, there appears to be a McCLIM issue, or at
 > least a justified confusion, over treatment of the shift modifier.
 > Whereas in keystrokes such as Shift-Escape it makes sense to treat the
 > modifier key as a real modifier, it doesn't in keystrokes such as
 > Shift-#.  I cannot type Shift-# on my keyboard, because on a UK
 > keyboard it's unshifted, just to the left of Return; on the other
 > hand, on a US keyboard, it's shifted on the 3 key.  

Matthias has the same problem on a French keyboard. 

 > Should we
 > workaround by adding both shifted and unshifted versions to the
 > command tables, or is there an easy resolution in McCLIM?

I think that would be a reasonable workaround.  I thought of it myself
last night, and I think it will be fine. 

 > Those are some of my initial ideas, anyway.  Looks fun!

Fun and an endless source of inspiration and work.  Though, this could
be one of the "Killer Apps" needed to make Common Lisp more popular,
especially since there is no real equivalent at the moment in the
free-software community, and that such a thing would pretty much HAVE
to be written in Lisp anyway.  

Bonne journée,
-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------