I haven't looked into this yet, but part of the reason is that
I don't know why I would want to use it.  I use python to generate
scores, but I don't understand what I might accomplish using the API.

Thanks,

Toby

The reason for using the API is to speed up the workflow. Of course,
it is one thing if you generate a piece all in one go with a program,
or if you generate various materials with programs and then assemble
them by hand in a sequencer or with a makefile or something.

Since I generate pieces all in one go, I put absolutely everything
possible into a single script. The script contains CsoundAC code for
generating the score, an embedded Csound orchestra, Csound API code
for rendering the score to a high-resolution float soundfile with ID
tags, and code for normalizing the output soundfile, producing a CD
Audio soundfile with ID tags, and producing an MP3 soundfile with ID
tags.

I make pieces by taking an earlier piece, saving it to a new filename,
and editing the score generation and Csound orchestra code in the
script. The script figures out the names for all the other files,
including the soundfiles, from the filename of the script itself.

Thus, I don't have to do anything but compose and arrange. If I get to
a point where I can't improve a piece and I like it, I just upload the
appropriate soundfiles to my Web site or TuneCore or something, and
I'm done. If I need to burn a CD, I just drop the CD audio soundfiles
on my CD burner list.

It turns out that this kind of integration ends up saving a good deal of time...

But if you assemble your finished pieces from parts, this might or
might not make sense for you.

Regards,
Mike



On 6/2/09, Tobiah  wrote:
> I haven't looked into this yet, but part of the reason is that
> I don't know why I would want to use it.  I use python to generate
> scores, but I don't understand what I might accomplish using the API.
>
> Thanks,
>
> Toby
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Well, I think one can do without the API and still have everything in
one script, calling csound via commandline (using one of the popen
methods perhaps).  I did this with blue calling commandline fo years.
I think for using the API, the decision should really be if you need
the additional features, which are to interact with the running engine
by reading/writing values or tables, adding your own Audio and MIDI
handling, or syncing with the engine to do further work with your own
code, i.e. maybe syncing video with the audio, etc.

For blue and Java, I use the API so that faders in the mixer,
automations, and widgets can act on the running csound in realtime.
Otherwise, I tend to not use the API when I don't need it as it adds
overhead and will slow down the rendering to hook into the host code
to do extra processing.

steven

On Tue, Jun 2, 2009 at 12:10 PM, Michael Gogins
 wrote:
> The reason for using the API is to speed up the workflow. Of course,
> it is one thing if you generate a piece all in one go with a program,
> or if you generate various materials with programs and then assemble
> them by hand in a sequencer or with a makefile or something.
>
> Since I generate pieces all in one go, I put absolutely everything
> possible into a single script. The script contains CsoundAC code for
> generating the score, an embedded Csound orchestra, Csound API code
> for rendering the score to a high-resolution float soundfile with ID
> tags, and code for normalizing the output soundfile, producing a CD
> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
> tags.
>
> I make pieces by taking an earlier piece, saving it to a new filename,
> and editing the score generation and Csound orchestra code in the
> script. The script figures out the names for all the other files,
> including the soundfiles, from the filename of the script itself.
>
> Thus, I don't have to do anything but compose and arrange. If I get to
> a point where I can't improve a piece and I like it, I just upload the
> appropriate soundfiles to my Web site or TuneCore or something, and
> I'm done. If I need to burn a CD, I just drop the CD audio soundfiles
> on my CD burner list.
>
> It turns out that this kind of integration ends up saving a good deal of time...
>
> But if you assemble your finished pieces from parts, this might or
> might not make sense for you.
>
> Regards,
> Mike
>
>
>
> On 6/2/09, Tobiah  wrote:
>> I haven't looked into this yet, but part of the reason is that
>> I don't know why I would want to use it.  I use python to generate
>> scores, but I don't understand what I might accomplish using the API.
>>
>> Thanks,
>>
>> Toby
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

It's certainly possible to use the subprocess.call() function to run
programs externally and wait for results. In fact, that's what I do to
rescale, make CD audio tracks, and make MP3s.

So yes, for some people it would be simpler to shell out to run
Csound. You could still keep the orchestra in your script and just
save it out to a file before running Csound.

Best,
Mike

