Csound Csound-dev Csound-tekno Search About

[Csnd] Csound and Python: What Exists and Would Csounders Like to Exist?

Date2013-03-19 19:50
FromJacob Joaquin
Subject[Csnd] Csound and Python: What Exists and Would Csounders Like to Exist?
What Csound-Python tools currently exist? I'm aware of CsoundAC,
PMask, Blue, the opcodes, and Python Score.

What tools, functions, capabilities would Csounders like to have in a
score environment? Big things and little things included.

Best,
Jake

Date2013-03-19 19:55
FromJustin Smith
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like to Exist?
I think the current version of cecilia uses python too.

or maybe this is just a fork? https://code.google.com/p/cecilia4/


On Tue, Mar 19, 2013 at 12:50 PM, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
What Csound-Python tools currently exist? I'm aware of CsoundAC,
PMask, Blue, the opcodes, and Python Score.

What tools, functions, capabilities would Csounders like to have in a
score environment? Big things and little things included.

Best,
Jake


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



Date2013-03-19 21:13
Fromluis jure
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
on 2013-03-19 at 12:50 Jacob Joaquin wrote:

> What Csound-Python tools currently exist? I'm aware of CsoundAC,
> PMask, Blue, the opcodes, and Python Score.

christopher ariza's athenaCL is written in python, and outputs several
formats, csound score among them:

"The athenaCL system is an open-source, object-oriented composition tool
written in Python. The system can be scripted and embedded, and includes
integrated instrument libraries, post-tonal and microtonal pitch modeling
tools, multiple-format graphical outputs, and musical output in Csound,
SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."

