Re: "Instrument" as first-class citizen

[Carl Sorensen]

On 4/22/15 7:17 PM, "Flaming Hakama by Elaine" <address@hidden>
wrote:

> 
>Since I understand programming languages rather well, if I understanding
>how something is organized, then I can code it 100% of the time.
>
>Surely, I will have to refer to manuals to find out specifics about
>objects, functional prototypes, etc.
>
>But the transition from concept to execution is simply a matter of
>following the recipe.
>
>Within the lilypond universe, however, this is complicated due to the
>several languages used (scheme, guile scheme and lilypond-specific
>syntax).

As far as I know, the only scheme used within lilypond is guile scheme.

>So, it is often not enough to know what you want to do, you need to know
>in which realm this activity is conducted.

I agree.

>
>
>It doesn't help that many things are implicit and based on contexts which
>are invisible and undocumented--or you can't find the documentation,
>which in the heat of the moment is more or less the same thing.

Hmm.  I have a bit more trouble understanding this.  I think the
documentation is pretty complete when it comes to contexts, engravers, and
grobs, and I can find pretty much anything I want in the documentation of
these things.  

Scheme functions, not so much.  I may have to grep the source.

>
>
>Also, the tendency of schemers to endlessly repeat the mantra "everything
>is a list" without really acknowledging that is both inaccurate and
>unhelpful.

Do you see a lot of that in the lilypond universe?  Maybe I haven't been
sensitive enough to that problem, but I haven't dealt with it a lot.

>
>
>(Yes, everything may be a list.  But depending on what you need to *do*
>with that list, there are undocumented requirements like, the first
>element needs to be a function, the second and third elements need to be
>strings, the fourth needs to be an ly:music type, the fifth element needs
>to be a list of notes.)
>

Pretty much every lilypond scheme function has a doc string that explains
the required inputs, in my experience.

>
>
> 
>> they would be a simple, high-level introduction about how all the
>>pieces and parts are put together, so you could say, "ok, here's where
>>the stuff I'm doing fits in, so here is the type of info that I will
>>need to learn?.

I agree that this would be helpful.  I'm working on trying to develop that
idea.

>
>But this does not address either the organization, which is to say, the
>TOC or index or FAQ organized by what users want to do.
>
>
>And what about all the inevitable cases where it is difficult to find the
>information, or requires looking at several disjunct places in the docs.?
>We can't know what are the gaps in documentation until we generate assess
>what people need to know (regardless of how easy it is, or how easy it is
>to locate).

I think the idea of trying to capture what new users need to know and are
having a hard time finding is a very powerful idea.  I don't know what the
solution to the problem would be, but if we can clearly identify a
problem, I'm pretty sure we can solve it.

>
>Without getting too technical, objects are things that you can create,
>have properties and relationships with other well-defined objects.
>
>This is true for things like staves, staff groups, scores, books, etc.
>You can say:  \new Staff = { ... } to create a new staff because there is
>an object class called Staff that is well-defined.
>
>It has known properties like Staff.TimeSignature, Staff.extraNatural, etc.
>
>Other objects (Staff Groups, Books, etc.) know how to handle this Staff
>object, or several Staff objects.

As far as I know, all the above are contexts.  Except for /book and
/bookpart.  I'm not sure that they are contexts.  They aren't listed in
the Internals Reference.
>
>
>However, in the case of "instrument", there is no such object so you
>cannot create one.

This is true.  In my understanding of the lilypond object model for
graphical output, we have iterators, contexts, engravers, music events,
and grobs.  And an instrument is none of these.  So we don't have the
concept of an instrument object.


>If there were, the syntax might be more like:
>
>violin = \new Instrument {
>    Instrument.name = 'violin'
>    Instrument.shortName = 'v.'
>    Instrument.midi = 'violin'
>
>
>    Instrument.clef = treble
>    ...
>
>}
>
>\new Staff { 
>
>    Staff.Instrument = \violin
>
>    \violinMusic
>
>}

So looking at this proposed usage, it appears to me that you'd like to
have an instrument be a collection of settings that would be applied to a
context (perhaps a Staff, as in the case of violin, or perhaps a
StaffGroup, as in the case of piano).
In lilypond terms, this set of settings includes context properties
(instrumentName, shortInstrumentName, instrumentCueName, midiInstrument)
and music events (clef).

I don't think this is an impossible request, but I'm not sure how easy it
is to do.

Are there any other music objects (not LilyPond music objects, but music
objects in your world) that are missing from LilyPond?

Thanks,

Carl