On 6/2/09, Steven Yi  wrote:
> Well, I think one can do without the API and still have everything in
> one script, calling csound via commandline (using one of the popen
> methods perhaps).  I did this with blue calling commandline fo years.
> I think for using the API, the decision should really be if you need
> the additional features, which are to interact with the running engine
> by reading/writing values or tables, adding your own Audio and MIDI
> handling, or syncing with the engine to do further work with your own
> code, i.e. maybe syncing video with the audio, etc.
>
> For blue and Java, I use the API so that faders in the mixer,
> automations, and widgets can act on the running csound in realtime.
> Otherwise, I tend to not use the API when I don't need it as it adds
> overhead and will slow down the rendering to hook into the host code
> to do extra processing.
>
> steven
>
> On Tue, Jun 2, 2009 at 12:10 PM, Michael Gogins
>  wrote:
>> The reason for using the API is to speed up the workflow. Of course,
>> it is one thing if you generate a piece all in one go with a program,
>> or if you generate various materials with programs and then assemble
>> them by hand in a sequencer or with a makefile or something.
>>
>> Since I generate pieces all in one go, I put absolutely everything
>> possible into a single script. The script contains CsoundAC code for
>> generating the score, an embedded Csound orchestra, Csound API code
>> for rendering the score to a high-resolution float soundfile with ID
>> tags, and code for normalizing the output soundfile, producing a CD
>> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
>> tags.
>>
>> I make pieces by taking an earlier piece, saving it to a new filename,
>> and editing the score generation and Csound orchestra code in the
>> script. The script figures out the names for all the other files,
>> including the soundfiles, from the filename of the script itself.
>>
>> Thus, I don't have to do anything but compose and arrange. If I get to
>> a point where I can't improve a piece and I like it, I just upload the
>> appropriate soundfiles to my Web site or TuneCore or something, and
>> I'm done. If I need to burn a CD, I just drop the CD audio soundfiles
>> on my CD burner list.
>>
>> It turns out that this kind of integration ends up saving a good deal of
>> time...
>>
>> But if you assemble your finished pieces from parts, this might or
>> might not make sense for you.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On 6/2/09, Tobiah  wrote:
>>> I haven't looked into this yet, but part of the reason is that
>>> I don't know why I would want to use it.  I use python to generate
>>> scores, but I don't understand what I might accomplish using the API.
>>>
>>> Thanks,
>>>
>>> Toby
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Sorry for intrusion,
but i'm really interested. The options for mp3 ID tag and similar are
possible via CsoundAC ?

PS. i use python only for create score for csound, but with api i can play
csd in quasi real time and then i don't need to write a sco file, open
csound and render the piece. Only this, by me, it's a great help in study.

ciao,

fran.
-- 
View this message in context: http://www.nabble.com/Python-API-tp23838459p23839221.html
Sent from the Csound - General mailing list archive at Nabble.com.

It's pretty useful for writing applications. Instead of finding Python
libraries for wav, jack, MIDI, OSC, soundfonts, etc., I just load
Csound and I have access to all those things. I haven't used it
directly for music myself, but as an audio library/backend.

-Chuckk

On Tue, Jun 2, 2009 at 9:50 PM, Tobiah  wrote:
> I haven't looked into this yet, but part of the reason is that
> I don't know why I would want to use it.  I use python to generate
> scores, but I don't understand what I might accomplish using the API.
>
> Thanks,
>
> Toby
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 
http://www.badmuthahubbard.com

Yes, I am interested in this as well. I would like 
to define gestures that I can run and interact with in real time.

I think of a gesture as being a collection of opcodes (the instrument),
and a set of processes (algorithmic or scripted) that describe its 
behavior. I also want to define relationships between gestures and 
control them in realtime. Basically I want to create a model of 
a piece of music that I can experiment with.

I am still unfamiliar with python/csound interaction to know 
the best route to take to get to this goal. Would I run these
things as separate processes? Is there any concept in csound/python 
of inter-process communication? Any advice?




Anthony



---- Michael Gogins  wrote: 
> It's certainly possible to use the subprocess.call() function to run
programs externally and wait for results. In fact, that's what I do to
rescale, make CD audio tracks, and make MP3s.

So yes, for some people it would be simpler to shell out to run
Csound. You could still keep the orchestra in your script and just
save it out to a file before running Csound.

Best,
Mike

On 6/2/09, Steven Yi  wrote:
> Well, I think one can do without the API and still have everything in
> one script, calling csound via commandline (using one of the popen
> methods perhaps).  I did this with blue calling commandline fo years.
> I think for using the API, the decision should really be if you need
> the additional features, which are to interact with the running engine
> by reading/writing values or tables, adding your own Audio and MIDI
> handling, or syncing with the engine to do further work with your own
> code, i.e. maybe syncing video with the audio, etc.
>
> For blue and Java, I use the API so that faders in the mixer,
> automations, and widgets can act on the running csound in realtime.
> Otherwise, I tend to not use the API when I don't need it as it adds
> overhead and will slow down the rendering to hook into the host code
> to do extra processing.
>
> steven
>
> On Tue, Jun 2, 2009 at 12:10 PM, Michael Gogins
>  wrote:
>> The reason for using the API is to speed up the workflow. Of course,
>> it is one thing if you generate a piece all in one go with a program,
>> or if you generate various materials with programs and then assemble
>> them by hand in a sequencer or with a makefile or something.
>>
>> Since I generate pieces all in one go, I put absolutely everything
>> possible into a single script. The script contains CsoundAC code for
>> generating the score, an embedded Csound orchestra, Csound API code
>> for rendering the score to a high-resolution float soundfile with ID
>> tags, and code for normalizing the output soundfile, producing a CD
>> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
>> tags.
>>
>> I make pieces by taking an earlier piece, saving it to a new filename,
>> and editing the score generation and Csound orchestra code in the
>> script. The script figures out the names for all the other files,
>> including the soundfiles, from the filename of the script itself.
>>
>> Thus, I don't have to do anything but compose and arrange. If I get to
>> a point where I can't improve a piece and I like it, I just upload the
>> appropriate soundfiles to my Web site or TuneCore or something, and
>> I'm done. If I need to burn a CD, I just drop the CD audio soundfiles
>> on my CD burner list.
>>
>> It turns out that this kind of integration ends up saving a good deal of
>> time...
>>
>> But if you assemble your finished pieces from parts, this might or
>> might not make sense for you.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On 6/2/09, Tobiah  wrote:
>>> I haven't looked into this yet, but part of the reason is that
>>> I don't know why I would want to use it.  I use python to generate
>>> scores, but I don't understand what I might accomplish using the API.
>>>
>>> Thanks,
>>>
>>> Toby
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Ableton Live + Max4Live

