Re: [haskell-art] abstract music from csound et.al. (Was: ANN - csound-expression-3.1.0)

2013-12-13 Thread Stephen Tetley
Hi Evan

Ha, though miles away from being ready for public consumption my own
"tower of DSLs" built over Csound gained symbolic notes, chords,
trills and "Solo Parts" this week. Hopefully arpeggios, tremolos and
more should follow soon.

More concretely Roger Dannenberg (Score), Stephen Travis Pope (Smoke)
and Paul Hudak, of course, have made score languages with tangible
musical objects like chords, clusters, drum rolls etc.

Regarding your comment in the other thread Evan, David Seidel (aka
Mystery Bear) has made music with Csound that crossed over well enough
from "computer music" to feature on Kyle Gann's Postclassic radio when
it was running.

Best wishes

Stephen

On 14 December 2013 04:12, Evan Laforge  wrote:

> Csound's instruments, once you design them, are instruments in the
> restrictive sense, and in fact they come with a very limited score
> language.  Too limited---to use them according to "the rules", you'd
> need layers of libraries and abstractions above to express notes,
> phrases, ornaments, and melodies linguistically.  Or you could
> short-circuit all that by recording data from a physical instrument.
> I'm sort of working on the first approach, but I haven't seen examples
> of someone else trying that. ...

___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art


Re: [haskell-art] abstract music from csound et.al. (Was: ANN - csound-expression-3.1.0)

2013-12-13 Thread Evan Laforge
On Fri, Dec 13, 2013 at 2:07 PM, Henning Thielemann
 wrote:
> At the Linux Audio Conference 2013 in Graz someone recommended in his talk
> not to think of audio programs as software but as instruments. For programs
> users request more and more features, whereas for instruments the
> restriction on certain producible sounds is a feature.

>From my point of view, the restrictions that instruments provide are
only the very lowest level, and the majority of what makes an
instrument (and sound into music) is the layers of history, cultural
context, and training.  That's where most of the "creative
restriction" comes from.  A violin played by a south Indian musician
is a very different from the one played by a German concertmaster,
even if it's physically the same!

The software programs do provide restrictions of their own, but are
disconnected from the cultural context since they didn't evolve
together.  Popular electronic music evolved along with the
restrictions of keyboard synthesizers and hardware sequencers from the
70s, and now they co-evolve to support each other, as established
traditions do.  The synthesis languages lived mostly in academia and
had fewer restrictions and thus a harder job, and haven't really done
anything like that.  It's probably also influenced by the academic
idea that you create your own uncompromising aesthetic with little
reference to historical practice.  They might see it as an advantage
that you can't easily express the same old tunes!

So I would say that thinking of software as instruments is the wrong
level, you would use the software to build instruments, in the same
way that you use the instruments to build music, by applying higher
and higher levels of rules and conventions.  The promise of software
is that they all exist in the same system, not distributed across
instrument, composer, notation, and performance.

Csound's instruments, once you design them, are instruments in the
restrictive sense, and in fact they come with a very limited score
language.  Too limited---to use them according to "the rules", you'd
need layers of libraries and abstractions above to express notes,
phrases, ornaments, and melodies linguistically.  Or you could
short-circuit all that by recording data from a physical instrument.
I'm sort of working on the first approach, but I haven't seen examples
of someone else trying that.  Without either the first or the second
you're stuck at "assembly language" level, and the only thing easily
expressible is the sound-scapey, generative, or otherwise randomized
or repetitive music.  Not that it's bad, I like sound-scapes too, but
since they follow fewer rules I contend that their enjoyment is also
less nuanced.

___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art


[haskell-art] abstract music from csound et.al. (Was: ANN - csound-expression-3.1.0)

2013-12-13 Thread Henning Thielemann


On Fri, 13 Dec 2013, Evan Laforge wrote:


This is my experience too (though I'm a notation guy, I tried hard
with DAWs but still found them slow and awkward).  And I've never
heard any music out of csound or other text languages that isn't more
or less abstract and sound-designy.  Maybe there is someone out there
that manages to do it, but I haven't heard them.

Music, as always, is largely determined by the tools used to create it.


At the Linux Audio Conference 2013 in Graz someone recommended in his talk 
not to think of audio programs as software but as instruments. For 
programs users request more and more features, whereas for instruments the 
restriction on certain producible sounds is a feature.


___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art


Re: [haskell-art] ANN - csound-expression-3.1.0 - now with GUI elements

2013-12-13 Thread Evan Laforge
Nice, I like "tibetan", it's a nice exploration of the harmonic
series.  It doesn't sound remotely "tibetan" but it does sound
interesting.

On Thu, Dec 12, 2013 at 11:42 PM, Anton Kholomiov
 wrote:
> I have to admit that writing the music in text mode is far less
> productive than with interactive DAWs like Cubase or Reaper
> and you have no presets.

This is my experience too (though I'm a notation guy, I tried hard
with DAWs but still found them slow and awkward).  And I've never
heard any music out of csound or other text languages that isn't more
or less abstract and sound-designy.  Maybe there is someone out there
that manages to do it, but I haven't heard them.

Music, as always, is largely determined by the tools used to create it.

___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art