For my own part, Csound itself is sufficient for instrument 
creation, as are Pd, and any of the other synthesis programs 
I've run across.  Score generation is quite another thing, 
however.  Whether or not you're doing algorithmic composition, 
of any type, you'd be insane (sooner or later) to try to do so 
just using Csound.  So, some other 'composition software' is 
almost required.

In the years that I've been playing with computers, I've looked 
at many different languages (including Haskell), and even used a 
few.  What I've noticed, and have seen written in print, is that 
the tasks that are made easier by using a computer fall into a 
few different types..broadly speaking, these are moving data, 
mathematical manipulation (calculating), making decisions 
(branching), and repeating an action (looping).  All the 
languages I've ever seen implement these activities in one way 
or another.  So, unless you can find some mission critical 
reason (such as realtime processing) to use one particular 
language, it really doesn't matter which you use..QBASIC is as 
good as any other!

So, my own approach is to use plain old English to decide what I 
want to happen, then refine it to pseudo-code, and then 
translate it into whatever language I feel most attracted to at 
the time.  To really decide which is best (for a given project), 
you'd really need to feel equally comfortable in all of them, 
and then see which one, if any, produces what you feel to be the 
best result for the time spent (based on whatever criteria you 
decide to use).  This is far too much an academic argument for 
me to spend that kind of time..especially since the 'winner' 
might not be the best one for my next project!!

Which, finally, leads me to agree with a previous post about 
this question that recommended C for speed critical routine 
(Assembly is faster, but not portable), and Python (currently 
the most popular and user friendly of the procedural languages) 
for everything else.  Haskell does make 'proving' your code a 
snap, and is very concise..but concise Haskell code is, to me, 
just as cryptic as a lot of C code I've seen.

I enjoy exploring languages..human and computer.., but when I 
want to produce music I want to think about music..not code, so 
I just use what I already know.

I hope this POV helps a little.
Bob Foose

Well its not totally impossible to write a score by hand. In classical
music composers always wind up writing a lot "by hand." But its
madness not to speed up the process.

I found Blue to be the best compositon tool for my needs. I still like
using images to write the music, so I like being able to use the piano
roll interface for things.

The patterns and tracker are cool as well. I'm just getting into
algorithmic/mathematical composition, so when I start coding music the
python and javascript embedded in Blue are useful tools for that as
well.

It took me a year to figure out how to use Blue, but now that I know
how to use it its hard to figure using anything else.

It has the embedded scripting, but then also has the GUI tools as
well, and runs the same on my windows pc or linux machine.

On Wed, May 20, 2009 at 8:06 PM, Robert or Gretchen Foose
 wrote:
> For my own part, Csound itself is sufficient for instrument creation, as are
> Pd, and any of the other synthesis programs I've run across.  Score
> generation is quite another thing, however.  Whether or not you're doing
> algorithmic composition, of any type, you'd be insane (sooner or later) to
> try to do so just using Csound.  So, some other 'composition software' is
> almost required.
>
> In the years that I've been playing with computers, I've looked at many
> different languages (including Haskell), and even used a few.  What I've
> noticed, and have seen written in print, is that the tasks that are made
> easier by using a computer fall into a few different types..broadly
> speaking, these are moving data, mathematical manipulation (calculating),
> making decisions (branching), and repeating an action (looping).  All the
> languages I've ever seen implement these activities in one way or another.
>  So, unless you can find some mission critical reason (such as realtime
> processing) to use one particular language, it really doesn't matter which
> you use..QBASIC is as good as any other!
>
> So, my own approach is to use plain old English to decide what I want to
> happen, then refine it to pseudo-code, and then translate it into whatever
> language I feel most attracted to at the time.  To really decide which is
> best (for a given project), you'd really need to feel equally comfortable in
> all of them, and then see which one, if any, produces what you feel to be
> the best result for the time spent (based on whatever criteria you decide to
> use).  This is far too much an academic argument for me to spend that kind
> of time..especially since the 'winner' might not be the best one for my next
> project!!
>
> Which, finally, leads me to agree with a previous post about this question
> that recommended C for speed critical routine (Assembly is faster, but not
> portable), and Python (currently the most popular and user friendly of the
> procedural languages) for everything else.  Haskell does make 'proving' your
> code a snap, and is very concise..but concise Haskell code is, to me, just
> as cryptic as a lot of C code I've seen.
>
> I enjoy exploring languages..human and computer.., but when I want to
> produce music I want to think about music..not code, so I just use what I
> already know.
>
> I hope this POV helps a little.
> Bob Foose
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