-----Original Message-----
From: apalomba@austin.rr.com [mailto:apalomba@austin.rr.com] 
Sent: Tuesday, June 02, 2009 1:21 PM
To: csound@lists.bath.ac.uk
Cc: Michael Gogins
Subject: [Csnd] Re: Re: Re: Re: Python API

Yes, I am interested in this as well. I would like 
to define gestures that I can run and interact with in real time.

I think of a gesture as being a collection of opcodes (the instrument),
and a set of processes (algorithmic or scripted) that describe its 
behavior. I also want to define relationships between gestures and 
control them in realtime. Basically I want to create a model of 
a piece of music that I can experiment with.

I am still unfamiliar with python/csound interaction to know 
the best route to take to get to this goal. Would I run these
things as separate processes? Is there any concept in csound/python 
of inter-process communication? Any advice?




Anthony



---- Michael Gogins  wrote: 
> It's certainly possible to use the subprocess.call() function to run
programs externally and wait for results. In fact, that's what I do to
rescale, make CD audio tracks, and make MP3s.

So yes, for some people it would be simpler to shell out to run
Csound. You could still keep the orchestra in your script and just
save it out to a file before running Csound.

Best,
Mike

On 6/2/09, Steven Yi  wrote:
> Well, I think one can do without the API and still have everything in
> one script, calling csound via commandline (using one of the popen
> methods perhaps).  I did this with blue calling commandline fo years.
> I think for using the API, the decision should really be if you need
> the additional features, which are to interact with the running engine
> by reading/writing values or tables, adding your own Audio and MIDI
> handling, or syncing with the engine to do further work with your own
> code, i.e. maybe syncing video with the audio, etc.
>
> For blue and Java, I use the API so that faders in the mixer,
> automations, and widgets can act on the running csound in realtime.
> Otherwise, I tend to not use the API when I don't need it as it adds
> overhead and will slow down the rendering to hook into the host code
> to do extra processing.
>
> steven
>
> On Tue, Jun 2, 2009 at 12:10 PM, Michael Gogins
>  wrote:
>> The reason for using the API is to speed up the workflow. Of course,
>> it is one thing if you generate a piece all in one go with a program,
>> or if you generate various materials with programs and then assemble
>> them by hand in a sequencer or with a makefile or something.
>>
>> Since I generate pieces all in one go, I put absolutely everything
>> possible into a single script. The script contains CsoundAC code for
>> generating the score, an embedded Csound orchestra, Csound API code
>> for rendering the score to a high-resolution float soundfile with ID
>> tags, and code for normalizing the output soundfile, producing a CD
>> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
>> tags.
>>
>> I make pieces by taking an earlier piece, saving it to a new filename,
>> and editing the score generation and Csound orchestra code in the
>> script. The script figures out the names for all the other files,
>> including the soundfiles, from the filename of the script itself.
>>
>> Thus, I don't have to do anything but compose and arrange. If I get to
>> a point where I can't improve a piece and I like it, I just upload the
>> appropriate soundfiles to my Web site or TuneCore or something, and
>> I'm done. If I need to burn a CD, I just drop the CD audio soundfiles
>> on my CD burner list.
>>
>> It turns out that this kind of integration ends up saving a good deal of
>> time...
>>
>> But if you assemble your finished pieces from parts, this might or
>> might not make sense for you.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On 6/2/09, Tobiah  wrote:
>>> I haven't looked into this yet, but part of the reason is that
>>> I don't know why I would want to use it.  I use python to generate
>>> scores, but I don't understand what I might accomplish using the API.
>>>
>>> Thanks,
>>>
>>> Toby
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"=

Ardour+csladspa
----- Original Message ----- 
From: 
To: 
Sent: Wednesday, June 03, 2009 6:52 AM
Subject: [Csnd] RE: Re: Re: Re: Re: Python API


Ableton Live + Max4Live

-----Original Message-----
From: apalomba@austin.rr.com [mailto:apalomba@austin.rr.com]
Sent: Tuesday, June 02, 2009 1:21 PM
To: csound@lists.bath.ac.uk
Cc: Michael Gogins
Subject: [Csnd] Re: Re: Re: Re: Python API

Yes, I am interested in this as well. I would like
to define gestures that I can run and interact with in real time.

I think of a gesture as being a collection of opcodes (the instrument),
and a set of processes (algorithmic or scripted) that describe its
behavior. I also want to define relationships between gestures and
control them in realtime. Basically I want to create a model of
a piece of music that I can experiment with.

I am still unfamiliar with python/csound interaction to know
the best route to take to get to this goal. Would I run these
things as separate processes? Is there any concept in csound/python
of inter-process communication? Any advice?




Anthony



---- Michael Gogins  wrote:
> It's certainly possible to use the subprocess.call() function to run
programs externally and wait for results. In fact, that's what I do to
rescale, make CD audio tracks, and make MP3s.

So yes, for some people it would be simpler to shell out to run
Csound. You could still keep the orchestra in your script and just
save it out to a file before running Csound.

Best,
Mike

