lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Drum notation, scheme functions and midi


From: Han-Wen Nienhuys
Subject: Drum notation, scheme functions and midi
Date: Sat, 17 Nov 2001 18:31:39 +0100

address@hidden writes:
> Prob 1: One have to create two score parts in order to make the midi-output
> right.

I think this is not so bad. We could even make this bug a feature,
i.e., force

 \paper {

    \notes  { .. }
 }

 \midi {
    \notes { ... }
 }

syntax.

> Prob 2: The global scheme-name-space is too polluted by drumpitch-init.ly.
> This is easily solved by changing the structure of the mappings.
> 
> Prob 3: It is a problem that after including "drumpitch-init.ly" one can no
> longer use normal note-names.
> The solution, imho, would be to add a ly-command that instead of replacing the
> old notenames with new ones MERGES a set of new note-names to the ones
> already defined.

No, I don't like this solution. I think it doesn't match with idea of
modes nesting in Lily. I prefer the following solution: have \notes
take an optional argument, i.e.

     \notes {  }  % standard  names
     \notes #english-names { .. }
     \notes #drum-pitch-names { .. }

> Prob 4: - And this is the "real" problem: The "apply"-syntax is too clumsy and
> not flexible enough.


> a: Instead of syntax
> \apply #<SCM-FUNC> <ARG>
> I would suggest
> \<SCM-FUNC> <ARG>
> or, if this is impossible,
> \#<SCM-FUNC> <ARG>
> The reason for this is that using scheme functions will require much less key
> presses, will look less temporary, and will suppress the difference between
> lilypond-commands and add-on scheme functions - making the scheme add-ons
> more comprehensive for the masses.

This is something that could be done, but we had better be very sure
about it. Going back after we change this is not an option. -- We
should probably merge this mechanism with identifiers, so that we can
once again have identifiers with numbers and underscores, i.e.

  foo=  \notes {   \#notes-from-staff-1 }


> b: Allow the scheme function to take any number of arguments of any type and
> return an argument of any type instead of only allowing functions taking one
> "music"-argument and returning a "music"-argument. It is annoying that scheme
> afaik have no type-checking - but I think it is possible to determine the
> number of arguments required for a given scm-function.

 > \transpose \fromto cis des \music2tranpose

The problem is that you can't have a variable number of arguments in
the grammar. However, an option would be to allow a variable number of
arguments if they are enclosed in delimiters, e.g.

  \#transpose \{ \fromto \{ cis des \} \#music2transpose \}

I must say, this doesn't look particularly elegant to me. Another
option is to have the lexer distinguish between the arity of a Scheme
function. However, it means we could only support a limited number of
arities.

Also, there is a type-checking problem: how do make sure that you both
allow

  \#smart-repeat 2 "unfold" \someMusic
 
and have a reasonable error message when you do

  \fromto #2 "unfold" 


Personally, I think that option 4b. is too difficult to get right.


-- 

Han-Wen Nienhuys   |   address@hidden    | http://www.cs.uu.nl/~hanwen/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]