(http://code.google.com/p/athenacl/)

i think it's a great idea to coordinate a collective effort to develop a
library of functions to generate events for the csound score. i'm trying
to teach myself a little python, it would be fun to (try to) contribute to
the project. i'll have to look closer at pysco, jacob!

best,


lj

Date2013-03-19 21:32
FromAdam Puckett
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like to Exist?
It uses Python, but its sound engine is pyo, not Csound.

On 3/19/13, Justin Smith  wrote:
> I think the current version of cecilia uses python too.
>
> or maybe this is just a fork? https://code.google.com/p/cecilia4/
>
>
> On Tue, Mar 19, 2013 at 12:50 PM, Jacob Joaquin
> wrote:
>
>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> PMask, Blue, the opcodes, and Python Score.
>>
>> What tools, functions, capabilities would Csounders like to have in a
>> score environment? Big things and little things included.
>>
>> Best,
>> Jake
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>

Date2013-03-19 22:00
Frompeiman khosravi
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
I love the pattern library from SC. I think that's a good starting point. http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_02_Basic_Vocabulary.html

P

On 19 March 2013 21:13, luis jure <ljc@internet.com.uy> wrote:

on 2013-03-19 at 12:50 Jacob Joaquin wrote:

> What Csound-Python tools currently exist? I'm aware of CsoundAC,
> PMask, Blue, the opcodes, and Python Score.

christopher ariza's athenaCL is written in python, and outputs several
formats, csound score among them:

"The athenaCL system is an open-source, object-oriented composition tool
written in Python. The system can be scripted and embedded, and includes
integrated instrument libraries, post-tonal and microtonal pitch modeling
tools, multiple-format graphical outputs, and musical output in Csound,
SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."

(http://code.google.com/p/athenacl/)

i think it's a great idea to coordinate a collective effort to develop a
library of functions to generate events for the csound score. i'm trying
to teach myself a little python, it would be fun to (try to) contribute to
the project. i'll have to look closer at pysco, jacob!

best,


lj


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



Date2013-03-19 22:06
Frompeiman khosravi
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
Also, it would be sweet if one could generate a list as string for each note, using patterns. So the same patterns can be used to generate sequences (or sequences of sequences) of 'notes', as well as to generate lists to be passed to the instrument as strings, to be used as envelopes inside the note. So one can effectively generate patterns on many structural levels. 

P  



On 19 March 2013 22:00, peiman khosravi <peimankhosravi@gmail.com> wrote:
I love the pattern library from SC. I think that's a good starting point. http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_02_Basic_Vocabulary.html

P

On 19 March 2013 21:13, luis jure <ljc@internet.com.uy> wrote:

on 2013-03-19 at 12:50 Jacob Joaquin wrote:

> What Csound-Python tools currently exist? I'm aware of CsoundAC,
> PMask, Blue, the opcodes, and Python Score.

christopher ariza's athenaCL is written in python, and outputs several
formats, csound score among them:

"The athenaCL system is an open-source, object-oriented composition tool
written in Python. The system can be scripted and embedded, and includes
integrated instrument libraries, post-tonal and microtonal pitch modeling
tools, multiple-format graphical outputs, and musical output in Csound,
SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."

(http://code.google.com/p/athenacl/)

i think it's a great idea to coordinate a collective effort to develop a
library of functions to generate events for the csound score. i'm trying
to teach myself a little python, it would be fun to (try to) contribute to
the project. i'll have to look closer at pysco, jacob!

best,


lj


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




Date2013-03-19 22:40
FromJacob Joaquin
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
I quickly took a look Pattern Basic Vocabulary guide. It appears that
some things are already built into Python that gets us part way there.
In particular, the random numbers list generators. For example, here's
SC code that generates a list of 4 values:

Pgauss(0.5, 0.5, 4).asStream.all

Output:
[ 0.37749603819767, 1.5397875446512, 0.076056728303353, -0.097579578566421 ]

Here's doing it with Python right out of the box with gauss imported
from Python's random lib:

print [gauss(0.5, 0.5) for i in range(4)]

Output:
[1.1820126378639217, 0.7564649879894227, -1.0602080628007708,
0.9946833806684703]

And if the syntax in the square brackets is scary, it can be wrapped
up into a function and placed into a library, closely resembling SC's
code:

def pGauss(mu, sigma, length):
    return [gauss(mu, sigma) for i in range(length)]

print pGauss(0.5, 0.5, 4)

Output:
[0.8475387220496782, 0.22159077101802582, 1.2479709480301213, 0.675590664776209]

Best,
Jake



On Tue, Mar 19, 2013 at 3:00 PM, peiman khosravi
 wrote:
> I love the pattern library from SC. I think that's a good starting point.
> http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_02_Basic_Vocabulary.html
>
> P
>
> On 19 March 2013 21:13, luis jure  wrote:
>>
>>
>> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>>
>> > What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> > PMask, Blue, the opcodes, and Python Score.
>>
>> christopher ariza's athenaCL is written in python, and outputs several
>> formats, csound score among them:
>>
>> "The athenaCL system is an open-source, object-oriented composition tool
>> written in Python. The system can be scripted and embedded, and includes
>> integrated instrument libraries, post-tonal and microtonal pitch modeling
>> tools, multiple-format graphical outputs, and musical output in Csound,
>> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>>
>> (http://code.google.com/p/athenacl/)
>>
>> i think it's a great idea to coordinate a collective effort to develop a
>> library of functions to generate events for the csound score. i'm trying
>> to teach myself a little python, it would be fun to (try to) contribute to
>> the project. i'll have to look closer at pysco, jacob!
>>
>> best,
>>
>>
>> lj
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>



-- 
codehop.com | #code #art #music

Date2013-03-19 22:57
FromMichael Gogins
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
Regarding athenaCL, it was not designed for scripting, but for
interaction with the composer via the command line, resulting in
pieces created by interactively issuing a series of commands in a
session. It is possible to script the system to some extent, but this
is not well documented or that easy to do.

Christopher Ariza, the author of athenaCL, now seems to be extensively
involved with music21, which deserves its own consideration by
composers.

http://mit.edu/music21/

Any efforts to develop a library of compositional routines is going to
run into the historical and present and probably future fact that
composers do not think alike. A fundamental problem will be
representing what is essential, at the lowest level of musical
description, in such a way that different functions can be composed
together.

This is a problem that has been considered, and partly solved, by my
system CsoundAC (where both musical notes and chords are vectors in
spaces and can be composed with techniques borrowed from computer
graphics), by Rubato Composer which takes a somewhat similar but
mathematically more sophisticated approach based on category theory
and understanding the types of algebras involved in working with
musical notes and scores, and of course those systems that are more or
less based on MIDI semantics, although this of course is quite
limiting. Also take a look at OpenMusic, which seems to have its own
mathematical basis though I don't think I understand just what it is,
and of course Grace (which sprang more or less fully formed from the
forehead of Common Music).

The kind of difficulty that you can anticipate will be like this: What
is pitch? Depends on the kind of piece you want to make. But to get a
SYSTEM going you need a basic representation of pitch that is amenable
to mathematical manipulation and that can easily be translated back
forth from the more specific notions of pitch used in actual pieces. I
think it should be MIDI note number only allowing fractional values
for fractional pitches and variant scales, but lots of people just
assume it should be integers standing for scale degree. Getting
composers to agree on something so basic is like herding cats... no,
worse than herding cats.

Regards,
Mike

On Tue, Mar 19, 2013 at 5:13 PM, luis jure  wrote:
>
> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>
>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> PMask, Blue, the opcodes, and Python Score.
>
> christopher ariza's athenaCL is written in python, and outputs several
> formats, csound score among them:
>
> "The athenaCL system is an open-source, object-oriented composition tool
> written in Python. The system can be scripted and embedded, and includes
> integrated instrument libraries, post-tonal and microtonal pitch modeling
> tools, multiple-format graphical outputs, and musical output in Csound,
> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>
> (http://code.google.com/p/athenacl/)
>
> i think it's a great idea to coordinate a collective effort to develop a
> library of functions to generate events for the csound score. i'm trying
> to teach myself a little python, it would be fun to (try to) contribute to
> the project. i'll have to look closer at pysco, jacob!
>
> best,
>
>
> lj
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> 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

Date2013-03-19 23:24
Frompeiman khosravi
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
Nice. 

On 19 March 2013 22:40, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
I quickly took a look Pattern Basic Vocabulary guide. It appears that
some things are already built into Python that gets us part way there.
In particular, the random numbers list generators. For example, here's
SC code that generates a list of 4 values:

Pgauss(0.5, 0.5, 4).asStream.all

Output:
[ 0.37749603819767, 1.5397875446512, 0.076056728303353, -0.097579578566421 ]

Here's doing it with Python right out of the box with gauss imported
from Python's random lib:

print [gauss(0.5, 0.5) for i in range(4)]

Output:
[1.1820126378639217, 0.7564649879894227, -1.0602080628007708,
0.9946833806684703]

And if the syntax in the square brackets is scary, it can be wrapped
up into a function and placed into a library, closely resembling SC's
code:

def pGauss(mu, sigma, length):
    return [gauss(mu, sigma) for i in range(length)]

print pGauss(0.5, 0.5, 4)

Output:
[0.8475387220496782, 0.22159077101802582, 1.2479709480301213, 0.675590664776209]

Best,
Jake



On Tue, Mar 19, 2013 at 3:00 PM, peiman khosravi
<peimankhosravi@gmail.com> wrote:
> I love the pattern library from SC. I think that's a good starting point.
> http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_02_Basic_Vocabulary.html
>
> P
>
> On 19 March 2013 21:13, luis jure <ljc@internet.com.uy> wrote:
>>
>>
>> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>>
>> > What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> > PMask, Blue, the opcodes, and Python Score.
>>
>> christopher ariza's athenaCL is written in python, and outputs several
>> formats, csound score among them:
>>
>> "The athenaCL system is an open-source, object-oriented composition tool
>> written in Python. The system can be scripted and embedded, and includes
>> integrated instrument libraries, post-tonal and microtonal pitch modeling
>> tools, multiple-format graphical outputs, and musical output in Csound,
>> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>>
>> (http://code.google.com/p/athenacl/)
>>
>> i think it's a great idea to coordinate a collective effort to develop a
>> library of functions to generate events for the csound score. i'm trying
>> to teach myself a little python, it would be fun to (try to) contribute to
>> the project. i'll have to look closer at pysco, jacob!
>>
>> best,
>>
>>
>> lj
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>



--
codehop.com | #code #art #music


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



Date2013-03-19 23:46
Frompeiman khosravi
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
This is what I like about this system.
 
Prand(list, repeats) 

randomly returns a member from the list, repeats times.    

Amazingly, list can contain patterns. So then you can have patterns of pattern of pattern. That's what I want!

By the way worth checking this: http://www.mcld.co.uk/blog/blog.php?339

P

On 19 March 2013 22:40, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
I quickly took a look Pattern Basic Vocabulary guide. It appears that
some things are already built into Python that gets us part way there.
In particular, the random numbers list generators. For example, here's
SC code that generates a list of 4 values:

Pgauss(0.5, 0.5, 4).asStream.all

Output:
[ 0.37749603819767, 1.5397875446512, 0.076056728303353, -0.097579578566421 ]

Here's doing it with Python right out of the box with gauss imported
from Python's random lib:

print [gauss(0.5, 0.5) for i in range(4)]

Output:
[1.1820126378639217, 0.7564649879894227, -1.0602080628007708,
0.9946833806684703]

And if the syntax in the square brackets is scary, it can be wrapped
up into a function and placed into a library, closely resembling SC's
code:

def pGauss(mu, sigma, length):
    return [gauss(mu, sigma) for i in range(length)]

print pGauss(0.5, 0.5, 4)

Output:
[0.8475387220496782, 0.22159077101802582, 1.2479709480301213, 0.675590664776209]

Best,
Jake



On Tue, Mar 19, 2013 at 3:00 PM, peiman khosravi
<peimankhosravi@gmail.com> wrote:
> I love the pattern library from SC. I think that's a good starting point.
> http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_02_Basic_Vocabulary.html
>
> P
>
> On 19 March 2013 21:13, luis jure <ljc@internet.com.uy> wrote:
>>
>>
>> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>>
>> > What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> > PMask, Blue, the opcodes, and Python Score.
>>
>> christopher ariza's athenaCL is written in python, and outputs several
>> formats, csound score among them:
>>
>> "The athenaCL system is an open-source, object-oriented composition tool
>> written in Python. The system can be scripted and embedded, and includes
>> integrated instrument libraries, post-tonal and microtonal pitch modeling
>> tools, multiple-format graphical outputs, and musical output in Csound,
>> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>>
>> (http://code.google.com/p/athenacl/)
>>
>> i think it's a great idea to coordinate a collective effort to develop a
>> library of functions to generate events for the csound score. i'm trying
>> to teach myself a little python, it would be fun to (try to) contribute to
>> the project. i'll have to look closer at pysco, jacob!
>>
>> best,
>>
>>
>> lj
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>



--
codehop.com | #code #art #music


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



Date2013-03-20 01:31
FromJacob Joaquin
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
I'm not sure what others are looking in a Python library for Csound,
but my personal focus is on creating a streamlined interface to the
Csound score for easily generating score events, and then have
multiple libraries for different intended uses. So something that
doesn't try to be all encompassing, but allows others to piece
together their own environments either from importing existing
libraries, or creating their own custom set of functions. Will every
library be interoperable, no. Will it be better than having all these
independent score generators that don't work together at all, big yes.

For example, I installed Music21 (which is awesome btw so thanks for
the suggestion) and had it working with Python Score. But then it
broke and broke badly and it isn't working, but I was close to having
a Bach piece in MusicXML converted into Csound score events.

Best,
Jake

On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
 wrote:
> Regarding athenaCL, it was not designed for scripting, but for
> interaction with the composer via the command line, resulting in
> pieces created by interactively issuing a series of commands in a
> session. It is possible to script the system to some extent, but this
> is not well documented or that easy to do.
>
> Christopher Ariza, the author of athenaCL, now seems to be extensively
> involved with music21, which deserves its own consideration by
> composers.
>
> http://mit.edu/music21/
>
> Any efforts to develop a library of compositional routines is going to
> run into the historical and present and probably future fact that
> composers do not think alike. A fundamental problem will be
> representing what is essential, at the lowest level of musical
> description, in such a way that different functions can be composed
> together.
>
> This is a problem that has been considered, and partly solved, by my
> system CsoundAC (where both musical notes and chords are vectors in
> spaces and can be composed with techniques borrowed from computer
> graphics), by Rubato Composer which takes a somewhat similar but
> mathematically more sophisticated approach based on category theory
> and understanding the types of algebras involved in working with
> musical notes and scores, and of course those systems that are more or
> less based on MIDI semantics, although this of course is quite
> limiting. Also take a look at OpenMusic, which seems to have its own
> mathematical basis though I don't think I understand just what it is,
> and of course Grace (which sprang more or less fully formed from the
> forehead of Common Music).
>
> The kind of difficulty that you can anticipate will be like this: What
> is pitch? Depends on the kind of piece you want to make. But to get a
> SYSTEM going you need a basic representation of pitch that is amenable
> to mathematical manipulation and that can easily be translated back
> forth from the more specific notions of pitch used in actual pieces. I
> think it should be MIDI note number only allowing fractional values
> for fractional pitches and variant scales, but lots of people just
> assume it should be integers standing for scale degree. Getting
> composers to agree on something so basic is like herding cats... no,
> worse than herding cats.
>
> Regards,
> Mike
>
> On Tue, Mar 19, 2013 at 5:13 PM, luis jure  wrote:
>>
>> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>>
>>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>>> PMask, Blue, the opcodes, and Python Score.
>>
>> christopher ariza's athenaCL is written in python, and outputs several
>> formats, csound score among them:
>>
>> "The athenaCL system is an open-source, object-oriented composition tool
>> written in Python. The system can be scripted and embedded, and includes
>> integrated instrument libraries, post-tonal and microtonal pitch modeling
>> tools, multiple-format graphical outputs, and musical output in Csound,
>> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>>
>> (http://code.google.com/p/athenacl/)
>>
>> i think it's a great idea to coordinate a collective effort to develop a
>> library of functions to generate events for the csound score. i'm trying
>> to teach myself a little python, it would be fun to (try to) contribute to
>> the project. i'll have to look closer at pysco, jacob!
>>
>> best,
>>
>>
>> lj
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> 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 the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 
codehop.com | #code #art #music

Date2013-03-20 08:51
Frompeiman khosravi
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
Agreed. 

P

On 20 March 2013 01:31, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
I'm not sure what others are looking in a Python library for Csound,
but my personal focus is on creating a streamlined interface to the
Csound score for easily generating score events, and then have
multiple libraries for different intended uses. So something that
doesn't try to be all encompassing, but allows others to piece
together their own environments either from importing existing
libraries, or creating their own custom set of functions. Will every
library be interoperable, no. Will it be better than having all these
independent score generators that don't work together at all, big yes.

For example, I installed Music21 (which is awesome btw so thanks for
the suggestion) and had it working with Python Score. But then it
broke and broke badly and it isn't working, but I was close to having
a Bach piece in MusicXML converted into Csound score events.

Best,
Jake

On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
<michael.gogins@gmail.com> wrote:
> Regarding athenaCL, it was not designed for scripting, but for
> interaction with the composer via the command line, resulting in
> pieces created by interactively issuing a series of commands in a
> session. It is possible to script the system to some extent, but this
> is not well documented or that easy to do.
>
> Christopher Ariza, the author of athenaCL, now seems to be extensively
> involved with music21, which deserves its own consideration by
> composers.
>
> http://mit.edu/music21/
>
> Any efforts to develop a library of compositional routines is going to
> run into the historical and present and probably future fact that
> composers do not think alike. A fundamental problem will be
> representing what is essential, at the lowest level of musical
> description, in such a way that different functions can be composed
> together.
>
> This is a problem that has been considered, and partly solved, by my
> system CsoundAC (where both musical notes and chords are vectors in
> spaces and can be composed with techniques borrowed from computer
> graphics), by Rubato Composer which takes a somewhat similar but
> mathematically more sophisticated approach based on category theory
> and understanding the types of algebras involved in working with
> musical notes and scores, and of course those systems that are more or
> less based on MIDI semantics, although this of course is quite
> limiting. Also take a look at OpenMusic, which seems to have its own
> mathematical basis though I don't think I understand just what it is,
> and of course Grace (which sprang more or less fully formed from the
> forehead of Common Music).
>
> The kind of difficulty that you can anticipate will be like this: What
> is pitch? Depends on the kind of piece you want to make. But to get a
> SYSTEM going you need a basic representation of pitch that is amenable
> to mathematical manipulation and that can easily be translated back
> forth from the more specific notions of pitch used in actual pieces. I
> think it should be MIDI note number only allowing fractional values
> for fractional pitches and variant scales, but lots of people just
> assume it should be integers standing for scale degree. Getting
> composers to agree on something so basic is like herding cats... no,
> worse than herding cats.
>
> Regards,
> Mike
>
> On Tue, Mar 19, 2013 at 5:13 PM, luis jure <ljc@internet.com.uy> wrote:
>>
>> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>>
>>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>>> PMask, Blue, the opcodes, and Python Score.
>>
>> christopher ariza's athenaCL is written in python, and outputs several
>> formats, csound score among them:
>>
>> "The athenaCL system is an open-source, object-oriented composition tool
>> written in Python. The system can be scripted and embedded, and includes
>> integrated instrument libraries, post-tonal and microtonal pitch modeling
>> tools, multiple-format graphical outputs, and musical output in Csound,
>> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>>
>> (http://code.google.com/p/athenacl/)
>>
>> i think it's a great idea to coordinate a collective effort to develop a
>> library of functions to generate events for the csound score. i'm trying
>> to teach myself a little python, it would be fun to (try to) contribute to
>> the project. i'll have to look closer at pysco, jacob!
>>
>> best,
>>
>>
>> lj
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> 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 the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



--
codehop.com | #code #art #music


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



Date2013-03-20 10:16
FromBen Hackbarth
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like to Exist?
i would love to see the python opcodes support the passing of strings.
 any maybe t-vars too, though i have not had the chance to use them
yet.

--  ben


On Tue, Mar 19, 2013 at 10:32 PM, Adam Puckett  wrote:
> It uses Python, but its sound engine is pyo, not Csound.
>
> On 3/19/13, Justin Smith  wrote:
>> I think the current version of cecilia uses python too.
>>
>> or maybe this is just a fork? https://code.google.com/p/cecilia4/
>>
>>
>> On Tue, Mar 19, 2013 at 12:50 PM, Jacob Joaquin
>> wrote:
>>
>>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>>> PMask, Blue, the opcodes, and Python Score.
>>>
>>> What tools, functions, capabilities would Csounders like to have in a
>>> score environment? Big things and little things included.
>>>
>>> Best,
>>> Jake
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

Date2013-03-20 20:41
FromJacob Joaquin
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
I started looking into creating Python Generators in which a generator
can also accept a generator. Which sorta like what SC is doing with
patterns, though very basic in comparison. For example, this:

p = rcycle(['A', 'B', rcycle(['C', 'D'])])

loops through this pattern:

['A', 'B', 'C', 'A', 'B', 'D']

Applying this concept to something musical, I came up with the
following example, in which rcycle is applied to the bassline, melody,
and rhythms, with a total of 1621 score events generated.

Code:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/rcycle.csd

Audio:
https://soundcloud.com/jacobjoaquin/csound-python-score-rcycle-csd

I'm not certain if I'll personally try to recreate SC Patterns,
especially since it appears someone may have already done so at the
link you provided, but I'll at least get something going which is
pythonic in nature.

Best,
Jake


On Tue, Mar 19, 2013 at 4:46 PM, peiman khosravi
 wrote:
> This is what I like about this system.
>
> Prand(list, repeats)
>
> randomly returns a member from the list, repeats times.
>
> Amazingly, list can contain patterns. So then you can have patterns of
> pattern of pattern. That's what I want!
>
> By the way worth checking this: http://www.mcld.co.uk/blog/blog.php?339
>
> P
>
> On 19 March 2013 22:40, Jacob Joaquin  wrote:
>>
>> I quickly took a look Pattern Basic Vocabulary guide. It appears that
>> some things are already built into Python that gets us part way there.
>> In particular, the random numbers list generators. For example, here's
>> SC code that generates a list of 4 values:
>>
>> Pgauss(0.5, 0.5, 4).asStream.all
>>
>> Output:
>> [ 0.37749603819767, 1.5397875446512, 0.076056728303353, -0.097579578566421
>> ]
>>
>> Here's doing it with Python right out of the box with gauss imported
>> from Python's random lib:
>>
>> print [gauss(0.5, 0.5) for i in range(4)]
>>
>> Output:
>> [1.1820126378639217, 0.7564649879894227, -1.0602080628007708,
>> 0.9946833806684703]
>>
>> And if the syntax in the square brackets is scary, it can be wrapped
>> up into a function and placed into a library, closely resembling SC's
>> code:
>>
>> def pGauss(mu, sigma, length):
>>     return [gauss(mu, sigma) for i in range(length)]
>>
>> print pGauss(0.5, 0.5, 4)
>>
>> Output:
>> [0.8475387220496782, 0.22159077101802582, 1.2479709480301213,
>> 0.675590664776209]
>>
>> Best,
>> Jake
>>
>>
>>
>> On Tue, Mar 19, 2013 at 3:00 PM, peiman khosravi
>>  wrote:
>> > I love the pattern library from SC. I think that's a good starting
>> > point.
>> >
>> > http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_02_Basic_Vocabulary.html
>> >
>> > P
>> >
>> > On 19 March 2013 21:13, luis jure  wrote:
>> >>
>> >>
>> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >>
>> >> > What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >> > PMask, Blue, the opcodes, and Python Score.
>> >>
>> >> christopher ariza's athenaCL is written in python, and outputs several
>> >> formats, csound score among them:
>> >>
>> >> "The athenaCL system is an open-source, object-oriented composition
>> >> tool
>> >> written in Python. The system can be scripted and embedded, and
>> >> includes
>> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> modeling
>> >> tools, multiple-format graphical outputs, and musical output in Csound,
>> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >>
>> >> (http://code.google.com/p/athenacl/)
>> >>
>> >> i think it's a great idea to coordinate a collective effort to develop
>> >> a
>> >> library of functions to generate events for the csound score. i'm
>> >> trying
>> >> to teach myself a little python, it would be fun to (try to) contribute
>> >> to
>> >> the project. i'll have to look closer at pysco, jacob!
>> >>
>> >> best,
>> >>
>> >>
>> >> lj
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> "unsubscribe
>> >> csound"
>> >>
>> >
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>



-- 
codehop.com | #code #art #music

Date2013-03-20 21:44
FromSteven Yi
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
Hi Jake,

I think it's a good idea you have to try to build up a library of
useful musical functions.  I'll certainly be happy to include whatever
you work on with Blue to make it available to Blue users out of the
box.

I also think MIchael's cautions are very important, but your point
about "something that doesn't try to be all encompassing, but allows
others to piece together their own environments" seems right on the
money to me.  I've been spending most of my reading time on Clojure
and Haskell literature, and function composition and reuse is a big
concern in these communities.  I think having a library for Python
could be very useful.

One other thing you had mentioned in looking at Pgauss is that "some
things are already built into Python".  I've had the same experience
in looking at Patterns in SC as well as CMask, nGen, PMask, and other
libraries, and comparing them to built-in features in Clojure (which
would also apply to Lisp, Scheme, Haskell, and other functional
programming languages).  Most functional languages deal heavily with
list processing, lazy list generation, stream transformations, etc.
Python does do support some functional programming aspects, and
generators are rather nice, I've found Clojure just a little bit more
to my liking now.

I had recently been working on organizing my own Python composition
code into a single library, but I'm now planning to build up a library
in Clojure instead.  However, I thought I'd mention that I found these
program/libraries useful to look at for music functions:

* Common Music (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
* Overtone (http://overtone.github.com)
* Symbolic Composer (http://www.symboliccomposer.com/)
* OpenMusic
* CsoundAC (Michael's system, comes with Csound installer)

Of these, I think Symbolic Composer probably has the largest set of
functions I've come across. (I didn't see any manuals viewable online,
but they're visible within the program.) While these aren't python
projects, I thought they were worth mentioning.

I also took a look at the link to isobar that Peiman listed and found
that rather interesting too.  The original project
(https://github.com/ideoforms/isobar) seems to have quite a bit of
functionality implemented.

Anyways, some ramblings on from me. :)  Looking forward to what comes
of all this and good luck with it!

steven


On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
 wrote:
> Agreed.
>
> P
>
>
> On 20 March 2013 01:31, Jacob Joaquin  wrote:
>>
>> I'm not sure what others are looking in a Python library for Csound,
>> but my personal focus is on creating a streamlined interface to the
>> Csound score for easily generating score events, and then have
>> multiple libraries for different intended uses. So something that
>> doesn't try to be all encompassing, but allows others to piece
>> together their own environments either from importing existing
>> libraries, or creating their own custom set of functions. Will every
>> library be interoperable, no. Will it be better than having all these
>> independent score generators that don't work together at all, big yes.
>>
>> For example, I installed Music21 (which is awesome btw so thanks for
>> the suggestion) and had it working with Python Score. But then it
>> broke and broke badly and it isn't working, but I was close to having
>> a Bach piece in MusicXML converted into Csound score events.
>>
>> Best,
>> Jake
>>
>> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>>  wrote:
>> > Regarding athenaCL, it was not designed for scripting, but for
>> > interaction with the composer via the command line, resulting in
>> > pieces created by interactively issuing a series of commands in a
>> > session. It is possible to script the system to some extent, but this
>> > is not well documented or that easy to do.
>> >
>> > Christopher Ariza, the author of athenaCL, now seems to be extensively
>> > involved with music21, which deserves its own consideration by
>> > composers.
>> >
>> > http://mit.edu/music21/
>> >
>> > Any efforts to develop a library of compositional routines is going to
>> > run into the historical and present and probably future fact that
>> > composers do not think alike. A fundamental problem will be
>> > representing what is essential, at the lowest level of musical
>> > description, in such a way that different functions can be composed
>> > together.
>> >
>> > This is a problem that has been considered, and partly solved, by my
>> > system CsoundAC (where both musical notes and chords are vectors in
>> > spaces and can be composed with techniques borrowed from computer
>> > graphics), by Rubato Composer which takes a somewhat similar but
>> > mathematically more sophisticated approach based on category theory
>> > and understanding the types of algebras involved in working with
>> > musical notes and scores, and of course those systems that are more or
>> > less based on MIDI semantics, although this of course is quite
>> > limiting. Also take a look at OpenMusic, which seems to have its own
>> > mathematical basis though I don't think I understand just what it is,
>> > and of course Grace (which sprang more or less fully formed from the
>> > forehead of Common Music).
>> >
>> > The kind of difficulty that you can anticipate will be like this: What
>> > is pitch? Depends on the kind of piece you want to make. But to get a
>> > SYSTEM going you need a basic representation of pitch that is amenable
>> > to mathematical manipulation and that can easily be translated back
>> > forth from the more specific notions of pitch used in actual pieces. I
>> > think it should be MIDI note number only allowing fractional values
>> > for fractional pitches and variant scales, but lots of people just
>> > assume it should be integers standing for scale degree. Getting
>> > composers to agree on something so basic is like herding cats... no,
>> > worse than herding cats.
>> >
>> > Regards,
>> > Mike
>> >
>> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure  wrote:
>> >>
>> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >>
>> >>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >>> PMask, Blue, the opcodes, and Python Score.
>> >>
>> >> christopher ariza's athenaCL is written in python, and outputs several
>> >> formats, csound score among them:
>> >>
>> >> "The athenaCL system is an open-source, object-oriented composition
>> >> tool
>> >> written in Python. The system can be scripted and embedded, and
>> >> includes
>> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> modeling
>> >> tools, multiple-format graphical outputs, and musical output in Csound,
>> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >>
>> >> (http://code.google.com/p/athenacl/)
>> >>
>> >> i think it's a great idea to coordinate a collective effort to develop
>> >> a
>> >> library of functions to generate events for the csound score. i'm
>> >> trying
>> >> to teach myself a little python, it would be fun to (try to) contribute
>> >> to
>> >> the project. i'll have to look closer at pysco, jacob!
>> >>
>> >> best,
>> >>
>> >>
>> >> lj
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> 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 the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>

Date2013-03-21 07:14
FromOeyvind Brandtsegg
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
This is indeed an interesting discussion.
I'd like to be more involved, but here's my "2 cents" for the moment:

I think Michael's point:
"Any efforts to develop a library of compositional routines is going to
run into the historical and present and probably future fact that
composers do not think alike. A fundamental problem will be
representing what is essential, at the lowest level of musical
description, in such a way that different functions can be composed
together."
... is right at the heart of the problem. And it is the main reason why I think some of the existing tools are hard to use. Because they don't fit. I do think that any system that builds from a representation of what is essential up towards more complex or abstract representations/ideas will simply *not fit* for many composers. The actual representation chosen determining who it will fit and for whom it will not work.
I am deeply unsure of how to make a better system, but I do think it should be built the other way around: deciding on a representation of what is essential for the output as the last operation, not the first. This wold probably make the learning curve steeper, but it would also make the curve flatten out nicely when it comes to solving more complex problems.  If need be, a *suggested* ("optional default") representation could be used to enable quick sketches and tutorials, but that this representation should be highly configurable and not tied to the actual manipulation of the data (the compositional algorithms).

Very humbly, as I said, i don't know exactly how it should be done, and being very much aware that others on this list have much more experience in software/language design.
(Also of course being open to suggestions of languages/systems actually working in this way)

best
Oeyvind



2013/3/20 Steven Yi <stevenyi@gmail.com>
Hi Jake,

I think it's a good idea you have to try to build up a library of
useful musical functions.  I'll certainly be happy to include whatever
you work on with Blue to make it available to Blue users out of the
box.

I also think MIchael's cautions are very important, but your point
about "something that doesn't try to be all encompassing, but allows
others to piece together their own environments" seems right on the
money to me.  I've been spending most of my reading time on Clojure
and Haskell literature, and function composition and reuse is a big
concern in these communities.  I think having a library for Python
could be very useful.

One other thing you had mentioned in looking at Pgauss is that "some
things are already built into Python".  I've had the same experience
in looking at Patterns in SC as well as CMask, nGen, PMask, and other
libraries, and comparing them to built-in features in Clojure (which
would also apply to Lisp, Scheme, Haskell, and other functional
programming languages).  Most functional languages deal heavily with
list processing, lazy list generation, stream transformations, etc.
Python does do support some functional programming aspects, and
generators are rather nice, I've found Clojure just a little bit more
to my liking now.

I had recently been working on organizing my own Python composition
code into a single library, but I'm now planning to build up a library
in Clojure instead.  However, I thought I'd mention that I found these
program/libraries useful to look at for music functions:

* Common Music (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
* Overtone (http://overtone.github.com)
* Symbolic Composer (http://www.symboliccomposer.com/)
* OpenMusic
* CsoundAC (Michael's system, comes with Csound installer)

Of these, I think Symbolic Composer probably has the largest set of
functions I've come across. (I didn't see any manuals viewable online,
but they're visible within the program.) While these aren't python
projects, I thought they were worth mentioning.

I also took a look at the link to isobar that Peiman listed and found
that rather interesting too.  The original project
(https://github.com/ideoforms/isobar) seems to have quite a bit of
functionality implemented.

Anyways, some ramblings on from me. :)  Looking forward to what comes
of all this and good luck with it!

steven


On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
<peimankhosravi@gmail.com> wrote:
> Agreed.
>
> P
>
>
> On 20 March 2013 01:31, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
>>
>> I'm not sure what others are looking in a Python library for Csound,
>> but my personal focus is on creating a streamlined interface to the
>> Csound score for easily generating score events, and then have
>> multiple libraries for different intended uses. So something that
>> doesn't try to be all encompassing, but allows others to piece
>> together their own environments either from importing existing
>> libraries, or creating their own custom set of functions. Will every
>> library be interoperable, no. Will it be better than having all these
>> independent score generators that don't work together at all, big yes.
>>
>> For example, I installed Music21 (which is awesome btw so thanks for
>> the suggestion) and had it working with Python Score. But then it
>> broke and broke badly and it isn't working, but I was close to having
>> a Bach piece in MusicXML converted into Csound score events.
>>
>> Best,
>> Jake
>>
>> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>> <michael.gogins@gmail.com> wrote:
>> > Regarding athenaCL, it was not designed for scripting, but for
>> > interaction with the composer via the command line, resulting in
>> > pieces created by interactively issuing a series of commands in a
>> > session. It is possible to script the system to some extent, but this
>> > is not well documented or that easy to do.
>> >
>> > Christopher Ariza, the author of athenaCL, now seems to be extensively
>> > involved with music21, which deserves its own consideration by
>> > composers.
>> >
>> > http://mit.edu/music21/
>> >
>> > Any efforts to develop a library of compositional routines is going to
>> > run into the historical and present and probably future fact that
>> > composers do not think alike. A fundamental problem will be
>> > representing what is essential, at the lowest level of musical
>> > description, in such a way that different functions can be composed
>> > together.
>> >
>> > This is a problem that has been considered, and partly solved, by my
>> > system CsoundAC (where both musical notes and chords are vectors in
>> > spaces and can be composed with techniques borrowed from computer
>> > graphics), by Rubato Composer which takes a somewhat similar but
>> > mathematically more sophisticated approach based on category theory
>> > and understanding the types of algebras involved in working with
>> > musical notes and scores, and of course those systems that are more or
>> > less based on MIDI semantics, although this of course is quite
>> > limiting. Also take a look at OpenMusic, which seems to have its own
>> > mathematical basis though I don't think I understand just what it is,
>> > and of course Grace (which sprang more or less fully formed from the
>> > forehead of Common Music).
>> >
>> > The kind of difficulty that you can anticipate will be like this: What
>> > is pitch? Depends on the kind of piece you want to make. But to get a
>> > SYSTEM going you need a basic representation of pitch that is amenable
>> > to mathematical manipulation and that can easily be translated back
>> > forth from the more specific notions of pitch used in actual pieces. I
>> > think it should be MIDI note number only allowing fractional values
>> > for fractional pitches and variant scales, but lots of people just
>> > assume it should be integers standing for scale degree. Getting
>> > composers to agree on something so basic is like herding cats... no,
>> > worse than herding cats.
>> >
>> > Regards,
>> > Mike
>> >
>> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure <ljc@internet.com.uy> wrote:
>> >>
>> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >>
>> >>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >>> PMask, Blue, the opcodes, and Python Score.
>> >>
>> >> christopher ariza's athenaCL is written in python, and outputs several
>> >> formats, csound score among them:
>> >>
>> >> "The athenaCL system is an open-source, object-oriented composition
>> >> tool
>> >> written in Python. The system can be scripted and embedded, and
>> >> includes
>> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> modeling
>> >> tools, multiple-format graphical outputs, and musical output in Csound,
>> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >>
>> >> (http://code.google.com/p/athenacl/)
>> >>
>> >> i think it's a great idea to coordinate a collective effort to develop
>> >> a
>> >> library of functions to generate events for the csound score. i'm
>> >> trying
>> >> to teach myself a little python, it would be fun to (try to) contribute
>> >> to
>> >> the project. i'll have to look closer at pysco, jacob!
>> >>
>> >> best,
>> >>
>> >>
>> >> lj
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> 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 the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

Date2013-03-21 10:58
Frompeiman khosravi
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like


On 21 March 2013 07:14, Oeyvind Brandtsegg <oyvind.brandtsegg@ntnu.no> wrote:
This is indeed an interesting discussion.
I'd like to be more involved, but here's my "2 cents" for the moment:

I think Michael's point:

"Any efforts to develop a library of compositional routines is going to
run into the historical and present and probably future fact that
composers do not think alike. A fundamental problem will be
representing what is essential, at the lowest level of musical
description, in such a way that different functions can be composed
together."
... is right at the heart of the problem. And it is the main reason why I think some of the existing tools are hard to use. Because they don't fit. I do think that any system that builds from a representation of what is essential up towards more complex or abstract representations/ideas will simply *not fit* for many composers. The actual representation chosen determining who it will fit and for whom it will not work.
I am deeply unsure of how to make a better system, but I do think it should be built the other way around: deciding on a representation of what is essential for the output as the last operation, not the first. This wold probably make the learning curve steeper, but it would also make the curve flatten out nicely when it comes to solving more complex problems.  If need be, a *suggested* ("optional default") representation could be used to enable quick sketches and tutorials, but that this representation should be highly configurable and not tied to the actual manipulation of the data (the compositional algorithms).


Hi Oeyvind,

Absolutely agreed. I don't think that an algorithmic system should be 'intelligent' enough to understand the representation of what is essential for the construction of musical meaning. I don't think there should be any value hierarchies in such a system. Composing on the note level should be as accessible as composing on the grain level. I don't want the software to 'know' what is essential because I don't know what is essential: that is why I compose - to find out. This is why I normally prefer tools that are not musically intelligent (or at least not on the surface). I have no specific solutions but it seems to me that the only way to achieve some level of flatness is by thinking purely in terms of sound structures, rather than musical structures, when making an algorithmic system. This way the system simply provides a playground, to take advantage of all the control that the computer offers us. Why should an algorithmic system even have a conception of what is a note, what is timbre and what is grain?    
     

P   
        

Very humbly, as I said, i don't know exactly how it should be done, and being very much aware that others on this list have much more experience in software/language design.
(Also of course being open to suggestions of languages/systems actually working in this way)

best
Oeyvind



2013/3/20 Steven Yi <stevenyi@gmail.com>
Hi Jake,

I think it's a good idea you have to try to build up a library of
useful musical functions.  I'll certainly be happy to include whatever
you work on with Blue to make it available to Blue users out of the
box.

I also think MIchael's cautions are very important, but your point
about "something that doesn't try to be all encompassing, but allows
others to piece together their own environments" seems right on the
money to me.  I've been spending most of my reading time on Clojure
and Haskell literature, and function composition and reuse is a big
concern in these communities.  I think having a library for Python
could be very useful.

One other thing you had mentioned in looking at Pgauss is that "some
things are already built into Python".  I've had the same experience
in looking at Patterns in SC as well as CMask, nGen, PMask, and other
libraries, and comparing them to built-in features in Clojure (which
would also apply to Lisp, Scheme, Haskell, and other functional
programming languages).  Most functional languages deal heavily with
list processing, lazy list generation, stream transformations, etc.
Python does do support some functional programming aspects, and
generators are rather nice, I've found Clojure just a little bit more
to my liking now.

I had recently been working on organizing my own Python composition
code into a single library, but I'm now planning to build up a library
in Clojure instead.  However, I thought I'd mention that I found these
program/libraries useful to look at for music functions:

* Common Music (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
* Overtone (http://overtone.github.com)
* Symbolic Composer (http://www.symboliccomposer.com/)
* OpenMusic
* CsoundAC (Michael's system, comes with Csound installer)

Of these, I think Symbolic Composer probably has the largest set of
functions I've come across. (I didn't see any manuals viewable online,
but they're visible within the program.) While these aren't python
projects, I thought they were worth mentioning.

I also took a look at the link to isobar that Peiman listed and found
that rather interesting too.  The original project
(https://github.com/ideoforms/isobar) seems to have quite a bit of
functionality implemented.

Anyways, some ramblings on from me. :)  Looking forward to what comes
of all this and good luck with it!

steven


On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
<peimankhosravi@gmail.com> wrote:
> Agreed.
>
> P
>
>
> On 20 March 2013 01:31, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
>>
>> I'm not sure what others are looking in a Python library for Csound,
>> but my personal focus is on creating a streamlined interface to the
>> Csound score for easily generating score events, and then have
>> multiple libraries for different intended uses. So something that
>> doesn't try to be all encompassing, but allows others to piece
>> together their own environments either from importing existing
>> libraries, or creating their own custom set of functions. Will every
>> library be interoperable, no. Will it be better than having all these
>> independent score generators that don't work together at all, big yes.
>>
>> For example, I installed Music21 (which is awesome btw so thanks for
>> the suggestion) and had it working with Python Score. But then it
>> broke and broke badly and it isn't working, but I was close to having
>> a Bach piece in MusicXML converted into Csound score events.
>>
>> Best,
>> Jake
>>
>> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>> <michael.gogins@gmail.com> wrote:
>> > Regarding athenaCL, it was not designed for scripting, but for
>> > interaction with the composer via the command line, resulting in
>> > pieces created by interactively issuing a series of commands in a
>> > session. It is possible to script the system to some extent, but this
>> > is not well documented or that easy to do.
>> >
>> > Christopher Ariza, the author of athenaCL, now seems to be extensively
>> > involved with music21, which deserves its own consideration by
>> > composers.
>> >
>> > http://mit.edu/music21/
>> >
>> > Any efforts to develop a library of compositional routines is going to
>> > run into the historical and present and probably future fact that
>> > composers do not think alike. A fundamental problem will be
>> > representing what is essential, at the lowest level of musical
>> > description, in such a way that different functions can be composed
>> > together.
>> >
>> > This is a problem that has been considered, and partly solved, by my
>> > system CsoundAC (where both musical notes and chords are vectors in
>> > spaces and can be composed with techniques borrowed from computer
>> > graphics), by Rubato Composer which takes a somewhat similar but
>> > mathematically more sophisticated approach based on category theory
>> > and understanding the types of algebras involved in working with
>> > musical notes and scores, and of course those systems that are more or
>> > less based on MIDI semantics, although this of course is quite
>> > limiting. Also take a look at OpenMusic, which seems to have its own
>> > mathematical basis though I don't think I understand just what it is,
>> > and of course Grace (which sprang more or less fully formed from the
>> > forehead of Common Music).
>> >
>> > The kind of difficulty that you can anticipate will be like this: What
>> > is pitch? Depends on the kind of piece you want to make. But to get a
>> > SYSTEM going you need a basic representation of pitch that is amenable
>> > to mathematical manipulation and that can easily be translated back
>> > forth from the more specific notions of pitch used in actual pieces. I
>> > think it should be MIDI note number only allowing fractional values
>> > for fractional pitches and variant scales, but lots of people just
>> > assume it should be integers standing for scale degree. Getting
>> > composers to agree on something so basic is like herding cats... no,
>> > worse than herding cats.
>> >
>> > Regards,
>> > Mike
>> >
>> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure <ljc@internet.com.uy> wrote:
>> >>
>> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >>
>> >>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >>> PMask, Blue, the opcodes, and Python Score.
>> >>
>> >> christopher ariza's athenaCL is written in python, and outputs several
>> >> formats, csound score among them:
>> >>
>> >> "The athenaCL system is an open-source, object-oriented composition
>> >> tool
>> >> written in Python. The system can be scripted and embedded, and
>> >> includes
>> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> modeling
>> >> tools, multiple-format graphical outputs, and musical output in Csound,
>> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >>
>> >> (http://code.google.com/p/athenacl/)
>> >>
>> >> i think it's a great idea to coordinate a collective effort to develop
>> >> a
>> >> library of functions to generate events for the csound score. i'm
>> >> trying
>> >> to teach myself a little python, it would be fun to (try to) contribute
>> >> to
>> >> the project. i'll have to look closer at pysco, jacob!
>> >>
>> >> best,
>> >>
>> >>
>> >> lj
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> 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 the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp


Date2013-03-21 11:18
FromJustin Smith
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
Traditionally, even in pure programming contexts, the set of tools provided is in some way curated in order to cultivate specific conceptual models. One can program functionally in C, declaratively in javascript, in an object oriented manner in forth, or imperatively in haskell, but the language in each case will put up a fight, and a path of least resistance guides the user to a language's preferred approach.

Since any library implements an extension to the language, a composition library extends its base language with its own assumptions and shortcuts. So, just as a programming language pushes you toward its programming theory of choice, a composition language will push you into its music theory of choice.

All of that being said, it has been lamented before that the csound score has no concept of a measure (for example). While we like the idea of complete composition freedom to define our own models and abstractions, in practice we are using many of the same abstractions in an ad hoc way. Composing with measures, those measures usually have 4 or 8 beats, scales with repeating octaves where notes an octave apart are considered in some sense equivalent, scales with notes that are spaced in one of the common variations of the 7 note diatonic scale, chords built according to something approximating a classical / jazz / pop chording convention, timbres that have a strong fundamental pitch to them, textures defined in terms of densities of constituant grains and their tendencies, patterns of events that unfold in similar iterative ways etc. - as a few examples off the top of my head. While few of us follow all of these conventions, it is likely that most of us follow at least one, and a sizable percentage use many. If we value our time, and would desire to spend more time composing than building our compositional tools, there is something to be said for providing the most commonly used abstractions as a default (while of course allowing the user to ignore or replace them as desired).


On Thu, Mar 21, 2013 at 3:58 AM, peiman khosravi <peimankhosravi@gmail.com> wrote:


On 21 March 2013 07:14, Oeyvind Brandtsegg <oyvind.brandtsegg@ntnu.no> wrote:
This is indeed an interesting discussion.
I'd like to be more involved, but here's my "2 cents" for the moment:

I think Michael's point:

"Any efforts to develop a library of compositional routines is going to
run into the historical and present and probably future fact that
composers do not think alike. A fundamental problem will be
representing what is essential, at the lowest level of musical
description, in such a way that different functions can be composed
together."
... is right at the heart of the problem. And it is the main reason why I think some of the existing tools are hard to use. Because they don't fit. I do think that any system that builds from a representation of what is essential up towards more complex or abstract representations/ideas will simply *not fit* for many composers. The actual representation chosen determining who it will fit and for whom it will not work.
I am deeply unsure of how to make a better system, but I do think it should be built the other way around: deciding on a representation of what is essential for the output as the last operation, not the first. This wold probably make the learning curve steeper, but it would also make the curve flatten out nicely when it comes to solving more complex problems.  If need be, a *suggested* ("optional default") representation could be used to enable quick sketches and tutorials, but that this representation should be highly configurable and not tied to the actual manipulation of the data (the compositional algorithms).


Hi Oeyvind,

Absolutely agreed. I don't think that an algorithmic system should be 'intelligent' enough to understand the representation of what is essential for the construction of musical meaning. I don't think there should be any value hierarchies in such a system. Composing on the note level should be as accessible as composing on the grain level. I don't want the software to 'know' what is essential because I don't know what is essential: that is why I compose - to find out. This is why I normally prefer tools that are not musically intelligent (or at least not on the surface). I have no specific solutions but it seems to me that the only way to achieve some level of flatness is by thinking purely in terms of sound structures, rather than musical structures, when making an algorithmic system. This way the system simply provides a playground, to take advantage of all the control that the computer offers us. Why should an algorithmic system even have a conception of what is a note, what is timbre and what is grain?    
     

P   
        

Very humbly, as I said, i don't know exactly how it should be done, and being very much aware that others on this list have much more experience in software/language design.
(Also of course being open to suggestions of languages/systems actually working in this way)

best
Oeyvind



2013/3/20 Steven Yi <stevenyi@gmail.com>
Hi Jake,

I think it's a good idea you have to try to build up a library of
useful musical functions.  I'll certainly be happy to include whatever
you work on with Blue to make it available to Blue users out of the
box.

I also think MIchael's cautions are very important, but your point
about "something that doesn't try to be all encompassing, but allows
others to piece together their own environments" seems right on the
money to me.  I've been spending most of my reading time on Clojure
and Haskell literature, and function composition and reuse is a big
concern in these communities.  I think having a library for Python
could be very useful.

One other thing you had mentioned in looking at Pgauss is that "some
things are already built into Python".  I've had the same experience
in looking at Patterns in SC as well as CMask, nGen, PMask, and other
libraries, and comparing them to built-in features in Clojure (which
would also apply to Lisp, Scheme, Haskell, and other functional
programming languages).  Most functional languages deal heavily with
list processing, lazy list generation, stream transformations, etc.
Python does do support some functional programming aspects, and
generators are rather nice, I've found Clojure just a little bit more
to my liking now.

I had recently been working on organizing my own Python composition
code into a single library, but I'm now planning to build up a library
in Clojure instead.  However, I thought I'd mention that I found these
program/libraries useful to look at for music functions:

* Common Music (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
* Overtone (http://overtone.github.com)
* Symbolic Composer (http://www.symboliccomposer.com/)
* OpenMusic
* CsoundAC (Michael's system, comes with Csound installer)

Of these, I think Symbolic Composer probably has the largest set of
functions I've come across. (I didn't see any manuals viewable online,
but they're visible within the program.) While these aren't python
projects, I thought they were worth mentioning.

I also took a look at the link to isobar that Peiman listed and found
that rather interesting too.  The original project
(https://github.com/ideoforms/isobar) seems to have quite a bit of
functionality implemented.

Anyways, some ramblings on from me. :)  Looking forward to what comes
of all this and good luck with it!

steven


On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
<peimankhosravi@gmail.com> wrote:
> Agreed.
>
> P
>
>
> On 20 March 2013 01:31, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
>>
>> I'm not sure what others are looking in a Python library for Csound,
>> but my personal focus is on creating a streamlined interface to the
>> Csound score for easily generating score events, and then have
>> multiple libraries for different intended uses. So something that
>> doesn't try to be all encompassing, but allows others to piece
>> together their own environments either from importing existing
>> libraries, or creating their own custom set of functions. Will every
>> library be interoperable, no. Will it be better than having all these
>> independent score generators that don't work together at all, big yes.
>>
>> For example, I installed Music21 (which is awesome btw so thanks for
>> the suggestion) and had it working with Python Score. But then it
>> broke and broke badly and it isn't working, but I was close to having
>> a Bach piece in MusicXML converted into Csound score events.
>>
>> Best,
>> Jake
>>
>> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>> <michael.gogins@gmail.com> wrote:
>> > Regarding athenaCL, it was not designed for scripting, but for
>> > interaction with the composer via the command line, resulting in
>> > pieces created by interactively issuing a series of commands in a
>> > session. It is possible to script the system to some extent, but this
>> > is not well documented or that easy to do.
>> >
>> > Christopher Ariza, the author of athenaCL, now seems to be extensively
>> > involved with music21, which deserves its own consideration by
>> > composers.
>> >
>> > http://mit.edu/music21/
>> >
>> > Any efforts to develop a library of compositional routines is going to
>> > run into the historical and present and probably future fact that
>> > composers do not think alike. A fundamental problem will be
>> > representing what is essential, at the lowest level of musical
>> > description, in such a way that different functions can be composed
>> > together.
>> >
>> > This is a problem that has been considered, and partly solved, by my
>> > system CsoundAC (where both musical notes and chords are vectors in
>> > spaces and can be composed with techniques borrowed from computer
>> > graphics), by Rubato Composer which takes a somewhat similar but
>> > mathematically more sophisticated approach based on category theory
>> > and understanding the types of algebras involved in working with
>> > musical notes and scores, and of course those systems that are more or
>> > less based on MIDI semantics, although this of course is quite
>> > limiting. Also take a look at OpenMusic, which seems to have its own
>> > mathematical basis though I don't think I understand just what it is,
>> > and of course Grace (which sprang more or less fully formed from the
>> > forehead of Common Music).
>> >
>> > The kind of difficulty that you can anticipate will be like this: What
>> > is pitch? Depends on the kind of piece you want to make. But to get a
>> > SYSTEM going you need a basic representation of pitch that is amenable
>> > to mathematical manipulation and that can easily be translated back
>> > forth from the more specific notions of pitch used in actual pieces. I
>> > think it should be MIDI note number only allowing fractional values
>> > for fractional pitches and variant scales, but lots of people just
>> > assume it should be integers standing for scale degree. Getting
>> > composers to agree on something so basic is like herding cats... no,
>> > worse than herding cats.
>> >
>> > Regards,
>> > Mike
>> >
>> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure <ljc@internet.com.uy> wrote:
>> >>
>> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >>
>> >>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >>> PMask, Blue, the opcodes, and Python Score.
>> >>
>> >> christopher ariza's athenaCL is written in python, and outputs several
>> >> formats, csound score among them:
>> >>
>> >> "The athenaCL system is an open-source, object-oriented composition
>> >> tool
>> >> written in Python. The system can be scripted and embedded, and
>> >> includes
>> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> modeling
>> >> tools, multiple-format graphical outputs, and musical output in Csound,
>> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >>
>> >> (http://code.google.com/p/athenacl/)
>> >>
>> >> i think it's a great idea to coordinate a collective effort to develop
>> >> a
>> >> library of functions to generate events for the csound score. i'm
>> >> trying
>> >> to teach myself a little python, it would be fun to (try to) contribute
>> >> to
>> >> the project. i'll have to look closer at pysco, jacob!
>> >>
>> >> best,
>> >>
>> >>
>> >> lj
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> 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 the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp



Date2013-03-21 11:54
FromStéphane_Boussuge
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
i think the concept of generator and processor can be sufficiently abstract for every usage.
ie, you can generate a stream of white-noise value and procees / rescale it ,remap it and use it as a flow of value for any parameters.


stf
 
Le 21 mars 2013 à 12:18, Justin Smith <noisesmith@gmail.com> a écrit :

Traditionally, even in pure programming contexts, the set of tools provided is in some way curated in order to cultivate specific conceptual models. One can program functionally in C, declaratively in javascript, in an object oriented manner in forth, or imperatively in haskell, but the language in each case will put up a fight, and a path of least resistance guides the user to a language's preferred approach.

Since any library implements an extension to the language, a composition library extends its base language with its own assumptions and shortcuts. So, just as a programming language pushes you toward its programming theory of choice, a composition language will push you into its music theory of choice.

All of that being said, it has been lamented before that the csound score has no concept of a measure (for example). While we like the idea of complete composition freedom to define our own models and abstractions, in practice we are using many of the same abstractions in an ad hoc way. Composing with measures, those measures usually have 4 or 8 beats, scales with repeating octaves where notes an octave apart are considered in some sense equivalent, scales with notes that are spaced in one of the common variations of the 7 note diatonic scale, chords built according to something approximating a classical / jazz / pop chording convention, timbres that have a strong fundamental pitch to them, textures defined in terms of densities of constituant grains and their tendencies, patterns of events that unfold in similar iterative ways etc. - as a few examples off the top of my head. While few of us follow all of these conventions, it is likely that most of us follow at least one, and a sizable percentage use many. If we value our time, and would desire to spend more time composing than building our compositional tools, there is something to be said for providing the most commonly used abstractions as a default (while of course allowing the user to ignore or replace them as desired).


On Thu, Mar 21, 2013 at 3:58 AM, peiman khosravi <peimankhosravi@gmail.com> wrote:


On 21 March 2013 07:14, Oeyvind Brandtsegg <oyvind.brandtsegg@ntnu.no> wrote:
This is indeed an interesting discussion.
I'd like to be more involved, but here's my "2 cents" for the moment:

I think Michael's point:

"Any efforts to develop a library of compositional routines is going to
run into the historical and present and probably future fact that
composers do not think alike. A fundamental problem will be
representing what is essential, at the lowest level of musical
description, in such a way that different functions can be composed
together."
... is right at the heart of the problem. And it is the main reason why I think some of the existing tools are hard to use. Because they don't fit. I do think that any system that builds from a representation of what is essential up towards more complex or abstract representations/ideas will simply *not fit* for many composers. The actual representation chosen determining who it will fit and for whom it will not work.
I am deeply unsure of how to make a better system, but I do think it should be built the other way around: deciding on a representation of what is essential for the output as the last operation, not the first. This wold probably make the learning curve steeper, but it would also make the curve flatten out nicely when it comes to solving more complex problems.  If need be, a *suggested* ("optional default") representation could be used to enable quick sketches and tutorials, but that this representation should be highly configurable and not tied to the actual manipulation of the data (the compositional algorithms).


Hi Oeyvind,

Absolutely agreed. I don't think that an algorithmic system should be 'intelligent' enough to understand the representation of what is essential for the construction of musical meaning. I don't think there should be any value hierarchies in such a system. Composing on the note level should be as accessible as composing on the grain level. I don't want the software to 'know' what is essential because I don't know what is essential: that is why I compose - to find out. This is why I normally prefer tools that are not musically intelligent (or at least not on the surface). I have no specific solutions but it seems to me that the only way to achieve some level of flatness is by thinking purely in terms of sound structures, rather than musical structures, when making an algorithmic system. This way the system simply provides a playground, to take advantage of all the control that the computer offers us. Why should an algorithmic system even have a conception of what is a note, what is timbre and what is grain?    
     

P   
        

Very humbly, as I said, i don't know exactly how it should be done, and being very much aware that others on this list have much more experience in software/language design.
(Also of course being open to suggestions of languages/systems actually working in this way)

best
Oeyvind



2013/3/20 Steven Yi <stevenyi@gmail.com>
Hi Jake,

I think it's a good idea you have to try to build up a library of
useful musical functions.  I'll certainly be happy to include whatever
you work on with Blue to make it available to Blue users out of the
box.

I also think MIchael's cautions are very important, but your point
about "something that doesn't try to be all encompassing, but allows
others to piece together their own environments" seems right on the
money to me.  I've been spending most of my reading time on Clojure
and Haskell literature, and function composition and reuse is a big
concern in these communities.  I think having a library for Python
could be very useful.

One other thing you had mentioned in looking at Pgauss is that "some
things are already built into Python".  I've had the same experience
in looking at Patterns in SC as well as CMask, nGen, PMask, and other
libraries, and comparing them to built-in features in Clojure (which
would also apply to Lisp, Scheme, Haskell, and other functional
programming languages).  Most functional languages deal heavily with
list processing, lazy list generation, stream transformations, etc.
Python does do support some functional programming aspects, and
generators are rather nice, I've found Clojure just a little bit more
to my liking now.

I had recently been working on organizing my own Python composition
code into a single library, but I'm now planning to build up a library
in Clojure instead.  However, I thought I'd mention that I found these
program/libraries useful to look at for music functions:

* Common Music (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
* Overtone (http://overtone.github.com)
* Symbolic Composer (http://www.symboliccomposer.com/)
* OpenMusic
* CsoundAC (Michael's system, comes with Csound installer)

Of these, I think Symbolic Composer probably has the largest set of
functions I've come across. (I didn't see any manuals viewable online,
but they're visible within the program.) While these aren't python
projects, I thought they were worth mentioning.

I also took a look at the link to isobar that Peiman listed and found
that rather interesting too.  The original project
(https://github.com/ideoforms/isobar) seems to have quite a bit of
functionality implemented.

Anyways, some ramblings on from me. :)  Looking forward to what comes
of all this and good luck with it!

steven


On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
<peimankhosravi@gmail.com> wrote:
> Agreed.
>
> P
>
>
> On 20 March 2013 01:31, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
>>
>> I'm not sure what others are looking in a Python library for Csound,
>> but my personal focus is on creating a streamlined interface to the
>> Csound score for easily generating score events, and then have
>> multiple libraries for different intended uses. So something that
>> doesn't try to be all encompassing, but allows others to piece
>> together their own environments either from importing existing
>> libraries, or creating their own custom set of functions. Will every
>> library be interoperable, no. Will it be better than having all these
>> independent score generators that don't work together at all, big yes.
>>
>> For example, I installed Music21 (which is awesome btw so thanks for
>> the suggestion) and had it working with Python Score. But then it
>> broke and broke badly and it isn't working, but I was close to having
>> a Bach piece in MusicXML converted into Csound score events.
>>
>> Best,
>> Jake
>>
>> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>> <michael.gogins@gmail.com> wrote:
>> > Regarding athenaCL, it was not designed for scripting, but for
>> > interaction with the composer via the command line, resulting in
>> > pieces created by interactively issuing a series of commands in a
>> > session. It is possible to script the system to some extent, but this
>> > is not well documented or that easy to do.
>> >
>> > Christopher Ariza, the author of athenaCL, now seems to be extensively
>> > involved with music21, which deserves its own consideration by
>> > composers.
>> >
>> > http://mit.edu/music21/
>> >
>> > Any efforts to develop a library of compositional routines is going to
>> > run into the historical and present and probably future fact that
>> > composers do not think alike. A fundamental problem will be
>> > representing what is essential, at the lowest level of musical
>> > description, in such a way that different functions can be composed
>> > together.
>> >
>> > This is a problem that has been considered, and partly solved, by my
>> > system CsoundAC (where both musical notes and chords are vectors in
>> > spaces and can be composed with techniques borrowed from computer
>> > graphics), by Rubato Composer which takes a somewhat similar but
>> > mathematically more sophisticated approach based on category theory
>> > and understanding the types of algebras involved in working with
>> > musical notes and scores, and of course those systems that are more or
>> > less based on MIDI semantics, although this of course is quite
>> > limiting. Also take a look at OpenMusic, which seems to have its own
>> > mathematical basis though I don't think I understand just what it is,
>> > and of course Grace (which sprang more or less fully formed from the
>> > forehead of Common Music).
>> >
>> > The kind of difficulty that you can anticipate will be like this: What
>> > is pitch? Depends on the kind of piece you want to make. But to get a
>> > SYSTEM going you need a basic representation of pitch that is amenable
>> > to mathematical manipulation and that can easily be translated back
>> > forth from the more specific notions of pitch used in actual pieces. I
>> > think it should be MIDI note number only allowing fractional values
>> > for fractional pitches and variant scales, but lots of people just
>> > assume it should be integers standing for scale degree. Getting
>> > composers to agree on something so basic is like herding cats... no,
>> > worse than herding cats.
>> >
>> > Regards,
>> > Mike
>> >
>> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure <ljc@internet.com.uy> wrote:
>> >>
>> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >>
>> >>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >>> PMask, Blue, the opcodes, and Python Score.
>> >>
>> >> christopher ariza's athenaCL is written in python, and outputs several
>> >> formats, csound score among them:
>> >>
>> >> "The athenaCL system is an open-source, object-oriented composition
>> >> tool
>> >> written in Python. The system can be scripted and embedded, and
>> >> includes
>> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> modeling
>> >> tools, multiple-format graphical outputs, and musical output in Csound,
>> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >>
>> >> (http://code.google.com/p/athenacl/)
>> >>
>> >> i think it's a great idea to coordinate a collective effort to develop
>> >> a
>> >> library of functions to generate events for the csound score. i'm
>> >> trying
>> >> to teach myself a little python, it would be fun to (try to) contribute
>> >> to
>> >> the project. i'll have to look closer at pysco, jacob!
>> >>
>> >> best,
>> >>
>> >>
>> >> lj
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> 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 the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp




Date2013-03-21 12:04
Frompeiman khosravi
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like


On 21 March 2013 11:18, Justin Smith <noisesmith@gmail.com> wrote:
Traditionally, even in pure programming contexts, the set of tools provided is in some way curated in order to cultivate specific conceptual models. One can program functionally in C, declaratively in javascript, in an object oriented manner in forth, or imperatively in haskell, but the language in each case will put up a fight, and a path of least resistance guides the user to a language's preferred approach.  

Since any library implements an extension to the language, a composition library extends its base language with its own assumptions and shortcuts. So, just as a programming language pushes you toward its programming theory of choice, a composition language will push you into its music theory of choice.


I think there are two different approaches to algorithmic composition. And which one one takes is a compositional/musical choice: 

1- Using algorithmic systems to compose sound structures
2- Using sound structures as signifiers for algorithms

In the latter, musical thinking happens at a much more abstract level. For my part, I don't think of music algorithmically, even if algorithmic thinking strongly influences my compositional procedures. I don't think music can be represented, only sound can be represented. So the notion of representing musical attributes within an abstract framework is very alien to me. 

An important aspect of algorithmic composition is that one can think about sound structures as processes and behavioural states. This is a valuable alternative to thinking in terms of morphological unites. 

For me, algorithms, on the level of the internal spectral components (FFT data management and transformations), are the same as those involved in creating larger sound structures (say, granular textures). They are means of sculpting sound structures. 
   
 
All of that being said, it has been lamented before that the csound score has no concept of a measure (for example). While we like the idea of complete composition freedom to define our own models and abstractions, in practice we are using many of the same abstractions in an ad hoc way. Composing with measures, those measures usually have 4 or 8 beats, scales with repeating octaves where notes an octave apart are considered in some sense equivalent, scales with notes that are spaced in one of the common variations of the 7 note diatonic scale, chords built according to something approximating a classical / jazz / pop chording convention, timbres that have a strong fundamental pitch to them, textures defined in terms of densities of constituant grains and their tendencies, patterns of events that unfold in similar iterative ways etc. - as a few examples off

Any such considerations will inevitably lead to a categorical system. In the first year, I ban students from using the grid in Protools, many of them still end up making beat-based music. And we have all heard highly texturally orientated pieces produced with the simplest of midi sequencers! 

P  
 
 
the top of my head. While few of us follow all of these conventions, it is likely that most of us follow at least one, and a sizable percentage use many. If we value our time, and would desire to spend more time composing than building our compositional tools, there is something to be said for providing the most commonly used abstractions as a default (while of course allowing the user to ignore or replace them as desired).


On Thu, Mar 21, 2013 at 3:58 AM, peiman khosravi <peimankhosravi@gmail.com> wrote:


On 21 March 2013 07:14, Oeyvind Brandtsegg <oyvind.brandtsegg@ntnu.no> wrote:
This is indeed an interesting discussion.
I'd like to be more involved, but here's my "2 cents" for the moment:

I think Michael's point:

"Any efforts to develop a library of compositional routines is going to
run into the historical and present and probably future fact that
composers do not think alike. A fundamental problem will be
representing what is essential, at the lowest level of musical
description, in such a way that different functions can be composed
together."
... is right at the heart of the problem. And it is the main reason why I think some of the existing tools are hard to use. Because they don't fit. I do think that any system that builds from a representation of what is essential up towards more complex or abstract representations/ideas will simply *not fit* for many composers. The actual representation chosen determining who it will fit and for whom it will not work.
I am deeply unsure of how to make a better system, but I do think it should be built the other way around: deciding on a representation of what is essential for the output as the last operation, not the first. This wold probably make the learning curve steeper, but it would also make the curve flatten out nicely when it comes to solving more complex problems.  If need be, a *suggested* ("optional default") representation could be used to enable quick sketches and tutorials, but that this representation should be highly configurable and not tied to the actual manipulation of the data (the compositional algorithms).


Hi Oeyvind,

Absolutely agreed. I don't think that an algorithmic system should be 'intelligent' enough to understand the representation of what is essential for the construction of musical meaning. I don't think there should be any value hierarchies in such a system. Composing on the note level should be as accessible as composing on the grain level. I don't want the software to 'know' what is essential because I don't know what is essential: that is why I compose - to find out. This is why I normally prefer tools that are not musically intelligent (or at least not on the surface). I have no specific solutions but it seems to me that the only way to achieve some level of flatness is by thinking purely in terms of sound structures, rather than musical structures, when making an algorithmic system. This way the system simply provides a playground, to take advantage of all the control that the computer offers us. Why should an algorithmic system even have a conception of what is a note, what is timbre and what is grain?    
     

P   
        

Very humbly, as I said, i don't know exactly how it should be done, and being very much aware that others on this list have much more experience in software/language design.
(Also of course being open to suggestions of languages/systems actually working in this way)

best
Oeyvind



2013/3/20 Steven Yi <stevenyi@gmail.com>
Hi Jake,

I think it's a good idea you have to try to build up a library of
useful musical functions.  I'll certainly be happy to include whatever
you work on with Blue to make it available to Blue users out of the
box.

I also think MIchael's cautions are very important, but your point
about "something that doesn't try to be all encompassing, but allows
others to piece together their own environments" seems right on the
money to me.  I've been spending most of my reading time on Clojure
and Haskell literature, and function composition and reuse is a big
concern in these communities.  I think having a library for Python
could be very useful.

One other thing you had mentioned in looking at Pgauss is that "some
things are already built into Python".  I've had the same experience
in looking at Patterns in SC as well as CMask, nGen, PMask, and other
libraries, and comparing them to built-in features in Clojure (which
would also apply to Lisp, Scheme, Haskell, and other functional
programming languages).  Most functional languages deal heavily with
list processing, lazy list generation, stream transformations, etc.
Python does do support some functional programming aspects, and
generators are rather nice, I've found Clojure just a little bit more
to my liking now.

I had recently been working on organizing my own Python composition
code into a single library, but I'm now planning to build up a library
in Clojure instead.  However, I thought I'd mention that I found these
program/libraries useful to look at for music functions:

* Common Music (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
* Overtone (http://overtone.github.com)
* Symbolic Composer (http://www.symboliccomposer.com/)
* OpenMusic
* CsoundAC (Michael's system, comes with Csound installer)

Of these, I think Symbolic Composer probably has the largest set of
functions I've come across. (I didn't see any manuals viewable online,
but they're visible within the program.) While these aren't python
projects, I thought they were worth mentioning.

I also took a look at the link to isobar that Peiman listed and found
that rather interesting too.  The original project
(https://github.com/ideoforms/isobar) seems to have quite a bit of
functionality implemented.

Anyways, some ramblings on from me. :)  Looking forward to what comes
of all this and good luck with it!

steven


On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
<peimankhosravi@gmail.com> wrote:
> Agreed.
>
> P
>
>
> On 20 March 2013 01:31, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
>>
>> I'm not sure what others are looking in a Python library for Csound,
>> but my personal focus is on creating a streamlined interface to the
>> Csound score for easily generating score events, and then have
>> multiple libraries for different intended uses. So something that
>> doesn't try to be all encompassing, but allows others to piece
>> together their own environments either from importing existing
>> libraries, or creating their own custom set of functions. Will every
>> library be interoperable, no. Will it be better than having all these
>> independent score generators that don't work together at all, big yes.
>>
>> For example, I installed Music21 (which is awesome btw so thanks for
>> the suggestion) and had it working with Python Score. But then it
>> broke and broke badly and it isn't working, but I was close to having
>> a Bach piece in MusicXML converted into Csound score events.
>>
>> Best,
>> Jake
>>
>> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>> <michael.gogins@gmail.com> wrote:
>> > Regarding athenaCL, it was not designed for scripting, but for
>> > interaction with the composer via the command line, resulting in
>> > pieces created by interactively issuing a series of commands in a
>> > session. It is possible to script the system to some extent, but this
>> > is not well documented or that easy to do.
>> >
>> > Christopher Ariza, the author of athenaCL, now seems to be extensively
>> > involved with music21, which deserves its own consideration by
>> > composers.
>> >
>> > http://mit.edu/music21/
>> >
>> > Any efforts to develop a library of compositional routines is going to
>> > run into the historical and present and probably future fact that
>> > composers do not think alike. A fundamental problem will be
>> > representing what is essential, at the lowest level of musical
>> > description, in such a way that different functions can be composed
>> > together.
>> >
>> > This is a problem that has been considered, and partly solved, by my
>> > system CsoundAC (where both musical notes and chords are vectors in
>> > spaces and can be composed with techniques borrowed from computer
>> > graphics), by Rubato Composer which takes a somewhat similar but
>> > mathematically more sophisticated approach based on category theory
>> > and understanding the types of algebras involved in working with
>> > musical notes and scores, and of course those systems that are more or
>> > less based on MIDI semantics, although this of course is quite
>> > limiting. Also take a look at OpenMusic, which seems to have its own
>> > mathematical basis though I don't think I understand just what it is,
>> > and of course Grace (which sprang more or less fully formed from the
>> > forehead of Common Music).
>> >
>> > The kind of difficulty that you can anticipate will be like this: What
>> > is pitch? Depends on the kind of piece you want to make. But to get a
>> > SYSTEM going you need a basic representation of pitch that is amenable
>> > to mathematical manipulation and that can easily be translated back
>> > forth from the more specific notions of pitch used in actual pieces. I
>> > think it should be MIDI note number only allowing fractional values
>> > for fractional pitches and variant scales, but lots of people just
>> > assume it should be integers standing for scale degree. Getting
>> > composers to agree on something so basic is like herding cats... no,
>> > worse than herding cats.
>> >
>> > Regards,
>> > Mike
>> >
>> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure <ljc@internet.com.uy> wrote:
>> >>
>> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >>
>> >>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >>> PMask, Blue, the opcodes, and Python Score.
>> >>
>> >> christopher ariza's athenaCL is written in python, and outputs several
>> >> formats, csound score among them:
>> >>
>> >> "The athenaCL system is an open-source, object-oriented composition
>> >> tool
>> >> written in Python. The system can be scripted and embedded, and
>> >> includes
>> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> modeling
>> >> tools, multiple-format graphical outputs, and musical output in Csound,
>> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >>
>> >> (http://code.google.com/p/athenacl/)
>> >>
>> >> i think it's a great idea to coordinate a collective effort to develop
>> >> a
>> >> library of functions to generate events for the csound score. i'm
>> >> trying
>> >> to teach myself a little python, it would be fun to (try to) contribute
>> >> to
>> >> the project. i'll have to look closer at pysco, jacob!
>> >>
>> >> best,
>> >>
>> >>
>> >> lj
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> 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 the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp




Date2013-03-21 13:53
FromMichael Gogins
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
About representing music at the bottom level or the top level, in
order for functional composition to work in Csound, elements of music
must be defined at the bottom level, not the top. As you note, what
comes out at the top should be reconfigurable to suit the purposes of
different composers.

But what is at the bottom must be standardized or it will not be
composable mathematically (which is what I mean by "functional
composition," I see there is a possibility of misunderstanding there).

In other words if at the bottom pitch in package A is octave.pch and
in package B it is MIDI key, you can't do this:

A.invert(B.transpose(36, 4), 5)

It is important that this "atomic" or "fundamental" representation of
musical elements be (a) intuitive to musicians, and (b) mathematically
as abstract, i.e. powerful, as possible.

For pitch, this is a difficult problem to solve. At this point, I
think that MIDI key is the most intuitive to musicians, but if it not
defined on the reals it is not as abstract as possible. That is why I,
music theorist Dmitri Tymoczko, and others use MIDI key as real
numbers.

When introducing other elements of music such as time, the question is
complicated further not only by idiosyncracies of musical time, but
also by the fact that composers often operate on pitch and time with
the same set of abstract operations (transposition, augmentation,
inversion, retrograde, etc., etc.). For this to work mathematically,
time and other elements of music also should be defined as real
numbers, then you have a linear space and an immense amount of
powerful mathematics becomes naturally applicable to music, including
all of linear algebra and much of abstract algebra, group theory, etc.

I couldn't begin to stress, in any adequate way, how crippled
composition software generally is by not taking this very basic
consideration rigorously into account. I invite you all to look
closely at the documentation of Rubato Composer and at its author
Guerino Mazzola's book The Topos of Music, where he spends quite a bit
of time at the beginning discussing why this kind of thinking is
important.

If I could get this herd of cats to do one thing together, it would be
to read Mazzola and understand how to implement music software in a
categorial way, meaning that the software is designed to operate in
such a way that compositions (mathematical ones) not pre-imagined by
the developer are nevertheless transparently possible. In such
software, if you want to take the pitch spectrum of a piece and make a
rhythm of it and then make a tiling canon of that, you can do it in a
few lines of code. The user doesn't constantly have to write "glue
code" to translate from one domain of music to another.

My two cents.

Regards,
Mike

On Thu, Mar 21, 2013 at 3:14 AM, Oeyvind Brandtsegg
 wrote:
> This is indeed an interesting discussion.
> I'd like to be more involved, but here's my "2 cents" for the moment:
>
> I think Michael's point:
>
> "Any efforts to develop a library of compositional routines is going to
> run into the historical and present and probably future fact that
> composers do not think alike. A fundamental problem will be
> representing what is essential, at the lowest level of musical
> description, in such a way that different functions can be composed
> together."
> ... is right at the heart of the problem. And it is the main reason why I
> think some of the existing tools are hard to use. Because they don't fit. I
> do think that any system that builds from a representation of what is
> essential up towards more complex or abstract representations/ideas will
> simply *not fit* for many composers. The actual representation chosen
> determining who it will fit and for whom it will not work.
> I am deeply unsure of how to make a better system, but I do think it should
> be built the other way around: deciding on a representation of what is
> essential for the output as the last operation, not the first. This wold
> probably make the learning curve steeper, but it would also make the curve
> flatten out nicely when it comes to solving more complex problems.  If need
> be, a *suggested* ("optional default") representation could be used to
> enable quick sketches and tutorials, but that this representation should be
> highly configurable and not tied to the actual manipulation of the data (the
> compositional algorithms).
>
> Very humbly, as I said, i don't know exactly how it should be done, and
> being very much aware that others on this list have much more experience in
> software/language design.
> (Also of course being open to suggestions of languages/systems actually
> working in this way)
>
> best
> Oeyvind
>
>
>
> 2013/3/20 Steven Yi 
>>
>> Hi Jake,
>>
>> I think it's a good idea you have to try to build up a library of
>> useful musical functions.  I'll certainly be happy to include whatever
>> you work on with Blue to make it available to Blue users out of the
>> box.
>>
>> I also think MIchael's cautions are very important, but your point
>> about "something that doesn't try to be all encompassing, but allows
>> others to piece together their own environments" seems right on the
>> money to me.  I've been spending most of my reading time on Clojure
>> and Haskell literature, and function composition and reuse is a big
>> concern in these communities.  I think having a library for Python
>> could be very useful.
>>
>> One other thing you had mentioned in looking at Pgauss is that "some
>> things are already built into Python".  I've had the same experience
>> in looking at Patterns in SC as well as CMask, nGen, PMask, and other
>> libraries, and comparing them to built-in features in Clojure (which
>> would also apply to Lisp, Scheme, Haskell, and other functional
>> programming languages).  Most functional languages deal heavily with
>> list processing, lazy list generation, stream transformations, etc.
>> Python does do support some functional programming aspects, and
>> generators are rather nice, I've found Clojure just a little bit more
>> to my liking now.
>>
>> I had recently been working on organizing my own Python composition
>> code into a single library, but I'm now planning to build up a library
>> in Clojure instead.  However, I thought I'd mention that I found these
>> program/libraries useful to look at for music functions:
>>
>> * Common Music (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
>> * Overtone (http://overtone.github.com)
>> * Symbolic Composer (http://www.symboliccomposer.com/)
>> * OpenMusic
>> * CsoundAC (Michael's system, comes with Csound installer)
>>
>> Of these, I think Symbolic Composer probably has the largest set of
>> functions I've come across. (I didn't see any manuals viewable online,
>> but they're visible within the program.) While these aren't python
>> projects, I thought they were worth mentioning.
>>
>> I also took a look at the link to isobar that Peiman listed and found
>> that rather interesting too.  The original project
>> (https://github.com/ideoforms/isobar) seems to have quite a bit of
>> functionality implemented.
>>
>> Anyways, some ramblings on from me. :)  Looking forward to what comes
>> of all this and good luck with it!
>>
>> steven
>>
>>
>> On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
>>  wrote:
>> > Agreed.
>> >
>> > P
>> >
>> >
>> > On 20 March 2013 01:31, Jacob Joaquin  wrote:
>> >>
>> >> I'm not sure what others are looking in a Python library for Csound,
>> >> but my personal focus is on creating a streamlined interface to the
>> >> Csound score for easily generating score events, and then have
>> >> multiple libraries for different intended uses. So something that
>> >> doesn't try to be all encompassing, but allows others to piece
>> >> together their own environments either from importing existing
>> >> libraries, or creating their own custom set of functions. Will every
>> >> library be interoperable, no. Will it be better than having all these
>> >> independent score generators that don't work together at all, big yes.
>> >>
>> >> For example, I installed Music21 (which is awesome btw so thanks for
>> >> the suggestion) and had it working with Python Score. But then it
>> >> broke and broke badly and it isn't working, but I was close to having
>> >> a Bach piece in MusicXML converted into Csound score events.
>> >>
>> >> Best,
>> >> Jake
>> >>
>> >> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>> >>  wrote:
>> >> > Regarding athenaCL, it was not designed for scripting, but for
>> >> > interaction with the composer via the command line, resulting in
>> >> > pieces created by interactively issuing a series of commands in a
>> >> > session. It is possible to script the system to some extent, but this
>> >> > is not well documented or that easy to do.
>> >> >
>> >> > Christopher Ariza, the author of athenaCL, now seems to be
>> >> > extensively
>> >> > involved with music21, which deserves its own consideration by
>> >> > composers.
>> >> >
>> >> > http://mit.edu/music21/
>> >> >
>> >> > Any efforts to develop a library of compositional routines is going
>> >> > to
>> >> > run into the historical and present and probably future fact that
>> >> > composers do not think alike. A fundamental problem will be
>> >> > representing what is essential, at the lowest level of musical
>> >> > description, in such a way that different functions can be composed
>> >> > together.
>> >> >
>> >> > This is a problem that has been considered, and partly solved, by my
>> >> > system CsoundAC (where both musical notes and chords are vectors in
>> >> > spaces and can be composed with techniques borrowed from computer
>> >> > graphics), by Rubato Composer which takes a somewhat similar but
>> >> > mathematically more sophisticated approach based on category theory
>> >> > and understanding the types of algebras involved in working with
>> >> > musical notes and scores, and of course those systems that are more
>> >> > or
>> >> > less based on MIDI semantics, although this of course is quite
>> >> > limiting. Also take a look at OpenMusic, which seems to have its own
>> >> > mathematical basis though I don't think I understand just what it is,
>> >> > and of course Grace (which sprang more or less fully formed from the
>> >> > forehead of Common Music).
>> >> >
>> >> > The kind of difficulty that you can anticipate will be like this:
>> >> > What
>> >> > is pitch? Depends on the kind of piece you want to make. But to get a
>> >> > SYSTEM going you need a basic representation of pitch that is
>> >> > amenable
>> >> > to mathematical manipulation and that can easily be translated back
>> >> > forth from the more specific notions of pitch used in actual pieces.
>> >> > I
>> >> > think it should be MIDI note number only allowing fractional values
>> >> > for fractional pitches and variant scales, but lots of people just
>> >> > assume it should be integers standing for scale degree. Getting
>> >> > composers to agree on something so basic is like herding cats... no,
>> >> > worse than herding cats.
>> >> >
>> >> > Regards,
>> >> > Mike
>> >> >
>> >> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure 
>> >> > wrote:
>> >> >>
>> >> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >> >>
>> >> >>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >> >>> PMask, Blue, the opcodes, and Python Score.
>> >> >>
>> >> >> christopher ariza's athenaCL is written in python, and outputs
>> >> >> several
>> >> >> formats, csound score among them:
>> >> >>
>> >> >> "The athenaCL system is an open-source, object-oriented composition
>> >> >> tool
>> >> >> written in Python. The system can be scripted and embedded, and
>> >> >> includes
>> >> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> >> modeling
>> >> >> tools, multiple-format graphical outputs, and musical output in
>> >> >> Csound,
>> >> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >> >>
>> >> >> (http://code.google.com/p/athenacl/)
>> >> >>
>> >> >> i think it's a great idea to coordinate a collective effort to
>> >> >> develop
>> >> >> a
>> >> >> library of functions to generate events for the csound score. i'm
>> >> >> trying
>> >> >> to teach myself a little python, it would be fun to (try to)
>> >> >> contribute
>> >> >> to
>> >> >> the project. i'll have to look closer at pysco, jacob!
>> >> >>
>> >> >> best,
>> >> >>
>> >> >>
>> >> >> lj
>> >> >>
>> >> >>
>> >> >> Send bugs reports to the Sourceforge bug tracker
>> >> >>
>> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> >> Discussions of bugs and features can be posted here
>> >> >> 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 the Sourceforge bug tracker
>> >> >
>> >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> > Discussions of bugs and features can be posted here
>> >> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> > "unsubscribe
>> >> > csound"
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> codehop.com | #code #art #music
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> "unsubscribe
>> >> csound"
>> >>
>> >
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp



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

Date2013-03-21 15:09
FromJustin Smith
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
I think that time in seconds and frequency in hz (aka the reciprocal of time in seconds) should be the base representation (as they already are in csound, modulo tempo manipulations in the score). Everything else should be able to convert to and from those units.

In regard to representing patterns, a Lindenmayer Tree is a superset of every other pattern type, (as cs folks may guess, that also means it is turing complete (though perhaps not the best basis for a whole language)). It works very well for self-similar and chaotic structures, but is fairly straightforward for representing deterministic patterns as well, so would be a good candidate for a base representation of "pattern" that other representations could reduce to.


On Thu, Mar 21, 2013 at 6:53 AM, Michael Gogins <michael.gogins@gmail.com> wrote:
About representing music at the bottom level or the top level, in
order for functional composition to work in Csound, elements of music
must be defined at the bottom level, not the top. As you note, what
comes out at the top should be reconfigurable to suit the purposes of
different composers.

But what is at the bottom must be standardized or it will not be
composable mathematically (which is what I mean by "functional
composition," I see there is a possibility of misunderstanding there).

In other words if at the bottom pitch in package A is octave.pch and
in package B it is MIDI key, you can't do this:

A.invert(B.transpose(36, 4), 5)

It is important that this "atomic" or "fundamental" representation of
musical elements be (a) intuitive to musicians, and (b) mathematically
as abstract, i.e. powerful, as possible.

For pitch, this is a difficult problem to solve. At this point, I
think that MIDI key is the most intuitive to musicians, but if it not
defined on the reals it is not as abstract as possible. That is why I,
music theorist Dmitri Tymoczko, and others use MIDI key as real
numbers.

When introducing other elements of music such as time, the question is
complicated further not only by idiosyncracies of musical time, but
also by the fact that composers often operate on pitch and time with
the same set of abstract operations (transposition, augmentation,
inversion, retrograde, etc., etc.). For this to work mathematically,
time and other elements of music also should be defined as real
numbers, then you have a linear space and an immense amount of
powerful mathematics becomes naturally applicable to music, including
all of linear algebra and much of abstract algebra, group theory, etc.

I couldn't begin to stress, in any adequate way, how crippled
composition software generally is by not taking this very basic
consideration rigorously into account. I invite you all to look
closely at the documentation of Rubato Composer and at its author
Guerino Mazzola's book The Topos of Music, where he spends quite a bit
of time at the beginning discussing why this kind of thinking is
important.

If I could get this herd of cats to do one thing together, it would be
to read Mazzola and understand how to implement music software in a
categorial way, meaning that the software is designed to operate in
such a way that compositions (mathematical ones) not pre-imagined by
the developer are nevertheless transparently possible. In such
software, if you want to take the pitch spectrum of a piece and make a
rhythm of it and then make a tiling canon of that, you can do it in a
few lines of code. The user doesn't constantly have to write "glue
code" to translate from one domain of music to another.

My two cents.

Regards,
Mike

On Thu, Mar 21, 2013 at 3:14 AM, Oeyvind Brandtsegg
<oyvind.brandtsegg@ntnu.no> wrote:
> This is indeed an interesting discussion.
> I'd like to be more involved, but here's my "2 cents" for the moment:
>
> I think Michael's point:
>
> "Any efforts to develop a library of compositional routines is going to
> run into the historical and present and probably future fact that
> composers do not think alike. A fundamental problem will be
> representing what is essential, at the lowest level of musical
> description, in such a way that different functions can be composed
> together."
> ... is right at the heart of the problem. And it is the main reason why I
> think some of the existing tools are hard to use. Because they don't fit. I
> do think that any system that builds from a representation of what is
> essential up towards more complex or abstract representations/ideas will
> simply *not fit* for many composers. The actual representation chosen
> determining who it will fit and for whom it will not work.
> I am deeply unsure of how to make a better system, but I do think it should
> be built the other way around: deciding on a representation of what is
> essential for the output as the last operation, not the first. This wold
> probably make the learning curve steeper, but it would also make the curve
> flatten out nicely when it comes to solving more complex problems.  If need
> be, a *suggested* ("optional default") representation could be used to
> enable quick sketches and tutorials, but that this representation should be
> highly configurable and not tied to the actual manipulation of the data (the
> compositional algorithms).
>
> Very humbly, as I said, i don't know exactly how it should be done, and
> being very much aware that others on this list have much more experience in
> software/language design.
> (Also of course being open to suggestions of languages/systems actually
> working in this way)
>
> best
> Oeyvind
>
>
>
> 2013/3/20 Steven Yi <stevenyi@gmail.com>
>>
>> Hi Jake,
>>
>> I think it's a good idea you have to try to build up a library of
>> useful musical functions.  I'll certainly be happy to include whatever
>> you work on with Blue to make it available to Blue users out of the
>> box.
>>
>> I also think MIchael's cautions are very important, but your point
>> about "something that doesn't try to be all encompassing, but allows
>> others to piece together their own environments" seems right on the
>> money to me.  I've been spending most of my reading time on Clojure
>> and Haskell literature, and function composition and reuse is a big
>> concern in these communities.  I think having a library for Python
>> could be very useful.
>>
>> One other thing you had mentioned in looking at Pgauss is that "some
>> things are already built into Python".  I've had the same experience
>> in looking at Patterns in SC as well as CMask, nGen, PMask, and other
>> libraries, and comparing them to built-in features in Clojure (which
>> would also apply to Lisp, Scheme, Haskell, and other functional
>> programming languages).  Most functional languages deal heavily with
>> list processing, lazy list generation, stream transformations, etc.
>> Python does do support some functional programming aspects, and
>> generators are rather nice, I've found Clojure just a little bit more
>> to my liking now.
>>
>> I had recently been working on organizing my own Python composition
>> code into a single library, but I'm now planning to build up a library
>> in Clojure instead.  However, I thought I'd mention that I found these
>> program/libraries useful to look at for music functions:
>>
>> * Common Music (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
>> * Overtone (http://overtone.github.com)
>> * Symbolic Composer (http://www.symboliccomposer.com/)
>> * OpenMusic
>> * CsoundAC (Michael's system, comes with Csound installer)
>>
>> Of these, I think Symbolic Composer probably has the largest set of
>> functions I've come across. (I didn't see any manuals viewable online,
>> but they're visible within the program.) While these aren't python
>> projects, I thought they were worth mentioning.
>>
>> I also took a look at the link to isobar that Peiman listed and found
>> that rather interesting too.  The original project
>> (https://github.com/ideoforms/isobar) seems to have quite a bit of
>> functionality implemented.
>>
>> Anyways, some ramblings on from me. :)  Looking forward to what comes
>> of all this and good luck with it!
>>
>> steven
>>
>>
>> On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
>> <peimankhosravi@gmail.com> wrote:
>> > Agreed.
>> >
>> > P
>> >
>> >
>> > On 20 March 2013 01:31, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
>> >>
>> >> I'm not sure what others are looking in a Python library for Csound,
>> >> but my personal focus is on creating a streamlined interface to the
>> >> Csound score for easily generating score events, and then have
>> >> multiple libraries for different intended uses. So something that
>> >> doesn't try to be all encompassing, but allows others to piece
>> >> together their own environments either from importing existing
>> >> libraries, or creating their own custom set of functions. Will every
>> >> library be interoperable, no. Will it be better than having all these
>> >> independent score generators that don't work together at all, big yes.
>> >>
>> >> For example, I installed Music21 (which is awesome btw so thanks for
>> >> the suggestion) and had it working with Python Score. But then it
>> >> broke and broke badly and it isn't working, but I was close to having
>> >> a Bach piece in MusicXML converted into Csound score events.
>> >>
>> >> Best,
>> >> Jake
>> >>
>> >> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>> >> <michael.gogins@gmail.com> wrote:
>> >> > Regarding athenaCL, it was not designed for scripting, but for
>> >> > interaction with the composer via the command line, resulting in
>> >> > pieces created by interactively issuing a series of commands in a
>> >> > session. It is possible to script the system to some extent, but this
>> >> > is not well documented or that easy to do.
>> >> >
>> >> > Christopher Ariza, the author of athenaCL, now seems to be
>> >> > extensively
>> >> > involved with music21, which deserves its own consideration by
>> >> > composers.
>> >> >
>> >> > http://mit.edu/music21/
>> >> >
>> >> > Any efforts to develop a library of compositional routines is going
>> >> > to
>> >> > run into the historical and present and probably future fact that
>> >> > composers do not think alike. A fundamental problem will be
>> >> > representing what is essential, at the lowest level of musical
>> >> > description, in such a way that different functions can be composed
>> >> > together.
>> >> >
>> >> > This is a problem that has been considered, and partly solved, by my
>> >> > system CsoundAC (where both musical notes and chords are vectors in
>> >> > spaces and can be composed with techniques borrowed from computer
>> >> > graphics), by Rubato Composer which takes a somewhat similar but
>> >> > mathematically more sophisticated approach based on category theory
>> >> > and understanding the types of algebras involved in working with
>> >> > musical notes and scores, and of course those systems that are more
>> >> > or
>> >> > less based on MIDI semantics, although this of course is quite
>> >> > limiting. Also take a look at OpenMusic, which seems to have its own
>> >> > mathematical basis though I don't think I understand just what it is,
>> >> > and of course Grace (which sprang more or less fully formed from the
>> >> > forehead of Common Music).
>> >> >
>> >> > The kind of difficulty that you can anticipate will be like this:
>> >> > What
>> >> > is pitch? Depends on the kind of piece you want to make. But to get a
>> >> > SYSTEM going you need a basic representation of pitch that is
>> >> > amenable
>> >> > to mathematical manipulation and that can easily be translated back
>> >> > forth from the more specific notions of pitch used in actual pieces.
>> >> > I
>> >> > think it should be MIDI note number only allowing fractional values
>> >> > for fractional pitches and variant scales, but lots of people just
>> >> > assume it should be integers standing for scale degree. Getting
>> >> > composers to agree on something so basic is like herding cats... no,
>> >> > worse than herding cats.
>> >> >
>> >> > Regards,
>> >> > Mike
>> >> >
>> >> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure <ljc@internet.com.uy>
>> >> > wrote:
>> >> >>
>> >> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >> >>
>> >> >>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >> >>> PMask, Blue, the opcodes, and Python Score.
>> >> >>
>> >> >> christopher ariza's athenaCL is written in python, and outputs
>> >> >> several
>> >> >> formats, csound score among them:
>> >> >>
>> >> >> "The athenaCL system is an open-source, object-oriented composition
>> >> >> tool
>> >> >> written in Python. The system can be scripted and embedded, and
>> >> >> includes
>> >> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> >> modeling
>> >> >> tools, multiple-format graphical outputs, and musical output in
>> >> >> Csound,
>> >> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >> >>
>> >> >> (http://code.google.com/p/athenacl/)
>> >> >>
>> >> >> i think it's a great idea to coordinate a collective effort to
>> >> >> develop
>> >> >> a
>> >> >> library of functions to generate events for the csound score. i'm
>> >> >> trying
>> >> >> to teach myself a little python, it would be fun to (try to)
>> >> >> contribute
>> >> >> to
>> >> >> the project. i'll have to look closer at pysco, jacob!
>> >> >>
>> >> >> best,
>> >> >>
>> >> >>
>> >> >> lj
>> >> >>
>> >> >>
>> >> >> Send bugs reports to the Sourceforge bug tracker
>> >> >>
>> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> >> Discussions of bugs and features can be posted here
>> >> >> 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 the Sourceforge bug tracker
>> >> >
>> >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> > Discussions of bugs and features can be posted here
>> >> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> > "unsubscribe
>> >> > csound"
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> codehop.com | #code #art #music
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> "unsubscribe
>> >> csound"
>> >>
>> >
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp



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


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



Date2013-03-21 15:10
FromJustin Smith
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
I meant "Lindenmayer System" where I said Lindenmayer Tree above, the Tree is one 2 or 3 dimensional visualization of Lindenmayer systems.


On Thu, Mar 21, 2013 at 8:09 AM, Justin Smith <noisesmith@gmail.com> wrote:
I think that time in seconds and frequency in hz (aka the reciprocal of time in seconds) should be the base representation (as they already are in csound, modulo tempo manipulations in the score). Everything else should be able to convert to and from those units.

In regard to representing patterns, a Lindenmayer Tree is a superset of every other pattern type, (as cs folks may guess, that also means it is turing complete (though perhaps not the best basis for a whole language)). It works very well for self-similar and chaotic structures, but is fairly straightforward for representing deterministic patterns as well, so would be a good candidate for a base representation of "pattern" that other representations could reduce to.


On Thu, Mar 21, 2013 at 6:53 AM, Michael Gogins <michael.gogins@gmail.com> wrote:
About representing music at the bottom level or the top level, in
order for functional composition to work in Csound, elements of music
must be defined at the bottom level, not the top. As you note, what
comes out at the top should be reconfigurable to suit the purposes of
different composers.

But what is at the bottom must be standardized or it will not be
composable mathematically (which is what I mean by "functional
composition," I see there is a possibility of misunderstanding there).

In other words if at the bottom pitch in package A is octave.pch and
in package B it is MIDI key, you can't do this:

A.invert(B.transpose(36, 4), 5)

It is important that this "atomic" or "fundamental" representation of
musical elements be (a) intuitive to musicians, and (b) mathematically
as abstract, i.e. powerful, as possible.

For pitch, this is a difficult problem to solve. At this point, I
think that MIDI key is the most intuitive to musicians, but if it not
defined on the reals it is not as abstract as possible. That is why I,
music theorist Dmitri Tymoczko, and others use MIDI key as real
numbers.

When introducing other elements of music such as time, the question is
complicated further not only by idiosyncracies of musical time, but
also by the fact that composers often operate on pitch and time with
the same set of abstract operations (transposition, augmentation,
inversion, retrograde, etc., etc.). For this to work mathematically,
time and other elements of music also should be defined as real
numbers, then you have a linear space and an immense amount of
powerful mathematics becomes naturally applicable to music, including
all of linear algebra and much of abstract algebra, group theory, etc.

I couldn't begin to stress, in any adequate way, how crippled
composition software generally is by not taking this very basic
consideration rigorously into account. I invite you all to look
closely at the documentation of Rubato Composer and at its author
Guerino Mazzola's book The Topos of Music, where he spends quite a bit
of time at the beginning discussing why this kind of thinking is
important.

If I could get this herd of cats to do one thing together, it would be
to read Mazzola and understand how to implement music software in a
categorial way, meaning that the software is designed to operate in
such a way that compositions (mathematical ones) not pre-imagined by
the developer are nevertheless transparently possible. In such
software, if you want to take the pitch spectrum of a piece and make a
rhythm of it and then make a tiling canon of that, you can do it in a
few lines of code. The user doesn't constantly have to write "glue
code" to translate from one domain of music to another.

My two cents.

Regards,
Mike

On Thu, Mar 21, 2013 at 3:14 AM, Oeyvind Brandtsegg
<oyvind.brandtsegg@ntnu.no> wrote:
> This is indeed an interesting discussion.
> I'd like to be more involved, but here's my "2 cents" for the moment:
>
> I think Michael's point:
>
> "Any efforts to develop a library of compositional routines is going to
> run into the historical and present and probably future fact that
> composers do not think alike. A fundamental problem will be
> representing what is essential, at the lowest level of musical
> description, in such a way that different functions can be composed
> together."
> ... is right at the heart of the problem. And it is the main reason why I
> think some of the existing tools are hard to use. Because they don't fit. I
> do think that any system that builds from a representation of what is
> essential up towards more complex or abstract representations/ideas will
> simply *not fit* for many composers. The actual representation chosen
> determining who it will fit and for whom it will not work.
> I am deeply unsure of how to make a better system, but I do think it should
> be built the other way around: deciding on a representation of what is
> essential for the output as the last operation, not the first. This wold
> probably make the learning curve steeper, but it would also make the curve
> flatten out nicely when it comes to solving more complex problems.  If need
> be, a *suggested* ("optional default") representation could be used to
> enable quick sketches and tutorials, but that this representation should be
> highly configurable and not tied to the actual manipulation of the data (the
> compositional algorithms).
>
> Very humbly, as I said, i don't know exactly how it should be done, and
> being very much aware that others on this list have much more experience in
> software/language design.
> (Also of course being open to suggestions of languages/systems actually
> working in this way)
>
> best
> Oeyvind
>
>
>
> 2013/3/20 Steven Yi <stevenyi@gmail.com>
>>
>> Hi Jake,
>>
>> I think it's a good idea you have to try to build up a library of
>> useful musical functions.  I'll certainly be happy to include whatever
>> you work on with Blue to make it available to Blue users out of the
>> box.
>>
>> I also think MIchael's cautions are very important, but your point
>> about "something that doesn't try to be all encompassing, but allows
>> others to piece together their own environments" seems right on the
>> money to me.  I've been spending most of my reading time on Clojure
>> and Haskell literature, and function composition and reuse is a big
>> concern in these communities.  I think having a library for Python
>> could be very useful.
>>
>> One other thing you had mentioned in looking at Pgauss is that "some
>> things are already built into Python".  I've had the same experience
>> in looking at Patterns in SC as well as CMask, nGen, PMask, and other
>> libraries, and comparing them to built-in features in Clojure (which
>> would also apply to Lisp, Scheme, Haskell, and other functional
>> programming languages).  Most functional languages deal heavily with
>> list processing, lazy list generation, stream transformations, etc.
>> Python does do support some functional programming aspects, and
>> generators are rather nice, I've found Clojure just a little bit more
>> to my liking now.
>>
>> I had recently been working on organizing my own Python composition
>> code into a single library, but I'm now planning to build up a library
>> in Clojure instead.  However, I thought I'd mention that I found these
>> program/libraries useful to look at for music functions:
>>
>> * Common Music (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
>> * Overtone (http://overtone.github.com)
>> * Symbolic Composer (http://www.symboliccomposer.com/)
>> * OpenMusic
>> * CsoundAC (Michael's system, comes with Csound installer)
>>
>> Of these, I think Symbolic Composer probably has the largest set of
>> functions I've come across. (I didn't see any manuals viewable online,
>> but they're visible within the program.) While these aren't python
>> projects, I thought they were worth mentioning.
>>
>> I also took a look at the link to isobar that Peiman listed and found
>> that rather interesting too.  The original project
>> (https://github.com/ideoforms/isobar) seems to have quite a bit of
>> functionality implemented.
>>
>> Anyways, some ramblings on from me. :)  Looking forward to what comes
>> of all this and good luck with it!
>>
>> steven
>>
>>
>> On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
>> <peimankhosravi@gmail.com> wrote:
>> > Agreed.
>> >
>> > P
>> >
>> >
>> > On 20 March 2013 01:31, Jacob Joaquin <jacobjoaquin@gmail.com> wrote:
>> >>
>> >> I'm not sure what others are looking in a Python library for Csound,
>> >> but my personal focus is on creating a streamlined interface to the
>> >> Csound score for easily generating score events, and then have
>> >> multiple libraries for different intended uses. So something that
>> >> doesn't try to be all encompassing, but allows others to piece
>> >> together their own environments either from importing existing
>> >> libraries, or creating their own custom set of functions. Will every
>> >> library be interoperable, no. Will it be better than having all these
>> >> independent score generators that don't work together at all, big yes.
>> >>
>> >> For example, I installed Music21 (which is awesome btw so thanks for
>> >> the suggestion) and had it working with Python Score. But then it
>> >> broke and broke badly and it isn't working, but I was close to having
>> >> a Bach piece in MusicXML converted into Csound score events.
>> >>
>> >> Best,
>> >> Jake
>> >>
>> >> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>> >> <michael.gogins@gmail.com> wrote:
>> >> > Regarding athenaCL, it was not designed for scripting, but for
>> >> > interaction with the composer via the command line, resulting in
>> >> > pieces created by interactively issuing a series of commands in a
>> >> > session. It is possible to script the system to some extent, but this
>> >> > is not well documented or that easy to do.
>> >> >
>> >> > Christopher Ariza, the author of athenaCL, now seems to be
>> >> > extensively
>> >> > involved with music21, which deserves its own consideration by
>> >> > composers.
>> >> >
>> >> > http://mit.edu/music21/
>> >> >
>> >> > Any efforts to develop a library of compositional routines is going
>> >> > to
>> >> > run into the historical and present and probably future fact that
>> >> > composers do not think alike. A fundamental problem will be
>> >> > representing what is essential, at the lowest level of musical
>> >> > description, in such a way that different functions can be composed
>> >> > together.
>> >> >
>> >> > This is a problem that has been considered, and partly solved, by my
>> >> > system CsoundAC (where both musical notes and chords are vectors in
>> >> > spaces and can be composed with techniques borrowed from computer
>> >> > graphics), by Rubato Composer which takes a somewhat similar but
>> >> > mathematically more sophisticated approach based on category theory
>> >> > and understanding the types of algebras involved in working with
>> >> > musical notes and scores, and of course those systems that are more
>> >> > or
>> >> > less based on MIDI semantics, although this of course is quite
>> >> > limiting. Also take a look at OpenMusic, which seems to have its own
>> >> > mathematical basis though I don't think I understand just what it is,
>> >> > and of course Grace (which sprang more or less fully formed from the
>> >> > forehead of Common Music).
>> >> >
>> >> > The kind of difficulty that you can anticipate will be like this:
>> >> > What
>> >> > is pitch? Depends on the kind of piece you want to make. But to get a
>> >> > SYSTEM going you need a basic representation of pitch that is
>> >> > amenable
>> >> > to mathematical manipulation and that can easily be translated back
>> >> > forth from the more specific notions of pitch used in actual pieces.
>> >> > I
>> >> > think it should be MIDI note number only allowing fractional values
>> >> > for fractional pitches and variant scales, but lots of people just
>> >> > assume it should be integers standing for scale degree. Getting
>> >> > composers to agree on something so basic is like herding cats... no,
>> >> > worse than herding cats.
>> >> >
>> >> > Regards,
>> >> > Mike
>> >> >
>> >> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure <ljc@internet.com.uy>
>> >> > wrote:
>> >> >>
>> >> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>> >> >>
>> >> >>> What Csound-Python tools currently exist? I'm aware of CsoundAC,
>> >> >>> PMask, Blue, the opcodes, and Python Score.
>> >> >>
>> >> >> christopher ariza's athenaCL is written in python, and outputs
>> >> >> several
>> >> >> formats, csound score among them:
>> >> >>
>> >> >> "The athenaCL system is an open-source, object-oriented composition
>> >> >> tool
>> >> >> written in Python. The system can be scripted and embedded, and
>> >> >> includes
>> >> >> integrated instrument libraries, post-tonal and microtonal pitch
>> >> >> modeling
>> >> >> tools, multiple-format graphical outputs, and musical output in
>> >> >> Csound,
>> >> >> SuperCollider, Pure Data, MIDI, audio file, XML, and text formats."
>> >> >>
>> >> >> (http://code.google.com/p/athenacl/)
>> >> >>
>> >> >> i think it's a great idea to coordinate a collective effort to
>> >> >> develop
>> >> >> a
>> >> >> library of functions to generate events for the csound score. i'm
>> >> >> trying
>> >> >> to teach myself a little python, it would be fun to (try to)
>> >> >> contribute
>> >> >> to
>> >> >> the project. i'll have to look closer at pysco, jacob!
>> >> >>
>> >> >> best,
>> >> >>
>> >> >>
>> >> >> lj
>> >> >>
>> >> >>
>> >> >> Send bugs reports to the Sourceforge bug tracker
>> >> >>
>> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> >> Discussions of bugs and features can be posted here
>> >> >> 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 the Sourceforge bug tracker
>> >> >
>> >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> > Discussions of bugs and features can be posted here
>> >> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> > "unsubscribe
>> >> > csound"
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> codehop.com | #code #art #music
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> "unsubscribe
>> >> csound"
>> >>
>> >
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp



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


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




Date2013-03-21 17:32
FromJacob Joaquin
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
Very productive discussion. Lot's to reply to, so I'm going to do my
best to cover much of this in one email. It's also long, so sorry
about that.

First, I want to make it clear that I have no intention of trying
formalize western music, eastern music, north and sound of the
Maxon-Dixon Line music, etc. My goals are focused on the Python
interface between the Csound Score and libraries that enhance a
composer's ability to write music/sound in a way that makes sense to
them.

Instead of starting with a grand vision of what the ultimate
collection of Csound/music libraries, I'm starting small. Something
along the lines of: compose, code, curate, repeat. This being a
community effort.

I've already started on Python Score, which is I believe is already a
reasonable interface to the score. There is an easy point of entry for
Csounder's familiar with the Csound score. Out of the box, it removes
most of the boilerplate code for generating scores with Python, such
as manually constructing strings and open files, and it works right
inside a CSD. It also plays well with existing Python libraries such
as music21.

So in theory, it's an environment in which a composer can mix and
match various types of composition. PMask + Music21 + Lindenmayer
Systems + Markov Chains and all simply exist in the same Python Score,
even if they themselves aren't necessarily compatible with each other.

I want to go through some of the things currently built into Python
Score, since it already does some of the things mentioned in this
thread, or a hop-skip-jump away from doing some of the other things.
And do ask questions. I'm willing to go over this in more detail,
whether on or off list.

1) Easy Point of Entry

Don't know Python, but know the Csound score. Everything, and I mean
everything, you already know about the score can be used in Pysco,
without modification, as long as it's wrapped in the score() function:

score('''
f 1 0 8192 10 1
t 0 189

i 1 0 0.5 0.707 9.02
i 1 + .   .     8.07
i 1 + .   .     8.09
i 1 + .   .     8.11
i 1 + .   .     9.00
i 1 + .   .     8.09
i 1 + .   .     8.11
i 1 + .   .     8.07
''')

Code:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test.csd

2) Pfield Translators

The original idea of Pysco came from a user request in the list in
which someone wanted to be able to use an alternative way of
expressing notes in the form of C5, D#4, G4, etc. The following
example does just that using the pfield mapper function pmap(). This
is a post-processor that goes through score data and changes it based
on the function passed to pmap.

score('''
f 1 0 8192 10 1
t 0 120

i 1 0 0.5 -3 D5
i 1 + .   .  G4
i 1 + .   .  A4
i 1 + .   .  B4
i 1 + .   .  C5
i 1 + .   .  A4
i 1 + .   .  B4
i 1 + .   .  G5
''')

pmap('i', 1, 4, dB)
pmap('i', 1, 5, conv_to_hz)

Code:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test2.csd

You may have noticed that it also translates decibels with pfield.

3) Time with the cue() object

Time is treated like other control structures, akin to the if
statement. The cue() object translates the current postion of time in
the score, and modifies pfield 2 to reflect the position. For example,
the follow two events start at beat 0 and beat 1.5

score('''
i 1 0   0.5 0.707 8.00
i 1 1.5 0.5 0.707 9.00
''')

Using the same two unmodified events combined with the statement "with
cue(100):", it plays these two events at beat 100 and beat 101.5:

with cue(100):
    score('''
    i 1 0   0.5 0.707 8.00
    i 1 1.5 0.5 0.707 9.00
    ''')

That is:
100 + 0 = 100
100 + 1.5 = 101.5

These cues also nest, and these two notes play on beats 103 and 104.5.

with cue(100):
    with cue(3):
        score('''
        i 1 0   0.5 0.707 8.00
        i 1 1.5 0.5 0.707 9.00
        ''')

That is:
100 + 3 + 0 = 103
100 + 3 + 1.5 = 104.5

Here's a code example that cues each measure independently, so that
the start times for each i-event block is normalized to zero. Crazy
easy to manage events in time this way:

https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test10.csd

4) Don't like Time-In-Beats? How about Measures instead

So you're writing a piece in 4/4 and you'd rather organize events in
measures instead of beats because it totally makes more sense to do it
that way. Here's how to customize the cue() with a Python function:

def measure(t):
    return cue((t - 1) * 4.0)

Now let's place those two notes into measure 16.

with measure(16):
    score('''
    i 1 0   0.5 0.707 8.00
    i 1 1.5 0.5 0.707 9.00
    ''')

That that math works out to:
(16 - 1) * 4) + 0 = 60
(16 - 1) * 4) + 1.5 = 61.5

Gone are the days of manually keeping track of absolute position in
beats, or even seconds, for each note.

Similiar code to example 3, but uses the custom measure():
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test11.csd

This is measure() example is a simple conversion, but it wouldn't take
much to create a custom object that allowed users to mix and match
time signatures.

5) Functions as Reusable Musical Phrases

Let's wrap up those two notes into a re-usable phrase.

def my_phrase():
    score('''
    i 1 0   0.5 0.707 8.00
    i 1 1.5 0.5 0.707 9.00
    ''')

And let's place them in the first four measure of the score:

with measure(1): my_phrase()
with measure(2): my_phrase()
with measure(3): my_phrase()
with measure(4): my_phrase()

6) Alternatives to Score() i_events

The score() isn't the only way to create i-events. Here is an
alternative form using event_i()

def my_phrase():
    event_i(1, 0, 0.5, 0.707, 8.00)
    event_i(1, 1.5, 0.5, 0.707, 9.00)

The advantage is that you can inline Python functions directly into i-events:

event_i(1, 0, random(), random(), cpspch(8.00))

7) p_callback(), And Alternative to pmap()

The pmap() is a processor, and processes data that is already inside
the score() object. The p_callback() modifies events as they're being
inserted. In this example, the data stored for pfield 5 is the
frequency, not the written string representation, once inserted into
the score.

p_callback('i', 1, 5, conv_to_hz)

event_i(1, 0, 4, 0.707, 'C4')

Related code:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test12.csd

8) cue() and p_callback() work as a team.

Remember our two note phrase:

def my_phrase():
    event_i(1, 0, 0.5, 0.707, 8.00)
    event_i(2, 1.5, 0.5, 0.707, 9.00)

Let's say we wanted to play it as is in measure 1, but wanted to
transpose it 1 octave lower in measure 2, and as back to normal in
measure 3. Any p_callback() placed within the context of a "with
cue()" statement, only exists for that block, disappearing once that
block is finished.

p_callback('i', 1, 5, cpspch)  # Pfield 5 will be stored as Hz in the score()

with measure(1):
    my_phrase()

# Plays 1 octave lower
with measure(2):
    p_callback('i', 1, 5, lambda x: x / 2.0)  # p5 will be divided by 2
    my_phrase()

# Back to normal
with measure(3):
    my_phrase()

Code example that illustrates this:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test16.csd


This is just scratches the surface, because there's also all of Python
to consider.

Best,
Jake

Date2013-03-21 20:43
FromOeyvind Brandtsegg
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
There are some nice things to this system, and I do like the ability to freely map generators to event parameters using any desired format of representation.
Can it also be used in a similar manner to generate events from an instrument in the orchestra?
best
Oeyvind


2013/3/21 Jacob Joaquin <jacobjoaquin@gmail.com>
Very productive discussion. Lot's to reply to, so I'm going to do my
best to cover much of this in one email. It's also long, so sorry
about that.

First, I want to make it clear that I have no intention of trying
formalize western music, eastern music, north and sound of the
Maxon-Dixon Line music, etc. My goals are focused on the Python
interface between the Csound Score and libraries that enhance a
composer's ability to write music/sound in a way that makes sense to
them.

Instead of starting with a grand vision of what the ultimate
collection of Csound/music libraries, I'm starting small. Something
along the lines of: compose, code, curate, repeat. This being a
community effort.

I've already started on Python Score, which is I believe is already a
reasonable interface to the score. There is an easy point of entry for
Csounder's familiar with the Csound score. Out of the box, it removes
most of the boilerplate code for generating scores with Python, such
as manually constructing strings and open files, and it works right
inside a CSD. It also plays well with existing Python libraries such
as music21.

So in theory, it's an environment in which a composer can mix and
match various types of composition. PMask + Music21 + Lindenmayer
Systems + Markov Chains and all simply exist in the same Python Score,
even if they themselves aren't necessarily compatible with each other.

I want to go through some of the things currently built into Python
Score, since it already does some of the things mentioned in this
thread, or a hop-skip-jump away from doing some of the other things.
And do ask questions. I'm willing to go over this in more detail,
whether on or off list.

1) Easy Point of Entry

Don't know Python, but know the Csound score. Everything, and I mean
everything, you already know about the score can be used in Pysco,
without modification, as long as it's wrapped in the score() function:

score('''
f 1 0 8192 10 1
t 0 189

i 1 0 0.5 0.707 9.02
i 1 + .   .     8.07
i 1 + .   .     8.09
i 1 + .   .     8.11
i 1 + .   .     9.00
i 1 + .   .     8.09
i 1 + .   .     8.11
i 1 + .   .     8.07
''')

Code:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test.csd

2) Pfield Translators

The original idea of Pysco came from a user request in the list in
which someone wanted to be able to use an alternative way of
expressing notes in the form of C5, D#4, G4, etc. The following
example does just that using the pfield mapper function pmap(). This
is a post-processor that goes through score data and changes it based
on the function passed to pmap.

score('''
f 1 0 8192 10 1
t 0 120

i 1 0 0.5 -3 D5
i 1 + .   .  G4
i 1 + .   .  A4
i 1 + .   .  B4
i 1 + .   .  C5
i 1 + .   .  A4
i 1 + .   .  B4
i 1 + .   .  G5
''')

pmap('i', 1, 4, dB)
pmap('i', 1, 5, conv_to_hz)

Code:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test2.csd

You may have noticed that it also translates decibels with pfield.

3) Time with the cue() object

Time is treated like other control structures, akin to the if
statement. The cue() object translates the current postion of time in
the score, and modifies pfield 2 to reflect the position. For example,
the follow two events start at beat 0 and beat 1.5

score('''
i 1 0   0.5 0.707 8.00
i 1 1.5 0.5 0.707 9.00
''')

Using the same two unmodified events combined with the statement "with
cue(100):", it plays these two events at beat 100 and beat 101.5:

with cue(100):
    score('''
    i 1 0   0.5 0.707 8.00
    i 1 1.5 0.5 0.707 9.00
    ''')

That is:
100 + 0 = 100
100 + 1.5 = 101.5

These cues also nest, and these two notes play on beats 103 and 104.5.

with cue(100):
    with cue(3):
        score('''
        i 1 0   0.5 0.707 8.00
        i 1 1.5 0.5 0.707 9.00
        ''')

That is:
100 + 3 + 0 = 103
100 + 3 + 1.5 = 104.5

Here's a code example that cues each measure independently, so that
the start times for each i-event block is normalized to zero. Crazy
easy to manage events in time this way:

https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test10.csd

4) Don't like Time-In-Beats? How about Measures instead

So you're writing a piece in 4/4 and you'd rather organize events in
measures instead of beats because it totally makes more sense to do it
that way. Here's how to customize the cue() with a Python function:

def measure(t):
    return cue((t - 1) * 4.0)

Now let's place those two notes into measure 16.

with measure(16):
    score('''
    i 1 0   0.5 0.707 8.00
    i 1 1.5 0.5 0.707 9.00
    ''')

That that math works out to:
(16 - 1) * 4) + 0 = 60
(16 - 1) * 4) + 1.5 = 61.5

Gone are the days of manually keeping track of absolute position in
beats, or even seconds, for each note.

Similiar code to example 3, but uses the custom measure():
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test11.csd

This is measure() example is a simple conversion, but it wouldn't take
much to create a custom object that allowed users to mix and match
time signatures.

5) Functions as Reusable Musical Phrases

Let's wrap up those two notes into a re-usable phrase.

def my_phrase():
    score('''
    i 1 0   0.5 0.707 8.00
    i 1 1.5 0.5 0.707 9.00
    ''')

And let's place them in the first four measure of the score:

with measure(1): my_phrase()
with measure(2): my_phrase()
with measure(3): my_phrase()
with measure(4): my_phrase()

6) Alternatives to Score() i_events

The score() isn't the only way to create i-events. Here is an
alternative form using event_i()

def my_phrase():
    event_i(1, 0, 0.5, 0.707, 8.00)
    event_i(1, 1.5, 0.5, 0.707, 9.00)

The advantage is that you can inline Python functions directly into i-events:

event_i(1, 0, random(), random(), cpspch(8.00))

7) p_callback(), And Alternative to pmap()

The pmap() is a processor, and processes data that is already inside
the score() object. The p_callback() modifies events as they're being
inserted. In this example, the data stored for pfield 5 is the
frequency, not the written string representation, once inserted into
the score.

p_callback('i', 1, 5, conv_to_hz)

event_i(1, 0, 4, 0.707, 'C4')

Related code:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test12.csd

8) cue() and p_callback() work as a team.

Remember our two note phrase:

def my_phrase():
    event_i(1, 0, 0.5, 0.707, 8.00)
    event_i(2, 1.5, 0.5, 0.707, 9.00)

Let's say we wanted to play it as is in measure 1, but wanted to
transpose it 1 octave lower in measure 2, and as back to normal in
measure 3. Any p_callback() placed within the context of a "with
cue()" statement, only exists for that block, disappearing once that
block is finished.

p_callback('i', 1, 5, cpspch)  # Pfield 5 will be stored as Hz in the score()

with measure(1):
    my_phrase()

# Plays 1 octave lower
with measure(2):
    p_callback('i', 1, 5, lambda x: x / 2.0)  # p5 will be divided by 2
    my_phrase()

# Back to normal
with measure(3):
    my_phrase()

Code example that illustrates this:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test16.csd


This is just scratches the surface, because there's also all of Python
to consider.

Best,
Jake


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

Date2013-03-21 20:57
FromJacob Joaquin
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
Possibly. Can you go into greater detail as to what you mean by
generating events from an instrument in the orchestra? Do you mean
using the python opcodes in Csound? If you have a use case in mind, as
that would also be helpful.

Best,
Jake

On Thu, Mar 21, 2013 at 1:43 PM, Oeyvind Brandtsegg
 wrote:
> There are some nice things to this system, and I do like the ability to
> freely map generators to event parameters using any desired format of
> representation.
> Can it also be used in a similar manner to generate events from an
> instrument in the orchestra?
> best
> Oeyvind
>
>
> 2013/3/21 Jacob Joaquin 
>>
>> Very productive discussion. Lot's to reply to, so I'm going to do my
>> best to cover much of this in one email. It's also long, so sorry
>> about that.
>>
>> First, I want to make it clear that I have no intention of trying
>> formalize western music, eastern music, north and sound of the
>> Maxon-Dixon Line music, etc. My goals are focused on the Python
>> interface between the Csound Score and libraries that enhance a
>> composer's ability to write music/sound in a way that makes sense to
>> them.
>>
>> Instead of starting with a grand vision of what the ultimate
>> collection of Csound/music libraries, I'm starting small. Something
>> along the lines of: compose, code, curate, repeat. This being a
>> community effort.
>>
>> I've already started on Python Score, which is I believe is already a
>> reasonable interface to the score. There is an easy point of entry for
>> Csounder's familiar with the Csound score. Out of the box, it removes
>> most of the boilerplate code for generating scores with Python, such
>> as manually constructing strings and open files, and it works right
>> inside a CSD. It also plays well with existing Python libraries such
>> as music21.
>>
>> So in theory, it's an environment in which a composer can mix and
>> match various types of composition. PMask + Music21 + Lindenmayer
>> Systems + Markov Chains and all simply exist in the same Python Score,
>> even if they themselves aren't necessarily compatible with each other.
>>
>> I want to go through some of the things currently built into Python
>> Score, since it already does some of the things mentioned in this
>> thread, or a hop-skip-jump away from doing some of the other things.
>> And do ask questions. I'm willing to go over this in more detail,
>> whether on or off list.
>>
>> 1) Easy Point of Entry
>>
>> Don't know Python, but know the Csound score. Everything, and I mean
>> everything, you already know about the score can be used in Pysco,
>> without modification, as long as it's wrapped in the score() function:
>>
>> score('''
>> f 1 0 8192 10 1
>> t 0 189
>>
>> i 1 0 0.5 0.707 9.02
>> i 1 + .   .     8.07
>> i 1 + .   .     8.09
>> i 1 + .   .     8.11
>> i 1 + .   .     9.00
>> i 1 + .   .     8.09
>> i 1 + .   .     8.11
>> i 1 + .   .     8.07
>> ''')
>>
>> Code:
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test.csd
>>
>> 2) Pfield Translators
>>
>> The original idea of Pysco came from a user request in the list in
>> which someone wanted to be able to use an alternative way of
>> expressing notes in the form of C5, D#4, G4, etc. The following
>> example does just that using the pfield mapper function pmap(). This
>> is a post-processor that goes through score data and changes it based
>> on the function passed to pmap.
>>
>> score('''
>> f 1 0 8192 10 1
>> t 0 120
>>
>> i 1 0 0.5 -3 D5
>> i 1 + .   .  G4
>> i 1 + .   .  A4
>> i 1 + .   .  B4
>> i 1 + .   .  C5
>> i 1 + .   .  A4
>> i 1 + .   .  B4
>> i 1 + .   .  G5
>> ''')
>>
>> pmap('i', 1, 4, dB)
>> pmap('i', 1, 5, conv_to_hz)
>>
>> Code:
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test2.csd
>>
>> You may have noticed that it also translates decibels with pfield.
>>
>> 3) Time with the cue() object
>>
>> Time is treated like other control structures, akin to the if
>> statement. The cue() object translates the current postion of time in
>> the score, and modifies pfield 2 to reflect the position. For example,
>> the follow two events start at beat 0 and beat 1.5
>>
>> score('''
>> i 1 0   0.5 0.707 8.00
>> i 1 1.5 0.5 0.707 9.00
>> ''')
>>
>> Using the same two unmodified events combined with the statement "with
>> cue(100):", it plays these two events at beat 100 and beat 101.5:
>>
>> with cue(100):
>>     score('''
>>     i 1 0   0.5 0.707 8.00
>>     i 1 1.5 0.5 0.707 9.00
>>     ''')
>>
>> That is:
>> 100 + 0 = 100
>> 100 + 1.5 = 101.5
>>
>> These cues also nest, and these two notes play on beats 103 and 104.5.
>>
>> with cue(100):
>>     with cue(3):
>>         score('''
>>         i 1 0   0.5 0.707 8.00
>>         i 1 1.5 0.5 0.707 9.00
>>         ''')
>>
>> That is:
>> 100 + 3 + 0 = 103
>> 100 + 3 + 1.5 = 104.5
>>
>> Here's a code example that cues each measure independently, so that
>> the start times for each i-event block is normalized to zero. Crazy
>> easy to manage events in time this way:
>>
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test10.csd
>>
>> 4) Don't like Time-In-Beats? How about Measures instead
>>
>> So you're writing a piece in 4/4 and you'd rather organize events in
>> measures instead of beats because it totally makes more sense to do it
>> that way. Here's how to customize the cue() with a Python function:
>>
>> def measure(t):
>>     return cue((t - 1) * 4.0)
>>
>> Now let's place those two notes into measure 16.
>>
>> with measure(16):
>>     score('''
>>     i 1 0   0.5 0.707 8.00
>>     i 1 1.5 0.5 0.707 9.00
>>     ''')
>>
>> That that math works out to:
>> (16 - 1) * 4) + 0 = 60
>> (16 - 1) * 4) + 1.5 = 61.5
>>
>> Gone are the days of manually keeping track of absolute position in
>> beats, or even seconds, for each note.
>>
>> Similiar code to example 3, but uses the custom measure():
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test11.csd
>>
>> This is measure() example is a simple conversion, but it wouldn't take
>> much to create a custom object that allowed users to mix and match
>> time signatures.
>>
>> 5) Functions as Reusable Musical Phrases
>>
>> Let's wrap up those two notes into a re-usable phrase.
>>
>> def my_phrase():
>>     score('''
>>     i 1 0   0.5 0.707 8.00
>>     i 1 1.5 0.5 0.707 9.00
>>     ''')
>>
>> And let's place them in the first four measure of the score:
>>
>> with measure(1): my_phrase()
>> with measure(2): my_phrase()
>> with measure(3): my_phrase()
>> with measure(4): my_phrase()
>>
>> 6) Alternatives to Score() i_events
>>
>> The score() isn't the only way to create i-events. Here is an
>> alternative form using event_i()
>>
>> def my_phrase():
>>     event_i(1, 0, 0.5, 0.707, 8.00)
>>     event_i(1, 1.5, 0.5, 0.707, 9.00)
>>
>> The advantage is that you can inline Python functions directly into
>> i-events:
>>
>> event_i(1, 0, random(), random(), cpspch(8.00))
>>
>> 7) p_callback(), And Alternative to pmap()
>>
>> The pmap() is a processor, and processes data that is already inside
>> the score() object. The p_callback() modifies events as they're being
>> inserted. In this example, the data stored for pfield 5 is the
>> frequency, not the written string representation, once inserted into
>> the score.
>>
>> p_callback('i', 1, 5, conv_to_hz)
>>
>> event_i(1, 0, 4, 0.707, 'C4')
>>
>> Related code:
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test12.csd
>>
>> 8) cue() and p_callback() work as a team.
>>
>> Remember our two note phrase:
>>
>> def my_phrase():
>>     event_i(1, 0, 0.5, 0.707, 8.00)
>>     event_i(2, 1.5, 0.5, 0.707, 9.00)
>>
>> Let's say we wanted to play it as is in measure 1, but wanted to
>> transpose it 1 octave lower in measure 2, and as back to normal in
>> measure 3. Any p_callback() placed within the context of a "with
>> cue()" statement, only exists for that block, disappearing once that
>> block is finished.
>>
>> p_callback('i', 1, 5, cpspch)  # Pfield 5 will be stored as Hz in the
>> score()
>>
>> with measure(1):
>>     my_phrase()
>>
>> # Plays 1 octave lower
>> with measure(2):
>>     p_callback('i', 1, 5, lambda x: x / 2.0)  # p5 will be divided by 2
>>     my_phrase()
>>
>> # Back to normal
>> with measure(3):
>>     my_phrase()
>>
>> Code example that illustrates this:
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test16.csd
>>
>>
>> This is just scratches the surface, because there's also all of Python
>> to consider.
>>
>> Best,
>> Jake
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp



-- 
codehop.com | #code #art #music

Date2013-03-21 23:05
FromOeyvind Brandtsegg
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
First thought was just, "oh, nice... and can it be used in an instrument", as for me realtime control over the event generation process would be essential so that I could sculpt the process by means of controllers, inputting new material by means of midi input or audio analysis etc.
Not at all sure how that would be done, but for example:

def my_phrase():
    event_i(1, 0, 0.5, 0.707, 8.00)
    event_i(2, 1.5, 0.5, 0.707, 9.00)

Is very similar to using event_i (or event) in an instrument.
Normally I would use pycallt triggered by a metronome or similar, get some values from Python, then forward those values to event.
It looks as if that process could be done more smoothly the way you do it here, if event was available directly in the Python code, and as we know, the Python code can already be inlined in the orchestra by means of pyrun or pyeval. It would be handy if such a function could directly generate Csound events and also return or transfer some value to Csound (e.g. delta time to next event so that the metronome trigger tempo can be adjusted accordingly.
Perhaps a combination of event generation and chn channel writing:

def my_phrase():
    event_i(1, 0, 0.5, 0.707, 8.00)
    event_i(2, 1.5, 0.5, 0.707, 9.00)
    chnset 1.5, "deltaTime"

best
Oeyvind


2013/3/21 Jacob Joaquin <jacobjoaquin@gmail.com>
Possibly. Can you go into greater detail as to what you mean by
generating events from an instrument in the orchestra? Do you mean
using the python opcodes in Csound? If you have a use case in mind, as
that would also be helpful.

Best,
Jake

On Thu, Mar 21, 2013 at 1:43 PM, Oeyvind Brandtsegg
<oyvind.brandtsegg@ntnu.no> wrote:
> There are some nice things to this system, and I do like the ability to
> freely map generators to event parameters using any desired format of
> representation.
> Can it also be used in a similar manner to generate events from an
> instrument in the orchestra?
> best
> Oeyvind
>
>
> 2013/3/21 Jacob Joaquin <jacobjoaquin@gmail.com>
>>
>> Very productive discussion. Lot's to reply to, so I'm going to do my
>> best to cover much of this in one email. It's also long, so sorry
>> about that.
>>
>> First, I want to make it clear that I have no intention of trying
>> formalize western music, eastern music, north and sound of the
>> Maxon-Dixon Line music, etc. My goals are focused on the Python
>> interface between the Csound Score and libraries that enhance a
>> composer's ability to write music/sound in a way that makes sense to
>> them.
>>
>> Instead of starting with a grand vision of what the ultimate
>> collection of Csound/music libraries, I'm starting small. Something
>> along the lines of: compose, code, curate, repeat. This being a
>> community effort.
>>
>> I've already started on Python Score, which is I believe is already a
>> reasonable interface to the score. There is an easy point of entry for
>> Csounder's familiar with the Csound score. Out of the box, it removes
>> most of the boilerplate code for generating scores with Python, such
>> as manually constructing strings and open files, and it works right
>> inside a CSD. It also plays well with existing Python libraries such
>> as music21.
>>
>> So in theory, it's an environment in which a composer can mix and
>> match various types of composition. PMask + Music21 + Lindenmayer
>> Systems + Markov Chains and all simply exist in the same Python Score,
>> even if they themselves aren't necessarily compatible with each other.
>>
>> I want to go through some of the things currently built into Python
>> Score, since it already does some of the things mentioned in this
>> thread, or a hop-skip-jump away from doing some of the other things.
>> And do ask questions. I'm willing to go over this in more detail,
>> whether on or off list.
>>
>> 1) Easy Point of Entry
>>
>> Don't know Python, but know the Csound score. Everything, and I mean
>> everything, you already know about the score can be used in Pysco,
>> without modification, as long as it's wrapped in the score() function:
>>
>> score('''
>> f 1 0 8192 10 1
>> t 0 189
>>
>> i 1 0 0.5 0.707 9.02
>> i 1 + .   .     8.07
>> i 1 + .   .     8.09
>> i 1 + .   .     8.11
>> i 1 + .   .     9.00
>> i 1 + .   .     8.09
>> i 1 + .   .     8.11
>> i 1 + .   .     8.07
>> ''')
>>
>> Code:
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test.csd
>>
>> 2) Pfield Translators
>>
>> The original idea of Pysco came from a user request in the list in
>> which someone wanted to be able to use an alternative way of
>> expressing notes in the form of C5, D#4, G4, etc. The following
>> example does just that using the pfield mapper function pmap(). This
>> is a post-processor that goes through score data and changes it based
>> on the function passed to pmap.
>>
>> score('''
>> f 1 0 8192 10 1
>> t 0 120
>>
>> i 1 0 0.5 -3 D5
>> i 1 + .   .  G4
>> i 1 + .   .  A4
>> i 1 + .   .  B4
>> i 1 + .   .  C5
>> i 1 + .   .  A4
>> i 1 + .   .  B4
>> i 1 + .   .  G5
>> ''')
>>
>> pmap('i', 1, 4, dB)
>> pmap('i', 1, 5, conv_to_hz)
>>
>> Code:
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test2.csd
>>
>> You may have noticed that it also translates decibels with pfield.
>>
>> 3) Time with the cue() object
>>
>> Time is treated like other control structures, akin to the if
>> statement. The cue() object translates the current postion of time in
>> the score, and modifies pfield 2 to reflect the position. For example,
>> the follow two events start at beat 0 and beat 1.5
>>
>> score('''
>> i 1 0   0.5 0.707 8.00
>> i 1 1.5 0.5 0.707 9.00
>> ''')
>>
>> Using the same two unmodified events combined with the statement "with
>> cue(100):", it plays these two events at beat 100 and beat 101.5:
>>
>> with cue(100):
>>     score('''
>>     i 1 0   0.5 0.707 8.00
>>     i 1 1.5 0.5 0.707 9.00
>>     ''')
>>
>> That is:
>> 100 + 0 = 100
>> 100 + 1.5 = 101.5
>>
>> These cues also nest, and these two notes play on beats 103 and 104.5.
>>
>> with cue(100):
>>     with cue(3):
>>         score('''
>>         i 1 0   0.5 0.707 8.00
>>         i 1 1.5 0.5 0.707 9.00
>>         ''')
>>
>> That is:
>> 100 + 3 + 0 = 103
>> 100 + 3 + 1.5 = 104.5
>>
>> Here's a code example that cues each measure independently, so that
>> the start times for each i-event block is normalized to zero. Crazy
>> easy to manage events in time this way:
>>
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test10.csd
>>
>> 4) Don't like Time-In-Beats? How about Measures instead
>>
>> So you're writing a piece in 4/4 and you'd rather organize events in
>> measures instead of beats because it totally makes more sense to do it
>> that way. Here's how to customize the cue() with a Python function:
>>
>> def measure(t):
>>     return cue((t - 1) * 4.0)
>>
>> Now let's place those two notes into measure 16.
>>
>> with measure(16):
>>     score('''
>>     i 1 0   0.5 0.707 8.00
>>     i 1 1.5 0.5 0.707 9.00
>>     ''')
>>
>> That that math works out to:
>> (16 - 1) * 4) + 0 = 60
>> (16 - 1) * 4) + 1.5 = 61.5
>>
>> Gone are the days of manually keeping track of absolute position in
>> beats, or even seconds, for each note.
>>
>> Similiar code to example 3, but uses the custom measure():
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test11.csd
>>
>> This is measure() example is a simple conversion, but it wouldn't take
>> much to create a custom object that allowed users to mix and match
>> time signatures.
>>
>> 5) Functions as Reusable Musical Phrases
>>
>> Let's wrap up those two notes into a re-usable phrase.
>>
>> def my_phrase():
>>     score('''
>>     i 1 0   0.5 0.707 8.00
>>     i 1 1.5 0.5 0.707 9.00
>>     ''')
>>
>> And let's place them in the first four measure of the score:
>>
>> with measure(1): my_phrase()
>> with measure(2): my_phrase()
>> with measure(3): my_phrase()
>> with measure(4): my_phrase()
>>
>> 6) Alternatives to Score() i_events
>>
>> The score() isn't the only way to create i-events. Here is an
>> alternative form using event_i()
>>
>> def my_phrase():
>>     event_i(1, 0, 0.5, 0.707, 8.00)
>>     event_i(1, 1.5, 0.5, 0.707, 9.00)
>>
>> The advantage is that you can inline Python functions directly into
>> i-events:
>>
>> event_i(1, 0, random(), random(), cpspch(8.00))
>>
>> 7) p_callback(), And Alternative to pmap()
>>
>> The pmap() is a processor, and processes data that is already inside
>> the score() object. The p_callback() modifies events as they're being
>> inserted. In this example, the data stored for pfield 5 is the
>> frequency, not the written string representation, once inserted into
>> the score.
>>
>> p_callback('i', 1, 5, conv_to_hz)
>>
>> event_i(1, 0, 4, 0.707, 'C4')
>>
>> Related code:
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test12.csd
>>
>> 8) cue() and p_callback() work as a team.
>>
>> Remember our two note phrase:
>>
>> def my_phrase():
>>     event_i(1, 0, 0.5, 0.707, 8.00)
>>     event_i(2, 1.5, 0.5, 0.707, 9.00)
>>
>> Let's say we wanted to play it as is in measure 1, but wanted to
>> transpose it 1 octave lower in measure 2, and as back to normal in
>> measure 3. Any p_callback() placed within the context of a "with
>> cue()" statement, only exists for that block, disappearing once that
>> block is finished.
>>
>> p_callback('i', 1, 5, cpspch)  # Pfield 5 will be stored as Hz in the
>> score()
>>
>> with measure(1):
>>     my_phrase()
>>
>> # Plays 1 octave lower
>> with measure(2):
>>     p_callback('i', 1, 5, lambda x: x / 2.0)  # p5 will be divided by 2
>>     my_phrase()
>>
>> # Back to normal
>> with measure(3):
>>     my_phrase()
>>
>> Code example that illustrates this:
>> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test16.csd
>>
>>
>> This is just scratches the surface, because there's also all of Python
>> to consider.
>>
>> Best,
>> Jake
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp



--
codehop.com | #code #art #music


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

Date2013-03-21 23:43
FromJacob Joaquin
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
> This is measure() example is a simple conversion, but it wouldn't take
> much to create a custom object that allowed users to mix and match
> time signatures.

Went ahead and threw together a method for mixed meter in a score.
This just a proof-of-concept, so there are probably bugs and perhaps
lacks features. The following creates a custom cue() object that
specifies the time signatures through out a score:

m = MixedMeter({
    1: (3, 4),
    5: (4, 4),
    9: (7, 4),
    13: (6, 8),
})

Starting at measure 1, the signature is 3/4. At measure 5, the sig
switches to 4/4. At measure 9 it becomes 7/4. And finally at measure
13, it becomes 6/8.

And then to use it:

# Measure 10 in 7/4
with m.measure(10):
        event_i(1, 0, 1, 0.707, 7.02)
        event_i(1, 1, 1, 0.707, 6.11)
        event_i(1, 2, 1, 0.707, 6.11)
        event_i(1, 3, 1, 0.707, 6.11)
        event_i(1, 4, 1, 0.707, 6.11)
        event_i(1, 5, 1, 0.707, 6.11)
        event_i(1, 6, 1, 0.707, 6.11)

Code:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/mixed_meter.csd

Audio (boring, but it demonstrates the point):
https://soundcloud.com/jacobjoaquin/csound-python-score

Python makes things easy.

Date2013-03-22 00:16
FromJacob Joaquin
SubjectRe: [Csnd] Csound and Python: What Exists and Would Csounders Like
At the current moment, score generation is at the forefront of my
mind. Though I have put a little thought into what some of the
challenges might be in making this compatible with realtime, because
realtime is a must have feature imho.

That said, I've never used the Python opcodes from within an
orchestra, so I have no idea how they can be used, and what they're
limitations are. Though as for your example:

> def my_phrase():
>     event_i(1, 0, 0.5, 0.707, 8.00)
>     event_i(2, 1.5, 0.5, 0.707, 9.00)
>     chnset 1.5, "deltaTime"

I have a feeling that wrapping up the chnset line into its own Csound
instrument might allow you to do what you want. Let's say it its instr
3:

with cue(4):
    event_i(3, 0, 1, 1.5, '"deltaTime"')

Haven't gotten into this yet, but I'd probably wrap that up into a new
function with a smaller interface:

def chnset(value, channel):
    event_i(3, 0, value, channel)

And then my_phrase would look like this:

def my_phrase():
     event_i(1, 0, 0.5, 0.707, 8.00)
     event_i(2, 1.5, 0.5, 0.707, 9.00)
     chnset(1.5, "deltaTime")




On Thu, Mar 21, 2013 at 4:05 PM, Oeyvind Brandtsegg
 wrote:
> First thought was just, "oh, nice... and can it be used in an instrument",
> as for me realtime control over the event generation process would be
> essential so that I could sculpt the process by means of controllers,
> inputting new material by means of midi input or audio analysis etc.
> Not at all sure how that would be done, but for example:
>
>
> def my_phrase():
>     event_i(1, 0, 0.5, 0.707, 8.00)
>     event_i(2, 1.5, 0.5, 0.707, 9.00)
>
> Is very similar to using event_i (or event) in an instrument.
> Normally I would use pycallt triggered by a metronome or similar, get some
> values from Python, then forward those values to event.
> It looks as if that process could be done more smoothly the way you do it
> here, if event was available directly in the Python code, and as we know,
> the Python code can already be inlined in the orchestra by means of pyrun or
> pyeval. It would be handy if such a function could directly generate Csound
> events and also return or transfer some value to Csound (e.g. delta time to
> next event so that the metronome trigger tempo can be adjusted accordingly.
> Perhaps a combination of event generation and chn channel writing:
>
>
> def my_phrase():
>     event_i(1, 0, 0.5, 0.707, 8.00)
>     event_i(2, 1.5, 0.5, 0.707, 9.00)
>     chnset 1.5, "deltaTime"
>
> best
> Oeyvind
>
>
> 2013/3/21 Jacob Joaquin 
>>
>> Possibly. Can you go into greater detail as to what you mean by
>> generating events from an instrument in the orchestra? Do you mean
>> using the python opcodes in Csound? If you have a use case in mind, as
>> that would also be helpful.
>>
>> Best,
>> Jake
>>
>> On Thu, Mar 21, 2013 at 1:43 PM, Oeyvind Brandtsegg
>>  wrote:
>> > There are some nice things to this system, and I do like the ability to
>> > freely map generators to event parameters using any desired format of
>> > representation.
>> > Can it also be used in a similar manner to generate events from an
>> > instrument in the orchestra?
>> > best
>> > Oeyvind
>> >
>> >
>> > 2013/3/21 Jacob Joaquin 
>> >>
>> >> Very productive discussion. Lot's to reply to, so I'm going to do my
>> >> best to cover much of this in one email. It's also long, so sorry
>> >> about that.
>> >>
>> >> First, I want to make it clear that I have no intention of trying
>> >> formalize western music, eastern music, north and sound of the
>> >> Maxon-Dixon Line music, etc. My goals are focused on the Python
>> >> interface between the Csound Score and libraries that enhance a
>> >> composer's ability to write music/sound in a way that makes sense to
>> >> them.
>> >>
>> >> Instead of starting with a grand vision of what the ultimate
>> >> collection of Csound/music libraries, I'm starting small. Something
>> >> along the lines of: compose, code, curate, repeat. This being a
>> >> community effort.
>> >>
>> >> I've already started on Python Score, which is I believe is already a
>> >> reasonable interface to the score. There is an easy point of entry for
>> >> Csounder's familiar with the Csound score. Out of the box, it removes
>> >> most of the boilerplate code for generating scores with Python, such
>> >> as manually constructing strings and open files, and it works right
>> >> inside a CSD. It also plays well with existing Python libraries such
>> >> as music21.
>> >>
>> >> So in theory, it's an environment in which a composer can mix and
>> >> match various types of composition. PMask + Music21 + Lindenmayer
>> >> Systems + Markov Chains and all simply exist in the same Python Score,
>> >> even if they themselves aren't necessarily compatible with each other.
>> >>
>> >> I want to go through some of the things currently built into Python
>> >> Score, since it already does some of the things mentioned in this
>> >> thread, or a hop-skip-jump away from doing some of the other things.
>> >> And do ask questions. I'm willing to go over this in more detail,
>> >> whether on or off list.
>> >>
>> >> 1) Easy Point of Entry
>> >>
>> >> Don't know Python, but know the Csound score. Everything, and I mean
>> >> everything, you already know about the score can be used in Pysco,
>> >> without modification, as long as it's wrapped in the score() function:
>> >>
>> >> score('''
>> >> f 1 0 8192 10 1
>> >> t 0 189
>> >>
>> >> i 1 0 0.5 0.707 9.02
>> >> i 1 + .   .     8.07
>> >> i 1 + .   .     8.09
>> >> i 1 + .   .     8.11
>> >> i 1 + .   .     9.00
>> >> i 1 + .   .     8.09
>> >> i 1 + .   .     8.11
>> >> i 1 + .   .     8.07
>> >> ''')
>> >>
>> >> Code:
>> >> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test.csd
>> >>
>> >> 2) Pfield Translators
>> >>
>> >> The original idea of Pysco came from a user request in the list in
>> >> which someone wanted to be able to use an alternative way of
>> >> expressing notes in the form of C5, D#4, G4, etc. The following
>> >> example does just that using the pfield mapper function pmap(). This
>> >> is a post-processor that goes through score data and changes it based
>> >> on the function passed to pmap.
>> >>
>> >> score('''
>> >> f 1 0 8192 10 1
>> >> t 0 120
>> >>
>> >> i 1 0 0.5 -3 D5
>> >> i 1 + .   .  G4
>> >> i 1 + .   .  A4
>> >> i 1 + .   .  B4
>> >> i 1 + .   .  C5
>> >> i 1 + .   .  A4
>> >> i 1 + .   .  B4
>> >> i 1 + .   .  G5
>> >> ''')
>> >>
>> >> pmap('i', 1, 4, dB)
>> >> pmap('i', 1, 5, conv_to_hz)
>> >>
>> >> Code:
>> >> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test2.csd
>> >>
>> >> You may have noticed that it also translates decibels with pfield.
>> >>
>> >> 3) Time with the cue() object
>> >>
>> >> Time is treated like other control structures, akin to the if
>> >> statement. The cue() object translates the current postion of time in
>> >> the score, and modifies pfield 2 to reflect the position. For example,
>> >> the follow two events start at beat 0 and beat 1.5
>> >>
>> >> score('''
>> >> i 1 0   0.5 0.707 8.00
>> >> i 1 1.5 0.5 0.707 9.00
>> >> ''')
>> >>
>> >> Using the same two unmodified events combined with the statement "with
>> >> cue(100):", it plays these two events at beat 100 and beat 101.5:
>> >>
>> >> with cue(100):
>> >>     score('''
>> >>     i 1 0   0.5 0.707 8.00
>> >>     i 1 1.5 0.5 0.707 9.00
>> >>     ''')
>> >>
>> >> That is:
>> >> 100 + 0 = 100
>> >> 100 + 1.5 = 101.5
>> >>
>> >> These cues also nest, and these two notes play on beats 103 and 104.5.
>> >>
>> >> with cue(100):
>> >>     with cue(3):
>> >>         score('''
>> >>         i 1 0   0.5 0.707 8.00
>> >>         i 1 1.5 0.5 0.707 9.00
>> >>         ''')
>> >>
>> >> That is:
>> >> 100 + 3 + 0 = 103
>> >> 100 + 3 + 1.5 = 104.5
>> >>
>> >> Here's a code example that cues each measure independently, so that
>> >> the start times for each i-event block is normalized to zero. Crazy
>> >> easy to manage events in time this way:
>> >>
>> >> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test10.csd
>> >>
>> >> 4) Don't like Time-In-Beats? How about Measures instead
>> >>
>> >> So you're writing a piece in 4/4 and you'd rather organize events in
>> >> measures instead of beats because it totally makes more sense to do it
>> >> that way. Here's how to customize the cue() with a Python function:
>> >>
>> >> def measure(t):
>> >>     return cue((t - 1) * 4.0)
>> >>
>> >> Now let's place those two notes into measure 16.
>> >>
>> >> with measure(16):
>> >>     score('''
>> >>     i 1 0   0.5 0.707 8.00
>> >>     i 1 1.5 0.5 0.707 9.00
>> >>     ''')
>> >>
>> >> That that math works out to:
>> >> (16 - 1) * 4) + 0 = 60
>> >> (16 - 1) * 4) + 1.5 = 61.5
>> >>
>> >> Gone are the days of manually keeping track of absolute position in
>> >> beats, or even seconds, for each note.
>> >>
>> >> Similiar code to example 3, but uses the custom measure():
>> >> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test11.csd
>> >>
>> >> This is measure() example is a simple conversion, but it wouldn't take
>> >> much to create a custom object that allowed users to mix and match
>> >> time signatures.
>> >>
>> >> 5) Functions as Reusable Musical Phrases
>> >>
>> >> Let's wrap up those two notes into a re-usable phrase.
>> >>
>> >> def my_phrase():
>> >>     score('''
>> >>     i 1 0   0.5 0.707 8.00
>> >>     i 1 1.5 0.5 0.707 9.00
>> >>     ''')
>> >>
>> >> And let's place them in the first four measure of the score:
>> >>
>> >> with measure(1): my_phrase()
>> >> with measure(2): my_phrase()
>> >> with measure(3): my_phrase()
>> >> with measure(4): my_phrase()
>> >>
>> >> 6) Alternatives to Score() i_events
>> >>
>> >> The score() isn't the only way to create i-events. Here is an
>> >> alternative form using event_i()
>> >>
>> >> def my_phrase():
>> >>     event_i(1, 0, 0.5, 0.707, 8.00)
>> >>     event_i(1, 1.5, 0.5, 0.707, 9.00)
>> >>
>> >> The advantage is that you can inline Python functions directly into
>> >> i-events:
>> >>
>> >> event_i(1, 0, random(), random(), cpspch(8.00))
>> >>
>> >> 7) p_callback(), And Alternative to pmap()
>> >>
>> >> The pmap() is a processor, and processes data that is already inside
>> >> the score() object. The p_callback() modifies events as they're being
>> >> inserted. In this example, the data stored for pfield 5 is the
>> >> frequency, not the written string representation, once inserted into
>> >> the score.
>> >>
>> >> p_callback('i', 1, 5, conv_to_hz)
>> >>
>> >> event_i(1, 0, 4, 0.707, 'C4')
>> >>
>> >> Related code:
>> >> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test12.csd
>> >>
>> >> 8) cue() and p_callback() work as a team.
>> >>
>> >> Remember our two note phrase:
>> >>
>> >> def my_phrase():
>> >>     event_i(1, 0, 0.5, 0.707, 8.00)
>> >>     event_i(2, 1.5, 0.5, 0.707, 9.00)
>> >>
>> >> Let's say we wanted to play it as is in measure 1, but wanted to
>> >> transpose it 1 octave lower in measure 2, and as back to normal in
>> >> measure 3. Any p_callback() placed within the context of a "with
>> >> cue()" statement, only exists for that block, disappearing once that
>> >> block is finished.
>> >>
>> >> p_callback('i', 1, 5, cpspch)  # Pfield 5 will be stored as Hz in the
>> >> score()
>> >>
>> >> with measure(1):
>> >>     my_phrase()
>> >>
>> >> # Plays 1 octave lower
>> >> with measure(2):
>> >>     p_callback('i', 1, 5, lambda x: x / 2.0)  # p5 will be divided by 2
>> >>     my_phrase()
>> >>
>> >> # Back to normal
>> >> with measure(3):
>> >>     my_phrase()
>> >>
>> >> Code example that illustrates this:
>> >> https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/test16.csd
>> >>
>> >>
>> >> This is just scratches the surface, because there's also all of Python
>> >> to consider.
>> >>
>> >> Best,
>> >> Jake
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> "unsubscribe
>> >> csound"
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > Oeyvind Brandtsegg
>> > Professor of Music Technology
>> > NTNU
>> > 7491 Trondheim
>> > Norway
>> > Cell: +47 92 203 205
>> >
>> > http://flyndresang.no/
>> > http://www.partikkelaudio.com/
>> > http://soundcloud.com/brandtsegg
>> > http://soundcloud.com/t-emp
>>
>>
>>
>> --
>> codehop.com | #code #art #music
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp



-- 
codehop.com | #code #art #music

Date2013-03-23 01:24
FromRobert or Gretchen Foose
SubjectRe: Re: [Csnd] Csound and Python: What Exists and Would Csounders
plus one to this post.  Over the past few years, a lot of effort 
has gone into making csound productively accessible to 
beginners.  Having background in 'traditional' methods of 
approaching composition, I like the idea of at least having 
quick access to csound through a more traditional approach to 
the score. (It is, after all, called a 'score' isn't it?)  But I 
also don't want to be locked into four beat measures, eight 
measure phrases, etc.  I've dumped a lot of software sequencers 
from my machine simply because they didn't let me subdivide my 
beats into triplets!  So, by all means, keep everything as open 
ended as possible.  Even though it's a pain in the butt, you can 
use a spreadsheet for creating scores if you feel too restricted 
by more traditional thought processes.
I'll probably continue to use this approach somewhat anyway.
Bob

On 13:59, Justin Smith wrote:
> Traditionally, even in pure programming contexts, the set of
> tools provided is in some way curated in order to cultivate
> specific conceptual models. One can program functionally in C,
> declaratively in javascript, in an object oriented manner in
> forth, or imperatively in haskell, but the language in each case
> will put up a fight, and a path of least resistance guides the
> user to a language's preferred approach.
>
> Since any library implements an extension to the language, a
> composition library extends its base language with its own
> assumptions and shortcuts. So, just as a programming language
> pushes you toward its programming theory of choice, a
> composition language will push you into its music theory of choice.
>
> All of that being said, it has been lamented before that the
> csound score has no concept of a measure (for example). While we
> like the idea of complete composition freedom to define our own
> models and abstractions, in practice we are using many of the
> same abstractions in an ad hoc way. Composing with measures,
> those measures usually have 4 or 8 beats, scales with repeating
> octaves where notes an octave apart are considered in some sense
> equivalent, scales with notes that are spaced in one of the
> common variations of the 7 note diatonic scale, chords built
> according to something approximating a classical / jazz / pop
> chording convention, timbres that have a strong fundamental
> pitch to them, textures defined in terms of densities of
> constituant grains and their tendencies, patterns of events that
> unfold in similar iterative ways etc. - as a few examples off
> the top of my head. While few of us follow all of these
> conventions, it is likely that most of us follow at least one,
> and a sizable percentage use many. If we value our time, and
> would desire to spend more time composing than building our
> compositional tools, there is something to be said for providing
> the most commonly used abstractions as a default (while of
> course allowing the user to ignore or replace them as desired).
>
>
> On Thu, Mar 21, 2013 at 3:58 AM, peiman khosravi
> > wrote:
>
>
>
>     On 21 March 2013 07:14, Oeyvind Brandtsegg
>          > wrote:
>
>         This is indeed an interesting discussion.
>         I'd like to be more involved, but here's my "2 cents"
>         for the moment:
>
>         I think Michael's point:
>
>         "Any efforts to develop a library of compositional
>         routines is going to
>         run into the historical and present and probably future
>         fact that
>         composers do not think alike. A fundamental problem will be
>         representing what is essential, at the lowest level of
>         musical
>         description, in such a way that different functions can
>         be composed
>         together."
>         ... is right at the heart of the problem. And it is the
>         main reason why I think some of the existing tools are
>         hard to use. Because they don't fit. I do think that any
>         system that builds from a representation of what is
>         essential up towards more complex or abstract
>         representations/ideas will simply *not fit* for many
>         composers. The actual representation chosen determining
>         who it will fit and for whom it will not work.
>         I am deeply unsure of how to make a better system, but I
>         do think it should be built the other way around:
>         deciding on a representation of what is essential for
>         the output as the last operation, not the first. This
>         wold probably make the learning curve steeper, but it
>         would also make the curve flatten out nicely when it
>         comes to solving more complex problems.  If need be, a
>         *suggested* ("optional default") representation could be
>         used to enable quick sketches and tutorials, but that
>         this representation should be highly configurable and
>         not tied to the actual manipulation of the data (the
>         compositional algorithms).
>
>
>
>     Hi Oeyvind,
>
>     Absolutely agreed. I don't think that an algorithmic system
>     should be 'intelligent' enough to understand the
>     representation of what is essential for the construction of
>     musical meaning. I don't think there should be any value
>     hierarchies in such a system. Composing on the note level
>     should be as accessible as composing on the grain level. I
>     don't want the software to 'know' what is essential because
>     I don't know what is essential: that is why I compose - to
>     find out. This is why I normally prefer tools that are not
>     musically intelligent (or at least not on the surface). I
>     have no specific solutions but it seems to me that the only
>     way to achieve some level of flatness is by thinking purely
>     in terms of sound structures, rather than musical
>     structures, when making an algorithmic system. This way the
>     system simply provides a playground, to take advantage of
>     all the control that the computer offers us. Why should an
>     algorithmic system even have a conception of what is a note,
>     what is timbre and what is grain?
>
>     P
>
>
>         Very humbly, as I said, i don't know exactly how it
>         should be done, and being very much aware that others on
>         this list have much more experience in software/language
>         design.
>         (Also of course being open to suggestions of
>         languages/systems actually working in this way)
>
>         best
>         Oeyvind
>
>
>
>         2013/3/20 Steven Yi          >
>
>             Hi Jake,
>
>             I think it's a good idea you have to try to build up
>             a library of
>             useful musical functions.  I'll certainly be happy
>             to include whatever
>             you work on with Blue to make it available to Blue
>             users out of the
>             box.
>
>             I also think MIchael's cautions are very important,
>             but your point
>             about "something that doesn't try to be all
>             encompassing, but allows
>             others to piece together their own environments"
>             seems right on the
>             money to me.  I've been spending most of my reading
>             time on Clojure
>             and Haskell literature, and function composition and
>             reuse is a big
>             concern in these communities.  I think having a
>             library for Python
>             could be very useful.
>
>             One other thing you had mentioned in looking at
>             Pgauss is that "some
>             things are already built into Python".  I've had the
>             same experience
>             in looking at Patterns in SC as well as CMask, nGen,
>             PMask, and other
>             libraries, and comparing them to built-in features
>             in Clojure (which
>             would also apply to Lisp, Scheme, Haskell, and other
>             functional
>             programming languages).  Most functional languages
>             deal heavily with
>             list processing, lazy list generation, stream
>             transformations, etc.
>             Python does do support some functional programming
>             aspects, and
>             generators are rather nice, I've found Clojure just
>             a little bit more
>             to my liking now.
>
>             I had recently been working on organizing my own
>             Python composition
>             code into a single library, but I'm now planning to
>             build up a library
>             in Clojure instead.  However, I thought I'd mention
>             that I found these
>             program/libraries useful to look at for music functions:
>
>             * Common Music
>             (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
>             * Overtone (http://overtone.github.com)
>             * Symbolic Composer (http://www.symboliccomposer.com/)
>             * OpenMusic
>             * CsoundAC (Michael's system, comes with Csound
>             installer)
>
>             Of these, I think Symbolic Composer probably has the
>             largest set of
>             functions I've come across. (I didn't see any
>             manuals viewable online,
>             but they're visible within the program.) While these
>             aren't python
>             projects, I thought they were worth mentioning.
>
>             I also took a look at the link to isobar that Peiman
>             listed and found
>             that rather interesting too.  The original project
>             (https://github.com/ideoforms/isobar) seems to have
>             quite a bit of
>             functionality implemented.
>
>             Anyways, some ramblings on from me. :)  Looking
>             forward to what comes
>             of all this and good luck with it!
>
>             steven
>
>
>             On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
>                          > wrote:
>              > Agreed.
>              >
>              > P
>              >
>              >
>              > On 20 March 2013 01:31, Jacob Joaquin
>                          > wrote:
>              >>
>              >> I'm not sure what others are looking in a Python
>             library for Csound,
>              >> but my personal focus is on creating a
>             streamlined interface to the
>              >> Csound score for easily generating score events,
>             and then have
>              >> multiple libraries for different intended uses.
>             So something that
>              >> doesn't try to be all encompassing, but allows
>             others to piece
>              >> together their own environments either from
>             importing existing
>              >> libraries, or creating their own custom set of
>             functions. Will every
>              >> library be interoperable, no. Will it be better
>             than having all these
>              >> independent score generators that don't work
>             together at all, big yes.
>              >>
>              >> For example, I installed Music21 (which is
>             awesome btw so thanks for
>              >> the suggestion) and had it working with Python
>             Score. But then it
>              >> broke and broke badly and it isn't working, but
>             I was close to having
>              >> a Bach piece in MusicXML converted into Csound
>             score events.
>              >>
>              >> Best,
>              >> Jake
>              >>
>              >> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>              >>              > wrote:
>              >> > Regarding athenaCL, it was not designed for
>             scripting, but for
>              >> > interaction with the composer via the command
>             line, resulting in
>              >> > pieces created by interactively issuing a
>             series of commands in a
>              >> > session. It is possible to script the system
>             to some extent, but this
>              >> > is not well documented or that easy to do.
>              >> >
>              >> > Christopher Ariza, the author of athenaCL, now
>             seems to be extensively
>              >> > involved with music21, which deserves its own
>             consideration by
>              >> > composers.
>              >> >
>              >> > http://mit.edu/music21/
>              >> >
>              >> > Any efforts to develop a library of
>             compositional routines is going to
>              >> > run into the historical and present and
>             probably future fact that
>              >> > composers do not think alike. A fundamental
>             problem will be
>              >> > representing what is essential, at the lowest
>             level of musical
>              >> > description, in such a way that different
>             functions can be composed
>              >> > together.
>              >> >
>              >> > This is a problem that has been considered,
>             and partly solved, by my
>              >> > system CsoundAC (where both musical notes and
>             chords are vectors in
>              >> > spaces and can be composed with techniques
>             borrowed from computer
>              >> > graphics), by Rubato Composer which takes a
>             somewhat similar but
>              >> > mathematically more sophisticated approach
>             based on category theory
>              >> > and understanding the types of algebras
>             involved in working with
>              >> > musical notes and scores, and of course those
>             systems that are more or
>              >> > less based on MIDI semantics, although this of
>             course is quite
>              >> > limiting. Also take a look at OpenMusic, which
>             seems to have its own
>              >> > mathematical basis though I don't think I
>             understand just what it is,
>              >> > and of course Grace (which sprang more or less
>             fully formed from the
>              >> > forehead of Common Music).
>              >> >
>              >> > The kind of difficulty that you can anticipate
>             will be like this: What
>              >> > is pitch? Depends on the kind of piece you
>             want to make. But to get a
>              >> > SYSTEM going you need a basic representation
>             of pitch that is amenable
>              >> > to mathematical manipulation and that can
>             easily be translated back
>              >> > forth from the more specific notions of pitch
>             used in actual pieces. I
>              >> > think it should be MIDI note number only
>             allowing fractional values
>              >> > for fractional pitches and variant scales, but
>             lots of people just
>              >> > assume it should be integers standing for
>             scale degree. Getting
>              >> > composers to agree on something so basic is
>             like herding cats... no,
>              >> > worse than herding cats.
>              >> >
>              >> > Regards,
>              >> > Mike
>              >> >
>              >> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure
>             >
>             wrote:
>              >> >>
>              >> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>              >> >>
>              >> >>> What Csound-Python tools currently exist?
>             I'm aware of CsoundAC,
>              >> >>> PMask, Blue, the opcodes, and Python Score.
>              >> >>
>              >> >> christopher ariza's athenaCL is written in
>             python, and outputs several
>              >> >> formats, csound score among them:
>              >> >>
>              >> >> "The athenaCL system is an open-source,
>             object-oriented composition
>              >> >> tool
>              >> >> written in Python. The system can be scripted
>             and embedded, and
>              >> >> includes
>              >> >> integrated instrument libraries, post-tonal
>             and microtonal pitch
>              >> >> modeling
>              >> >> tools, multiple-format graphical outputs, and
>             musical output in Csound,
>              >> >> SuperCollider, Pure Data, MIDI, audio file,
>             XML, and text formats."
>              >> >>
>              >> >> (http://code.google.com/p/athenacl/)
>              >> >>
>              >> >> i think it's a great idea to coordinate a
>             collective effort to develop
>              >> >> a
>              >> >> library of functions to generate events for
>             the csound score. i'm
>              >> >> trying
>              >> >> to teach myself a little python, it would be
>             fun to (try to) contribute
>              >> >> to
>              >> >> the project. i'll have to look closer at
>             pysco, jacob!
>              >> >>
>              >> >> best,
>              >> >>
>              >> >>
>              >> >> lj
>              >> >>
>              >> >>
>              >> >> Send bugs reports to the Sourceforge bug tracker
>              >> >>
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>             
>              >> >> Discussions of bugs and features can be
>             posted here
>              >> >> 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 the Sourceforge bug tracker
>              >> >
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>             
>              >> > Discussions of bugs and features can be posted
>             here
>              >> > To unsubscribe, send email
>             sympa@lists.bath.ac.uk
>              with body "unsubscribe
>              >> > csound"
>              >> >
>              >>
>              >>
>              >>
>              >> --
>              >> codehop.com  | #code #art #music
>              >>
>              >>
>              >> Send bugs reports to the Sourceforge bug tracker
>              >>
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>             
>              >> Discussions of bugs and features can be posted here
>              >> To unsubscribe, send email
>             sympa@lists.bath.ac.uk
>              with body "unsubscribe
>              >> csound"
>              >>
>              >
>
>
>             Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>             
>             Discussions of bugs and features can be posted here
>             To unsubscribe, send email sympa@lists.bath.ac.uk
>              with body
>             "unsubscribe csound"
>
>
>
>
>         --
>
>         Oeyvind Brandtsegg
>         Professor of Music Technology
>         NTNU
>         7491 Trondheim
>         Norway
>         Cell: +47 92 203 205 
>
>         http://flyndresang.no/
>         http://www.partikkelaudio.com/
>         http://soundcloud.com/brandtsegg
>         http://soundcloud.com/t-emp
>
>
>

Date2013-03-23 02:12
FromJacob Joaquin
SubjectRe: Re: [Csnd] Csound and Python: What Exists and Would Csounders
As of yesterday, Python Score supports mixed meter in a Csound score.
This example mixes 3/4, 4/4, 7/4 and 3/8.

Code:
https://github.com/jacobjoaquin/csd/blob/master/demo/pysco/mixed_meter.csd

Audio:
https://soundcloud.com/jacobjoaquin/csound-python-score




On Fri, Mar 22, 2013 at 6:24 PM, Robert or Gretchen Foose
 wrote:
> plus one to this post.  Over the past few years, a lot of effort has gone
> into making csound productively accessible to beginners.  Having background
> in 'traditional' methods of approaching composition, I like the idea of at
> least having quick access to csound through a more traditional approach to
> the score. (It is, after all, called a 'score' isn't it?)  But I also don't
> want to be locked into four beat measures, eight measure phrases, etc.  I've
> dumped a lot of software sequencers from my machine simply because they
> didn't let me subdivide my beats into triplets!  So, by all means, keep
> everything as open ended as possible.  Even though it's a pain in the butt,
> you can use a spreadsheet for creating scores if you feel too restricted by
> more traditional thought processes.
> I'll probably continue to use this approach somewhat anyway.
> Bob
>
> On 13:59, Justin Smith wrote:
>>
>> Traditionally, even in pure programming contexts, the set of
>> tools provided is in some way curated in order to cultivate
>> specific conceptual models. One can program functionally in C,
>> declaratively in javascript, in an object oriented manner in
>> forth, or imperatively in haskell, but the language in each case
>> will put up a fight, and a path of least resistance guides the
>> user to a language's preferred approach.
>>
>> Since any library implements an extension to the language, a
>> composition library extends its base language with its own
>> assumptions and shortcuts. So, just as a programming language
>> pushes you toward its programming theory of choice, a
>> composition language will push you into its music theory of choice.
>>
>> All of that being said, it has been lamented before that the
>> csound score has no concept of a measure (for example). While we
>> like the idea of complete composition freedom to define our own
>> models and abstractions, in practice we are using many of the
>> same abstractions in an ad hoc way. Composing with measures,
>> those measures usually have 4 or 8 beats, scales with repeating
>> octaves where notes an octave apart are considered in some sense
>> equivalent, scales with notes that are spaced in one of the
>> common variations of the 7 note diatonic scale, chords built
>> according to something approximating a classical / jazz / pop
>> chording convention, timbres that have a strong fundamental
>> pitch to them, textures defined in terms of densities of
>> constituant grains and their tendencies, patterns of events that
>> unfold in similar iterative ways etc. - as a few examples off
>> the top of my head. While few of us follow all of these
>> conventions, it is likely that most of us follow at least one,
>> and a sizable percentage use many. If we value our time, and
>> would desire to spend more time composing than building our
>> compositional tools, there is something to be said for providing
>> the most commonly used abstractions as a default (while of
>> course allowing the user to ignore or replace them as desired).
>>
>>
>> On Thu, Mar 21, 2013 at 3:58 AM, peiman khosravi
>> > wrote:
>>
>>
>>
>>     On 21 March 2013 07:14, Oeyvind Brandtsegg
>>     >     > wrote:
>>
>>         This is indeed an interesting discussion.
>>         I'd like to be more involved, but here's my "2 cents"
>>         for the moment:
>>
>>         I think Michael's point:
>>
>>         "Any efforts to develop a library of compositional
>>         routines is going to
>>         run into the historical and present and probably future
>>         fact that
>>         composers do not think alike. A fundamental problem will be
>>         representing what is essential, at the lowest level of
>>         musical
>>         description, in such a way that different functions can
>>         be composed
>>         together."
>>         ... is right at the heart of the problem. And it is the
>>         main reason why I think some of the existing tools are
>>         hard to use. Because they don't fit. I do think that any
>>         system that builds from a representation of what is
>>         essential up towards more complex or abstract
>>         representations/ideas will simply *not fit* for many
>>         composers. The actual representation chosen determining
>>         who it will fit and for whom it will not work.
>>         I am deeply unsure of how to make a better system, but I
>>         do think it should be built the other way around:
>>         deciding on a representation of what is essential for
>>         the output as the last operation, not the first. This
>>         wold probably make the learning curve steeper, but it
>>         would also make the curve flatten out nicely when it
>>         comes to solving more complex problems.  If need be, a
>>         *suggested* ("optional default") representation could be
>>         used to enable quick sketches and tutorials, but that
>>         this representation should be highly configurable and
>>         not tied to the actual manipulation of the data (the
>>         compositional algorithms).
>>
>>
>>
>>     Hi Oeyvind,
>>
>>     Absolutely agreed. I don't think that an algorithmic system
>>     should be 'intelligent' enough to understand the
>>     representation of what is essential for the construction of
>>     musical meaning. I don't think there should be any value
>>     hierarchies in such a system. Composing on the note level
>>     should be as accessible as composing on the grain level. I
>>     don't want the software to 'know' what is essential because
>>     I don't know what is essential: that is why I compose - to
>>     find out. This is why I normally prefer tools that are not
>>     musically intelligent (or at least not on the surface). I
>>     have no specific solutions but it seems to me that the only
>>     way to achieve some level of flatness is by thinking purely
>>     in terms of sound structures, rather than musical
>>     structures, when making an algorithmic system. This way the
>>     system simply provides a playground, to take advantage of
>>     all the control that the computer offers us. Why should an
>>     algorithmic system even have a conception of what is a note,
>>     what is timbre and what is grain?
>>
>>     P
>>
>>
>>         Very humbly, as I said, i don't know exactly how it
>>         should be done, and being very much aware that others on
>>         this list have much more experience in software/language
>>         design.
>>         (Also of course being open to suggestions of
>>         languages/systems actually working in this way)
>>
>>         best
>>         Oeyvind
>>
>>
>>
>>         2013/3/20 Steven Yi >         >
>>
>>             Hi Jake,
>>
>>             I think it's a good idea you have to try to build up
>>             a library of
>>             useful musical functions.  I'll certainly be happy
>>             to include whatever
>>             you work on with Blue to make it available to Blue
>>             users out of the
>>             box.
>>
>>             I also think MIchael's cautions are very important,
>>             but your point
>>             about "something that doesn't try to be all
>>             encompassing, but allows
>>             others to piece together their own environments"
>>             seems right on the
>>             money to me.  I've been spending most of my reading
>>             time on Clojure
>>             and Haskell literature, and function composition and
>>             reuse is a big
>>             concern in these communities.  I think having a
>>             library for Python
>>             could be very useful.
>>
>>             One other thing you had mentioned in looking at
>>             Pgauss is that "some
>>             things are already built into Python".  I've had the
>>             same experience
>>             in looking at Patterns in SC as well as CMask, nGen,
>>             PMask, and other
>>             libraries, and comparing them to built-in features
>>             in Clojure (which
>>             would also apply to Lisp, Scheme, Haskell, and other
>>             functional
>>             programming languages).  Most functional languages
>>             deal heavily with
>>             list processing, lazy list generation, stream
>>             transformations, etc.
>>             Python does do support some functional programming
>>             aspects, and
>>             generators are rather nice, I've found Clojure just
>>             a little bit more
>>             to my liking now.
>>
>>             I had recently been working on organizing my own
>>             Python composition
>>             code into a single library, but I'm now planning to
>>             build up a library
>>             in Clojure instead.  However, I thought I'd mention
>>             that I found these
>>             program/libraries useful to look at for music functions:
>>
>>             * Common Music
>>             (http://commonmusic.sourceforge.net/cm/res/doc/cm.html)
>>             * Overtone (http://overtone.github.com)
>>             * Symbolic Composer (http://www.symboliccomposer.com/)
>>             * OpenMusic
>>             * CsoundAC (Michael's system, comes with Csound
>>             installer)
>>
>>             Of these, I think Symbolic Composer probably has the
>>             largest set of
>>             functions I've come across. (I didn't see any
>>             manuals viewable online,
>>             but they're visible within the program.) While these
>>             aren't python
>>             projects, I thought they were worth mentioning.
>>
>>             I also took a look at the link to isobar that Peiman
>>             listed and found
>>             that rather interesting too.  The original project
>>             (https://github.com/ideoforms/isobar) seems to have
>>             quite a bit of
>>             functionality implemented.
>>
>>             Anyways, some ramblings on from me. :)  Looking
>>             forward to what comes
>>             of all this and good luck with it!
>>
>>             steven
>>
>>
>>             On Wed, Mar 20, 2013 at 8:51 AM, peiman khosravi
>>             >             > wrote:
>>              > Agreed.
>>              >
>>              > P
>>              >
>>              >
>>              > On 20 March 2013 01:31, Jacob Joaquin
>>             >             > wrote:
>>              >>
>>              >> I'm not sure what others are looking in a Python
>>             library for Csound,
>>              >> but my personal focus is on creating a
>>             streamlined interface to the
>>              >> Csound score for easily generating score events,
>>             and then have
>>              >> multiple libraries for different intended uses.
>>             So something that
>>              >> doesn't try to be all encompassing, but allows
>>             others to piece
>>              >> together their own environments either from
>>             importing existing
>>              >> libraries, or creating their own custom set of
>>             functions. Will every
>>              >> library be interoperable, no. Will it be better
>>             than having all these
>>              >> independent score generators that don't work
>>             together at all, big yes.
>>              >>
>>              >> For example, I installed Music21 (which is
>>             awesome btw so thanks for
>>              >> the suggestion) and had it working with Python
>>             Score. But then it
>>              >> broke and broke badly and it isn't working, but
>>             I was close to having
>>              >> a Bach piece in MusicXML converted into Csound
>>             score events.
>>              >>
>>              >> Best,
>>              >> Jake
>>              >>
>>              >> On Tue, Mar 19, 2013 at 3:57 PM, Michael Gogins
>>              >> >             > wrote:
>>              >> > Regarding athenaCL, it was not designed for
>>             scripting, but for
>>              >> > interaction with the composer via the command
>>             line, resulting in
>>              >> > pieces created by interactively issuing a
>>             series of commands in a
>>              >> > session. It is possible to script the system
>>             to some extent, but this
>>              >> > is not well documented or that easy to do.
>>              >> >
>>              >> > Christopher Ariza, the author of athenaCL, now
>>             seems to be extensively
>>              >> > involved with music21, which deserves its own
>>             consideration by
>>              >> > composers.
>>              >> >
>>              >> > http://mit.edu/music21/
>>              >> >
>>              >> > Any efforts to develop a library of
>>             compositional routines is going to
>>              >> > run into the historical and present and
>>             probably future fact that
>>              >> > composers do not think alike. A fundamental
>>             problem will be
>>              >> > representing what is essential, at the lowest
>>             level of musical
>>              >> > description, in such a way that different
>>             functions can be composed
>>              >> > together.
>>              >> >
>>              >> > This is a problem that has been considered,
>>             and partly solved, by my
>>              >> > system CsoundAC (where both musical notes and
>>             chords are vectors in
>>              >> > spaces and can be composed with techniques
>>             borrowed from computer
>>              >> > graphics), by Rubato Composer which takes a
>>             somewhat similar but
>>              >> > mathematically more sophisticated approach
>>             based on category theory
>>              >> > and understanding the types of algebras
>>             involved in working with
>>              >> > musical notes and scores, and of course those
>>             systems that are more or
>>              >> > less based on MIDI semantics, although this of
>>             course is quite
>>              >> > limiting. Also take a look at OpenMusic, which
>>             seems to have its own
>>              >> > mathematical basis though I don't think I
>>             understand just what it is,
>>              >> > and of course Grace (which sprang more or less
>>             fully formed from the
>>              >> > forehead of Common Music).
>>              >> >
>>              >> > The kind of difficulty that you can anticipate
>>             will be like this: What
>>              >> > is pitch? Depends on the kind of piece you
>>             want to make. But to get a
>>              >> > SYSTEM going you need a basic representation
>>             of pitch that is amenable
>>              >> > to mathematical manipulation and that can
>>             easily be translated back
>>              >> > forth from the more specific notions of pitch
>>             used in actual pieces. I
>>              >> > think it should be MIDI note number only
>>             allowing fractional values
>>              >> > for fractional pitches and variant scales, but
>>             lots of people just
>>              >> > assume it should be integers standing for
>>             scale degree. Getting
>>              >> > composers to agree on something so basic is
>>             like herding cats... no,
>>              >> > worse than herding cats.
>>              >> >
>>              >> > Regards,
>>              >> > Mike
>>              >> >
>>              >> > On Tue, Mar 19, 2013 at 5:13 PM, luis jure
>>             >
>>             wrote:
>>              >> >>
>>              >> >> on 2013-03-19 at 12:50 Jacob Joaquin wrote:
>>              >> >>
>>              >> >>> What Csound-Python tools currently exist?
>>             I'm aware of CsoundAC,
>>              >> >>> PMask, Blue, the opcodes, and Python Score.
>>              >> >>
>>              >> >> christopher ariza's athenaCL is written in
>>             python, and outputs several
>>              >> >> formats, csound score among them:
>>              >> >>
>>              >> >> "The athenaCL system is an open-source,
>>             object-oriented composition
>>              >> >> tool
>>              >> >> written in Python. The system can be scripted
>>             and embedded, and
>>              >> >> includes
>>              >> >> integrated instrument libraries, post-tonal
>>             and microtonal pitch
>>              >> >> modeling
>>              >> >> tools, multiple-format graphical outputs, and
>>             musical output in Csound,
>>              >> >> SuperCollider, Pure Data, MIDI, audio file,
>>             XML, and text formats."
>>              >> >>
>>              >> >> (http://code.google.com/p/athenacl/)
>>              >> >>
>>              >> >> i think it's a great idea to coordinate a
>>             collective effort to develop
>>              >> >> a
>>              >> >> library of functions to generate events for
>>             the csound score. i'm
>>              >> >> trying
>>              >> >> to teach myself a little python, it would be
>>             fun to (try to) contribute
>>              >> >> to
>>              >> >> the project. i'll have to look closer at
>>             pysco, jacob!
>>              >> >>
>>              >> >> best,
>>              >> >>
>>              >> >>
>>              >> >> lj
>>              >> >>
>>              >> >>
>>              >> >> Send bugs reports to the Sourceforge bug tracker
>>              >> >>
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>             
>>              >> >> Discussions of bugs and features can be
>>             posted here
>>              >> >> 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 the Sourceforge bug tracker
>>              >> >
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>             
>>              >> > Discussions of bugs and features can be posted
>>             here
>>              >> > To unsubscribe, send email
>>             sympa@lists.bath.ac.uk
>>              with body "unsubscribe
>>              >> > csound"
>>              >> >
>>              >>
>>              >>
>>              >>
>>              >> --
>>              >> codehop.com  | #code #art #music
>>              >>
>>              >>
>>              >> Send bugs reports to the Sourceforge bug tracker
>>              >>
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>             
>>              >> Discussions of bugs and features can be posted here
>>              >> To unsubscribe, send email
>>             sympa@lists.bath.ac.uk
>>              with body "unsubscribe
>>              >> csound"
>>              >>
>>              >
>>
>>
>>             Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>             
>>             Discussions of bugs and features can be posted here
>>             To unsubscribe, send email sympa@lists.bath.ac.uk
>>              with body
>>             "unsubscribe csound"
>>
>>
>>
>>
>>         --
>>
>>         Oeyvind Brandtsegg
>>         Professor of Music Technology
>>         NTNU
>>         7491 Trondheim
>>         Norway
>>         Cell: +47 92 203 205 
>>
>>         http://flyndresang.no/
>>         http://www.partikkelaudio.com/
>>         http://soundcloud.com/brandtsegg
>>         http://soundcloud.com/t-emp
>>
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 
codehop.com | #code #art #music