On 6/2/09, Steven Yi  wrote:
> Well, I think one can do without the API and still have everything in
> one script, calling csound via commandline (using one of the popen
> methods perhaps).  I did this with blue calling commandline fo years.
> I think for using the API, the decision should really be if you need
> the additional features, which are to interact with the running engine
> by reading/writing values or tables, adding your own Audio and MIDI
> handling, or syncing with the engine to do further work with your own
> code, i.e. maybe syncing video with the audio, etc.
>
> For blue and Java, I use the API so that faders in the mixer,
> automations, and widgets can act on the running csound in realtime.
> Otherwise, I tend to not use the API when I don't need it as it adds
> overhead and will slow down the rendering to hook into the host code
> to do extra processing.
>
> steven
>
> On Tue, Jun 2, 2009 at 12:10 PM, Michael Gogins
>  wrote:
>> The reason for using the API is to speed up the workflow. Of course,
>> it is one thing if you generate a piece all in one go with a program,
>> or if you generate various materials with programs and then assemble
>> them by hand in a sequencer or with a makefile or something.
>>
>> Since I generate pieces all in one go, I put absolutely everything
>> possible into a single script. The script contains CsoundAC code for
>> generating the score, an embedded Csound orchestra, Csound API code
>> for rendering the score to a high-resolution float soundfile with ID
>> tags, and code for normalizing the output soundfile, producing a CD
>> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
>> tags.
>>
>> I make pieces by taking an earlier piece, saving it to a new filename,
>> and editing the score generation and Csound orchestra code in the
>> script. The script figures out the names for all the other files,
>> including the soundfiles, from the filename of the script itself.
>>
>> Thus, I don't have to do anything but compose and arrange. If I get to
>> a point where I can't improve a piece and I like it, I just upload the
>> appropriate soundfiles to my Web site or TuneCore or something, and
>> I'm done. If I need to burn a CD, I just drop the CD audio soundfiles
>> on my CD burner list.
>>
>> It turns out that this kind of integration ends up saving a good deal of
>> time...
>>
>> But if you assemble your finished pieces from parts, this might or
>> might not make sense for you.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On 6/2/09, Tobiah  wrote:
>>> I haven't looked into this yet, but part of the reason is that
>>> I don't know why I would want to use it.  I use python to generate
>>> scores, but I don't understand what I might accomplish using the API.
>>>
>>> Thanks,
>>>
>>> Toby
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"=



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"= 

Hi Anthony,

You could set them up in separate processes or not, depending on what
degree of having them in sync you require.  There are articles by
Oeyvind in the Csound Journal about setting up a sound server with
python that is based on his own musical work.  Other example in the
Journal and that come with Csound show having them in the same process
with Csound running in its own thread.

You could also run Csound and have it listen to OSC messages, then
communicate to Csound from your python project generating OSC
messages.

I'd probably start with either OSC to communicate or single process.
Single process would give you the most control, while OSC might get
you off the ground faster though you'd probably hit a ceiling faster
too.

As for why people are mentioning Live/Ardour, but if that's the case
I'll recommend blue then. :P  In blue, you could use blueLive to write
your python scripts to generate notes and have them fed to csound in
realtime, as well as turn off all running notes if you want to stop
the gesture and try a new one out.  You could then take the scripts
for your gestures and start putting them on the timeline to compose in
time if you wished too.

steven



On Tue, Jun 2, 2009 at 1:20 PM,   wrote:
> Yes, I am interested in this as well. I would like
> to define gestures that I can run and interact with in real time.
>
> I think of a gesture as being a collection of opcodes (the instrument),
> and a set of processes (algorithmic or scripted) that describe its
> behavior. I also want to define relationships between gestures and
> control them in realtime. Basically I want to create a model of
> a piece of music that I can experiment with.
>
> I am still unfamiliar with python/csound interaction to know
> the best route to take to get to this goal. Would I run these
> things as separate processes? Is there any concept in csound/python
> of inter-process communication? Any advice?
>
>
>
>
> Anthony
>
>
>
> ---- Michael Gogins  wrote:
>> It's certainly possible to use the subprocess.call() function to run
> programs externally and wait for results. In fact, that's what I do to
> rescale, make CD audio tracks, and make MP3s.
>
> So yes, for some people it would be simpler to shell out to run
> Csound. You could still keep the orchestra in your script and just
> save it out to a file before running Csound.
>
> Best,
> Mike
>
> On 6/2/09, Steven Yi  wrote:
>> Well, I think one can do without the API and still have everything in
>> one script, calling csound via commandline (using one of the popen
>> methods perhaps).  I did this with blue calling commandline fo years.
>> I think for using the API, the decision should really be if you need
>> the additional features, which are to interact with the running engine
>> by reading/writing values or tables, adding your own Audio and MIDI
>> handling, or syncing with the engine to do further work with your own
>> code, i.e. maybe syncing video with the audio, etc.
>>
>> For blue and Java, I use the API so that faders in the mixer,
>> automations, and widgets can act on the running csound in realtime.
>> Otherwise, I tend to not use the API when I don't need it as it adds
>> overhead and will slow down the rendering to hook into the host code
>> to do extra processing.
>>
>> steven
>>
>> On Tue, Jun 2, 2009 at 12:10 PM, Michael Gogins
>>  wrote:
>>> The reason for using the API is to speed up the workflow. Of course,
>>> it is one thing if you generate a piece all in one go with a program,
>>> or if you generate various materials with programs and then assemble
>>> them by hand in a sequencer or with a makefile or something.
>>>
>>> Since I generate pieces all in one go, I put absolutely everything
>>> possible into a single script. The script contains CsoundAC code for
>>> generating the score, an embedded Csound orchestra, Csound API code
>>> for rendering the score to a high-resolution float soundfile with ID
>>> tags, and code for normalizing the output soundfile, producing a CD
>>> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
>>> tags.
>>>
>>> I make pieces by taking an earlier piece, saving it to a new filename,
>>> and editing the score generation and Csound orchestra code in the
>>> script. The script figures out the names for all the other files,
>>> including the soundfiles, from the filename of the script itself.
>>>
>>> Thus, I don't have to do anything but compose and arrange. If I get to
>>> a point where I can't improve a piece and I like it, I just upload the
>>> appropriate soundfiles to my Web site or TuneCore or something, and
>>> I'm done. If I need to burn a CD, I just drop the CD audio soundfiles
>>> on my CD burner list.
>>>
>>> It turns out that this kind of integration ends up saving a good deal of
>>> time...
>>>
>>> But if you assemble your finished pieces from parts, this might or
>>> might not make sense for you.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>>
>>> On 6/2/09, Tobiah  wrote:
>>>> I haven't looked into this yet, but part of the reason is that
>>>> I don't know why I would want to use it.  I use python to generate
>>>> scores, but I don't understand what I might accomplish using the API.
>>>>
>>>> Thanks,
>>>>
>>>> Toby
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

