Re: Open Sound control?

[andersvi]

> "D" == David Wright  writes:

D> If one can save OSC files like MIDI files, could you please send
D> me one, and some instructions on how to play it.



score-with-notes.osc
Description: Binary data

If you by "play it" mean getting sound from it, set up whatever OSC
enabled player you prefer, making sure the OSC-path \myNote reacts to
something having a start time and a 'freq' parameter.

For fun i included messages and parameters with symbolic names for
time-signatures, beams, and tuplets in this prototype file, ie. it could
be used to carry layout info for notation for LY.

D> It's a bit premature for me to try to compare the protocols or
D> the formats as I have no experience with OSC, only MIDI.

MIDI is fixed.  OSC (the protocol) doesn't care, which is perhaps
confusing, but is what could make it useful in this context.

If you want to gain a basic understanding you can check out
SuperCollider, esp. the docs relating to NRT synthesis, perhaps also
simple clients like Matt Wrights sendOSC.

Cheers,

-anders
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing basic distance between stanzas

[Joshua Nichols]

On Tue, Aug 16, 2016 at 9:06 PM, David Nalesnik 
wrote:

> \layout {
>   \context {
> \Lyrics
>   \override VerticalAxisGroup #'nonstaff-nonstaff-spacing =
> #'((basic-distance . 5))
>   }
>   }
>

​That worked very well! Thanks!

Can anyone comment on why \override VerticalAxisGroup #'minimum-Y-extent =
#'(-5 . 40) didn't work?​



IX,

Josh
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing basic distance between stanzas

[David Nalesnik]

On Tue, Aug 16, 2016 at 8:58 PM, Joshua Nichols
 wrote:
> Thanks, I did look into this, and instead of a warning, I get no change.
>
> See below for what I used.
>
> \version "2.18.2"
>
> notesA = {
>   c'
> }
>
> vOne = \lyricmode {
>   a
> }
>
> vTwo = \lyricmode {
>   b
> }
>
> \score {
>   <<
> \new Voice = "mel" { \notesA }
> \new Lyrics \lyricsto "mel" { \vOne }
> \new Lyrics \lyricsto "mel" { \vTwo }
>
>
>   >>
>   \layout {
>   \context {
> \Lyrics
>   \override VerticalAxisGroup #'minimum-Y-extent = #'(-5 . 40)
>   }
>   }
> }
>
>
> IX,
>

For your layout block, try (as one possibility):

 \layout {
  \context {
\Lyrics
  \override VerticalAxisGroup #'nonstaff-nonstaff-spacing =
#'((basic-distance . 5))
  }
  }

The relevant section in the Notation Reference is
http://lilypond.org/doc/v2.18/Documentation/notation/flexible-vertical-spacing-within-systems#spacing-of-non_002dstaff-lines

Hope this helps!

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing basic distance between stanzas

[Joshua Nichols]

Thanks, I did look into this, and instead of a warning, I get no change.

See below for what I used.

\version "2.18.2"

notesA = {
  c'
}

vOne = \lyricmode {
  a
}

vTwo = \lyricmode {
  b
}

\score {
  <<
\new Voice = "mel" { \notesA }
\new Lyrics \lyricsto "mel" { \vOne }
\new Lyrics \lyricsto "mel" { \vTwo }


  >>
  \layout {
  \context {
\Lyrics
  \override VerticalAxisGroup #'minimum-Y-extent = #'(-5 . 40)
  }
  }
}


IX,

Josh

On Tue, Aug 16, 2016 at 8:56 PM, David Nalesnik 
wrote:

> Hi Josh,
>
> On Tue, Aug 16, 2016 at 8:34 PM, Joshua Nichols
>  wrote:
> > I am looking for a tweak to decrease or increase the vertical distance
> > between multiple stanzas.
> >
> > I found this online (not in the manual):
> >
> > \context {
> > \Lyrics
> > minimumVerticalExtent = #'(0 . 0)
> >   }
> >
> > But, when I compile (with any number in the variable) I get this message:
> >
> > warning: cannot find property type-check for `minimumVerticalExtent'
> > (translation-type?). perhaps a typing error?
> >
> > warning: skipping assignment
> >
>
> I think what you found online applies to any extremely old version of
> LilyPond.  I find this thread:
> https://lists.gnu.org/archive/html/bug-lilypond/2005-11/msg00119.html
> which may be of help.  (I haven't tried it to see if the solution
> therein is still current.)
>
> David
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing basic distance between stanzas

[David Nalesnik]

Hi Josh,

On Tue, Aug 16, 2016 at 8:34 PM, Joshua Nichols
 wrote:
> I am looking for a tweak to decrease or increase the vertical distance
> between multiple stanzas.
>
> I found this online (not in the manual):
>
> \context {
> \Lyrics
> minimumVerticalExtent = #'(0 . 0)
>   }
>
> But, when I compile (with any number in the variable) I get this message:
>
> warning: cannot find property type-check for `minimumVerticalExtent'
> (translation-type?). perhaps a typing error?
>
> warning: skipping assignment
>

