Re: restrainOpenStrings

[BB]

I just pointed out - I can live with this contradictories. So simply let 
me annul my question.


Thanks

On 13.09.2015 12:33, David Kastrup wrote:

BB  writes:


If one interprets the text of the manual the line
\set TabStaff.restrainOpenStrings = ##t
powers up the not really perfect working
\set TabStaff.minimumFret = #1
to work as one would expect by simply interpreting the text implies.

Huh?

I quote:

Even when ‘minimumFret’ is set, open strings are used whenever
 possible.  This behaviour can be changed by setting
 ‘restrainOpenStrings’ to ‘#t’.


But that does not depreciate the basic question about the logik. One
might extend the logik question  to ask why \set TabStaff.minimumFret
= #1 does not do what one would expect spontaneous from the
statement. The question why \set TabStaff.restrainOpenStrings = ##t
does not do what one would expect spontaneous  from the statement.

Anyway, as I just pointed out - I can live with this
contradictories. So simply let me annul my question.

There is no contradiction.  If you are playing around the fifth fret,
you can perfectly well still use empty strings.  So there is a separate
setting to stop that, like if you are playing barred.

I find absolutely nothing in the documentation that would suggest any
"contradiction" or whatever else.  Please quote any passages that would
make you think otherwise.




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

Re: restrainOpenStrings

[David Kastrup]

BB  writes:

> If one interprets the text of the manual the line
> \set TabStaff.restrainOpenStrings = ##t
> powers up the not really perfect working
> \set TabStaff.minimumFret = #1
> to work as one would expect by simply interpreting the text implies.

Huh?

I quote:

   Even when ‘minimumFret’ is set, open strings are used whenever
possible.  This behaviour can be changed by setting
‘restrainOpenStrings’ to ‘#t’.

> But that does not depreciate the basic question about the logik. One
> might extend the logik question  to ask why \set TabStaff.minimumFret
> = #1 does not do what one would expect spontaneous from the
> statement. The question why \set TabStaff.restrainOpenStrings = ##t
> does not do what one would expect spontaneous  from the statement.
>
> Anyway, as I just pointed out - I can live with this
> contradictories. So simply let me annul my question.

There is no contradiction.  If you are playing around the fifth fret,
you can perfectly well still use empty strings.  So there is a separate
setting to stop that, like if you are playing barred.

I find absolutely nothing in the documentation that would suggest any
"contradiction" or whatever else.  Please quote any passages that would
make you think otherwise.

-- 
David Kastrup

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

restrainOpenStrings

[BB]

I wonder that
\set TabStaff.restrainOpenStrings = ##t
is not enough to really avoid open strings?
It only works together with
\set TabStaff.minimumFret = #1

I can live with this need of this aditional line, but I find the logik 
is questionable. Is that done by will?


Regards

%

\version "2.19.25"

#(set-global-staff-size 22)

be-bass = \stringTuning 

BB-Bass = {
\key g \major
\clef bass
\relative c'
{
g,4 d  d' a |
\bar ":|."
}
}

\score {
  <<
  \new Staff {
\BB-Bass
  }
  \new TabStaff {
  \tabFullNotation
  \set TabStaff.stringTunings = #be-bass
  %\set TabStaff.minimumFret = #1
  \set TabStaff.restrainOpenStrings = ##t
  \BB-Bass
  }
  >>
}

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

Re: restrainOpenStrings

[David Kastrup]

BB  writes:

> I wonder that
> \set TabStaff.restrainOpenStrings = ##t
> is not enough to really avoid open strings?
> It only works together with
> \set TabStaff.minimumFret = #1
>
> I can live with this need of this aditional line, but I find the logik
> is questionable. Is that done by will?

What does the documentation have to say about it?

-- 
David Kastrup

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

Re: restrainOpenStrings

[David Kastrup]

BB  writes:

> I just pointed out - I can live with this contradictories. So simply
> let me annul my question.

LilyPond's behavior and documentation is not supposed to be
contradictory.  So please point out any actual contradictions in the
documentation or LilyPond's behavior so that they may be fixed.