We are actually referring to a "csound" not a "cmusic" API. i.e. there  
are more (interesting possible) uses of csound that as the synthesis  
end of an approach to music composition as the synthesis of data  
generation processes, MIDI etc.
IMO the real general power of a python csound API will emerge when it  
can be automatically compiled for whatever version of python the user  
happens to be using on their  hardware/OS. This requires a shift in  
thinking to csound being a part (albeit an important one) of an open  
framework, rather than it forcing users to consider it to the centre  
of attention. As you can imagine, this shift in thinking may be  
difficult while those whose activity revolves around csound don't  
consider it important enough to support  that shift in thinking.
Until then, a more satisfactory generalist approach can be had by  
using python (with its myriad of disparate modules) to generate OSC  
messages to an independently running SCsynth process.

David
On 03/06/2009, at 5:52 AM, Chuckk Hubbard wrote:

> It's pretty useful for writing applications. Instead of finding Python
> libraries for wav, jack, MIDI, OSC, soundfonts, etc., I just load
> Csound and I have access to all those things. I haven't used it
> directly for music myself, but as an audio library/backend.
>
> -Chuckk
>
> On Tue, Jun 2, 2009 at 9:50 PM, Tobiah  wrote:
>> I haven't looked into this yet, but part of the reason is that
>> I don't know why I would want to use it.  I use python to generate
>> scores, but I don't understand what I might accomplish using the API.
>>
>> Thanks,
>>
>> Toby
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>
>
>
> -- 
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Csound can be compiled for any version of python up to 2.6.

The next version of Csound will be able to be compiled for Python 3.0,
and Python 3.0 will be the standard.

It will probably never be the case, unfortunately, that Csound will be
able to use any arbitrary version of Python at run time, because this
is a limitation of SWIG which is used to generate the API.

Regards,
Mike

On 6/3/09, DavidW  wrote:
> We are actually referring to a "csound" not a "cmusic" API. i.e. there
> are more (interesting possible) uses of csound that as the synthesis
> end of an approach to music composition as the synthesis of data
> generation processes, MIDI etc.
> IMO the real general power of a python csound API will emerge when it
> can be automatically compiled for whatever version of python the user
> happens to be using on their  hardware/OS. This requires a shift in
> thinking to csound being a part (albeit an important one) of an open
> framework, rather than it forcing users to consider it to the centre
> of attention. As you can imagine, this shift in thinking may be
> difficult while those whose activity revolves around csound don't
> consider it important enough to support  that shift in thinking.
> Until then, a more satisfactory generalist approach can be had by
> using python (with its myriad of disparate modules) to generate OSC
> messages to an independently running SCsynth process.
>
> David
> On 03/06/2009, at 5:52 AM, Chuckk Hubbard wrote:
>
>> It's pretty useful for writing applications. Instead of finding Python
>> libraries for wav, jack, MIDI, OSC, soundfonts, etc., I just load
>> Csound and I have access to all those things. I haven't used it
>> directly for music myself, but as an audio library/backend.
>>
>> -Chuckk
>>
>> On Tue, Jun 2, 2009 at 9:50 PM, Tobiah  wrote:
>>> I haven't looked into this yet, but part of the reason is that
>>> I don't know why I would want to use it.  I use python to generate
>>> scores, but I don't understand what I might accomplish using the API.
>>>
>>> Thanks,
>>>
>>> Toby
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe csound"
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

On 03/06/2009, at 10:15 PM, Michael Gogins wrote:

> Csound can be compiled for any version of python up to 2.6.
>
on all platforms?

> The next version of Csound will be able to be compiled for Python 3.0,
> and Python 3.0 will be the standard.
>
> It will probably never be the case, unfortunately, that Csound will be
> able to use any arbitrary version of Python at run time, because this
> is a limitation of SWIG which is used to generate the API.
>
mmm. If only the way SWIG works was more transparent!
Has anyone experimented with generating a ctypes interface?

D.

