[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Denemo-devel] LinuxMusiciansForum[User:Raboof] An idea about struct
Re: [Denemo-devel] LinuxMusiciansForum[User:Raboof] An idea about structured notation/composing and references/links in notation
Tue, 03 Feb 2009 09:12:57 +0000
This a very good idea. It has got me thinking.
There is, in the Denemo examples, an example of doing a cue, using the
LilyPond backend. (A cue is the music belonging to another musician that
appears in small notes in your part while you have rests; it helps you
come in at the right point).
In the example you change the music in one part and the cue in the other
part automatically refects the change.
This is so tricky to do in LilyPond that I thought that having Denemo
control the LilyPond syntax to do this would be Good. So I wrote that
example, and imagined we might build on top of it.
What Raboof has made me think about is that a better approach would be
to do it inside Denemo, and get Denemo to output the cue to the backend
as regular LilyPond music syntax - no use of the tricky special cue
The thing is, this idea would cover both cues and the repeated-motif
thing that Raboof has proposed.
We have a structure that is quite suited to holding music fragments -
the (so-called) Movement. It holds a bit of baggage that it does not
need for this purpose (multiple staffs, fields for the Composer ...),
but it has the great advantage over lower level structures (such as a
list of measures or a Staff) that it already has navigation and display
facilities associated with it.
This would involve a relatively small amount of coding, but the ice
would be quite thin - very easy to introduce dangling pointers and
associated chaos. And the code would be less easy to understand than if
it had been written from the bottom up with this in mind.
Strange to say, Denemo actually did have a feature like this about 4-5
years ago - it came with parsing LilyPond definitions: if you put in a
reference to a definition in two places Denemo would incorporate them by
reference. But the thin ice and rapidly changing LilyPond parser did for
The above idea falls short of the real object-oriented idea proposed by
Raboof - that would require a series of Denemo operators (e.g. transpose
and merge) that would create music out of the fragments. That may be
quite possible, requiring more thought (and going a bit beyond my
personal interests I have to confess).
On Mon, 2009-02-02 at 13:13 +0100, Nils Gey wrote:
> The following comes from the user "Raboof" from the LinuxMusiciansForum. He
> wanted to create a new notation editor, but I said maybe I know a place where
> innovative ideas gather...
> I think its a good start to have references and links... If you write
> something with a "Refrain" this could just be a reference to the first
> refrain. You could even "hide" the redundant parts and just place something
> like "16 measures REFRAIN [1-16]".
> Original Text:
> One thing that has always irked me about the popular notation editors is that
> a lot of the 'structure' of your song gets lost: when notes are copy-pasted
> (common in pop music :) ), their relationship is not recorded.
> In programmers' terms, this violates the "don't repeat yourself" mantra, and
> like when programming, it is error-prone and makes your score less
> maintainable. The one `notation editor' that is of help here is Lilypond, but
> editing Lilypond by hand is rather cumbersome, and most frontends either
> don't support these features or don't present enough guidance to use them
> I'm exploring the idea of building up a score out of 'fragments', where each
> 'fragment' might appear many times in a composition, sometimes 'processed'
> (merged with other fragments, transposed, etc). The main point is when you
> modify a fragment, this affects all locations in the song where the fragment
> is (directly or indirectly) used.
> I mocked up a small example to demonstrate how a simple 12-bar accompaniment
> can be built up by applying some simple operations (transposition, merging,
> repetition and concatenation) on a 2-bar fragment.
> When you'd now alter the 2-bar fragment at the bottom, the entire 12-bar
> block should change accordingly.
> This mockup serves only to show the general idea: the rendered notes aren't
> quite right and it doesn't show what the UI to interact with such a piece
> should look like. More on that later :).
> Denemo-devel mailing list