I think what you found online applies to any extremely old version of
LilyPond.  I find this thread:
https://lists.gnu.org/archive/html/bug-lilypond/2005-11/msg00119.html
which may be of help.  (I haven't tried it to see if the solution
therein is still current.)

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Changing basic distance between stanzas

[Joshua Nichols]

I am looking for a tweak to decrease or increase the vertical distance
between multiple stanzas.

I found this online (not in the manual):

\context {
\Lyrics
minimumVerticalExtent = #'(0 . 0)
  }

​But, when I compile (with any number in the variable) I get this message:

warning: cannot find property type-check for `minimumVerticalExtent'
(translation-type?). perhaps a typing error?

warning: skipping assignment


Here is an example:


\version "2.18.2"

notesA = {
  c'
}

vOne = \lyricmode {
  a
}

vTwo = \lyricmode {
  b
}

\score {
  <<
\new Voice = "mel" { \notesA }
\new Lyrics \lyricsto "mel" { \vOne }
\new Lyrics \lyricsto "mel" { \vTwo }


  >>
  \layout {
  \context {
  \Lyrics
  minimumVerticalExtent = #'(0 . 0)
  }
}
}


Help?


​Sincerely,

Josh
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

MusicXML2Ly: Problem with minor chords

[Johan Vromans]

Hi,

In the attached XML, the minor D chord

  

  D

minor
  

is translated into

  d:m5

and apparently not understood -- lilypond renders it as a major D chord
without warning.

Dm(maj7) becomes d:maj7m5.

A similar thing happens to half-diminished chords: Bm7b5 becomes b:dim5m7.

Is this a known problem? Googling for "musicxml2ly minor" did not return
anything relevant.

-- Johan
\version "2.19.45"
% automatically converted by musicxml2ly from x.xml
\pointAndClickOff

\header {
encodingsoftware =  "MuseScore 2.0.3"
source =  "http://musescore.com/score/1578186;
copyright =  "Círculo da Música - 2011"
encodingdate =  "2016-08-16"
}

PartPOneVoiceOne =  \relative a {
\clef "treble" \key f \major \numericTimeSignature\time 4/4 \partial
8 a8 \bar "||"
a'8 f8 d2. }

PartPOneVoiceOneChords =  \chordmode {
\partial 8 s8 \bar "||"
d8:m5 s8 }


% The score definition
\score {
<<

\context ChordNames = "PartPOneVoiceOneChords" { \PartPOneVoiceOneChords}
\new Staff
<<
\set Staff.instrumentName = "Guitar"

\context Staff << 
\mergeDifferentlyDottedOn\mergeDifferentlyHeadedOn
\context Voice = "PartPOneVoiceOne" {  \PartPOneVoiceOne }
>>
>>

>>
\layout {}
% To create MIDI output, uncomment the following line:
%  \midi {\tempo 4 = 100 }
}



minor.pdf
Description: Adobe PDF document


minor.xml
Description: XML document
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Custom glyph depending on the 'glyph-name

[Pierre Perol-Schneider]

Ok I got it. Sorry for the noise.
Cheers,
Pierre

2016-08-16 22:06 GMT+02:00 Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com>:

> Hi,
>
> I'd like to customize the clefs depending on their glyph-name:
>
> %%
> \version "2.19.46"
>
> my-clef-G = \markup "G"
>
> my-clef-F = \markup "F"
>
> \score {
>   \new PianoStaff <<
> \new Staff { c' }
> \new Staff { \clef F c' }
>   >>
>   \layout {
> \context {
>   \Score
>   \override Clef.stencil =
> #(lambda (grob)
>(let ((glyph (ly:grob-property grob 'glyph-name)))
>  (case glyph
>(("clefs.G") (grob-interpret-markup grob my-clef-G))
>(("clefs.F") (grob-interpret-markup grob my-clef-F))
>(else (ly:clef::print grob)
> }
>   }
> }
> %%
>
> But nothing happend.
> Any idea?
> Thanks in advance,
>
> Cheers,
> Pierre
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Compiling against guile-2.*

[Urs Liska]

Am 16. August 2016 22:21:13 MESZ, schrieb Jacques Menu Muzhic 
:
>Hello Andrew,
>
>Guile 2.x features semantic changes (in memory management IIRC) that
>prevent LP from being able to use it, DK will tell you more.

... or simply search the archives for this recurring nasty issue. 

Currently your only option seems to be keeping Guile deliberately old (or try 
having both 1.8 and 2.x installed in parallel (otherwise other programs might 
complain).

>
>JM
>
>> Le 16 août 2016 à 22:03, N. Andrew Walsh  a
>écrit :
>> 
>> Hi List,
>> 
>> so I'm compiling a "live" build of Lily that seems to build from git,
>and I got this error:
>> 
>> WARNING: Please consider installing optional programs or files: 
>guile < 1.9.0 (installed: 2.0.12) texi2html dblatex lh CTAN package
>(texlive-lang-cyrillic or texlive-texmf-fonts)
>> 
>> ERROR: Please install required programs:  guile-config < 1.9.0
>(installed: 2.0.12) (guile-devel, guile-dev or libguile-dev package)
>GUILE-with-rational-bugfix
>> 
>> See INSTALL.txt for more information on how to build LilyPond
>> 
>> 
>> So, it appears that Lily won't build against guile-2.*, yes? Is this
>a known issue? Is there a workaround, besides blocking guile from
>updating past 1.9?
>> 
>> Cheers,
>> 
>> A
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Compiling against guile-2.*

[Jacques Menu Muzhic]

Hello Andrew,

Guile 2.x features semantic changes (in memory management IIRC) that prevent LP 
from being able to use it, DK will tell you more.

JM

> Le 16 août 2016 à 22:03, N. Andrew Walsh  a écrit :
> 
> Hi List,
> 
> so I'm compiling a "live" build of Lily that seems to build from git, and I 
> got this error:
> 
> WARNING: Please consider installing optional programs or files:  guile < 
> 1.9.0 (installed: 2.0.12) texi2html dblatex lh CTAN package 
> (texlive-lang-cyrillic or texlive-texmf-fonts)
> 
> ERROR: Please install required programs:  guile-config < 1.9.0 (installed: 
> 2.0.12) (guile-devel, guile-dev or libguile-dev package) 
> GUILE-with-rational-bugfix
> 
> See INSTALL.txt for more information on how to build LilyPond
> 
> 
> So, it appears that Lily won't build against guile-2.*, yes? Is this a known 
> issue? Is there a workaround, besides blocking guile from updating past 1.9?
> 
> Cheers,
> 
> A
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Keep alive together - call for use cases

[Kieren MacMillan]

Hi David (et al.),

> (The last line of the thread made me chuckle and sigh.)

=)

Here’s a later incarnation of the same thread/topic:


Still unresolved… sigh.
But I have great hopes for Mark’s work on this!

Best,
Kieren.



Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Custom glyph depending on the 'glyph-name

[Pierre Perol-Schneider]

Hi,

I'd like to customize the clefs depending on their glyph-name:

%%
\version "2.19.46"

my-clef-G = \markup "G"

my-clef-F = \markup "F"

\score {
  \new PianoStaff <<
\new Staff { c' }
\new Staff { \clef F c' }
  >>
  \layout {
\context {
  \Score
  \override Clef.stencil =
#(lambda (grob)
   (let ((glyph (ly:grob-property grob 'glyph-name)))
 (case glyph
   (("clefs.G") (grob-interpret-markup grob my-clef-G))
   (("clefs.F") (grob-interpret-markup grob my-clef-F))
   (else (ly:clef::print grob)
}
  }
}
%%

But nothing happend.
Any idea?
Thanks in advance,

Cheers,
Pierre
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Compiling against guile-2.*

[N. Andrew Walsh]

Hi List,

so I'm compiling a "live" build of Lily that seems to build from git, and I
got this error:

WARNING: Please consider installing optional programs or files:  guile <
1.9.0 (installed: 2.0.12) texi2html dblatex lh CTAN package
(texlive-lang-cyrillic or texlive-texmf-fonts)

ERROR: Please install required programs:  guile-config < 1.9.0 (installed:
2.0.12) (guile-devel, guile-dev or libguile-dev package)
GUILE-with-rational-bugfix

See INSTALL.txt for more information on how to build LilyPond


So, it appears that Lily won't build against guile-2.*, yes? Is this a
known issue? Is there a workaround, besides blocking guile from updating
past 1.9?

Cheers,

A
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Keep alive together - call for use cases

[David Wright]

On Tue 16 Aug 2016 at 15:00:05 (-0400), Kieren MacMillan wrote:
> On Aug 16, 2016, at 2:50 PM, tisimst  wrote:
> > I'll just re-state my earlier use-case (in the devel- mailing list) for 
> > good measure that extends divisi staves.
> 
> Yes. On a related note, see the thread I started a few years ago (still open, 
> ultimately) on choral divisi: 
> 

I took a look at that thread: I can't find the string "indivisible" in
the 2.19.44 PDFs. Do you have a reference.

(The last line of the thread made me chuckle and sigh.)

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Keep alive together - call for use cases

[Mark Knoop]

At 12:13 on 16 Aug 2016, tisimst wrote:
>A great example (better and more likely to happen than mine)! Maybe
>you'll be able to check this item off you wish-list soon!

Thanks both for those. I probably won't do anything on this for the
next couple of days, so feel free to add more thoughts if you have
them. 

-- 
Mark Knoop

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Keep alive together - call for use cases

[tisimst]

On Tue, Aug 16, 2016 at 1:01 PM, Kieren MacMillan [via Lilypond] <
ml-node+s1069038n193727...@n5.nabble.com> wrote:

>
> On Aug 16, 2016, at 2:50 PM, tisimst <[hidden email]
> > wrote:
> > I'll just re-state my earlier use-case (in the devel- mailing list) for
> good measure that extends divisi staves.
>
> Yes. On a related note, see the thread I started a few years ago (still
> open, ultimately) on choral divisi:  html/lilypond-user/2014-12/msg00481.html>
>

A great example (better and more likely to happen than mine)! Maybe you'll
be able to check this item off you wish-list soon!




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Keep-alive-together-call-for-use-cases-tp193723p193728.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Keep alive together - call for use cases

[Kieren MacMillan]

Hi Abraham,

On Aug 16, 2016, at 2:50 PM, tisimst  wrote:
> I'll just re-state my earlier use-case (in the devel- mailing list) for good 
> measure that extends divisi staves.

Yes. On a related note, see the thread I started a few years ago (still open, 
ultimately) on choral divisi: 


Best,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Keep alive together - call for use cases

[tisimst]

On Tue, Aug 16, 2016 at 12:22 PM, Kieren MacMillan [via Lilypond] <
ml-node+s1069038n193724...@n5.nabble.com> wrote:

> Hi Mark,
>
> > I've been working on some patches to enable more flexible uses
> > for the Keep_alive_together_engraver.
>
> Thank you!
>
> > if I could ask users for any situations where they can imagine this
> > engraver helping, that currently don't work, or don't work easily.
>
> 2. The “divisi staves” use-case is also a primary feature/request for me.
> Similar/analogous use-cases: a two-stave harp part compressing (if
> necessary) to a single staff in the full score.
>

I'll just re-state my earlier use-case (in the devel- mailing list) for
good measure that extends divisi staves.

Let's say I have a 4-horn group. The way these appear in the score depends
on the complexity of their parts, in the following configurations:

1. Each has their own staff
2. They can be grouped into a 1/3 staff and 2/4 staff.
3. They can be grouped together into a single staff.

I imagine them falling into a "keep-alive-tree" like this:

All Horns Group staff
|
|-- Horns 1/3 Joint Staff
|  |
|  |-- Horn 1 Staff
|  |-- Horn 3 Staff
|
|-- Horns 2/4 Joint Staff
   |
   |-- Horn 2 Staff
   |-- Horn 4 Staff

The expected behavior in this (albeit hypothetical) situation would
automatically allow for each branch to hide its own higher nodes while
allowing the other branches to join together at their highest available
node.

For example, say I want to show the Horn 1 part in its own staff. This
would FORCE Horn 3 to show up on its own staff, but would ALLOW Horns 2/4
to appear on their joint staff, to get:

- Horn 1 Staff
- Horn 3 Staff
- Horns 2/4 Staff

Alternatively, Horn 3 could jump to the joint staff to minimize the number
of extra staves, like:

- Horn 1 Staff
- Horns 2/3/4 Staff

As discussed before, I couldn't find a good way to allow this kind of
"nested" divisi functionality because it seemed like the trigger acted more
like a global on/off switch. I realize this could really be a coding
nightmare, but could be a really helpful feature, too, for automatically
splitting/combining frenched staves.

Forgive me if I didn't explain that very well.

Best,
Abraham




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Keep-alive-together-call-for-use-cases-tp193723p193726.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Keep alive together - call for use cases

[Kieren MacMillan]

Hi Mark,

> I've been working on some patches to enable more flexible uses
> for the Keep_alive_together_engraver.

Thank you!

> if I could ask users for any situations where they can imagine this
> engraver helping, that currently don't work, or don't work easily.

1a. The "frenched score with ScoreMarks / MarkLine / whatever” use-case is my 
main one. (This use-case would, I assume, include “large time signature” lines, 
chord symbols, etc.?)

1b. Essentially identical — but not “marks” exactly — is the “dialogue” 
(TextLine) above/below a theatre work (e.g., musical, opera, narrated). Again, 
in a frenched score situation, that line should live and die with the “last 
context standing”.

2. The “divisi staves” use-case is also a primary feature/request for me. 
Similar/analogous use-cases: a two-stave harp part compressing (if necessary) 
to a single staff in the full score.

To be honest, I can’t really think of any other significantly different 
use-cases at the moment… but I have no doubt that they’re out there, and if I 
think of one, I’ll be sure to let you know about it.

Thanks! Can’t wait for this feature to be available “in the trenches".  =)
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Keep alive together - call for use cases

[Mark Knoop]

I've been working on some patches to enable more flexible uses for the
Keep_alive_together_engraver. Whilst I've achieved my particular use
case, David K is (rightly) keen that any changes might also address (or
at least not rule out) other potential improvements.

(If you're interested in the code, look here:
https://codereview.appspot.com/308910043/)

So if I could ask users for any situations where they can imagine this
engraver helping, that currently don't work, or don't work easily. I'll
start by describing my case, which came up on the list recently.

Duplicating rehearsal, tempo, volta marks etc at multiple vertical
positions in an orchestral score is possible with a custom MarkLine
context (http://lsr.di.unimi.it/LSR/Item?id=1010), however this
technique currently doesn't work in a Frenched score, as there may be
passages where e.g. the brass are tacet so two MarkLines would be shown
together. My fix makes it possible to set a context (Staff or MarkLine)
to be kept alive only while there is another Staff in the group.

See also the temporary divisi staves example here:
http://lilypond.org/doc/v2.19/input/regression/a6/lily-436997bb.ly
as another use of the engraver.

Many thanks for your input.

--
Mark Knoop

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Open Sound control?

[andersvi]

> "D" == David Kastrup  writes:

D> MusicXML export would likely be quite more useful for letting
D> LilyPond interface with other applications while preserving more
D> information about the original input.

Obviously.  I'm commenting on a misunderstanding vs. potential use of
OSC raised in this thread.

-anders


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Bay Area

[Urs Liska]

Hi everyone,

I'm really looking forward to attend the GSoC mentors summit on the last
weekend of October in Sunnyvale. I intend to be in the Bay Area somewhat
earlier, depending on how many days of leave I can negotiate with my
family ;-)

So I expect to be around SF ca. Oct 25-27(28) and would be happy meeting
LilyPond people during these days. I'll be mainly interested in
sight-seeing at that occasion, but talking about LilyPond is of course
not prohibited!

Please get in touch with me if you're interested in meeting me, if you
have a few spare hours to show me something interesting etc.

For social as well as economic considerations I'd also be glad if
someone would be able to provide me with a bed for one or more night(s).
But I'll at the same time look for commercial accomodation right now, as
there seem to be *still* some reasonably priced beds available on AirBnB ...

Best
Urs


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Open Sound control?

[David Kastrup]

ander...@notam02.no writes:

>> "D" == David Wright  writes:
>
> D> I've googled around for a file format, but all I find are
> D> applications and program fragments. OK, an application might be
> D> able to store an OSC protocol stream in a file, but that does not
> D> make that a file format.
>
> OSC has no more need for a special file format than does my TODO list.
>
> The question was whether OSC could be useful with LY, which it surely
> would be.  Esp. compared to MIDI, where any notation quality apart from
> delta-time, coarse pitch values and dynamics are eraded.

LilyPond does not use Midi as a storage format but as an output format,
just like PDF is an output format.  The salient point of having a Midi
backend is not to store information but to pass it on.  Without a large
body of soft- and hardware able to process the resulting OSC files, this
is a pretty pointless exercise.  MusicXML export would likely be quite
more useful for letting LilyPond interface with other applications while
preserving more information about the original input.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user