> Regards,
> Mike
>
> On 6/3/09, DavidW  wrote:
>> We are actually referring to a "csound" not a "cmusic" API. i.e.  
>> there
>> are more (interesting possible) uses of csound that as the synthesis
>> end of an approach to music composition as the synthesis of data
>> generation processes, MIDI etc.
>> IMO the real general power of a python csound API will emerge when it
>> can be automatically compiled for whatever version of python the user
>> happens to be using on their  hardware/OS. This requires a shift in
>> thinking to csound being a part (albeit an important one) of an open
>> framework, rather than it forcing users to consider it to the centre
>> of attention. As you can imagine, this shift in thinking may be
>> difficult while those whose activity revolves around csound don't
>> consider it important enough to support  that shift in thinking.
>> Until then, a more satisfactory generalist approach can be had by
>> using python (with its myriad of disparate modules) to generate OSC
>> messages to an independently running SCsynth process.
>>
>> David
>> On 03/06/2009, at 5:52 AM, Chuckk Hubbard wrote:
>>
>>> It's pretty useful for writing applications. Instead of finding  
>>> Python
>>> libraries for wav, jack, MIDI, OSC, soundfonts, etc., I just load
>>> Csound and I have access to all those things. I haven't used it
>>> directly for music myself, but as an audio library/backend.
>>>
>>> -Chuckk
>>>
>>> On Tue, Jun 2, 2009 at 9:50 PM, Tobiah  wrote:
>>>> I haven't looked into this yet, but part of the reason is that
>>>> I don't know why I would want to use it.  I use python to generate
>>>> scores, but I don't understand what I might accomplish using the  
>>>> API.
>>>>
>>>> Thanks,
>>>>
>>>> Toby
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe csound"
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg
- MARCS Auditory Laboratories: marcs.uws.edu.au

Actually, I think Live is pretty limited in its support for python.
I doubt you could implement what I want with it.

Max, on the other hand supports python scripting so
I should be able to easily adapt the python code to work in a
Max environment. Max would be the front end for my
gesture modeling system.



Anthony




----- Original Message ----- 
From: 
To: 
Sent: Wednesday, June 03, 2009 12:52 AM
Subject: [Csnd] RE: Re: Re: Re: Re: Python API


Ableton Live + Max4Live

-----Original Message-----
From: apalomba@austin.rr.com [mailto:apalomba@austin.rr.com]
Sent: Tuesday, June 02, 2009 1:21 PM
To: csound@lists.bath.ac.uk
Cc: Michael Gogins
Subject: [Csnd] Re: Re: Re: Re: Python API

Yes, I am interested in this as well. I would like
to define gestures that I can run and interact with in real time.

I think of a gesture as being a collection of opcodes (the instrument),
and a set of processes (algorithmic or scripted) that describe its
behavior. I also want to define relationships between gestures and
control them in realtime. Basically I want to create a model of
a piece of music that I can experiment with.

I am still unfamiliar with python/csound interaction to know
the best route to take to get to this goal. Would I run these
things as separate processes? Is there any concept in csound/python
of inter-process communication? Any advice?




Anthony



---- Michael Gogins  wrote:
> It's certainly possible to use the subprocess.call() function to run
programs externally and wait for results. In fact, that's what I do to
rescale, make CD audio tracks, and make MP3s.

So yes, for some people it would be simpler to shell out to run
Csound. You could still keep the orchestra in your script and just
save it out to a file before running Csound.

Best,
Mike

On 6/2/09, Steven Yi  wrote:
> Well, I think one can do without the API and still have everything in
> one script, calling csound via commandline (using one of the popen
> methods perhaps).  I did this with blue calling commandline fo years.
> I think for using the API, the decision should really be if you need
> the additional features, which are to interact with the running engine
> by reading/writing values or tables, adding your own Audio and MIDI
> handling, or syncing with the engine to do further work with your own
> code, i.e. maybe syncing video with the audio, etc.
>
> For blue and Java, I use the API so that faders in the mixer,
> automations, and widgets can act on the running csound in realtime.
> Otherwise, I tend to not use the API when I don't need it as it adds
> overhead and will slow down the rendering to hook into the host code
> to do extra processing.
>
> steven
>
> On Tue, Jun 2, 2009 at 12:10 PM, Michael Gogins
>  wrote:
>> The reason for using the API is to speed up the workflow. Of course,
>> it is one thing if you generate a piece all in one go with a program,
>> or if you generate various materials with programs and then assemble
>> them by hand in a sequencer or with a makefile or something.
>>
>> Since I generate pieces all in one go, I put absolutely everything
>> possible into a single script. The script contains CsoundAC code for
>> generating the score, an embedded Csound orchestra, Csound API code
>> for rendering the score to a high-resolution float soundfile with ID
>> tags, and code for normalizing the output soundfile, producing a CD
>> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
>> tags.
>>
>> I make pieces by taking an earlier piece, saving it to a new filename,
>> and editing the score generation and Csound orchestra code in the
>> script. The script figures out the names for all the other files,
>> including the soundfiles, from the filename of the script itself.
>>
>> Thus, I don't have to do anything but compose and arrange. If I get to
>> a point where I can't improve a piece and I like it, I just upload the
>> appropriate soundfiles to my Web site or TuneCore or something, and
>> I'm done. If I need to burn a CD, I just drop the CD audio soundfiles
>> on my CD burner list.
>>
>> It turns out that this kind of integration ends up saving a good deal of
>> time...
>>
>> But if you assemble your finished pieces from parts, this might or
>> might not make sense for you.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On 6/2/09, Tobiah  wrote:
>>> I haven't looked into this yet, but part of the reason is that
>>> I don't know why I would want to use it.  I use python to generate
>>> scores, but I don't understand what I might accomplish using the API.
>>>
>>> Thanks,
>>>
>>> Toby
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"=



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"= 