Robert or Gretchen Foose wrote:

> All the 
> languages I've ever seen implement these activities in one way 
> or another.  So, unless you can find some mission critical 
> reason (such as realtime processing) to use one particular 
> language, it really doesn't matter which you use..QBASIC is as 
> good as any other!

This may be true if you have an infinite amount of spare time.
If your spare time is not infinite, you should care about
two things; minimising the amount of time it takes to write
code in the first place and minimising the amount of time you
spend debugging it once its written.

All software has bugs. Some languages (ASM, C, C++) allow classes
of bugs (buffer overflows) which other languages (Python and
Haskell to name just two) simply do not allow. So the ASM/C/C++
programmer has to spend time thinking about how to avoid buffer
overflows while programmers working in other langauges do not.

Narrowing this down and comparing two languages, C and Haskell,
there are many, *many* classes of error that are possible in a C
program that cannot happen in a Haskell program. By cannot happen,
I mean that the compiler will not let you make these errors.
Going the other way, I cannot think of a single error that I
could make in a Haskell program that is impossible to make in a
C program.

There is also the matter of program efficiency. Here is a simple
Haskell program that takes two file names from the command line
and copies the contents of the first to the second.

    import System.Environment
    main = do
        [infile, outfile] <- getArgs
        s <- readFile infile 
        writeFile outfile s

In Python, I believe this would be:

    import sys
    f = open (sys.argv [2], "w")
    f.write (open (sys.argv [1], "r").read ())
    f.close ()

Disregarding one very big difference [0] between these two programs,
both of these programs are far, far simpler and quicker to write 
than the equivalent C program.

All programming languages are not created equal, otherwise we would
all still be programming in ASM, C or Fortran.

Erik

[0] Due to Haskell's lazy evaluation, the Haskell program can copy
    files bigger than the system's virtual memory. In the same
    situation, the Python program would consume all available memory
    before crashing.
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Erik de Castro Lopo wrote:

>     import System.Environment
>     main = do
>         [infile, outfile] <- getArgs
>         s <- readFile infile 
>         writeFile outfile s
> 
> In Python, I believe this would be:
> 
>     import sys
>     f = open (sys.argv [2], "w")
>     f.write (open (sys.argv [1], "r").read ())
>     f.close ()
> 
> Disregarding one very big difference [0] between these two programs,
> both of these programs are far, far simpler and quicker to write 
> than the equivalent C program.
> 

A major difference between Python and Haskell (and one reason I'm going to 
Haskell) is speed: Haskell is compiled. (Speed may not be a factor in your 
example above.)

Haskell has both strict typing (even stricter than C++; there are no automatic 
promotions) and type inference, which means you get the best of both worlds. You 
don't need to declare the type of most things (like in Python) but get 
absolutely strict type checking, thereby avoiding a whole class of errors. I 
never fully appreciated this until using Haskell for the past two months and 
then switching back to Python last week, and running into a darn runtime bug in 
the Python---after solving it, realized it was a type error and Haskell would 
have caught it at compilation.

Mike

On 5/20/09 23:06, "    Robert or Gretchen Foose"  wrote:

> For my own part, Csound itself is sufficient for instrument
> creation, as are Pd, and any of the other synthesis programs
> I've run across.  Score generation is quite another thing,
> however.  Whether or not you're doing algorithmic composition,
> of any type, you'd be insane (sooner or later) to try to do so
> just using Csound.  So, some other 'composition software' is
> almost required.


Actually, my work has evolved recently to the point where I use csound
itself to generate all score events. All my algorithms are written in
csound, and they in use the "event" opcode to make things happen.

This enables me to take advantage of the endless number of opcodes and other
features of csound that generate control signals -- I don't have to reinvent
them in another language. I use the control signals in many ways to support
my algorithmic composition.

An example of this technique can be found at

http://www.jolc.net/lcpublic/shape01html/

In terms of writing algorithms and of debugging them, csound is certainly
not the most elegant platform in the world but I find it gets the job done,
and that's all I ask for.

-Lou