-- 
David Kastrup

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

Re: restrainOpenStrings

[BB]

If one interprets the text of the manual the line
\set TabStaff.restrainOpenStrings = ##t
powers up the not really perfect working
\set TabStaff.minimumFret = #1
to work as one would expect by simply interpreting the text implies.

But that does not depreciate the basic question about the logik. One 
might extend the logik question  to ask why \set TabStaff.minimumFret = 
#1 does not do what one would expect spontaneous from the statement. The 
question why \set TabStaff.restrainOpenStrings = ##t does not do what 
one would expect spontaneous  from the statement.


Anyway, as I just pointed out - I can live with this contradictories. So 
simply let me annul my question.


Thanks.


On 13.09.2015 12:13, David Kastrup wrote:

BB  writes:


I wonder that
\set TabStaff.restrainOpenStrings = ##t
is not enough to really avoid open strings?
It only works together with
\set TabStaff.minimumFret = #1

I can live with this need of this aditional line, but I find the logik
is questionable. Is that done by will?

What does the documentation have to say about it?




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

RE: Clef symbol after a barline

[David Sumbler]

On Sat, 2015-09-12 at 14:10 -0700, Mark Stephen Mrotek wrote:
> David,
> 
> Here is a snippet. I am not sure where it is located in the manual, V 2.18.
> 
> \once \override Score.BreakAlignment #'break-align-orders = #(make-vector 3
> '( staff-bar
> clef
> key-cancellation
> key-signature
> time-signature))
> 
> The order of the items can be changed to suit needs. All of them need not be
> included.
> 
> Mark

That's pretty much what I had - except that I had not realised that I
could miss out the irrelevant items.  Thanks a lot.

David


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

Re: Unterminated tie

[David Sumbler]