I am familiar with ctypes, which I have used both for music
programmina and in my day job as a financial programmer. Ctypes works
very well and can wrap complex structures, callbacks, and C++ classes.

The problem with ctypes is that different compilers mangle C++ symbols
differently, thus the Python code for the C++ shared library functions
would be different for different compilers.

More importantly, the sheer amount of ctypes code that would have to
be written for all the CsoundAC classes would be formidable! This
would include wrapping much of the Standard C++ Library and much of
the boost::numeric::ublas linear algebra library. And then I'm
planning to replace ublas with Eigen soon... and maybe to add Lua to
the CsoundAC wrappers...

Using ctypes definitely is technically possible, but SWIG saves us
simply OODLES of work!

If anyone knows of a program similar to SWIG that generates ctypes
code from C++ header files, I'd love to hear about it. Even a program
to generate ctypes code from SWIG-generated code would be useful.

Regards,
Mike

On 6/3/09, DavidW  wrote:
>
> On 03/06/2009, at 10:15 PM, Michael Gogins wrote:
>
>> Csound can be compiled for any version of python up to 2.6.
>>
> on all platforms?
>
>> The next version of Csound will be able to be compiled for Python 3.0,
>> and Python 3.0 will be the standard.
>>
>> It will probably never be the case, unfortunately, that Csound will be
>> able to use any arbitrary version of Python at run time, because this
>> is a limitation of SWIG which is used to generate the API.
>>
> mmm. If only the way SWIG works was more transparent!
> Has anyone experimented with generating a ctypes interface?
>
> D.
>
>> Regards,
>> Mike
>>
>> On 6/3/09, DavidW  wrote:
>>> We are actually referring to a "csound" not a "cmusic" API. i.e.
>>> there
>>> are more (interesting possible) uses of csound that as the synthesis
>>> end of an approach to music composition as the synthesis of data
>>> generation processes, MIDI etc.
>>> IMO the real general power of a python csound API will emerge when it
>>> can be automatically compiled for whatever version of python the user
>>> happens to be using on their  hardware/OS. This requires a shift in
>>> thinking to csound being a part (albeit an important one) of an open
>>> framework, rather than it forcing users to consider it to the centre
>>> of attention. As you can imagine, this shift in thinking may be
>>> difficult while those whose activity revolves around csound don't
>>> consider it important enough to support  that shift in thinking.
>>> Until then, a more satisfactory generalist approach can be had by
>>> using python (with its myriad of disparate modules) to generate OSC
>>> messages to an independently running SCsynth process.
>>>
>>> David
>>> On 03/06/2009, at 5:52 AM, Chuckk Hubbard wrote:
>>>
>>>> It's pretty useful for writing applications. Instead of finding
>>>> Python
>>>> libraries for wav, jack, MIDI, OSC, soundfonts, etc., I just load
>>>> Csound and I have access to all those things. I haven't used it
>>>> directly for music myself, but as an audio library/backend.
>>>>
>>>> -Chuckk
>>>>
>>>> On Tue, Jun 2, 2009 at 9:50 PM, Tobiah  wrote:
>>>>> I haven't looked into this yet, but part of the reason is that
>>>>> I don't know why I would want to use it.  I use python to generate
>>>>> scores, but I don't understand what I might accomplish using the
>>>>> API.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Toby
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe csound"
>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe csound"
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:	www.avatar.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
> Australian research affiliations:
> - Capital Markets Cooperative Research Centre: www.cmcrc.com
> - Sonic Communications Research Group:	creative.canberra.edu.au/scrg
> - MARCS Auditory Laboratories: marcs.uws.edu.au
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Maybe so, but I happen to think my passe manual composition purposes
are pretty worthwhile (in tuning systems that have never had proper
interfaces, and which are thus still starving to be well represented
in music), and Csound has been the best solution for these purposes.
It could be done without the API, by saving temp files and calling a
separate Csound process, but I find using the API a little simpler.
Lucky for me that I don't need anyone's approval, because my use would
unquestionably not be progressive enough for some people.

-Chuckk

On Wed, Jun 3, 2009 at 2:58 PM, DavidW  wrote:
> We are actually referring to a "csound" not a "cmusic" API. i.e. there are
> more (interesting possible) uses of csound that as the synthesis end of an
> approach to music composition as the synthesis of data generation processes,
> MIDI etc.
> IMO the real general power of a python csound API will emerge when it can be
> automatically compiled for whatever version of python the user happens to be
> using on their  hardware/OS. This requires a shift in thinking to csound
> being a part (albeit an important one) of an open framework, rather than it
> forcing users to consider it to the centre of attention. As you can imagine,
> this shift in thinking may be difficult while those whose activity revolves
> around csound don't consider it important enough to support  that shift in
> thinking.
> Until then, a more satisfactory generalist approach can be had by using
> python (with its myriad of disparate modules) to generate OSC messages to an
> independently running SCsynth process.
>
> David
> On 03/06/2009, at 5:52 AM, Chuckk Hubbard wrote:
>
>> It's pretty useful for writing applications. Instead of finding Python
>> libraries for wav, jack, MIDI, OSC, soundfonts, etc., I just load
>> Csound and I have access to all those things. I haven't used it
>> directly for music myself, but as an audio library/backend.
>>
>> -Chuckk
>>
>> On Tue, Jun 2, 2009 at 9:50 PM, Tobiah  wrote:
>>>
>>> I haven't looked into this yet, but part of the reason is that
>>> I don't know why I would want to use it.  I use python to generate
>>> scores, but I don't understand what I might accomplish using the API.
>>>
>>> Thanks,
>>>
>>> Toby
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 
http://www.badmuthahubbard.com

