> I freely admit that I am not very experienced with mixing and this is 
> likely much of the problem, but it is, at very least, exacerbated by the 
> fact that it often takes very long periods of time to hear the results 
> of any changes made to the code.  Small changes and tweaks became very 
> time-prohibitive.

I approach a piece like a C program.  There is a tree of dependencies.
I separate the piece into different ideas.  Sometimes these are parallel,
and sometimes act as sections of the piece.

I use a Makefile to describe the dependencies between the different
conceptual parts of the piece.  At the top of one node of the tree
is a mixing instrument, leading up to the very top where a final mix
takes place.  If this was a popular music piece then, I could change
the drum sound, and render just the drums, then mix with the other
'tracks' at the end.  This ends up saving loads of time, just as it
does with a C program compilation.  

Toby

This is a very interesting question!  I have often found that working with
straight Csound can discourage tweaking.  And this in itself can lead to
overly simplistic and sometimes poorly conceived music to the point that I
have questioned at times whether Csound is the right tool for me.  I did
once import a track into a sequencer to make some final changes and another
time I had several long AIFFs that I mixed in Csound with diskin, but I have
honestly never gotten very complex this way.  I would like a good solution
to this issue myself.

I think Tobiah's idea of segmenting a piece and using makefiles to put it
together is closest to how I would like to work but I would prefer working
in a GUI environment where you can draw line segments or curves for
controlling mixing and other parameters.  I think that Steven Yi's blue has
the ability to freeze Csound tracks as sound files and them automatically
add them to your orchestra/score.  I don't know whether there is a built-in
dependency system in blue though.

In general, I need to explore blue a great deal more as I have had the sense
for a long time that it solves many compositional problems of working with
Csound.  Time is always the issue though, and developing music software
continues to impede my desire to use music software to actually make music.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

Tobiah wrote on 12/9/08 3:29 PM:

>> I freely admit that I am not very experienced with mixing and this is
>> likely much of the problem, but it is, at very least, exacerbated by the
>> fact that it often takes very long periods of time to hear the results
>> of any changes made to the code.  Small changes and tweaks became very
>> time-prohibitive.
> 
> I approach a piece like a C program.  There is a tree of dependencies.
> I separate the piece into different ideas.  Sometimes these are parallel,
> and sometimes act as sections of the piece.
> 
> I use a Makefile to describe the dependencies between the different
> conceptual parts of the piece. [...]
> This ends up saving loads of time, just as it
> does with a C program compilation.  

Agree--working entirely in Csound can make things difficult and slow. 
I've recently started using C++ in conjunction with Csound with the 
aim of building a library of functions that can potentially be used 
with many different sounds. The C++ program does a lot of the work 
that would otherwise be handled by the orchestra and spews out the 
score as a text file. This enables me to keep the parameters of the 
Csound instrument fairly simple, facilitates tweaking, and eliminates 
typing all those values into the score. Realtime isn't a big concern 
for me either. To mix, I move tracks to SONAR.

--David

At 04:12 PM 12/9/2008, you wrote:
>This is a very interesting question!  I have often found that working with
>straight Csound can discourage tweaking.  And this in itself can lead to
>overly simplistic and sometimes poorly conceived music to the point that I
>have questioned at times whether Csound is the right tool for me.  I did
>once import a track into a sequencer to make some final changes and another
>time I had several long AIFFs that I mixed in Csound with diskin, but I have
>honestly never gotten very complex this way.  I would like a good solution
>to this issue myself.
>
>I think Tobiah's idea of segmenting a piece and using makefiles to put it
>together is closest to how I would like to work but I would prefer working
>in a GUI environment where you can draw line segments or curves for
>controlling mixing and other parameters.  I think that Steven Yi's blue has
>the ability to freeze Csound tracks as sound files and them automatically
>add them to your orchestra/score.  I don't know whether there is a built-in
>dependency system in blue though.
>
>In general, I need to explore blue a great deal more as I have had the sense
>for a long time that it solves many compositional problems of working with
>Csound.  Time is always the issue though, and developing music software
>continues to impede my desire to use music software to actually make music.
>
>Anthony Kozar
>mailing-lists-1001 AT anthonykozar DOT net
>http://anthonykozar.net/
>
>Tobiah wrote on 12/9/08 3:29 PM:
>
> >> I freely admit that I am not very experienced with mixing and this is
> >> likely much of the problem, but it is, at very least, exacerbated by the
> >> fact that it often takes very long periods of time to hear the results
> >> of any changes made to the code.  Small changes and tweaks became very
> >> time-prohibitive.
> >
> > I approach a piece like a C program.  There is a tree of dependencies.
> > I separate the piece into different ideas.  Sometimes these are parallel,
> > and sometimes act as sections of the piece.
> >
> > I use a Makefile to describe the dependencies between the different
> > conceptual parts of the piece. [...]
> > This ends up saving loads of time, just as it
> > does with a C program compilation.
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>"unsubscribe csound"
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.

David Mooney:  dmooney@city-net.com
Maxine Heller:  mheller@city-net.com
Opaque Melodies:  www.city-net.com/~moko/

David Mooney/Maxine Heller wrote:
> Agree--working entirely in Csound can make things difficult and slow. 
> I've recently started using C++ in conjunction with Csound with the aim 
> of building a library of functions 

I'm just curious - why C++?  Isn't it a little cumbersome
for writing score generation programs?  

Hi David, 

I'm curious how you can accomplish all of your goals at once using C++.
I understand how using a high-level program language can save typing and
(sometimes) allow easier, large-scale changes to the score.  But how does
your program also "[do] a lot of the work that would otherwise be
handled by the orchestra and [...] keep the parameters of the Csound
instrument fairly simple" ?

Hoping that you can share some interesting techniques with us.  TIA.

Anthony

David Mooney/Maxine Heller wrote on 12/10/08 4:19 PM:

> Agree--working entirely in Csound can make things difficult and slow.
> I've recently started using C++ in conjunction with Csound with the
> aim of building a library of functions that can potentially be used
> with many different sounds. The C++ program does a lot of the work
> that would otherwise be handled by the orchestra and spews out the
> score as a text file. This enables me to keep the parameters of the
> Csound instrument fairly simple, facilitates tweaking, and eliminates
> typing all those values into the score. Realtime isn't a big concern
> for me either. To mix, I move tracks to SONAR.

> but if you think
> about how composers worked until a hundred years ago or so, writing
> pieces for orchestras and doing most of the work on a single keyboard
> or voice, it's still a step up.  Their skill lay in knowing the
> instruments or voices they were working with very well internally;
> they didn't always need to hear something performed exactly in order
> to know how to arrange it.
>

Yes but today many composers are concerned with other, and often more  
complex, aspects of sound for which no a priori conception and/or  
representation exist. In many cases it is impossible to think in  
terms of notes and instrumentally orientated ideas. Not to rule  
anything out of course, but I am sure we can agree that  
electroacoustic music has in general opened up possibilities that  
were minimised in traditional instrumental music. I think there is a  
place for coding and a place for DAW. For very detailed mixing (e.g.  
additive synthesis) a text based approach is clearly preferable but  
when it comes to fine-tuning a gesture that's made up of say 20 very  
short sound events, one prefers a GUI to be able to tweak the timing  
down to every millisecond.

Best
Peiman