On Sun, 2015-09-13 at 00:46 +0200, Thomas Morley wrote:
> 2015-09-13 0:11 GMT+02:00 David Sumbler :
> > I have yet another problem related to repeats.  The piece I am setting
> > has one instrument which is tied from the last note in the
> > first-time-bar to the note at the start of the repeat.  (Moving the
> > repeats does not help, because there are a lot of overlapping ties.)
> >
> > I tried to produce an unterminated tie in the last bar of the first
> > alternative by having a second, invisible voice with two tied notes in
> > the bar:
> >
> > \version "2.19.24"
> >
> > { g'1 ~|
> >   \repeat volta 2 { g'1 | d'1 | }
> >   \alternative {
> >   {
> >   << { g'1 } \\ { \override Dots.stencil = ##f
> >   \override Stem.stencil = ##f
> >   \override Flag.stencil = ##f
> >   g'2... ~ g'16
> >   \revert Flag.stencil
> >   \revert Stem.stencil
> >   \revert Dots.stencil
> >   } >> |
> >   } {
> >   a'1 |
> >   } }
> >   g'1 |
> > }
> >
> > So far, so good, but the note heads in the bar are still there of
> > course.  But when I add "\override NoteHead.stencil = ##f" the compiler
> > gives up with the message:
> >
> > Drawing systems...lilypond:
> > /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/skyline.cc:119:
> > void Building::precompute(Real, Real, Real, Real): Assertion `!isinf
> > (slope_) && !isnan (slope_)' failed.
> >
> > Why does this happen?  And is there perhaps a simpler way of producing
> > my unterminated tie?
> 
> If you set NoteHead.stencil #f, then the Tie has nothing to attach to.
> Use point-stencil instead.
> Scaling durations will save much code:
> 
> \version "2.19.24"
> 
> {
>   g'1 ~|
>   \repeat volta 2 { g'1 | d'1 | }
>   \alternative {
>   {
> g'1*15/16~
> \once \override Stem.stencil = #point-stencil
> \once \override Flag.stencil = #point-stencil
> \once \override NoteHead.stencil = #point-stencil
> \once \override Tie.minimum-length = 10
> g'16
>   }
>   { a'1 | }
>   }
>   g'1 |
> }
> 
> 
> Other possibility would be to use \repeatTie and use \shape on it.
> I doubt it would be the better one ...
> 
> Cheers,
>   Harm

That's brilliant - thank you so much.

I wasn't aware of point-stencil (or had forgotten about it).

The scaling of durations is a neat trick too - I hadn't thought of it.

I find that the override of the tie-length is unnecessary.

David


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

Re: questions about chord ties to null and Ped. glyph

[Alex Jones]

Thank you!!!

-akj

> On Sep 13, 2015, at 11:15 AM, David Kastrup  wrote:
> 
> \musicglyph #"pedal.Ped"

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

Re: OT: Beauty of programming languages

[Peter Gentry]

While we are at it

Age 73 - Married - North of England

previous life Senior Scientific Oficer - Heat Transfer
Mechanical Engineering Degree
Struggling clarinet player and general music lover

Started producing music scores using NoteWorthy Composer

Graduated to LilyPond some years ago - still very much on the learning curve.

Like many others have had a fair amout of programming experience on IBM and ICL 
mainframes, PDP8 mini computers BBC Microcomputers
and the works of Master Gates. Minimal exposure to the likes of unix and linux 
and cannot afford extortionate Macs.

Lilypond is a godsend and a wonderful example of open source software with so 
many contributing and providing help and advice to
hapless strugglers. Bravo.

Should any other clarinet players want some baroque music to play feel free to 
raid  http://sunscales.co.uk not all of the files are
finished and I'm sure many contain errors.  They also reflect my modest 
progress with LilyPond. There aren't many ly files but just
ask should you want them.

regards
Peter Gentry 



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

Re: restrainOpenStrings

[BB]

I read the manual. But please answer the question WHY should lilypond 
statements not do what the statement text straight implies?


Obviously you have not read my postings, as I have
1. pointed out that I can handle the "contradictories"
2. quotation: "So simply let me annul my question."

Cheers!

On 13.09.2015 13:56, Phil Holmes wrote:
I think the issue here is that David K has read the documentation (the 
NR, section 2.4.1) but BB probably hasn't, and is trying to guess what 
a lilypond command does from its name.  This is always likely to be 
problematical.


--
Phil Holmes

- Original Message -
*From:* BB 
*To:* David Kastrup 
*Cc:* lilypond-user Mailinglist 
*Sent:* Sunday, September 13, 2015 12:25 PM
*Subject:* Re: restrainOpenStrings

I try an explanation again:

If a user says
\set TabStaff.minimumFret = #5
I would expect that LP obeys and just uses no frets closer to the
nut tha five. As you wrote, LP is unobedient and uses open strings
against that imperative  TabStaff.minimumFret = #5 ? On the other
extreme if one sets
\set TabStaff.minimumFret = #5
in my short code example LP is fussy and omits the d that would
simply be feasible with the 3rd fret.
Why does LP use open strings (fret 0 = nut) lower than 5th fret,
but is not flexible enough to use 3rd string for d in my example -
certainly with a warning or simple notice? (Indeed there is a
warning that no string is defined for that note d ...). I think, a
positive warning in the sense " I cannot accomplish your wish for
d with minimum Fret = #5. I warn/inform you, that I will/can do it
with the 3rd fret. So please react if you do not like that". So I
can react and change something or I may agree. Beside: There is
simply no alternative to the 3rd fret in my example!

The same is true for
\set TabStaff.restrainOpenStrings = ##t
For me the text implies, that LP must not use open strings. In my
interpretation minimumFret has nothing to do with \set
TabStaff.minimumFret = #5 straight. I would expect, that LP will
obey and fullfill my wish "no open strings". Whereas "restrain" is
not a strong categorically prohibition, but is a bit softer -
maybe in the meaning "whenever possible". (A problem with this
only happens with the "last" string, i. e. 6th string on guitar or
the equivalent for other stringed instruments.)

That soft "whenever possible" I would like for \set
TabStaff.minimumFret as well.

Again, let me point out that I know the "contradictories"
("contradictories" in my view/logic) and therefore I can handle it.

Thanks.

On 13.09.2015 12:44, David Kastrup wrote:

BB  writes:


I just pointed out - I can live with this contradictories. So simply
let me annul my question.

LilyPond's behavior and documentation is not supposed to be
contradictory.  So please point out any actual contradictions in the
documentation or LilyPond's behavior so that they may be fixed.




___
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: restrainOpenStrings

[BB]

I try an explanation again:

If a user says
\set TabStaff.minimumFret = #5
I would expect that LP obeys and just uses no frets closer to the nut 
tha five. As you wrote, LP is unobedient and uses open strings against 
that imperative  TabStaff.minimumFret = #5 ? On the other extreme if one 
sets

\set TabStaff.minimumFret = #5
in my short code example LP is fussy and omits the d that would simply 
be feasible with the 3rd fret.
Why does LP use open strings (fret 0 = nut) lower than 5th fret, but is 
not flexible enough to use 3rd string for d in my example - certainly 
with a warning or simple notice? (Indeed there is a warning that no 
string is defined for that note d ...). I think, a positive warning in 
the sense " I cannot accomplish your wish for d with minimum Fret = #5. 
I warn/inform you, that I will/can do it with the 3rd fret. So please 
react if you do not like that". So I can react and change something or I 
may agree. Beside: There is simply no alternative to the 3rd fret in my 
example!


The same is true for
\set TabStaff.restrainOpenStrings = ##t
For me the text implies, that LP must not use open strings. In my 
interpretation minimumFret has nothing to do with \set 
TabStaff.minimumFret = #5 straight. I would expect, that LP will obey 
and fullfill my wish "no open strings". Whereas "restrain" is not a 
strong categorically prohibition, but is a bit softer - maybe in the 
meaning "whenever possible". (A problem with this only happens with the 
"last" string, i. e. 6th string on guitar or the equivalent for other 
stringed instruments.)


That soft "whenever possible" I would like for \set TabStaff.minimumFret 
as well.


Again, let me point out that I know the "contradictories" 
("contradictories" in my view/logic) and therefore I can handle it.


Thanks.
//
On 13.09.2015 12:44, David Kastrup wrote:

BB  writes:


I just pointed out - I can live with this contradictories. So simply
let me annul my question.

LilyPond's behavior and documentation is not supposed to be
contradictory.  So please point out any actual contradictions in the
documentation or LilyPond's behavior so that they may be fixed.



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

Re: restrainOpenStrings

[Phil Holmes]

I think the issue here is that David K has read the documentation (the NR, 
section 2.4.1) but BB probably hasn't, and is trying to guess what a lilypond 
command does from its name.  This is always likely to be problematical.

--
Phil Holmes


  - Original Message - 
  From: BB 
  To: David Kastrup 
  Cc: lilypond-user Mailinglist 
  Sent: Sunday, September 13, 2015 12:25 PM
  Subject: Re: restrainOpenStrings


  I try an explanation again:

  If a user says 
  \set TabStaff.minimumFret = #5
  I would expect that LP obeys and just uses no frets closer to the nut tha 
five. As you wrote, LP is unobedient and uses open strings against that 
imperative  TabStaff.minimumFret = #5 ? On the other extreme if one sets 
  \set TabStaff.minimumFret = #5
  in my short code example LP is fussy and omits the d that would simply be 
feasible with the 3rd fret. 
  Why does LP use open strings (fret 0 = nut) lower than 5th fret, but is not 
flexible enough to use 3rd string for d in my example - certainly with a 
warning or simple notice? (Indeed there is a warning that no string is defined 
for that note d ...). I think, a positive warning in the sense " I cannot 
accomplish your wish for d with minimum Fret = #5. I warn/inform you, that I 
will/can do it with the 3rd fret. So please react if you do not like that". So 
I can react and change something or I may agree. Beside: There is simply no 
alternative to the 3rd fret in my example! 

  The same is true for 
  \set TabStaff.restrainOpenStrings = ##t
  For me the text implies, that LP must not use open strings. In my 
interpretation minimumFret has nothing to do with \set TabStaff.minimumFret = 
#5 straight. I would expect, that LP will obey and fullfill my wish "no open 
strings". Whereas "restrain" is not a strong categorically prohibition, but is 
a bit softer - maybe in the meaning "whenever possible". (A problem with this 
only happens with the "last" string, i. e. 6th string on guitar or the 
equivalent for other stringed instruments.) 

  That soft "whenever possible" I would like for \set TabStaff.minimumFret as 
well.  

  Again, let me point out that I know the "contradictories" ("contradictories" 
in my view/logic) and therefore I can handle it. 

  Thanks.


  On 13.09.2015 12:44, David Kastrup wrote:

BB  writes:

I just pointed out - I can live with this contradictories. So simply
let me annul my question.
LilyPond's behavior and documentation is not supposed to be
contradictory.  So please point out any actual contradictions in the
documentation or LilyPond's behavior so that they may be fixed.





--


  ___
  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

questions about chord ties to null and Ped. glyph

[Alex Jones]

Two questions,

I’m trying to write a chord with a tie to null space (see pic below).  I tried
1 (<>) and only get one slur

then I tried
<< {e1 (<>)} \\ {g! (<>)} \\ {b (<>)} \\ {e (<>)} >>

and the notes are not vertically aligned

suggestions?

Second question: I’m trying to write a dynamic followed by a col Ped. notation. 
 Its hard to do this with the “sustain” commands, is there a way to get the Ped 
glyph in a markup?

Thanks!

-akj

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

Re: restrainOpenStrings

[Marc Hohl]

Am 13.09.2015 um 14:07 schrieb BB:

I read the manual. But please answer the question WHY should lilypond
 statements not do what the statement text straight implies?


IIRC, we discussed quite a lot about the new restrainOpenStrings
functionality and how to name this new property. There were some
proposals, and restrain... was chosen as the best fit.

It may not be the perfect choice, but then again, the manual explains in
more detail what the property is used for.

\set
TabStaff.allowOpenStringsInTheCalculationOfPossibleFretPositionsEvenIfMinimumFretIsSet
= ##t

would be quite a bit of stuff to type, but completely understandable
without the manual ;-)

I agree that the minimumFret/restrainOpenStrings way is not fully
convincing to me either, but I can't think of anything better. There are
cases where you need strings fretted above a minimum fret with or
without empty strings, so Lilypond should handle both.

Just my 2ct,

Marc


Obviously you have not read my postings, as I have 1. pointed out
that I can handle the "contradictories" 2. quotation: "So simply let
me annul my question."

Cheers!

On 13.09.2015 13:56, Phil Holmes wrote:

I think the issue here is that David K has read the documentation
(the NR, section 2.4.1) but BB probably hasn't, and is trying to
guess what a lilypond command does from its name.  This is always
likely to be problematical.

-- Phil Holmes

- Original Message - *From:* BB
 *To:* David Kastrup
 *Cc:* lilypond-user Mailinglist
 *Sent:* Sunday, September 13, 2015
12:25 PM *Subject:* Re: restrainOpenStrings

I try an explanation again:

If a user says \set TabStaff.minimumFret = #5 I would expect that
LP obeys and just uses no frets closer to the nut tha five. As you
wrote, LP is unobedient and uses open strings against that
imperative  TabStaff.minimumFret = #5 ? On the other extreme if one
sets \set TabStaff.minimumFret = #5 in my short code example LP is
fussy and omits the d that would simply be feasible with the 3rd
fret. Why does LP use open strings (fret 0 = nut) lower than 5th
fret, but is not flexible enough to use 3rd string for d in my
example - certainly with a warning or simple notice? (Indeed there
is a warning that no string is defined for that note d ...). I
think, a positive warning in the sense " I cannot accomplish your
wish for d with minimum Fret = #5. I warn/inform you, that I
will/can do it with the 3rd fret. So please react if you do not
like that". So I can react and change something or I may agree.
Beside: There is simply no alternative to the 3rd fret in my
example!

The same is true for \set TabStaff.restrainOpenStrings = ##t For me
the text implies, that LP must not use open strings. In my
interpretation minimumFret has nothing to do with \set
TabStaff.minimumFret = #5 straight. I would expect, that LP will
obey and fullfill my wish "no open strings". Whereas "restrain" is
not a strong categorically prohibition, but is a bit softer - maybe
in the meaning "whenever possible". (A problem with this only
happens with the "last" string, i. e. 6th string on guitar or the
equivalent for other stringed instruments.)

That soft "whenever possible" I would like for \set
TabStaff.minimumFret as well.

Again, let me point out that I know the "contradictories"
("contradictories" in my view/logic) and therefore I can handle
it.

Thanks.

On 13.09.2015 12:44, David Kastrup wrote:

BB  writes:


I just pointed out - I can live with this contradictories. So
simply let me annul my question.

LilyPond's behavior and documentation is not supposed to be
contradictory.  So please point out any actual contradictions in
the documentation or LilyPond's behavior so that they may be
fixed.







___

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




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

Re: questions about chord ties to null and Ped. glyph

[David Kastrup]

Alex Jones  writes:

> Two questions,
>
> I’m trying to write a chord with a tie to null space (see pic below). I tried
> 1 (<>) and only get one slur
>
> then I tried
> << {e1 (<>)} \\ {g! (<>)} \\ {b (<>)} \\ {e (<>)} >>
>
> and the notes are not vertically aligned
>
> suggestions?

\relative { 1\laissezVibrer }
> Second question: I’m trying to write a dynamic followed by a col
> Ped. notation. Its hard to do this with the “sustain” commands, is
> there a way to get the Ped glyph in a markup?

\markup \musicglyph #"pedal.Ped"

Cf


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

RE: Clef symbol after a barline

[Mark Stephen Mrotek]

Welcome!

Mark

-Original Message-
From: David Sumbler [mailto:da...@aeolia.co.uk] 
Sent: Sunday, September 13, 2015 6:21 AM
To: Mark Stephen Mrotek 
Cc: lilypond-user@gnu.org
Subject: RE: Clef symbol after a barline

On Sat, 2015-09-12 at 14:10 -0700, Mark Stephen Mrotek wrote:
> David,
> 
> Here is a snippet. I am not sure where it is located in the manual, V 2.18.
> 
> \once \override Score.BreakAlignment #'break-align-orders = 
> #(make-vector 3 '( staff-bar clef key-cancellation key-signature
> time-signature))
> 
> The order of the items can be changed to suit needs. All of them need 
> not be included.
> 
> Mark

That's pretty much what I had - except that I had not realised that I could 
miss out the irrelevant items.  Thanks a lot.

David


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

Re: Fwd: Re: OT: Beauty of programming languages

[Edward Ardzinski]

I'm just about 6 weeks shy of 50, been programming computers for close to 20
years. I have been involved with deep database design, GUI design, and
reporting over the years, I'm primarily a SQL jock now.

I picked up Lilypond in early 2006, if the modified dates on my files are
any indication.  I'm assiduous that way - It's helped narrow the genesis of
ideas.

Lilypond's set up immediately hooked me, I really have never used any other
manuscript programs, so my perspective is probably pretty limited.  And
unique - as a programmer I created my own text editor...now that the source
code is on a very old computer, I'm kind of locked into the very old LP
version I run...I did some experimenting with v2.12, so I think I could
convert, but at this point I have not had any limitations in 2.6.5.  (yes,
that old)...

I am primarily a rock bassist, but with some classical piano and trumpet
training,and I also can play guitar.  I developed my own template and
methods of taking a simple musical theme and weaving it into a 2-4 minute
song.  I'm trying to write out a cogent essay outlining the symbiotic
process between my music LP and the other software products I employ. 
Mainly I create midi files for a 3 part "power trio" - a treble part, a bass
part, and a 2 stave drum kit.  From there I use AcidPRO to create mp3's
files to hear, in a general way, the way the music sounds.



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Fwd-Re-OT-Beauty-of-programming-languages-tp181025p181091.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: Fwd: Re: OT: Beauty of programming languages

[Edward Ardzinski]

At this point I can't even locate the LP 2.6.5 install package - so I'll be
faced with a change when I need a new computer, and that is probably a
shockingly small number of days.

I figure I can figure something out for opening ly files - they are text
after all.  The custom editor was fun and all that, but it's been 6 years
since I did an update to that even, and now have a "code fragments" text
file I keep open.

I think my structured work of the last few years will be easier to port - I
can't even get good work done on some of my oldest work since I was writing
things out in such a verbose way.  I suspect I will need primarily to tweak
the template file for the little bits I've read on newer versions of LP. 
The version of AP I'm using also also ages old, so I might be porting in a
lot of ways.





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Fwd-Re-OT-Beauty-of-programming-languages-tp181025p181093.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: Fwd: Re: OT: Beauty of programming languages

[David Kastrup]

Edward Ardzinski  writes:

> Lilypond's set up immediately hooked me, I really have never used any
> other manuscript programs, so my perspective is probably pretty
> limited.  And unique - as a programmer I created my own text
> editor...now that the source code is on a very old computer, I'm kind
> of locked into the very old LP version I run...I did some
> experimenting with v2.12, so I think I could convert, but at this
> point I have not had any limitations in 2.6.5.  (yes, that old)...

10 years.  You know, if you created your own text editor on a very old
computer and still have the source code for it around: it's rather
likely that you can compile the bulk of the source code on a more modern
computer and get the screen/kbd code warped to the ncurses library or
similar.

Output quality has improved just the tiniest of bits since then.

> I am primarily a rock bassist, but with some classical piano and
> trumpet training,and I also can play guitar.  I developed my own
> template and methods of taking a simple musical theme and weaving it
> into a 2-4 minute song.  I'm trying to write out a cogent essay
> outlining the symbiotic process between my music LP and the other
> software products I employ.  Mainly I create midi files for a 3 part
> "power trio" - a treble part, a bass part, and a 2 stave drum kit.
> From there I use AcidPRO to create mp3's files to hear, in a general
> way, the way the music sounds.

In the last few years, Midi can be made to output a lot more of
articulations/dynamics and other niceties, and you can give various
instruments their own pan/balance.

-- 
David Kastrup

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

Re: OT: Beauty of programming languages

[Ralph Palmer]

On Sun, Sep 13, 2015 at 6:47 PM, Flaming Hakama by Elaine <
ela...@flaminghakama.com> wrote:

>
> Started composing in high school in the 1890s,
>
>
Really? Wow! (1980s?)

Ralph

-- 
Ralph Palmer
Brattleboro, VT
USA
palmer.r.vio...@gmail.com
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: OT: Beauty of programming languages

[Flaming Hakama by Elaine]

44 years old

Day job: web development, mostly JavaScript these days, but I've used quite
a number of others over the years (including APL).

Started composing in high school in the 1890s, primarily Jazz and chamber
music, with some larger works.  I've been using Lilypond to produce scores
for players, as well as to generate MIDI input for recordings.

My first exposure to music notation software was in college in the early
1990s, entering notes and rhythms in Finale for a professor (it was deemed
a waste of time to enter the articulations and dynamics, so those were done
by hand in ink).

I stuck with handwriting for many years--the only times I heard people talk
about Sibelius or Finale was to complain about it, so I was never curious
to re-evaluate, despite my process being pretty lame:  write music on paper
with pencil and ruler, then photocopy and scan it, then use photoshop to
add titles and text and deal with margins/sizing/pagination.

The need to transpose parts is what convinced me to switch to Lilypond,
some time around 2012.  I was introduced to Lilypond through a brass band I
played with that used it for its rep
http://brassliberation.org/sheetmusic.php

I've been largely happy with Lilypond for small and medium-scale projects.
There is of course a learning curve, but it is easy to consolidate
learnings, and keep developing better and better templates and techniques.
This mailing list is also wonderful.

The combination of working with larger scores, and using Lilypond for
workshopping and rearrangements is my current bete noir.


David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user