|
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 < address@hidden> 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:
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:
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 --------------------------------------------------
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
address@hidden
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
Trevor Bača
address@hidden -------------------------------------------------- Andrea Valle -------------------------------------------------- CIRMA - DAMS Università degli Studi di Torino --------------------------------------------------
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)
|