Michael Gogins wrote:
> The reason for using the API is to speed up the workflow. Of course,
> it is one thing if you generate a piece all in one go with a program,
> or if you generate various materials with programs and then assemble
> them by hand in a sequencer or with a makefile or something.
> 
> Since I generate pieces all in one go, I put absolutely everything
> possible into a single script. The script contains CsoundAC code for
> generating the score, an embedded Csound orchestra, Csound API code
> for rendering the score to a high-resolution float soundfile with ID
> tags, and code for normalizing the output soundfile, producing a CD
> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
> tags.

For this purpose, bash seems a far more suitable language.  If it's in
one go, like you suggest, the script could call the score generator,
run csound, normalize the file all in a very natural and readable way.

I build my pieces in layers with many orchestras and scores so the
above process is handled by a makefile where a mixing orchestra is
the 'linker'.  The edit/audition cycle can be made far shorter this way for
a complex piece.

Yes, that would be quicker if you only change one layer at a time. A
makefile would make sense in that case. But it's not how I work, if I
change something everything changes.

I don't find bash more suitable for automating things than Python,
quite the contrary. I find Python better for manipulating files,
automating tasks, etc.

In any event if I use Python I only need to know Python. It's not that
learning languages is hard for me, but why should I learn two when
learning one will do the same job?

Regards,
Mike


On 6/8/09, Tobiah  wrote:
> Michael Gogins wrote:
>> The reason for using the API is to speed up the workflow. Of course,
>> it is one thing if you generate a piece all in one go with a program,
>> or if you generate various materials with programs and then assemble
>> them by hand in a sequencer or with a makefile or something.
>>
>> Since I generate pieces all in one go, I put absolutely everything
>> possible into a single script. The script contains CsoundAC code for
>> generating the score, an embedded Csound orchestra, Csound API code
>> for rendering the score to a high-resolution float soundfile with ID
>> tags, and code for normalizing the output soundfile, producing a CD
>> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
>> tags.
>
> For this purpose, bash seems a far more suitable language.  If it's in
> one go, like you suggest, the script could call the score generator,
> run csound, normalize the file all in a very natural and readable way.
>
> I build my pieces in layers with many orchestras and scores so the
> above process is handled by a makefile where a mixing orchestra is
> the 'linker'.  The edit/audition cycle can be made far shorter this way for
> a complex piece.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

I agree Mike.
I can only imagine the agony involved in trying to make the sort of  
music I do using sh/csh/bash/ etc.
I guess the issue can always be reduced to "well for the sort of music  
I make, tool x is ok, so why would I use anything else?"
For which there is no definitive answer. I mean we _could_ make music  
without OOP, or even structured programming  if we _had_ to,
but that would ignore the fact that notation is a tool for thought,  
as  Ken Iverson so eloquently penned,
and as superseding of roman by arabic notation, the addition of the  
cypher etc has surely demonstrates.

And, as I keep banging on, one of the powers of using python is the  
general availability of a huge amount of work by other users that can  
be integrated into one's own toolkit.
D.

On 09/06/2009, at 10:59 AM, Michael Gogins wrote:

> Yes, that would be quicker if you only change one layer at a time. A
> makefile would make sense in that case. But it's not how I work, if I
> change something everything changes.
>
> I don't find bash more suitable for automating things than Python,
> quite the contrary. I find Python better for manipulating files,
> automating tasks, etc.
>
> In any event if I use Python I only need to know Python. It's not that
> learning languages is hard for me, but why should I learn two when
> learning one will do the same job?
>
> Regards,
> Mike
>
>
> On 6/8/09, Tobiah  wrote:
>> Michael Gogins wrote:
>>> The reason for using the API is to speed up the workflow. Of course,
>>> it is one thing if you generate a piece all in one go with a  
>>> program,
>>> or if you generate various materials with programs and then assemble
>>> them by hand in a sequencer or with a makefile or something.
>>>
>>> Since I generate pieces all in one go, I put absolutely everything
>>> possible into a single script. The script contains CsoundAC code for
>>> generating the score, an embedded Csound orchestra, Csound API code
>>> for rendering the score to a high-resolution float soundfile with ID
>>> tags, and code for normalizing the output soundfile, producing a CD
>>> Audio soundfile with ID tags, and producing an MP3 soundfile with ID
>>> tags.
>>
>> For this purpose, bash seems a far more suitable language.  If it's  
>> in
>> one go, like you suggest, the script could call the score generator,
>> run csound, normalize the file all in a very natural and readable  
>> way.
>>
>> I build my pieces in layers with many orchestras and scores so the
>> above process is handled by a makefile where a mixing orchestra is
>> the 'linker'.  The edit/audition cycle can be made far shorter this  
>> way for
>> a complex piece.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg
- MARCS Auditory Laboratories: marcs.uws.edu.au