Hi Trevor,
thanks for sharing your thoughts with such an analytical insight.
So, still waiting for the system...:)
Really, there are some people interested in this stuff so would be
nice to have a wiki or something...
Best
-a-
On 30 Nov 2007, at 18:24, Trevor Bača wrote:
Hi Andrea and Miguel and Eyolf and everybody,
Sorry I've been absent from this thread for a bit; Andrea's
guessing right that I've been busy ...
:-)
Warning: lots of words, and it's all personal stuff, too.
Quite a few years ago I sat down and made the conscious decision
that trying to write out by hand the massive textural type of stuff
that I was writing was going to kill me. That realization started
me down the score formalization path -- modelling increasingly many
score elements as data structures in some programming language or
other. The initial efforts were all implemented in C ... most
definitely *not* because it was the language for the job ... but
because it was the language that I happened to know the best at the
time ... this being the mid- to late-nineties. And the output was
only MIDI for input to Finale. I know. Gasp.
I moved to Mathematica in 2001 and -- exactly like Miguel -- found
the language outstanding. There are tons of combinatorial functions
in Steve Skiena's Combinatorica package and -- more importantly --
the functional constructs are completely effortless. There's
something magical about watching Nest[ ] and NestWhile[ ] and Sow
[ ] and Reap[ ] do their work over huge music expressions ... and
render magic bits of score. And the notation input at this time
switched from Finale (after a brief stint with Sibelius ... which
helped not at all) to Leland Smith's SCORE, which I loved. The
SCORE GUI is crude. But the SCORE parameter description .pmx format
allowed for *very* minute control of absolutely every glyph on the
score ... and was clear-text.
But there were a couple of problems with the Mathematica / SCORE
approach. Debugging, to start with. The Mathematica model of
computation is just vastly different than anything I was used to.
And while most of the time I strongly benefited from the
differences -- literally EVERYTHING is an expression, the
functional constructs are effortless, etc -- what eventually
brought me down was not being able to profile and manage the
recursion in the structures that I kept building bigger and bigger.
In Java I would've just encapsulated more stuff in classes,
sprinkled some printfs all over the place and figured it out. But
precisely because you can express so much power in a single
expressions in Mma, stuff can become *extremely* difficult to
debug. (Though, as Miguel notes, Mathematica is increasingly
becoming an enviornment ... complete with what I hear is an ever-
better profiler ... so perhaps my management problems would be
somewhat ameliorated were I to go back now.)
Similar problem with SCORE -- though 20 years behind. The
SCORE .pmx formats read most nearly like Fortran (from what I've
been able to gather): rows and rows of nothing but numbers. So,
although the .pmx format is clear-text, it's almost strictly
*numeric* clear-text ... and deciphering whether a tuplet bracket
has nibs that point up, down, or disappear, and have a certain
length and thickness means examining your parameter 08 to find that
slots 6 through 10 have values 0, 0, 1.95, 1.95 and 1.83, all in a
row. Imagine if every Lily grob override had the format \override
08 #'3 = 1.95 instead of \override TupletBracket #'transparent =
##t ...
So (lack of) robustness drove me away from C / Finale and (lack of)
maintainability drove me away from Mathematica / SCORE.
Then I (re)discovered Lily in about 2006. And in the interests of
full disclosure I should mention that I had found Lily as early as
2001 ... but (and it kills me to say this, but there's a lesson in
here) both the tone of the docs and the examples on the site kept
me -- incorrectly -- from thinking that Lily would suit my
purposes. The tone seemed to have a "we're not really into modern
music so don't bother us" sorta feel to it. And the examples seemed
to be a couple of pages of absolutely beautifully engraved
Classical and Romantic stuff ... together with pages and pages and
pages of two-note examples of middle C slurring or beaming or
linking or whatever to another middle C. There just wasn't anything
there that jumped out at me and said "yep, you're gonna be able to
model whatever level of rhythmic complexity you want AND have it
turn out beautifully."
My understanding was wrong, of course. And the tone of the docs has
changed forever for the better. Lily turns out to be
extraordinarily friendly to composers of whatever stripe ... with
rhythmic (and other types of complexity) being no object.
Then I switched to python ... just like Andrea. There were a couple
of different reasons motivating the move. To start with, I had just
finished up a subsystem at work, all python (in my other life I do
engineering stuff). The work was realtime network stat analysis and
after deployment I was amazed at two things: (1) the code was
extraordinarily compressed (compared to, say, comparable Java) and
(2) it was turning out to be extremely maintainable. Oh, and easy
to trial (because of the interpreter and dynamic reloads) and easy
to debug. Turns out there are stories like this ("I ported my stuff
to python and the number of lines reduced by 10x") all over the
internet and so I ported my score modelling out of Mathematica and
into python. My way of working benefited as a result.
I've continued to model in python since then and I really have no
complaints. As the complexity of some of the music classes
increases I do sometimes find myself wanting explicit typing (which
is insane ... because one of the first things I liked about python
was the freedom *not* to worry about explicit typing) to protect
myself from my own mistakes. But it's quite a minor complaint;
almost always better is to go back in and simplify the data
structures in question.
A major benefit of python for most projects is the large and easy-
to-use standard library. But I have to admit that I get relatively
less use out of these ... largely because the music modelling work
is deeply symbolic (and not at all network based ... the fact that
it's easy to wrap SMPT headers around stuff and open and close
sockets without a billion parameters doesn't buy me much when I'm
building score).
Both Andrea and Víctor (Adán) are also putting python to good use,
and both seem quite happy with the language. Andrea has documented
the position of python in his overflow compositional and production
workflow, and it's very much worth taking a look at his papers to
see this in action.
* * *
Language considerations are interesting. And I think especially
good cases can be made for going with any of the LISP-derived
functional languages ... with the EXTREMELY important caveat that
*true oop-style classes be available* -- the act of composition is
almost inherently functional (in the programming sense of the term)
for a great many of us ... but to lose access to oop classes (as
possibly the single greatest organizer available for code in
general) simply makes no sense whatsoever (at least to me).
OpenMusic falls into precisely this happy category, and the
presence of the GUI renders the system *much* more accessible to
newcomers. And I would definitely recommend interested composes to
the system. (Of course, there's also something deeply important
about authoring one's *own* models of musical score ... rather than
adopting the models of others ... which is probably why I've never
worked a complete piece in OM myself ... but this is a whole other
topic and it seems to me that the importance of invention and the
practicality of code reuse are at direct odds for us at composers
whenever we consider working within someone else's framework ...)
That said, probably the most improtant thing I can add to a thread
on formalization (or algorithmics or whatever this actually is) is
this: the language doesn't fundamentally matter; what matters is
the *score model*.
After going through implementations in C and Mathematica and python
(and now some ruby, with my eyes on OCaml in the future) the
biggest lesson I've taken is that *what* we choose to model -- and
what we don't -- is a core reflection of what the (technique, at
least) of our compositions will be about. As an example, beaming
has been extremely important to me over the last several years as a
way of surfacing broken, dismembered and sometimes very beautiful,
errorded earlier stages of the compositional process in the final
score (I work layer complete passes over the entire score again and
again to get results here). And getting that particular part of the
notation to actually carry the burden of information was quite
difficult ... until I made the decision to formally model beam
constructs as abstract but first-class elements of the score,
complete with duration and membership attributes and the whole bit.
(As a more recent example, I've recently moved to modelling
arbitrary brackets and spanners as classes that be can interrogated
to find things like "is the first / last / whatever note that you
encompass a member of this set of pitches or does it contain these
articulations or does it appear within a run of notes matching this
pattern ...). The language here matters very little; the model of
the objects and transformations, on the other hand, matters a great
deal.
* * *
So there's my input. If I ever do get the models (and
implementation) to a point where I feel comfortable releasing, I'll
try to do so, following Andrea's advice, probably as a regular
project on sourceforge. Though it's looking like I'm still many,
many months away ...
I'd also like to point to Víctor (if he's been reading the thread)
as a great source of friendship and collaboration on all of these
points. We've worked together and shared ideas on the fundamental
*model* of the score for years. And my work has benefited
considerably from many of those conversations ...
Trevor.
On Nov 29, 2007 3:18 PM, Andrea Valle <[EMAIL PROTECTED]> wrote:
(Still can't understand this list behaviour of replying to the
author and not to the list...)
Hi Miguel,
I don't like lisp-like languages. I really prefer OO languages.
More, I've always find difficult to understand lily internals (no
figure, scheme stuff etc).
So, for my personal preference indeed, I have used Python. There's
also to say that Trevor B. has an incredible on going project
integrating Python and Lilypond.
I started pressing him to release it under sourceforge but
evidently he is busy...:-)
For the last project I used SuperCollider, an audio prog language
which has a Smalltalk-like syntax: this allowed me to integrate
notation with audio analysis and synthesis.
If you want to integrate very complex audio stuff, use a very
sophisticated language and then output to lily, I'll suggest SC.
More, I wrote some classes in SC which allowed me to import/export
with Praat. So, I have all the audio analysis I need.
You may check this:
http://www.nabble.com/python-%3Elilypond-tf2401329.html#a6698740
http://archive.contextgarden.net/message/
20070504.140614.ff7f1029.en.html
There are some people interested in stuff like this. We could share
some infos on a wiki or something.
Best
-a-
On 29 Nov 2007, at 20:18, Miguel Lopes Santos Ramos wrote:
From: Andrea Valle < [EMAIL PROTECTED]>
I typically use lilypond for algorithmic composition.
I use Python to =20= script lily.
Sorry to meddle in the thread.
Why Python and not the built-in Scheme interpreter?
Personal preference or something you would advise other people to?
I would be interested to know. I've used Excel outputting to
Cakewalk in the
distant past, then LISP with output hand copied to score, more
recently
Mathematica with cut-and-paste to lilypond.
Mathematica is great, has lots of combinatorial functions and also
does
audio, but I'm finding some problems keeping things working across
versions and
it really is not free at all; it's becoming more an environment
than a
programming language and it's too expensive to use only as a
programming
language.
I'm considering either moving back to Common LISP with Lilypond
output
or using the built-in Scheme interpreter; but although I have a 15
+ year
programming background, I'm not finding it very easy to use
Lilypond Scheme.
Greetings,
Miguel Ramos
Lisboa
--------------------------------------------------
Andrea Valle
--------------------------------------------------
CIRMA - DAMS
Università degli Studi di Torino
--> http://www.cirma.unito.it/andrea/
--> [EMAIL PROTECTED]
--------------------------------------------------
I did this interview where I just mentioned that I read Foucault .
Who doesn't in university , right? I was in this strip club giving
this guy a lap dance and all he wanted to do was to discuss
Foucault with me. Well, I can stand naked and do my little dance,
or I can discuss Foucault, but not at the same time; too much
information.
(Annabel Chong)
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
Trevor Bača
[EMAIL PROTECTED]
--------------------------------------------------
Andrea Valle
--------------------------------------------------
CIRMA - DAMS
Università degli Studi di Torino
--> http://www.cirma.unito.it/andrea/
--> [EMAIL PROTECTED]
--------------------------------------------------
I did this interview where I just mentioned that I read Foucault. Who
doesn't in university, right? I was in this strip club giving this
guy a lap dance and all he wanted to do was to discuss Foucault with
me. Well, I can stand naked and do my little dance, or I can discuss
Foucault, but not at the same time; too much information.
(Annabel Chong)
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
