I'm not a fan of typing down-left-space over and over after changing a single
Csound score pfield. Some time ago, I wrote a Perl script that
auto-magically does the work for me. I formally started learning Python over
the weekend, and decided to port my favorite and most used Perl script, whle
making a few improvements on the way. I figure this might be useful for
others, so here it is:

scoref.zip
http://www.thumbuki.com/csound/files/mailinglist/scoref.zip

Here's an example score that displays the unaligned code alongside various
alignments using the command-line options:
http://www.thumbuki.com/csound/files/mailinglist/refactored.sco

As for the bigger picture. Scripts that refactor Csound code can be
incorporated with existing text editors. For example, I use jedit. Jedit
supports java plugins and beanshell macros.  Though I haven't done this yet,
my research leads me to believe that I will be able to create a macro that
aligns any highlighted code at the stroke of a key combo, without having to
make modifications scorerefactor.py.

In fact, I think I would only have to create a basic beanshell script that
would be able to run several command-line scripts. Another example of a
potentially useful script is a script that shifts the start times of a large
section of score code (I have a perl script for this as well).  These
scripts, along with scripts developed by others could be loosely integrated
into other editors. Perhaps QuteSound?

Food for thought, anyways.

Best,
Jake
-- 
View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24227460.html
Sent from the Csound - General mailing list archive at Nabble.com.

WOW....

Just got to check it out.  Awesome... will save TONS of time!

Would LOVE to have this incredibly useful utility added to QUTEcsound  
- and Smultron!

But even as a stand-alone - it's fantastic, easy, and super useful.

Also, I appreciate the trix you shared about the macintosh terminal in  
your readme....

pbpaste

pbcopy


COOL

Thanks Jake....

-dB


On Jun 26, 2009, at 5:21 PM, Jacob Joaquin wrote:

>
> I'm not a fan of typing down-left-space over and over after changing  
> a single
> Csound score pfield. Some time ago, I wrote a Perl script that
> auto-magically does the work for me. I formally started learning  
> Python over
> the weekend, and decided to port my favorite and most used Perl  
> script, whle
> making a few improvements on the way. I figure this might be useful  
> for
> others, so here it is:
>
> scoref.zip
> http://www.thumbuki.com/csound/files/mailinglist/scoref.zip
>
> Here's an example score that displays the unaligned code alongside  
> various
> alignments using the command-line options:
> http://www.thumbuki.com/csound/files/mailinglist/refactored.sco
>
> As for the bigger picture. Scripts that refactor Csound code can be
> incorporated with existing text editors. For example, I use jedit.  
> Jedit
> supports java plugins and beanshell macros.  Though I haven't done  
> this yet,
> my research leads me to believe that I will be able to create a  
> macro that
> aligns any highlighted code at the stroke of a key combo, without  
> having to
> make modifications scorerefactor.py.
>
> In fact, I think I would only have to create a basic beanshell  
> script that
> would be able to run several command-line scripts. Another example  
> of a
> potentially useful script is a script that shifts the start times of  
> a large
> section of score code (I have a perl script for this as well).  These
> scripts, along with scripts developed by others could be loosely  
> integrated
> into other editors. Perhaps QuteSound?
>
> Food for thought, anyways.
>
> Best,
> Jake
> -- 
> View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24227460.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Thanks everyone for the feedback.  The align script is only a rough draft. 
One of my goals is to create a general purpose Python module for Csound
score processing.

I can use your help.  What types of score processing features would you like
to see?  I may not be able to implement everything, but at least these
suggestions will help me identify useful methods that can be reused in the
construction of various score processors, and help others write their own
processing scripts without having to reinventing the wheel.

Here's an example of what might be a useful script for someone; A script
that converts identical pfield values in proceeding score lines to periods:

i 1 0 1 1.0 440
i 1 0 1 1.0 440
i 1 0 1 1.0 220
i 1 0 1 1.0 220

becomes

i 1 0 1 1.0 440
i 1 1 . .   .
i 1 2 . .   220
i 1 3 . .   .

A script like this could also work in the opposite direction, converting
periods to values. Just let me know. I'm going to be doing this all weekend.

Best,
Jake



csounder wrote:
> 
> WOW....
> 
> Just got to check it out.  Awesome... will save TONS of time!
> 
> Would LOVE to have this incredibly useful utility added to QUTEcsound  
> - and Smultron!
> 
> But even as a stand-alone - it's fantastic, easy, and super useful.
> 
> Also, I appreciate the trix you shared about the macintosh terminal in  
> your readme....
> 
> pbpaste
> 
> pbcopy
> 
> 
> COOL
> 
> Thanks Jake....
> 
> -dB
> 
> 
> On Jun 26, 2009, at 5:21 PM, Jacob Joaquin wrote:
> 
>>
>> I'm not a fan of typing down-left-space over and over after changing  
>> a single
>> Csound score pfield. Some time ago, I wrote a Perl script that
>> auto-magically does the work for me. I formally started learning  
>> Python over
>> the weekend, and decided to port my favorite and most used Perl  
>> script, whle
>> making a few improvements on the way. I figure this might be useful  
>> for
>> others, so here it is:
>>
>> scoref.zip
>> http://www.thumbuki.com/csound/files/mailinglist/scoref.zip
>>
>> Here's an example score that displays the unaligned code alongside  
>> various
>> alignments using the command-line options:
>> http://www.thumbuki.com/csound/files/mailinglist/refactored.sco
>>
>> As for the bigger picture. Scripts that refactor Csound code can be
>> incorporated with existing text editors. For example, I use jedit.  
>> Jedit
>> supports java plugins and beanshell macros.  Though I haven't done  
>> this yet,
>> my research leads me to believe that I will be able to create a  
>> macro that
>> aligns any highlighted code at the stroke of a key combo, without  
>> having to
>> make modifications scorerefactor.py.
>>
>> In fact, I think I would only have to create a basic beanshell  
>> script that
>> would be able to run several command-line scripts. Another example  
>> of a
>> potentially useful script is a script that shifts the start times of  
>> a large
>> section of score code (I have a perl script for this as well).  These
>> scripts, along with scripts developed by others could be loosely  
>> integrated
>> into other editors. Perhaps QuteSound?
>>
>> Food for thought, anyways.
>>
>> Best,
>> Jake
>> -- 
>> View this message in context:
>> http://www.nabble.com/Score-Alignment-Utility-tp24227460p24227460.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24234262.html
Sent from the Csound - General mailing list archive at Nabble.com.

Your new feature suggested in this email would be cool.

Also... it would be nice when using ramps >  or } or random ~ to see  
the actual values chosen.

-dB

On Jun 27, 2009, at 11:59 AM, Jacob Joaquin wrote:

>
> Thanks everyone for the feedback.  The align script is only a rough  
> draft.
> One of my goals is to create a general purpose Python module for  
> Csound
> score processing.
>
> I can use your help.  What types of score processing features would  
> you like
> to see?  I may not be able to implement everything, but at least these
> suggestions will help me identify useful methods that can be reused  
> in the
> construction of various score processors, and help others write  
> their own
> processing scripts without having to reinventing the wheel.
>
> Here's an example of what might be a useful script for someone; A  
> script
> that converts identical pfield values in proceeding score lines to  
> periods:
>
> i 1 0 1 1.0 440
> i 1 0 1 1.0 440
> i 1 0 1 1.0 220
> i 1 0 1 1.0 220
>
> becomes
>
> i 1 0 1 1.0 440
> i 1 1 . .   .
> i 1 2 . .   220
> i 1 3 . .   .
>
> A script like this could also work in the opposite direction,  
> converting
> periods to values. Just let me know. I'm going to be doing this all  
> weekend.
>
> Best,
> Jake
>
>
>
> csounder wrote:
>>
>> WOW....
>>
>> Just got to check it out.  Awesome... will save TONS of time!
>>
>> Would LOVE to have this incredibly useful utility added to QUTEcsound
>> - and Smultron!
>>
>> But even as a stand-alone - it's fantastic, easy, and super useful.
>>
>> Also, I appreciate the trix you shared about the macintosh terminal  
>> in
>> your readme....
>>
>> pbpaste
>>
>> pbcopy
>>
>>
>> COOL
>>
>> Thanks Jake....
>>
>> -dB
>>
>>
>> On Jun 26, 2009, at 5:21 PM, Jacob Joaquin wrote:
>>
>>>
>>> I'm not a fan of typing down-left-space over and over after changing
>>> a single
>>> Csound score pfield. Some time ago, I wrote a Perl script that
>>> auto-magically does the work for me. I formally started learning
>>> Python over
>>> the weekend, and decided to port my favorite and most used Perl
>>> script, whle
>>> making a few improvements on the way. I figure this might be useful
>>> for
>>> others, so here it is:
>>>
>>> scoref.zip
>>> http://www.thumbuki.com/csound/files/mailinglist/scoref.zip
>>>
>>> Here's an example score that displays the unaligned code alongside
>>> various
>>> alignments using the command-line options:
>>> http://www.thumbuki.com/csound/files/mailinglist/refactored.sco
>>>
>>> As for the bigger picture. Scripts that refactor Csound code can be
>>> incorporated with existing text editors. For example, I use jedit.
>>> Jedit
>>> supports java plugins and beanshell macros.  Though I haven't done
>>> this yet,
>>> my research leads me to believe that I will be able to create a
>>> macro that
>>> aligns any highlighted code at the stroke of a key combo, without
>>> having to
>>> make modifications scorerefactor.py.
>>>
>>> In fact, I think I would only have to create a basic beanshell
>>> script that
>>> would be able to run several command-line scripts. Another example
>>> of a
>>> potentially useful script is a script that shifts the start times of
>>> a large
>>> section of score code (I have a perl script for this as well).   
>>> These
>>> scripts, along with scripts developed by others could be loosely
>>> integrated
>>> into other editors. Perhaps QuteSound?
>>>
>>> Food for thought, anyways.
>>>
>>> Best,
>>> Jake
>>> -- 
>>> View this message in context:
>>> http://www.nabble.com/Score-Alignment-Utility-tp24227460p24227460.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24234262.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

> Also... it would be nice when using ramps >  or } or random ~ to see the 
> actual values chosen.
> 
> -dB

shouldn't this functionality be provided by the API (or a command-line 
option) ? I would certainly use it.

Stef

we would all use it!  maybe we could request the feature in the next  
release.

On Jun 27, 2009, at 2:07 PM, Stéphane Rollandin wrote:

>
>> Also... it would be nice when using ramps >  or } or random ~ to  
>> see the actual values chosen.
>> -dB
>
> shouldn't this functionality be provided by the API (or a command- 
> line option) ? I would certainly use it.
>
> Stef
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

The scsort utility allows you to pipe a standard numberic score to it.  The
only issue is that it does not return a standard numeric score.  Though at
least you can get a sense of of the values.  For example:

i 1 0 0.25 100
i 1 + .    <
i 1 + .    <
i 1 + .    <
i 1 + .    1000
i 1 + .    [~ * 1000 + 2000]
i 1 + .    [~ * 1000 + 2000]
i 1 + .    [~ * 1000 + 2000]
i 1 + .    100
i 1 + .    ~
i 1 + .    ~
i 1 + .    ~
i 1 + .    1000
i 1 + .    pp3
i 1 + .    0.222

will be translated into:

w 0 60
i 1 0.000000 0.000000 0.250000 0.250000 100
i 1 0.250000 0.250000 0.250000 0.250000 325.000000
i 1 0.500000 0.500000 0.250000 0.250000 550.000000
i 1 0.750000 0.750000 0.250000 0.250000 775.000000
i 1 1.000000 1.000000 0.250000 0.250000 1000
i 1 1.250000 1.250000 0.250000 0.250000 2526.244873
i 1 1.500000 1.500000 0.250000 0.250000 2162.524902
i 1 1.750000 1.750000 0.250000 0.250000 2697.484375
i 1 2.000000 2.000000 0.250000 0.250000 100
i 1 2.250000 2.250000 0.250000 0.250000 181.801468
i 1 2.500000 2.500000 0.250000 0.250000 829.774414
i 1 2.750000 2.750000 0.250000 0.250000 177.975800
i 1 3.000000 3.000000 0.250000 0.250000 1000
i 1 3.250000 3.250000 0.250000 0.250000 0.25
i 1 3.500000 3.500000 0.250000 0.250000 0.222

As far as I can tell, you have to pipe in the info, like this:

$ cat score.sco | scsort

Best,
jake



csounder wrote:
> 
> we would all use it!  maybe we could request the feature in the next  
> release.
> 
> On Jun 27, 2009, at 2:07 PM, Stéphane Rollandin wrote:
> 
>>
>>> Also... it would be nice when using ramps >  or } or random ~ to  
>>> see the actual values chosen.
>>> -dB
>>
>> shouldn't this functionality be provided by the API (or a command- 
>> line option) ? I would certainly use it.
>>
>> Stef
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 

-- 
View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24235796.html
Sent from the Csound - General mailing list archive at Nabble.com.

> The scsort utility allows you to pipe a standard numberic score to it.  The
> only issue is that it does not return a standard numeric score. 

yes, I'm aware of it. but as you say, it does not return a standard 
numeric score. at times the second/third columns and fourth/fifth ones 
are exactly identical, in some other cases they are different (although 
I don't have an example at hand). I have never found a description of 
this format so I don't know in which cases one can just remove the third 
and fifth columns and get the sorted score.

Stef

Hi Stef, All,
Excellent idea.
IMO, it is better to keep it independent until the API is made  
generally accessible.
If it is locked into the API then it will not be accessible to those  
who use the most current version of python.

David.

On 28/06/2009, at 4:07 AM, Stéphane Rollandin wrote:

>
> shouldn't this functionality be provided by the API (or a command- 
> line option) ? I would certainly use it.
>

What do you mean? Should we move to Python 2.6?

Victor

----- Original Message ----- 
From: "DavidW" 
To: 
Sent: Saturday, June 27, 2009 11:37 PM
Subject: [Csnd] Re: Re: Re: Re: Score Alignment Utility


Hi Stef, All,
Excellent idea.
IMO, it is better to keep it independent until the API is made
generally accessible.
If it is locked into the API then it will not be accessible to those
who use the most current version of python.

David.

On 28/06/2009, at 4:07 AM, Stéphane Rollandin wrote:

>
> shouldn't this functionality be provided by the API (or a command- line 
> option) ? I would certainly use it.
>



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

On 28/06/2009, at 9:23 AM, victor wrote:

> What do you mean? Should we move to Python 2.6?


Sorry if I wasn't clear. I'm not saying anything different to what I  
was saying on the dev-list for a couple of years. Maybe the issue is  
still discussed there; I don't know, I stopped reading it some time ago.

Python APIs are useful for different reasons, including compositional/ 
sonification/exhibtion etc etc (*), and in such application, csound is  
just another API whose explicit purpose is the synthesis/processing of  
sound. Other extensions include interfaces to 3 or 4 different  
database types, fast multidimensional array processing, graphical  
output, GUI, network applications, etc etc for all of which developers  
maintain versions that use eggs or at least easy_install that compile/ 
install dependent on the _users_ version of python (within some  
backwards-compatibility window).

Csound python API is a library _extension_ of python so in the general- 
to-specific usage model outlined above, it makes sense to ensure it  
independent of (or as easily compilable for) any particular version of  
python.  At the moment the interaction between csound and SCons seems  
to require some 'hand nursing' to produce an API for particular  
version of python and so if you want to integrate csound into your  
work you're restricted to the use of versions of python for which that  
nursing has been effected. Or if you're using an older version of  
python, you don't have access to the latest csound additions.

IMO, that limitation is a debilitating one and limits the potential  
user base of csound;  most (serious) python users (a considerably  
larger user base than that of csound) simply will not entertain using  
csound while that limitation applied. Thankfully there are other  
alternatives, which, while they may not be as comprehensive as csound,  
are not dependent in the manner described.

So, in short my answer to

>  Should we move to Python 2.6?


is that it doesn't matter. Most python users who maintain a body of  
code are probably already testing against v3.
The solution must lie in the domain of generalising the build process.

D.

(*) Limiting music with computers to _sound_, will ensure it continues  
to suffer from the same problems that all Cartesian models do.


________________________________________________
David Worrall.
- Experimental Polymedia:	worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au

Regarding versions, has anyone any code using csound via ctypes? I'm
curious as to performance. I used a similar type of thing for Java
called JNA but found the performance too slow at the time compared to
SWIG Java binding to Csound, but ctypes may be more optimized. If so,
that may allow at least a separate option.

On 6/27/09, DavidW  wrote:
> On 28/06/2009, at 9:23 AM, victor wrote:
>
>> What do you mean? Should we move to Python 2.6?
>
>
> Sorry if I wasn't clear. I'm not saying anything different to what I
> was saying on the dev-list for a couple of years. Maybe the issue is
> still discussed there; I don't know, I stopped reading it some time ago.
>
> Python APIs are useful for different reasons, including compositional/
> sonification/exhibtion etc etc (*), and in such application, csound is
> just another API whose explicit purpose is the synthesis/processing of
> sound. Other extensions include interfaces to 3 or 4 different
> database types, fast multidimensional array processing, graphical
> output, GUI, network applications, etc etc for all of which developers
> maintain versions that use eggs or at least easy_install that compile/
> install dependent on the _users_ version of python (within some
> backwards-compatibility window).
>
> Csound python API is a library _extension_ of python so in the general-
> to-specific usage model outlined above, it makes sense to ensure it
> independent of (or as easily compilable for) any particular version of
> python.  At the moment the interaction between csound and SCons seems
> to require some 'hand nursing' to produce an API for particular
> version of python and so if you want to integrate csound into your
> work you're restricted to the use of versions of python for which that
> nursing has been effected. Or if you're using an older version of
> python, you don't have access to the latest csound additions.
>
> IMO, that limitation is a debilitating one and limits the potential
> user base of csound;  most (serious) python users (a considerably
> larger user base than that of csound) simply will not entertain using
> csound while that limitation applied. Thankfully there are other
> alternatives, which, while they may not be as comprehensive as csound,
> are not dependent in the manner described.
>
> So, in short my answer to
>
>>  Should we move to Python 2.6?
>
>
> is that it doesn't matter. Most python users who maintain a body of
> code are probably already testing against v3.
> The solution must lie in the domain of generalising the build process.
>
> D.
>
> (*) Limiting music with computers to _sound_, will ensure it continues
> to suffer from the same problems that all Cartesian models do.
>
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:	worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

-- 
Sent from my mobile device

another great trick.... Jake, it would be cool to have some of the  
manual - maybe under the scsort utilities page?
On Jun 27, 2009, at 3:06 PM, Jacob Joaquin wrote:

>
> The scsort utility allows you to pipe a standard numberic score to  
> it.  The
> only issue is that it does not return a standard numeric score.   
> Though at
> least you can get a sense of of the values.  For example:
>
> i 1 0 0.25 100
> i 1 + .    <
> i 1 + .    <
> i 1 + .    <
> i 1 + .    1000
> i 1 + .    [~ * 1000 + 2000]
> i 1 + .    [~ * 1000 + 2000]
> i 1 + .    [~ * 1000 + 2000]
> i 1 + .    100
> i 1 + .    ~
> i 1 + .    ~
> i 1 + .    ~
> i 1 + .    1000
> i 1 + .    pp3
> i 1 + .    0.222
>
> will be translated into:
>
> w 0 60
> i 1 0.000000 0.000000 0.250000 0.250000 100
> i 1 0.250000 0.250000 0.250000 0.250000 325.000000
> i 1 0.500000 0.500000 0.250000 0.250000 550.000000
> i 1 0.750000 0.750000 0.250000 0.250000 775.000000
> i 1 1.000000 1.000000 0.250000 0.250000 1000
> i 1 1.250000 1.250000 0.250000 0.250000 2526.244873
> i 1 1.500000 1.500000 0.250000 0.250000 2162.524902
> i 1 1.750000 1.750000 0.250000 0.250000 2697.484375
> i 1 2.000000 2.000000 0.250000 0.250000 100
> i 1 2.250000 2.250000 0.250000 0.250000 181.801468
> i 1 2.500000 2.500000 0.250000 0.250000 829.774414
> i 1 2.750000 2.750000 0.250000 0.250000 177.975800
> i 1 3.000000 3.000000 0.250000 0.250000 1000
> i 1 3.250000 3.250000 0.250000 0.250000 0.25
> i 1 3.500000 3.500000 0.250000 0.250000 0.222
>
> As far as I can tell, you have to pipe in the info, like this:
>
> $ cat score.sco | scsort
>
> Best,
> jake
>
>
>
> csounder wrote:
>>
>> we would all use it!  maybe we could request the feature in the next
>> release.
>>
>> On Jun 27, 2009, at 2:07 PM, Stéphane Rollandin wrote:
>>
>>>
>>>> Also... it would be nice when using ramps >  or } or random ~ to
>>>> see the actual values chosen.
>>>> -dB
>>>
>>> shouldn't this functionality be provided by the API (or a command-
>>> line option) ? I would certainly use it.
>>>
>>> Stef
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>
> -- 
> View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24235796.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Hi Stephen,
I asked about this on 3 June and Michael replied on same date:

http://www.nabble.com/Python-API-to23838459.html#a23851302

David.

On 28/06/2009, at 2:27 PM, Steven Yi wrote:

> Regarding versions, has anyone any code using csound via ctypes? I'm
> curious as to performance. I used a similar type of thing for Java
> called JNA but found the performance too slow at the time compared to
> SWIG Java binding to Csound, but ctypes may be more optimized. If so,
> that may allow at least a separate option.
>
> On 6/27/09, DavidW  wrote:
>> On 28/06/2009, at 9:23 AM, victor wrote:
>>
>>> What do you mean? Should we move to Python 2.6?
>>
>>
>> Sorry if I wasn't clear. I'm not saying anything different to what I
>> was saying on the dev-list for a couple of years. Maybe the issue is
>> still discussed there; I don't know, I stopped reading it some time  
>> ago.
>>
>> Python APIs are useful for different reasons, including  
>> compositional/
>> sonification/exhibtion etc etc (*), and in such application, csound  
>> is
>> just another API whose explicit purpose is the synthesis/processing  
>> of
>> sound. Other extensions include interfaces to 3 or 4 different
>> database types, fast multidimensional array processing, graphical
>> output, GUI, network applications, etc etc for all of which  
>> developers
>> maintain versions that use eggs or at least easy_install that  
>> compile/
>> install dependent on the _users_ version of python (within some
>> backwards-compatibility window).
>>
>> Csound python API is a library _extension_ of python so in the  
>> general-
>> to-specific usage model outlined above, it makes sense to ensure it
>> independent of (or as easily compilable for) any particular version  
>> of
>> python.  At the moment the interaction between csound and SCons seems
>> to require some 'hand nursing' to produce an API for particular
>> version of python and so if you want to integrate csound into your
>> work you're restricted to the use of versions of python for which  
>> that
>> nursing has been effected. Or if you're using an older version of
>> python, you don't have access to the latest csound additions.
>>
>> IMO, that limitation is a debilitating one and limits the potential
>> user base of csound;  most (serious) python users (a considerably
>> larger user base than that of csound) simply will not entertain using
>> csound while that limitation applied. Thankfully there are other
>> alternatives, which, while they may not be as comprehensive as  
>> csound,
>> are not dependent in the manner described.
>>
>> So, in short my answer to
>>
>>> Should we move to Python 2.6?
>>
>>
>> is that it doesn't matter. Most python users who maintain a body of
>> code are probably already testing against v3.
>> The solution must lie in the domain of generalising the build  
>> process.
>>
>> D.
>>
>> (*) Limiting music with computers to _sound_, will ensure it  
>> continues
>> to suffer from the same problems that all Cartesian models do.
>>


_________________________________________________
David Worrall.
- Experimental Polymedia:	worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au

DavidW a écrit :
> If it is locked into the API then it will not be accessible to those who 
> use the most current version of python.

I'm using the Java API ... :)

Stef

And your suggestion to bring Csound in line to what you
think should be is? You need to educate us here.

Victor
----- Original Message ----- 
From: "DavidW" 
To: 
Sent: Sunday, June 28, 2009 5:14 AM
Subject: [Csnd] Re: Re: Re: Re: Re: Re: Score Alignment Utility


> On 28/06/2009, at 9:23 AM, victor wrote:
>
>> What do you mean? Should we move to Python 2.6?
>
>
> Sorry if I wasn't clear. I'm not saying anything different to what I  was 
> saying on the dev-list for a couple of years. Maybe the issue is  still 
> discussed there; I don't know, I stopped reading it some time ago.
>
> Python APIs are useful for different reasons, including compositional/ 
> sonification/exhibtion etc etc (*), and in such application, csound is 
> just another API whose explicit purpose is the synthesis/processing of 
> sound. Other extensions include interfaces to 3 or 4 different  database 
> types, fast multidimensional array processing, graphical  output, GUI, 
> network applications, etc etc for all of which developers  maintain 
> versions that use eggs or at least easy_install that compile/ install 
> dependent on the _users_ version of python (within some 
> backwards-compatibility window).
>
> Csound python API is a library _extension_ of python so in the general- 
> to-specific usage model outlined above, it makes sense to ensure it 
> independent of (or as easily compilable for) any particular version of 
> python.  At the moment the interaction between csound and SCons seems  to 
> require some 'hand nursing' to produce an API for particular  version of 
> python and so if you want to integrate csound into your  work you're 
> restricted to the use of versions of python for which that  nursing has 
> been effected. Or if you're using an older version of  python, you don't 
> have access to the latest csound additions.
>
> IMO, that limitation is a debilitating one and limits the potential  user 
> base of csound;  most (serious) python users (a considerably  larger user 
> base than that of csound) simply will not entertain using  csound while 
> that limitation applied. Thankfully there are other  alternatives, which, 
> while they may not be as comprehensive as csound,  are not dependent in 
> the manner described.
>
> So, in short my answer to
>
>>  Should we move to Python 2.6?
>
>
> is that it doesn't matter. Most python users who maintain a body of  code 
> are probably already testing against v3.
> The solution must lie in the domain of generalising the build process.
>
> D.
>
> (*) Limiting music with computers to _sound_, will ensure it continues  to 
> suffer from the same problems that all Cartesian models do.
>
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia: worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

But is it not the case that if you are using say, numpy, scipy
and wants to use python 2.2, you would not be able to use
the latest version of those modules? I can't see why Csound
is different in that respect.

Victor
----- Original Message ----- 
From: "DavidW" 
To: 
Sent: Sunday, June 28, 2009 5:14 AM
Subject: [Csnd] Re: Re: Re: Re: Re: Re: Score Alignment Utility


> On 28/06/2009, at 9:23 AM, victor wrote:
>
>> What do you mean? Should we move to Python 2.6?
>
>
> Sorry if I wasn't clear. I'm not saying anything different to what I  was 
> saying on the dev-list for a couple of years. Maybe the issue is  still 
> discussed there; I don't know, I stopped reading it some time ago.
>
> Python APIs are useful for different reasons, including compositional/ 
> sonification/exhibtion etc etc (*), and in such application, csound is 
> just another API whose explicit purpose is the synthesis/processing of 
> sound. Other extensions include interfaces to 3 or 4 different  database 
> types, fast multidimensional array processing, graphical  output, GUI, 
> network applications, etc etc for all of which developers  maintain 
> versions that use eggs or at least easy_install that compile/ install 
> dependent on the _users_ version of python (within some 
> backwards-compatibility window).
>
> Csound python API is a library _extension_ of python so in the general- 
> to-specific usage model outlined above, it makes sense to ensure it 
> independent of (or as easily compilable for) any particular version of 
> python.  At the moment the interaction between csound and SCons seems  to 
> require some 'hand nursing' to produce an API for particular  version of 
> python and so if you want to integrate csound into your  work you're 
> restricted to the use of versions of python for which that  nursing has 
> been effected. Or if you're using an older version of  python, you don't 
> have access to the latest csound additions.
>
> IMO, that limitation is a debilitating one and limits the potential  user 
> base of csound;  most (serious) python users (a considerably  larger user 
> base than that of csound) simply will not entertain using  csound while 
> that limitation applied. Thankfully there are other  alternatives, which, 
> while they may not be as comprehensive as csound,  are not dependent in 
> the manner described.
>
> So, in short my answer to
>
>>  Should we move to Python 2.6?
>
>
> is that it doesn't matter. Most python users who maintain a body of  code 
> are probably already testing against v3.
> The solution must lie in the domain of generalising the build process.
>
> D.
>
> (*) Limiting music with computers to _sound_, will ensure it continues  to 
> suffer from the same problems that all Cartesian models do.
>
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia: worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

All Python extensions made using SWIG must be used with specific
versions of Python. Since most Python extensions are in fact made
using SWIG, this is hardly uncommon. You can verify it by going to the
Python home page and looking through the catalog of extensions.

Where Csound differs from other SWIG-based extensions, perhaps, is
that we do not currently produce multiple versions of the extension
modules targetted to different versions of Python. Feel free to
contribute this to Csound, if you think it important enough.

The SWIG approach has worked extremely well for us to date. It would
be possible to move to boost::python or to ctypes, but both would
involve considerably more work. I suspect the boost::python approach
also would be harder to build and maintain.

I have Csound working with Python 2.6 on Windows, and the next Windows
release will be targetted for Python 2.6.

Regards,
Mike

On 6/28/09, DavidW  wrote:
> On 28/06/2009, at 9:23 AM, victor wrote:
>
>> What do you mean? Should we move to Python 2.6?
>
>
> Sorry if I wasn't clear. I'm not saying anything different to what I
> was saying on the dev-list for a couple of years. Maybe the issue is
> still discussed there; I don't know, I stopped reading it some time ago.
>
> Python APIs are useful for different reasons, including compositional/
> sonification/exhibtion etc etc (*), and in such application, csound is
> just another API whose explicit purpose is the synthesis/processing of
> sound. Other extensions include interfaces to 3 or 4 different
> database types, fast multidimensional array processing, graphical
> output, GUI, network applications, etc etc for all of which developers
> maintain versions that use eggs or at least easy_install that compile/
> install dependent on the _users_ version of python (within some
> backwards-compatibility window).
>
> Csound python API is a library _extension_ of python so in the general-
> to-specific usage model outlined above, it makes sense to ensure it
> independent of (or as easily compilable for) any particular version of
> python.  At the moment the interaction between csound and SCons seems
> to require some 'hand nursing' to produce an API for particular
> version of python and so if you want to integrate csound into your
> work you're restricted to the use of versions of python for which that
> nursing has been effected. Or if you're using an older version of
> python, you don't have access to the latest csound additions.
>
> IMO, that limitation is a debilitating one and limits the potential
> user base of csound;  most (serious) python users (a considerably
> larger user base than that of csound) simply will not entertain using
> csound while that limitation applied. Thankfully there are other
> alternatives, which, while they may not be as comprehensive as csound,
> are not dependent in the manner described.
>
> So, in short my answer to
>
>>  Should we move to Python 2.6?
>
>
> is that it doesn't matter. Most python users who maintain a body of
> code are probably already testing against v3.
> The solution must lie in the domain of generalising the build process.
>
> D.
>
> (*) Limiting music with computers to _sound_, will ensure it continues
> to suffer from the same problems that all Cartesian models do.
>
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:	worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


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

I might be horribly out of date because I stopped struggling with the  
API a while ago. Anyway, as I see it, there are two main tasks and a  
development process issue. I think it is unnecessarily difficult, and  
not very efficient, for one person to try to solve these build and  
distribute issues for versions, all platforms.

1. Begin with the latest versions of SCons and python. Solve the SCons  
build problems - probably on a platform by platform basis.  It's a  
while since I played with the SCons build so I can't remember the  
specifics. Anyway, you're the most experienced at the build, so I  
don't know I can add anything to what you already know.

2. Develop user downloadable "easy_install" install.py file(s) (or  
better still python eggs which pulls all the necessary stuff from the  
repository,+ the right version of numpy if the API is now dependent on  
it etc).  The user, irrespective of the version of python they have  
installed,  just types "python install.py".

3.  There needs to be a willingness to make the build process  
inclusive of more users. That is a development 'policy' issue. I've  
been there before so I won't bang on. I'd start by cleaning up what's  
downloaded. Last time I looked the csound root directory was a dog's  
breakfast to any but the most frequent visitors.  Csound already has a  
steep learning curve, so there's no reasonable reason why it should be  
made steeper by having to avoid other people's litter.  If you want  
people to share a workshop then workshop tidiness is essential.  I'd  
start by tossing out everything that is not API related and make sure  
file names reflect their functions  and platform restrictions. Boring  
stuff, I know.

D.


  On 28/06/2009, at 9:15 PM, victor wrote:

> And your suggestion to bring Csound in line to what you
> think should be is? You need to educate us here.
>
> Victor
> ----- Original Message ----- From: "DavidW" 
> To: 
> Sent: Sunday, June 28, 2009 5:14 AM
> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Score Alignment Utility
>
>
>> On 28/06/2009, at 9:23 AM, victor wrote:
>>
>>> What do you mean? Should we move to Python 2.6?
>>
>>
>> Sorry if I wasn't clear. I'm not saying anything different to what  
>> I  was saying on the dev-list for a couple of years. Maybe the  
>> issue is  still discussed there; I don't know, I stopped reading it  
>> some time ago.
>>
>> Python APIs are useful for different reasons, including  
>> compositional/ sonification/exhibtion etc etc (*), and in such  
>> application, csound is just another API whose explicit purpose is  
>> the synthesis/processing of sound. Other extensions include  
>> interfaces to 3 or 4 different  database types, fast  
>> multidimensional array processing, graphical  output, GUI, network  
>> applications, etc etc for all of which developers  maintain  
>> versions that use eggs or at least easy_install that compile/  
>> install dependent on the _users_ version of python (within some  
>> backwards-compatibility window).
>>
>> Csound python API is a library _extension_ of python so in the  
>> general- to-specific usage model outlined above, it makes sense to  
>> ensure it independent of (or as easily compilable for) any  
>> particular version of python.  At the moment the interaction  
>> between csound and SCons seems  to require some 'hand nursing' to  
>> produce an API for particular  version of python and so if you want  
>> to integrate csound into your  work you're restricted to the use of  
>> versions of python for which that  nursing has been effected. Or if  
>> you're using an older version of  python, you don't have access to  
>> the latest csound additions.
>>
>> IMO, that limitation is a debilitating one and limits the  
>> potential  user base of csound;  most (serious) python users (a  
>> considerably  larger user base than that of csound) simply will not  
>> entertain using  csound while that limitation applied. Thankfully  
>> there are other  alternatives, which, while they may not be as  
>> comprehensive as csound,  are not dependent in the manner described.
>>
>> So, in short my answer to
>>
>>> Should we move to Python 2.6?
>>
>>
>> is that it doesn't matter. Most python users who maintain a body  
>> of  code are probably already testing against v3.
>> The solution must lie in the domain of generalising the build  
>> process.
>>
>> D.
>>
>> (*) Limiting music with computers to _sound_, will ensure it  
>> continues  to suffer from the same problems that all Cartesian  
>> models do.
>>
>>
>> ________________________________________________
>> David Worrall.
>> - Experimental Polymedia: worrall.avatar.com.au
>> - Sonification: www.sonifiction.com.au
>> - Education for Financial Independence: www.mindthemarkets.com.au
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

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

On 28/06/2009, at 9:18 PM, victor wrote:

> But is it not the case that if you are using say, numpy, scipy
> and wants to use python 2.2, you would not be able to use
> the latest version of those modules? I can't see why Csound
> is different in that respect.
>
> Victor

It's probably not. You might run into problems, if you try to do that.  
I was getting carried away :-)
So if you want to use later features of, say Numpy that are python  
version dependent, you'd probably just upgrade your version of python.  
The only reason not to, would probably be because you're trying to use  
a third-party module that won't load into a later python for some  
weird reason. Which is where the regress kicks in. But in my  
experience this is quite rare. Python is quite backwards compatible  
and deprecation is usually overt, so updating your own code it is  
usually not such a big problem. There was a time, for eg, when numpy  
was called numeric and you'll find python code put there which won't  
run in the later pythons because numeric is no longer supported as a  
separate module.

D.

> ----- Original Message ----- From: "DavidW" 
> To: 
> Sent: Sunday, June 28, 2009 5:14 AM
> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Score Alignment Utility
>
>
>> On 28/06/2009, at 9:23 AM, victor wrote:
>>
>>> What do you mean? Should we move to Python 2.6?
>>
>>
>> Sorry if I wasn't clear. I'm not saying anything different to what  
>> I  was saying on the dev-list for a couple of years. Maybe the  
>> issue is  still discussed there; I don't know, I stopped reading it  
>> some time ago.
>>
>> Python APIs are useful for different reasons, including  
>> compositional/ sonification/exhibtion etc etc (*), and in such  
>> application, csound is just another API whose explicit purpose is  
>> the synthesis/processing of sound. Other extensions include  
>> interfaces to 3 or 4 different  database types, fast  
>> multidimensional array processing, graphical  output, GUI, network  
>> applications, etc etc for all of which developers  maintain  
>> versions that use eggs or at least easy_install that compile/  
>> install dependent on the _users_ version of python (within some  
>> backwards-compatibility window).
>>
>> Csound python API is a library _extension_ of python so in the  
>> general- to-specific usage model outlined above, it makes sense to  
>> ensure it independent of (or as easily compilable for) any  
>> particular version of python.  At the moment the interaction  
>> between csound and SCons seems  to require some 'hand nursing' to  
>> produce an API for particular  version of python and so if you want  
>> to integrate csound into your  work you're restricted to the use of  
>> versions of python for which that  nursing has been effected. Or if  
>> you're using an older version of  python, you don't have access to  
>> the latest csound additions.
>>
>> IMO, that limitation is a debilitating one and limits the  
>> potential  user base of csound;  most (serious) python users (a  
>> considerably  larger user base than that of csound) simply will not  
>> entertain using  csound while that limitation applied. Thankfully  
>> there are other  alternatives, which, while they may not be as  
>> comprehensive as csound,  are not dependent in the manner described.
>>
>> So, in short my answer to
>>
>>> Should we move to Python 2.6?
>>
>>
>> is that it doesn't matter. Most python users who maintain a body  
>> of  code are probably already testing against v3.
>> The solution must lie in the domain of generalising the build  
>> process.
>>
>> D.
>>
>> (*) Limiting music with computers to _sound_, will ensure it  
>> continues  to suffer from the same problems that all Cartesian  
>> models do.
>>
>>
>> ________________________________________________
>> David Worrall.
>> - Experimental Polymedia: worrall.avatar.com.au
>> - Sonification: www.sonifiction.com.au
>> - Education for Financial Independence: www.mindthemarkets.com.au
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

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

On 29/06/2009, at 1:47 AM, Michael Gogins wrote:
..
> Where Csound differs from other SWIG-based extensions, perhaps, is
> that we do not currently produce multiple versions of the extension
> modules targetted to different versions of Python. Feel free to
> contribute this to Csound, if you think it important enough.
>
Its not just a matter of importance.
I won't be contributing code to csound until the development process  
is made more inclusive.

> The SWIG approach has worked extremely well for us to date.

Maybe. Depends how you define "us". My last experience was is that it  
was mysteriously buggy under OSX.
> It would
> be possible to move to boost::python or to ctypes, but both would
> involve considerably more work. I suspect the boost::python approach
> also would be harder to build and maintain.
>
I was not recommending that. I was simply asking if anyone had  
developed an alternative to the problems exhibited by the SWIG/SCons  
process on OSX.

> I have Csound working with Python 2.6 on Windows, and the next Windows
> release will be targetted for Python 2.6.
>
lucky for 'doze users!

D.

> Regards,
> Mike
>
> On 6/28/09, DavidW  wrote:
>> On 28/06/2009, at 9:23 AM, victor wrote:
>>
>>> What do you mean? Should we move to Python 2.6?
>>
>>
>> Sorry if I wasn't clear. I'm not saying anything different to what I
>> was saying on the dev-list for a couple of years. Maybe the issue is
>> still discussed there; I don't know, I stopped reading it some time  
>> ago.
>>
>> Python APIs are useful for different reasons, including  
>> compositional/
>> sonification/exhibtion etc etc (*), and in such application, csound  
>> is
>> just another API whose explicit purpose is the synthesis/processing  
>> of
>> sound. Other extensions include interfaces to 3 or 4 different
>> database types, fast multidimensional array processing, graphical
>> output, GUI, network applications, etc etc for all of which  
>> developers
>> maintain versions that use eggs or at least easy_install that  
>> compile/
>> install dependent on the _users_ version of python (within some
>> backwards-compatibility window).
>>
>> Csound python API is a library _extension_ of python so in the  
>> general-
>> to-specific usage model outlined above, it makes sense to ensure it
>> independent of (or as easily compilable for) any particular version  
>> of
>> python.  At the moment the interaction between csound and SCons seems
>> to require some 'hand nursing' to produce an API for particular
>> version of python and so if you want to integrate csound into your
>> work you're restricted to the use of versions of python for which  
>> that
>> nursing has been effected. Or if you're using an older version of
>> python, you don't have access to the latest csound additions.
>>
>> IMO, that limitation is a debilitating one and limits the potential
>> user base of csound;  most (serious) python users (a considerably
>> larger user base than that of csound) simply will not entertain using
>> csound while that limitation applied. Thankfully there are other
>> alternatives, which, while they may not be as comprehensive as  
>> csound,
>> are not dependent in the manner described.
>>
>> So, in short my answer to
>>
>>> Should we move to Python 2.6?
>>
>>
>> is that it doesn't matter. Most python users who maintain a body of
>> code are probably already testing against v3.
>> The solution must lie in the domain of generalising the build  
>> process.
>>
>> D.
>>
>> (*) Limiting music with computers to _sound_, will ensure it  
>> continues
>> to suffer from the same problems that all Cartesian models do.
>>
>>
>> ________________________________________________
>> David Worrall.
>> - Experimental Polymedia:	worrall.avatar.com.au
>> - Sonification: www.sonifiction.com.au
>> - Education for Financial Independence: www.mindthemarkets.com.au
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

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

Csound is not user-friendly.  If developers and others in the community spent
a full year working towards improving the user-experience, while putting on
hold everything else Csound related, this would be time well spent.  People
are easily turned off the number of hoops they have to jump through -
whether its issues with Python, or just rendering a file.  Csound is
supposed to be an instrument of musical expression, not a technical hurdle.

In my humble opinion.  :)



David Worrall wrote:
> 
> I might be horribly out of date because I stopped struggling with the  
> API a while ago. Anyway, as I see it, there are two main tasks and a  
> development process issue. I think it is unnecessarily difficult, and  
> not very efficient, for one person to try to solve these build and  
> distribute issues for versions, all platforms.
> 
> 1. Begin with the latest versions of SCons and python. Solve the SCons  
> build problems - probably on a platform by platform basis.  It's a  
> while since I played with the SCons build so I can't remember the  
> specifics. Anyway, you're the most experienced at the build, so I  
> don't know I can add anything to what you already know.
> 
> 2. Develop user downloadable "easy_install" install.py file(s) (or  
> better still python eggs which pulls all the necessary stuff from the  
> repository,+ the right version of numpy if the API is now dependent on  
> it etc).  The user, irrespective of the version of python they have  
> installed,  just types "python install.py".
> 
> 3.  There needs to be a willingness to make the build process  
> inclusive of more users. That is a development 'policy' issue. I've  
> been there before so I won't bang on. I'd start by cleaning up what's  
> downloaded. Last time I looked the csound root directory was a dog's  
> breakfast to any but the most frequent visitors.  Csound already has a  
> steep learning curve, so there's no reasonable reason why it should be  
> made steeper by having to avoid other people's litter.  If you want  
> people to share a workshop then workshop tidiness is essential.  I'd  
> start by tossing out everything that is not API related and make sure  
> file names reflect their functions  and platform restrictions. Boring  
> stuff, I know.
> 
> D.
> 
> 
>   On 28/06/2009, at 9:15 PM, victor wrote:
> 
>> And your suggestion to bring Csound in line to what you
>> think should be is? You need to educate us here.
>>
>> Victor
>> ----- Original Message ----- From: "DavidW" 
>> To: 
>> Sent: Sunday, June 28, 2009 5:14 AM
>> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Score Alignment Utility
>>
>>
>>> On 28/06/2009, at 9:23 AM, victor wrote:
>>>
>>>> What do you mean? Should we move to Python 2.6?
>>>
>>>
>>> Sorry if I wasn't clear. I'm not saying anything different to what  
>>> I  was saying on the dev-list for a couple of years. Maybe the  
>>> issue is  still discussed there; I don't know, I stopped reading it  
>>> some time ago.
>>>
>>> Python APIs are useful for different reasons, including  
>>> compositional/ sonification/exhibtion etc etc (*), and in such  
>>> application, csound is just another API whose explicit purpose is  
>>> the synthesis/processing of sound. Other extensions include  
>>> interfaces to 3 or 4 different  database types, fast  
>>> multidimensional array processing, graphical  output, GUI, network  
>>> applications, etc etc for all of which developers  maintain  
>>> versions that use eggs or at least easy_install that compile/  
>>> install dependent on the _users_ version of python (within some  
>>> backwards-compatibility window).
>>>
>>> Csound python API is a library _extension_ of python so in the  
>>> general- to-specific usage model outlined above, it makes sense to  
>>> ensure it independent of (or as easily compilable for) any  
>>> particular version of python.  At the moment the interaction  
>>> between csound and SCons seems  to require some 'hand nursing' to  
>>> produce an API for particular  version of python and so if you want  
>>> to integrate csound into your  work you're restricted to the use of  
>>> versions of python for which that  nursing has been effected. Or if  
>>> you're using an older version of  python, you don't have access to  
>>> the latest csound additions.
>>>
>>> IMO, that limitation is a debilitating one and limits the  
>>> potential  user base of csound;  most (serious) python users (a  
>>> considerably  larger user base than that of csound) simply will not  
>>> entertain using  csound while that limitation applied. Thankfully  
>>> there are other  alternatives, which, while they may not be as  
>>> comprehensive as csound,  are not dependent in the manner described.
>>>
>>> So, in short my answer to
>>>
>>>> Should we move to Python 2.6?
>>>
>>>
>>> is that it doesn't matter. Most python users who maintain a body  
>>> of  code are probably already testing against v3.
>>> The solution must lie in the domain of generalising the build  
>>> process.
>>>
>>> D.
>>>
>>> (*) Limiting music with computers to _sound_, will ensure it  
>>> continues  to suffer from the same problems that all Cartesian  
>>> models do.
>>>
>>>
>>> ________________________________________________
>>> David Worrall.
>>> - Experimental Polymedia: worrall.avatar.com.au
>>> - Sonification: www.sonifiction.com.au
>>> - Education for Financial Independence: www.mindthemarkets.com.au
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
> 
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:	www.avatar.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
> Australian research affiliations:
> - Capital Markets Cooperative Research Centre: www.cmcrc.com
> - Sonic Communications Research Group:	creative.canberra.edu.au/scrg
> - MARCS Auditory Laboratories: marcs.uws.edu.au
> 
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24246351.html
Sent from the Csound - General mailing list archive at Nabble.com.

I'm coming out of first gear on this... I now remember the issue that  
tripped me last time. It was the ability to choose the python  
distribution.
from http://csound.sourceforge.net/faq.html#Q3
> Which version of Python do I need to use the Python opcodes or  
> interface?
>
...
> Mac OS X: On OS X 10.3 and 10.4, Csound uses Python 2.3 by default  
> because this is what is supplied by Apple. However, from version  
> 5.07 of Csound on, the OSX-10.4 installers also supply a Python 2.4  
> and/or Python 2.5 csnd module(s). These are installed with the  
> corresponding MacPython 2.x framework and either Apple Python or  
> MacPython may be used. Python opcodes, however, are currently only  
> linked to Apple's supplied Python 2.3 framework for all 10.3 and  
> 10.4 binary installers.
>
> For the OS X 10.5-only installers , both the Python opcodes and  
> Python csnd module are linked only with the Apple-supplied Python 2.5
>
I don't know a single regular user of python on the mac who uses this  
version. And the python developers specifically recommend against it.

see http://www.python.org/download/mac/

Does a fix for this exist yet that allows the builds on OS 10.5 to / 
Library/Frameworks/Python.framework/Versions/Current/bin/python ?

D.


On 29/06/2009, at 2:30 AM, Victor.Lazzarini@nuim.ie wrote:

> The Python API on OSX works as elsewhere, as far as I can see.
> There are no specific bugs to it, AFAIK. As far as building it,
> if you have SWIG (a reasonably recent version), it will build OK,
> without any issues.
>
> The major problem I see in building Csound is that there are lots
> of dependencies; that's not a problem with Csound itself being
> easy or not to build, but a question of having a reasonably
> complete developer's system. On Linux, this is not an issue
> as systems are generally complete and packages can be easily found
> for everything. On OSX and Windows, you need to have a
> developer's attitude to it.
>
> Victor
>
> ----- Original Message -----
> From: DavidW 
> Date: Sunday, June 28, 2009 5:20 pm
> Subject: [Csnd] Re: Building Python API (was Re: : Score Alignment  
> Utility)
> To: csound@lists.bath.ac.uk
>
> >
> > On 29/06/2009, at 1:47 AM, Michael Gogins wrote:
> > ..
> > > Where Csound differs from other SWIG-based extensions,
> > perhaps, is
> > > that we do not currently produce multiple versions of the  
> extension
> > > modules targetted to different versions of Python. Feel free to
> > > contribute this to Csound, if you think it important enough.
> > >
> > Its not just a matter of importance.
> > I won't be contributing code to csound until the development
> > process
> > is made more inclusive.
> >
> > > The SWIG approach has worked extremely well for us to date.
> >
> > Maybe. Depends how you define "us". My last experience was is
> > that it
> > was mysteriously buggy under OSX.
> > > It would
> > > be possible to move to boost::python or to ctypes, but both would
> > > involve considerably more work. I suspect the boost::python  
> approach
> > > also would be harder to build and maintain.
> > >
> > I was not recommending that. I was simply asking if anyone
> > had
> > developed an alternative to the problems exhibited by the
> > SWIG/SCons
> > process on OSX.
> >
> > > I have Csound working with Python 2.6 on Windows, and the next
> > Windows> release will be targetted for Python 2.6.
> > >
> > lucky for 'doze users!
> >
> > D.
> >
> > > Regards,
> > > Mike
> > >
> > > On 6/28/09, DavidW  wrote:
> > >> On 28/06/2009, at 9:23 AM, victor wrote:
> > >>
> > >>> What do you mean? Should we move to Python 2.6?
> > >>
> > >>
> > >> Sorry if I wasn't clear. I'm not saying anything different to
> > what I
> > >> was saying on the dev-list for a couple of years. Maybe the
> > issue is
> > >> still discussed there; I don't know, I stopped reading it
> > some time
> > >> ago.
> > >>
> > >> Python APIs are useful for different reasons, including
> > >> compositional/
> > >> sonification/exhibtion etc etc (*), and in such application,
> > csound
> > >> is
> > >> just another API whose explicit purpose is the
> > synthesis/processing
> > >> of
> > >> sound. Other extensions include interfaces to 3 or 4 different
> > >> database types, fast multidimensional array processing, graphical
> > >> output, GUI, network applications, etc etc for all of
> > which
> > >> developers
> > >> maintain versions that use eggs or at least easy_install
> > that
> > >> compile/
> > >> install dependent on the _users_ version of python (within some
> > >> backwards-compatibility window).
> > >>
> > >> Csound python API is a library _extension_ of python so in
> > the
> > >> general-
> > >> to-specific usage model outlined above, it makes sense to
> > ensure it
> > >> independent of (or as easily compilable for) any particular
> > version
> > >> of
> > >> python.  At the moment the interaction between csound
> > and SCons seems
> > >> to require some 'hand nursing' to produce an API for particular
> > >> version of python and so if you want to integrate csound into  
> your
> > >> work you're restricted to the use of versions of python for
> > which
> > >> that
> > >> nursing has been effected. Or if you're using an older
> > version of
> > >> python, you don't have access to the latest csound additions.
> > >>
> > >> IMO, that limitation is a debilitating one and limits the  
> potential
> > >> user base of csound;  most (serious) python users (a
> > considerably>> larger user base than that of csound) simply will
> > not entertain using
> > >> csound while that limitation applied. Thankfully there are other
> > >> alternatives, which, while they may not be as comprehensive
> > as
> > >> csound,
> > >> are not dependent in the manner described.
> > >>
> > >> So, in short my answer to
> > >>
> > >>> Should we move to Python 2.6?
> > >>
> > >>
> > >> is that it doesn't matter. Most python users who maintain a
> > body of
> > >> code are probably already testing against v3.
> > >> The solution must lie in the domain of generalising the
> > build
> > >> process.
> > >>
> > >> D.
> > >>
> > >> (*) Limiting music with computers to _sound_, will ensure
> > it
> > >> continues
> > >> to suffer from the same problems that all Cartesian models do.
> > >>
> > >>
> > >> ________________________________________________
> > >> David Worrall.
> > >> - Experimental Polymedia:	worrall.avatar.com.au
> > >> - Sonification: www.sonifiction.com.au
> > >> - Education for Financial Independence: www.mindthemarkets.com.au
> > >>
> > >>
> > >>
> > >> Send bugs reports to this list.
> > >> To unsubscribe, send email sympa@lists.bath.ac.uk with
> > body
> > >> "unsubscribe
> > >> csound"
> > >>
> > >
> > >
> > > --
> > > Michael Gogins
> > > Irreducible Productions
> > > http://www.michael-gogins.com
> > > Michael dot Gogins at gmail dot com
> > >
> > >
> > > Send bugs reports to this list.
> > > To unsubscribe, send email sympa@lists.bath.ac.uk with
> > body
> > > "unsubscribe csound"
> >
> > ________________________________________________
> > David Worrall.
> > - Experimental Polymedia:	www.avatar.com.au
> > - Education for Financial Independence: www.mindthemarkets.com.au
> > Australian research affiliations:
> > - Capital Markets Cooperative Research Centre: www.cmcrc.com
> > - Sonic Communications Research Group:	creative.canberra.edu.au/scrg
> > - MARCS Auditory Laboratories: marcs.uws.edu.au
> >
> >
> >
> >
> >
> > Send bugs reports to this list.
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
> > "unsubscribe csound"
>
> Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,
> National University of Ireland, Maynooth

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

On 28/06/2009, DavidW  wrote:
> I might be horribly out of date because I stopped struggling with the API a
> while ago. Anyway, as I see it, there are two main tasks and a development
> process issue. I think it is unnecessarily difficult, and not very
> efficient, for one person to try to solve these build and distribute issues
> for versions, all platforms.
>
> 1. Begin with the latest versions of SCons and python. Solve the SCons build
> problems - probably on a platform by platform basis.  It's a while since I
> played with the SCons build so I can't remember the specifics. Anyway,
> you're the most experienced at the build, so I don't know I can add anything
> to what you already know.
>
> 2. Develop user downloadable "easy_install" install.py file(s) (or better
> still python eggs which pulls all the necessary stuff from the repository,+
> the right version of numpy if the API is now dependent on it etc).  The
> user, irrespective of the version of python they have installed,  just types
> "python install.py".

I still wonder why regular users need to bother with building csound.
There is *no* need for that.
Just to make it clear: you do *not* need to build csound to use the
API. Unless the binary packages for OSX and Windows don't install the
headers (which I'd be surprised to learn they don't).

>
> 3.  There needs to be a willingness to make the build process inclusive of
> more users. That is a development 'policy' issue. I've been there before so
> I won't bang on. I'd start by cleaning up what's downloaded. Last time I
> looked the csound root directory was a dog's breakfast to any but the most
> frequent visitors.  Csound already has a steep learning curve, so there's no
> reasonable reason why it should be made steeper by having to avoid other
> people's litter.  If you want people to share a workshop then workshop
> tidiness is essential.  I'd start by tossing out everything that is not API
> related and make sure file names reflect their functions  and platform
> restrictions. Boring stuff, I know.


Any relatively large project is "dog's breakfast" to newcomers.


BTW, I do agree the csound build system is less than optimal, but it
is not easy to cater for all use cases. Anyways, it is not that hard
either: setup the appropriate environment (ie, install all needed
dependencies), setup your path and specific flags in custom.py and run
scons with the wanted flags. If you have build errors, report them so
that the minimum versions of dependencies are adjusted or the problem
is fixed within csound.

Saludos,
Felipe Sateler

Felipe Sateler wrote:
> 
> I still wonder why regular users need to bother with building csound.
> There is *no* need for that.
> Just to make it clear: you do *not* need to build csound to use the
> API. Unless the binary packages for OSX and Windows don't install the
> headers (which I'd be surprised to learn they don't).
> 

Python does not work with the Csound API on my system. So I have to build it
to use it.


Felipe Sateler wrote:
> 
> BTW, I do agree the csound build system is less than optimal, but it
> is not easy to cater for all use cases. Anyways, it is not that hard
> either: setup the appropriate environment (ie, install all needed
> dependencies), setup your path and specific flags in custom.py and run
> scons with the wanted flags. If you have build errors, report them so
> that the minimum versions of dependencies are adjusted or the problem
> is fixed within csound.
> 

Hard is a relative term.  Setting up the appropriate environment,
dependencies, paths, flags, etc...  There  are lots of people who have no
clue how to interact with these technical hurdles, who are still very
capable of writing Csound and python code.  Generally speaking, for every
obstacle there is to get Csound up and running, we lose potential Csounders. 
Unfortunately, Csound has more obstacles than just about anything else out
in the wild.

For all the time and hard work the developers and other put into Csound
(which I truly appreciate), much of it is wasted because of often
unnecessary technical hurdles for newbies.  There are some technical issues
that may never be eliminated, I understand this, but there is certainly much
streamlining that can be done.  I'm willing to do my part.

Plus, Csound isn't the only game in town, anymore;  It's hard enough to get
people to give Csound a try with other great music tools such as MaxMSP,
Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to grow the
Csound community, we have knock off this technical elite attitude, and start
looking at Csound through the eyes of newbies.  

My two cents.
Jake



-- 
View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24311001.html
Sent from the Csound - General mailing list archive at Nabble.com.

> Plus, Csound isn't the only game in town, anymore;  It's hard enough to get
> people to give Csound a try with other great music tools such as MaxMSP,
> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to grow the
> Csound community, we have knock off this technical elite attitude, and start
> looking at Csound through the eyes of newbies.  

Csound is very different from the others you list. It is more low-level, 
and more powerful IMO. What we would need is a friendly layer above it 
exposing its power in a clean and simple way to newbies, or simply 
composers that are not fond of assembly programming. To me it would be 
another system altogether. Some attempts have been made, from Blue to 
Cecilia or older stuff like PatchWork and many others. These are/were 
all individual projects so they have limited scope and lack the manpower 
required to build a Reaktor clone.

So, to summarize, the technical elite attitude you regret mirrors the 
actual technical nature of Csound itself. I don't think it can be very 
much more newbie friendly.

What I do believe is that a whole other project is needed to wrap Csound 
within a full-blown composition system. But for this to happen we need a 
group of motivated people, sharing a common vision of what such a system 
should be. This is very challenging.

Personnaly I have my own one-person thing, Surmulot, developed along the 
lines I just exposed: it is very easy to install (just unzip the 
archive), it has graphical front-ends for score, orchestra and 
envelopes, a powerful textual front-end (Emacs), algorithmic tools, high 
level languages for composing (Lisp and Smalltalk). But it definitely is 
not friendly to newbies. Could be made so, maybe, sometime...



Stef

I can't agree more.

We desperately need a simple *installable* Windows version of Csound5  
with the QuteCsound front-end - as part of the package.

I can't tell you how many Electronic Musicians, Synth Majors, Synth  
professor, and very skilled and
Experienced Computer Music/Electronic Music colleagues - just give  
UP!  When common sense fails,
when logic fails, when professional standards are not met... they move  
on - to the TONS of other
great and powerful tools at their disposal.

At least there is NOW a Macintosh version that simple installs in a  
clean and professional way, although
one has to find and know to install QuteCsound too... and even then,  
there is confusion about which version
will work with which version and platform.

Hopefully Michael Gogins can deliver a binary distribution that just  
installs and works and contains what is necessary
to do study, learn, and use Csound with an affordable PC running  
Windows XT and/or Vista

-dB


On Jul 2, 2009, at 1:37 PM, Jacob Joaquin wrote:

>
>
> Felipe Sateler wrote:
>>
>> I still wonder why regular users need to bother with building csound.
>> There is *no* need for that.
>> Just to make it clear: you do *not* need to build csound to use the
>> API. Unless the binary packages for OSX and Windows don't install the
>> headers (which I'd be surprised to learn they don't).
>>
>
> Python does not work with the Csound API on my system. So I have to  
> build it
> to use it.
>
>
> Felipe Sateler wrote:
>>
>> BTW, I do agree the csound build system is less than optimal, but it
>> is not easy to cater for all use cases. Anyways, it is not that hard
>> either: setup the appropriate environment (ie, install all needed
>> dependencies), setup your path and specific flags in custom.py and  
>> run
>> scons with the wanted flags. If you have build errors, report them so
>> that the minimum versions of dependencies are adjusted or the problem
>> is fixed within csound.
>>
>
> Hard is a relative term.  Setting up the appropriate environment,
> dependencies, paths, flags, etc...  There  are lots of people who  
> have no
> clue how to interact with these technical hurdles, who are still very
> capable of writing Csound and python code.  Generally speaking, for  
> every
> obstacle there is to get Csound up and running, we lose potential  
> Csounders.
> Unfortunately, Csound has more obstacles than just about anything  
> else out
> in the wild.
>
> For all the time and hard work the developers and other put into  
> Csound
> (which I truly appreciate), much of it is wasted because of often
> unnecessary technical hurdles for newbies.  There are some technical  
> issues
> that may never be eliminated, I understand this, but there is  
> certainly much
> streamlining that can be done.  I'm willing to do my part.
>
> Plus, Csound isn't the only game in town, anymore;  It's hard enough  
> to get
> people to give Csound a try with other great music tools such as  
> MaxMSP,
> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to  
> grow the
> Csound community, we have knock off this technical elite attitude,  
> and start
> looking at Csound through the eyes of newbies.
>
> My two cents.
> Jake
>
>
>
> -- 
> View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24311001.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

There is Blue.  There is Lettuce.  and they are  great.
In fact, over the years, there have been many wonderful Windows front- 
ends that integrate powerful compositional/work-flow environments
and they have been wonderful in their way too.

BUT...

A beginner needs to be able to download and install Csound - for their  
PC especially - and have a version that will let them at least explore  
it some.

So happy that that situation has been somewhat remedied for the Mac  
(thanks to Victor Lazzarini and Andreas Cabrera's work),
but it is still a bit of a nightmare and showstopper for Windows.

I have a blind student getting started with his Windows PC and  
Csound.... he uses the Jaws program to read the PC displays to him.
It works great with all his softwware... It just to us (took ME - mr  
Csound) two weeks to get the latest Csound running on his laptop!

Like Art, I have resorted to older versions of the program that just  
worked on Windows... John ffitch's original Winsound from
The Csound Book and Csound Catalog!  (thanks John)

uuuuugggghhhhh - getting a Windows version that was up to date  
running.... nice........ NOT!

I did a workshop in Korea last year.  All the professors and grad  
students are inspired and rush home to install and try Csound.

They all come back the next day - NO ONE got it running!  NO ONE!!!

Next week, I am doing a workshop at Berklee for gifted High School  
students... Most of them will have PCs....

Last year... I gave out a Prize - the Csound Book - to the student who  
could get it running on their PC and make Toot1.
Of the 40+ API advanced Physics Science Prize nerds there.... ONE  
student succeeded - and it took ALL night.

This year... well I have my fingers crossed that Michael might get  
something happening with Andres' QuteCsound in time.

I'll let you know... But.. truly... it is sad that Windows beginners/ 
users/curious (regardless of their experience level)
can't ever really get started...

maybe deep down... we don't want them to?  maybe... it makes us more  
special?

I hope not.... because I want everyone to get it?  to get infected  
with the mind-opening and ear-expanding power of Csound

-dB


On Jul 2, 2009, at 2:24 PM, Stéphane Rollandin wrote:

>> Plus, Csound isn't the only game in town, anymore;  It's hard  
>> enough to get
>> people to give Csound a try with other great music tools such as  
>> MaxMSP,
>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to  
>> grow the
>> Csound community, we have knock off this technical elite attitude,  
>> and start
>> looking at Csound through the eyes of newbies.
>
> Csound is very different from the others you list. It is more low- 
> level, and more powerful IMO. What we would need is a friendly layer  
> above it exposing its power in a clean and simple way to newbies, or  
> simply composers that are not fond of assembly programming. To me it  
> would be another system altogether. Some attempts have been made,  
> from Blue to Cecilia or older stuff like PatchWork and many others.  
> These are/were all individual projects so they have limited scope  
> and lack the manpower required to build a Reaktor clone.
>
> So, to summarize, the technical elite attitude you regret mirrors  
> the actual technical nature of Csound itself. I don't think it can  
> be very much more newbie friendly.
>
> What I do believe is that a whole other project is needed to wrap  
> Csound within a full-blown composition system. But for this to  
> happen we need a group of motivated people, sharing a common vision  
> of what such a system should be. This is very challenging.
>
> Personnaly I have my own one-person thing, Surmulot, developed along  
> the lines I just exposed: it is very easy to install (just unzip the  
> archive), it has graphical front-ends for score, orchestra and  
> envelopes, a powerful textual front-end (Emacs), algorithmic tools,  
> high level languages for composing (Lisp and Smalltalk). But it  
> definitely is not friendly to newbies. Could be made so, maybe,  
> sometime...
>
>
>
> Stef
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Hi,

Just to let you know that I never had problems of this sort when installing
Csound in Windows. It works «out of the box» and I am not a PC wizard...

Can you tell us what the fundamental problem is? Or maybe they experience
different problems...

Regards,

Marc

p.s. In my case I have more problems with Windows... Last night I have
installed the Vista SP2 in one of my laptop and it stops working. I love you
Bill...

-----Message d'origine-----
De : Dr. Richard Boulanger [mailto:richardboulanger@comcast.net] 
Envoyé : 2 juillet 2009 14:42
À : csound@lists.bath.ac.uk
Objet : [Csnd] WE Desperately NEED a Simple Installer/Build for Windows with
QuteCsound (was: Building Python API (was: Score Alignment Utility)

There is Blue.  There is Lettuce.  and they are  great.
In fact, over the years, there have been many wonderful Windows front- 
ends that integrate powerful compositional/work-flow environments
and they have been wonderful in their way too.

BUT...

A beginner needs to be able to download and install Csound - for their  
PC especially - and have a version that will let them at least explore  
it some.

So happy that that situation has been somewhat remedied for the Mac  
(thanks to Victor Lazzarini and Andreas Cabrera's work),
but it is still a bit of a nightmare and showstopper for Windows.

I have a blind student getting started with his Windows PC and  
Csound.... he uses the Jaws program to read the PC displays to him.
It works great with all his softwware... It just to us (took ME - mr  
Csound) two weeks to get the latest Csound running on his laptop!

Like Art, I have resorted to older versions of the program that just  
worked on Windows... John ffitch's original Winsound from
The Csound Book and Csound Catalog!  (thanks John)

uuuuugggghhhhh - getting a Windows version that was up to date  
running.... nice........ NOT!

I did a workshop in Korea last year.  All the professors and grad  
students are inspired and rush home to install and try Csound.

They all come back the next day - NO ONE got it running!  NO ONE!!!

Next week, I am doing a workshop at Berklee for gifted High School  
students... Most of them will have PCs....

Last year... I gave out a Prize - the Csound Book - to the student who  
could get it running on their PC and make Toot1.
Of the 40+ API advanced Physics Science Prize nerds there.... ONE  
student succeeded - and it took ALL night.

This year... well I have my fingers crossed that Michael might get  
something happening with Andres' QuteCsound in time.

I'll let you know... But.. truly... it is sad that Windows beginners/ 
users/curious (regardless of their experience level)
can't ever really get started...

maybe deep down... we don't want them to?  maybe... it makes us more  
special?

I hope not.... because I want everyone to get it?  to get infected  
with the mind-opening and ear-expanding power of Csound

-dB


On Jul 2, 2009, at 2:24 PM, Stéphane Rollandin wrote:

>> Plus, Csound isn't the only game in town, anymore;  It's hard  
>> enough to get
>> people to give Csound a try with other great music tools such as  
>> MaxMSP,
>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to  
>> grow the
>> Csound community, we have knock off this technical elite attitude,  
>> and start
>> looking at Csound through the eyes of newbies.
>
> Csound is very different from the others you list. It is more low- 
> level, and more powerful IMO. What we would need is a friendly layer  
> above it exposing its power in a clean and simple way to newbies, or  
> simply composers that are not fond of assembly programming. To me it  
> would be another system altogether. Some attempts have been made,  
> from Blue to Cecilia or older stuff like PatchWork and many others.  
> These are/were all individual projects so they have limited scope  
> and lack the manpower required to build a Reaktor clone.
>
> So, to summarize, the technical elite attitude you regret mirrors  
> the actual technical nature of Csound itself. I don't think it can  
> be very much more newbie friendly.
>
> What I do believe is that a whole other project is needed to wrap  
> Csound within a full-blown composition system. But for this to  
> happen we need a group of motivated people, sharing a common vision  
> of what such a system should be. This is very challenging.
>
> Personnaly I have my own one-person thing, Surmulot, developed along  
> the lines I just exposed: it is very easy to install (just unzip the  
> archive), it has graphical front-ends for score, orchestra and  
> envelopes, a powerful textual front-end (Emacs), algorithmic tools,  
> high level languages for composing (Lisp and Smalltalk). But it  
> definitely is not friendly to newbies. Could be made so, maybe,  
> sometime...
>
>
>
> Stef
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



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

I really don't understand the difficulty with the Windows installers.
I routinely test it at home and at work; and at work, i uninstall
Csound before installing it again. It always just runs out of the box.

Are all of the difficulties that people have because of Python? I'd
appreciate a specific list of problems that people have, preferably
with screen shots of error messages and such.

I need more information! "Doesn't work" or "Took all day" is not helpful.

I can't fix a problem that I can't reproduce...

Best,
Mike

On 7/2/09, Dr. Richard Boulanger  wrote:
> There is Blue.  There is Lettuce.  and they are  great.
> In fact, over the years, there have been many wonderful Windows front-
> ends that integrate powerful compositional/work-flow environments
> and they have been wonderful in their way too.
>
> BUT...
>
> A beginner needs to be able to download and install Csound - for their
> PC especially - and have a version that will let them at least explore
> it some.
>
> So happy that that situation has been somewhat remedied for the Mac
> (thanks to Victor Lazzarini and Andreas Cabrera's work),
> but it is still a bit of a nightmare and showstopper for Windows.
>
> I have a blind student getting started with his Windows PC and
> Csound.... he uses the Jaws program to read the PC displays to him.
> It works great with all his softwware... It just to us (took ME - mr
> Csound) two weeks to get the latest Csound running on his laptop!
>
> Like Art, I have resorted to older versions of the program that just
> worked on Windows... John ffitch's original Winsound from
> The Csound Book and Csound Catalog!  (thanks John)
>
> uuuuugggghhhhh - getting a Windows version that was up to date
> running.... nice........ NOT!
>
> I did a workshop in Korea last year.  All the professors and grad
> students are inspired and rush home to install and try Csound.
>
> They all come back the next day - NO ONE got it running!  NO ONE!!!
>
> Next week, I am doing a workshop at Berklee for gifted High School
> students... Most of them will have PCs....
>
> Last year... I gave out a Prize - the Csound Book - to the student who
> could get it running on their PC and make Toot1.
> Of the 40+ API advanced Physics Science Prize nerds there.... ONE
> student succeeded - and it took ALL night.
>
> This year... well I have my fingers crossed that Michael might get
> something happening with Andres' QuteCsound in time.
>
> I'll let you know... But.. truly... it is sad that Windows beginners/
> users/curious (regardless of their experience level)
> can't ever really get started...
>
> maybe deep down... we don't want them to?  maybe... it makes us more
> special?
>
> I hope not.... because I want everyone to get it?  to get infected
> with the mind-opening and ear-expanding power of Csound
>
> -dB
>
>
> On Jul 2, 2009, at 2:24 PM, Stéphane Rollandin wrote:
>
>>> Plus, Csound isn't the only game in town, anymore;  It's hard
>>> enough to get
>>> people to give Csound a try with other great music tools such as
>>> MaxMSP,
>>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to
>>> grow the
>>> Csound community, we have knock off this technical elite attitude,
>>> and start
>>> looking at Csound through the eyes of newbies.
>>
>> Csound is very different from the others you list. It is more low-
>> level, and more powerful IMO. What we would need is a friendly layer
>> above it exposing its power in a clean and simple way to newbies, or
>> simply composers that are not fond of assembly programming. To me it
>> would be another system altogether. Some attempts have been made,
>> from Blue to Cecilia or older stuff like PatchWork and many others.
>> These are/were all individual projects so they have limited scope
>> and lack the manpower required to build a Reaktor clone.
>>
>> So, to summarize, the technical elite attitude you regret mirrors
>> the actual technical nature of Csound itself. I don't think it can
>> be very much more newbie friendly.
>>
>> What I do believe is that a whole other project is needed to wrap
>> Csound within a full-blown composition system. But for this to
>> happen we need a group of motivated people, sharing a common vision
>> of what such a system should be. This is very challenging.
>>
>> Personnaly I have my own one-person thing, Surmulot, developed along
>> the lines I just exposed: it is very easy to install (just unzip the
>> archive), it has graphical front-ends for score, orchestra and
>> envelopes, a powerful textual front-end (Emacs), algorithmic tools,
>> high level languages for composing (Lisp and Smalltalk). But it
>> definitely is not friendly to newbies. Could be made so, maybe,
>> sometime...
>>
>>
>>
>> Stef
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


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

I will go through the process again here this weekend - on two  
machines - and let you know specifically.
I will also have my student assistant - Nicolas - who worked with  
Ozgur - to detail all the problems that he had.
(I think that most of them involved Python)

But also worth noting is the fact that - Art Hunkins - a serious PC- 
based Csounder, has also reported that
he isn't able to work with the latest versions and has resorted to  
older versions and some subset.

I am just wondering if we can't support a Base Versions - with a  
standard front-end (like QuteCsound) for all platforms
that simply installs on the machine with by double-clicking on a  
single package file.

-dB

On Jul 2, 2009, at 5:08 PM, Michael Gogins wrote:

> I really don't understand the difficulty with the Windows installers.
> I routinely test it at home and at work; and at work, i uninstall
> Csound before installing it again. It always just runs out of the box.
>
> Are all of the difficulties that people have because of Python? I'd
> appreciate a specific list of problems that people have, preferably
> with screen shots of error messages and such.
>
> I need more information! "Doesn't work" or "Took all day" is not  
> helpful.
>
> I can't fix a problem that I can't reproduce...
>
> Best,
> Mike
>
> On 7/2/09, Dr. Richard Boulanger  wrote:
>> There is Blue.  There is Lettuce.  and they are  great.
>> In fact, over the years, there have been many wonderful Windows  
>> front-
>> ends that integrate powerful compositional/work-flow environments
>> and they have been wonderful in their way too.
>>
>> BUT...
>>
>> A beginner needs to be able to download and install Csound - for  
>> their
>> PC especially - and have a version that will let them at least  
>> explore
>> it some.
>>
>> So happy that that situation has been somewhat remedied for the Mac
>> (thanks to Victor Lazzarini and Andreas Cabrera's work),
>> but it is still a bit of a nightmare and showstopper for Windows.
>>
>> I have a blind student getting started with his Windows PC and
>> Csound.... he uses the Jaws program to read the PC displays to him.
>> It works great with all his softwware... It just to us (took ME - mr
>> Csound) two weeks to get the latest Csound running on his laptop!
>>
>> Like Art, I have resorted to older versions of the program that just
>> worked on Windows... John ffitch's original Winsound from
>> The Csound Book and Csound Catalog!  (thanks John)
>>
>> uuuuugggghhhhh - getting a Windows version that was up to date
>> running.... nice........ NOT!
>>
>> I did a workshop in Korea last year.  All the professors and grad
>> students are inspired and rush home to install and try Csound.
>>
>> They all come back the next day - NO ONE got it running!  NO ONE!!!
>>
>> Next week, I am doing a workshop at Berklee for gifted High School
>> students... Most of them will have PCs....
>>
>> Last year... I gave out a Prize - the Csound Book - to the student  
>> who
>> could get it running on their PC and make Toot1.
>> Of the 40+ API advanced Physics Science Prize nerds there.... ONE
>> student succeeded - and it took ALL night.
>>
>> This year... well I have my fingers crossed that Michael might get
>> something happening with Andres' QuteCsound in time.
>>
>> I'll let you know... But.. truly... it is sad that Windows beginners/
>> users/curious (regardless of their experience level)
>> can't ever really get started...
>>
>> maybe deep down... we don't want them to?  maybe... it makes us more
>> special?
>>
>> I hope not.... because I want everyone to get it?  to get infected
>> with the mind-opening and ear-expanding power of Csound
>>
>> -dB
>>
>>
>> On Jul 2, 2009, at 2:24 PM, Stéphane Rollandin wrote:
>>
>>>> Plus, Csound isn't the only game in town, anymore;  It's hard
>>>> enough to get
>>>> people to give Csound a try with other great music tools such as
>>>> MaxMSP,
>>>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to
>>>> grow the
>>>> Csound community, we have knock off this technical elite attitude,
>>>> and start
>>>> looking at Csound through the eyes of newbies.
>>>
>>> Csound is very different from the others you list. It is more low-
>>> level, and more powerful IMO. What we would need is a friendly layer
>>> above it exposing its power in a clean and simple way to newbies, or
>>> simply composers that are not fond of assembly programming. To me it
>>> would be another system altogether. Some attempts have been made,
>>> from Blue to Cecilia or older stuff like PatchWork and many others.
>>> These are/were all individual projects so they have limited scope
>>> and lack the manpower required to build a Reaktor clone.
>>>
>>> So, to summarize, the technical elite attitude you regret mirrors
>>> the actual technical nature of Csound itself. I don't think it can
>>> be very much more newbie friendly.
>>>
>>> What I do believe is that a whole other project is needed to wrap
>>> Csound within a full-blown composition system. But for this to
>>> happen we need a group of motivated people, sharing a common vision
>>> of what such a system should be. This is very challenging.
>>>
>>> Personnaly I have my own one-person thing, Surmulot, developed along
>>> the lines I just exposed: it is very easy to install (just unzip the
>>> archive), it has graphical front-ends for score, orchestra and
>>> envelopes, a powerful textual front-end (Emacs), algorithmic tools,
>>> high level languages for composing (Lisp and Smalltalk). But it
>>> definitely is not friendly to newbies. Could be made so, maybe,
>>> sometime...
>>>
>>>
>>>
>>> Stef
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

It is good to here that it is not just me banging on about these  
issue. It is simply not true - or a solution - to assume that build  
difficulties mean "(dumb) newbie at work." In another current thread  
(Sugar on a Stick - and OLPCsound) On 03/07/2009, at 7:01 AM, Michael  
Gogins wrote:

> As I have mentioned several times on this list, making the Csound API
> independent of the Python version is not practical.
>
> We use SWIG to generate the Python wrapper, because it saves a simply
> enormous amount of work to do so. Using SWIG also makes it easy to
> generate two of the other wrappers: the Lua API and the Java API (the
> Lisp API is done with cffi, which is different).
>
> SWIG, however, makes the Python wrapper depend on the specific version
> of Python.


As I and others have mentioned several times on this list, keeping the  
Csound API dependent on a specific version of Python is not practical  
from a user
(as opposed to a developer clique) perspective.
As I have mentioned several times on this list, there is a middle way:

1) It is not using SWIG to generate the wrapper that creates the  
dependency. It is the way it is (not) used that creates the  
dependency. The build process needs to be made easy enough that the  
user can download the sources and use easy-install. Lots of complex  
packages out there do this. However it requires a

2) Change in the oligarchical 'priesthood' approach to developer  
status. (Notice how warmly Brian's recent offer to become involved in  
OSX-oriented development was met? NOT!  I hope he's not holding his  
breath!) This would mean that the whole idea of there not being a  
version build available would more likely to disappear. jp's recent  
Adminstrivia Message said:
>  Newbies are
> sometimes afraid to post because they read discussions about the
> incomprehensible deep inner workings, and all they want to know is how
> to get a sound to come out of their iBook.  Rest assured that your
> question will be answered quickly, and (usually) in a helpful and
> courteous manner.  We've all been there.  Please post.


This could have come straight out of Hesse's The Glass Bead Game! Your  
questions may be answered but your suggestions frequently ignored.  
Afterall, the priests far to busy doing important things like  
producing the next version release, to fix "newbie problems. Get back  
in your box and genuflect,  genuflect,  genuflect!

Michael recently said
> I really don't understand the difficulty with the Windows installers.
> I routinely test it at home and at work; and at work, i uninstall
> Csound before installing it again. It always just runs out of the box.

The difficulty is not a failure of the people trying to do the  
install, it a development process failure. We all know how hard it is  
to do the n'th correction of a text we've written, whereas fresh eyes  
see the flaws easily. Ditto SW development.

On 03/07/2009, at 4:26 AM, Dr. Richard Boulanger wrote:

> I can't agree more.
>
> We desperately need a simple *installable* Windows version of  
> Csound5 with the QuteCsound front-end - as part of the package.
>
> I can't tell you how many Electronic Musicians, Synth Majors, Synth  
> professor, and very skilled and
> Experienced Computer Music/Electronic Music colleagues - just give  
> UP!  When common sense fails,
> when logic fails, when professional standards are not met... they  
> move on - to the TONS of other
> great and powerful tools at their disposal.
>
> At least there is NOW a Macintosh version that simple installs in a  
> clean and professional way, although
> one has to find and know to install QuteCsound too... and even then,  
> there is confusion about which version
> will work with which version and platform.

It is somewhat consoling to here your  build difficulty anecdotes.   
Unfortunately the Mac version is not as up to the standard you think.
As Victor said earlier in this thread
> The Intel binaries I build are linked against MacPython 2.5. But it's
> done in 10.4 (at the moment), so no guarantees for OSX 10.5.

So around we go again. Problems mentioned, excuses (complexity, blah,  
blah) offered. Solution: People disappear (back) to a more user- 
oriented environment.

And for the record... Csound may be fantastic, but it really is no  
more complex that Supercollider. Bigger, yes, more weighed down by its  
own history and self importance, yes, but not more complex.

None of my posts on this are meant personally. I have considerable  
regard for the work of many on this list. But the elephant (and rhino)  
in the room need to be identified for what they are.
In the meantime, when people as whether they should learn csound, I  
continue to say "not yet, not yet".

D.
...
> -dB
>
>
> On Jul 2, 2009, at 1:37 PM, Jacob Joaquin wrote:
>
>>
>>
>> Felipe Sateler wrote:
>>>
>>> I still wonder why regular users need to bother with building  
>>> csound.
>>> There is *no* need for that.
>>> Just to make it clear: you do *not* need to build csound to use the
>>> API. Unless the binary packages for OSX and Windows don't install  
>>> the
>>> headers (which I'd be surprised to learn they don't).
>>>
>>
>> Python does not work with the Csound API on my system. So I have to  
>> build it
>> to use it.
>>
>>
>> Felipe Sateler wrote:
>>>
>>> BTW, I do agree the csound build system is less than optimal, but it
>>> is not easy to cater for all use cases. Anyways, it is not that hard
>>> either: setup the appropriate environment (ie, install all needed
>>> dependencies), setup your path and specific flags in custom.py and  
>>> run
>>> scons with the wanted flags. If you have build errors, report them  
>>> so
>>> that the minimum versions of dependencies are adjusted or the  
>>> problem
>>> is fixed within csound.
>>>
>>
>> Hard is a relative term.  Setting up the appropriate environment,
>> dependencies, paths, flags, etc...  There  are lots of people who  
>> have no
>> clue how to interact with these technical hurdles, who are still very
>> capable of writing Csound and python code.  Generally speaking, for  
>> every
>> obstacle there is to get Csound up and running, we lose potential  
>> Csounders.
>> Unfortunately, Csound has more obstacles than just about anything  
>> else out
>> in the wild.
>>
>> For all the time and hard work the developers and other put into  
>> Csound
>> (which I truly appreciate), much of it is wasted because of often
>> unnecessary technical hurdles for newbies.  There are some  
>> technical issues
>> that may never be eliminated, I understand this, but there is  
>> certainly much
>> streamlining that can be done.  I'm willing to do my part.
>>
>> Plus, Csound isn't the only game in town, anymore;  It's hard  
>> enough to get
>> people to give Csound a try with other great music tools such as  
>> MaxMSP,
>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to  
>> grow the
>> Csound community, we have knock off this technical elite attitude,  
>> and start
>> looking at Csound through the eyes of newbies.
>>
>> My two cents.
>> Jake
>>
> ...
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

________________________________________________
David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au

2009/7/2 Stéphane Rollandin :
>
> What I do believe is that a whole other project is needed to wrap Csound
> within a full-blown composition system. But for this to happen we need a
> group of motivated people, sharing a common vision of what such a system
> should be. This is very challenging.
>
> Personnaly I have my own one-person thing, Surmulot, developed along the
> lines I just exposed: it is very easy to install (just unzip the archive),
> it has graphical front-ends for score, orchestra and envelopes, a powerful
> textual front-end (Emacs), algorithmic tools, high level languages for
> composing (Lisp and Smalltalk). But it definitely is not friendly to
> newbies. Could be made so, maybe, sometime...
>

As part of the AudioCarver project, I've been developing two base libraries to wrap Csound the "Qt way".

The first project, MiQtCsound, is a thin C++ wrapper for Csound's C api. It main feature is that it uses Qt's library loading class in such a way that (in theory) allows it to wrap any version of the api that uses the same function names, based solely on the library name passed into a constructor at runtime with no link-time dependencies to Csound.

The second MiQtCsound project is contained in the larger MiQt project and is aimed at providing a trimmed down, logical, and Qt-like interface to Csound's api via the first project's library.  I have only recently worked out a rudimentary playback system in it, and it is probably not very useful to anyone other than myself at the moment -- but I'm hopeful AudioCarver will become a full blown sequencer based on it in the near future.

At this point the projects are only setup to build on Windows but I'm having success building small parts of it on Ubuntu as well -- and it should not be difficult to get it up and running on Mac platforms in due time, either, assuming I'm able to afford it.

---

Being self-taught I consider myself only an amatuer programmer, but I have 10 years of fairly complex (albeit non-professional) C++ design under my belt -- and I've taken great care in learning Qt's design methodologies and naming schemes with the idea being from the start that others will find it useful, too.  This is a critical time in all three projects' development, though.  In the last two weeks I've gotten to the bottom of most of my "how" and "why" questions regarding the csound api and I'll soon be entering the over-arching design phase now that the intitial research phase is nearing completion.  I think it might be really cool if some of the devs here could take a look at code for these projects and see if they could possibly fit the bill for something along the lines of what Stephane is talking about -- and this is the perfect time to be considering large-scale changes in their design should it be deemed necessary.

I'd post links to the projects (MiQtCsound, MiQt, and AudioCarver) but SourceForge has locked me out of them while it updates it's new look/feel.  In the meantime they should be easy enough to locate via SourceForge's search function, and hopefully they'll be up again soon.

Regards,
-andy.f



----- "Stéphane Rollandin"  wrote:
> > Plus, Csound isn't the only game in town, anymore;  It's hard enough
> to get
> > people to give Csound a try with other great music tools such as
> MaxMSP,
> > Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to
> grow the
> > Csound community, we have knock off this technical elite attitude,
> and start
> > looking at Csound through the eyes of newbies.  
> 
> Csound is very different from the others you list. It is more
> low-level, 
> and more powerful IMO. What we would need is a friendly layer above it
> 
> exposing its power in a clean and simple way to newbies, or simply 
> composers that are not fond of assembly programming. To me it would be
> 
> another system altogether. Some attempts have been made, from Blue to
> 
> Cecilia or older stuff like PatchWork and many others. These are/were
> 
> all individual projects so they have limited scope and lack the
> manpower 
> required to build a Reaktor clone.
> 
> So, to summarize, the technical elite attitude you regret mirrors the
> 
> actual technical nature of Csound itself. I don't think it can be very
> 
> much more newbie friendly.
> 
> What I do believe is that a whole other project is needed to wrap
> Csound 
> within a full-blown composition system. But for this to happen we need
> a 
> group of motivated people, sharing a common vision of what such a
> system 
> should be. This is very challenging.
> 
> Personnaly I have my own one-person thing, Surmulot, developed along
> the 
> lines I just exposed: it is very easy to install (just unzip the 
> archive), it has graphical front-ends for score, orchestra and 
> envelopes, a powerful textual front-end (Emacs), algorithmic tools,
> high 
> level languages for composing (Lisp and Smalltalk). But it definitely
> is 
> not friendly to newbies. Could be made so, maybe, sometime...
> 
> 
> 
> Stef
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body
> "unsubscribe csound"

I'd like to discuss this more in detail. I'd appreciate if we could  
define some subjects/ projects: what must be done to improve the user- 
friendlyness of Csound, and how can it be done? If there is a  
consensus about some points, we could perhaps have some groups of  
people who are willing to contribute to a certain issue.

To begin with my own opinion: I'd like to have something like a  
practical guide (and contribute to it) to the different approaches of  
Csound. There should be good examples with rather short explanations  
to the different chapters of Csound, including
- general configuration
- working with live input
- working with MIDI
- loop constructions and event management
- classical sound synthesis
- granular synthesis
- spectral processing
- working with the API
- using Csound and the utilities with Shell Scripts
- and and and ...

The goal of this practical guide would be:
1) to collect the most important informations about the different ways  
of using Csound (for example, "what you should know about commandline  
flags", "what you should know when you work with MIDI input")
2) to give hints about which opcodes can be used for the different  
approaches, uncluding some kind of selection (for example, the pvs  
opcodes are actually replacing some older opcodes, or poscil can be  
used instead of oscil also for non-power-of-two function tables)
3) to show a rich collection of good examples: good in programming,  
with interesting musical results.

What others think about this? And are there other items, perhaps more  
necessary?

	joachim


Am 29.06.2009 um 00:51 schrieb Jacob Joaquin:

>
> Csound is not user-friendly.  If developers and others in the  
> community spent
> a full year working towards improving the user-experience, while  
> putting on
> hold everything else Csound related, this would be time well spent.   
> People
> are easily turned off the number of hoops they have to jump through -
> whether its issues with Python, or just rendering a file.  Csound is
> supposed to be an instrument of musical expression, not a technical  
> hurdle.
>
> In my humble opinion.  :)
>

Much of this information already exists in "A Csound Tutorial" by me.
I would be happy for other people to edit this or add to it. It is in
the tutorial module of Csound CVS.

Regards,
Mike


On 7/4/09, joachim heintz  wrote:
> I'd like to discuss this more in detail. I'd appreciate if we could
> define some subjects/ projects: what must be done to improve the user-
> friendlyness of Csound, and how can it be done? If there is a
> consensus about some points, we could perhaps have some groups of
> people who are willing to contribute to a certain issue.
>
> To begin with my own opinion: I'd like to have something like a
> practical guide (and contribute to it) to the different approaches of
> Csound. There should be good examples with rather short explanations
> to the different chapters of Csound, including
> - general configuration
> - working with live input
> - working with MIDI
> - loop constructions and event management
> - classical sound synthesis
> - granular synthesis
> - spectral processing
> - working with the API
> - using Csound and the utilities with Shell Scripts
> - and and and ...
>
> The goal of this practical guide would be:
> 1) to collect the most important informations about the different ways
> of using Csound (for example, "what you should know about commandline
> flags", "what you should know when you work with MIDI input")
> 2) to give hints about which opcodes can be used for the different
> approaches, uncluding some kind of selection (for example, the pvs
> opcodes are actually replacing some older opcodes, or poscil can be
> used instead of oscil also for non-power-of-two function tables)
> 3) to show a rich collection of good examples: good in programming,
> with interesting musical results.
>
> What others think about this? And are there other items, perhaps more
> necessary?
>
> 	joachim
>
>
> Am 29.06.2009 um 00:51 schrieb Jacob Joaquin:
>
>>
>> Csound is not user-friendly.  If developers and others in the
>> community spent
>> a full year working towards improving the user-experience, while
>> putting on
>> hold everything else Csound related, this would be time well spent.
>> People
>> are easily turned off the number of hoops they have to jump through -
>> whether its issues with Python, or just rendering a file.  Csound is
>> supposed to be an instrument of musical expression, not a technical
>> hurdle.
>>
>> In my humble opinion.  :)
>>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


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

Here are somethings I think we should consider, but not necessarily
implement.

-Messages should be written to  instead of .

-0dbfs should be set to 1.0 by default.  Hard coding to a range of +/- 32768
should be considered bad practice.

-Every new feature that is intended to go into Csound should be spec'd out,
and with extensive community input.  Since backwards compatibility is a
staple of Csound culture, I think it would be wise to start doing this
immediately.

-Debate the merits breaking backwards compatibility in Csound6.  What would
lose?  What could we gain? Could a script be written to convert from the old
to new? Or perhaps a guide showing how to update older pieces? 

-Csound Core might be a priorty, with a focus on getting it up and running
fast and easy.

-Defragment the Csound knowledge base.  There is a lot of scattered
information out.  On top of this, much of it is deprecated, which can be
very confusing for beginners and power users.

-Community should find ways of putting more emphasis on music and art.  We
often live in our own little worlds and only come together when it comes to
technical related issues.

-Look at everything and ask ourselves, "Can this be done better?"  For
example, $ csound outputs a list of flags and extras 55 lines long.  Would
this be better if reduced the list of flags to only the most common flags? 
And then emphasize --help.

-Bring the sexy back.  Superficially speaking, we live in a world where
people find Wine tastes better if it comes out of an expensive looking
bottle.  Csound looks like it's being consumed from a straw sticking out of
a paper bag, despite being an excellent vintage.

-User test everything, just to be sure. Just because someone may seem like a
no brainer to one person, doesn't mean it isn't really confusing to everyone
else. I've seen many examples in various online tech communities where some
explains something, and leaves out important details because he or she
assumes that everyone knows what the know.

Off the top of my head.

Best,
Jake



joachim heintz wrote:
> 
> I'd like to discuss this more in detail. I'd appreciate if we could  
> define some subjects/ projects: what must be done to improve the user- 
> friendlyness of Csound, and how can it be done? If there is a  
> consensus about some points, we could perhaps have some groups of  
> people who are willing to contribute to a certain issue.
> 
> To begin with my own opinion: I'd like to have something like a  
> practical guide (and contribute to it) to the different approaches of  
> Csound. There should be good examples with rather short explanations  
> to the different chapters of Csound, including
> - general configuration
> - working with live input
> - working with MIDI
> - loop constructions and event management
> - classical sound synthesis
> - granular synthesis
> - spectral processing
> - working with the API
> - using Csound and the utilities with Shell Scripts
> - and and and ...
> 
> The goal of this practical guide would be:
> 1) to collect the most important informations about the different ways  
> of using Csound (for example, "what you should know about commandline  
> flags", "what you should know when you work with MIDI input")
> 2) to give hints about which opcodes can be used for the different  
> approaches, uncluding some kind of selection (for example, the pvs  
> opcodes are actually replacing some older opcodes, or poscil can be  
> used instead of oscil also for non-power-of-two function tables)
> 3) to show a rich collection of good examples: good in programming,  
> with interesting musical results.
> 
> What others think about this? And are there other items, perhaps more  
> necessary?
> 
> 	joachim
> 
> 
> Am 29.06.2009 um 00:51 schrieb Jacob Joaquin:
> 
>>
>> Csound is not user-friendly.  If developers and others in the  
>> community spent
>> a full year working towards improving the user-experience, while  
>> putting on
>> hold everything else Csound related, this would be time well spent.   
>> People
>> are easily turned off the number of hoops they have to jump through -
>> whether its issues with Python, or just rendering a file.  Csound is
>> supposed to be an instrument of musical expression, not a technical  
>> hurdle.
>>
>> In my humble opinion.  :)
>>
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24338067.html
Sent from the Csound - General mailing list archive at Nabble.com.

I'd like to discuss this more in detail. I'd appreciate if we could define some subjects/ projects: what must be done to improve the user-friendlyness of Csound, and how can it be done? If there is a consensus about some points, we could perhaps have some groups of people who are willing to contribute to a certain issue.

To begin with my own opinion: I'd like to have something like a practical guide (and contribute to it) to the different approaches of Csound. There should be good examples with rather short explanations to the different chapters of Csound, including
- general configuration
- working with live input
- working with MIDI
- loop constructions and event management
- classical sound synthesis
- granular synthesis
- spectral processing
- working with the API
- using Csound and the utilities with Shell Scripts
- and and and ...

The goal of this practical guide would be:
1) to collect the most important informations about the different ways of using Csound (for example, "what you should know about commandline flags", "what you should know when you work with MIDI input")
2) to give hints about which opcodes can be used for the different approaches, uncluding some kind of selection (for example, the pvs opcodes are actually replacing some older opcodes, or poscil can be used instead of oscil also for non-power-of-two function tables)
3) to show a rich collection of good examples: good in programming, with interesting musical results.

What others think about this? And are there other items, perhaps more necessary?

    joachim


Am 29.06.2009 um 00:51 schrieb Jacob Joaquin:

Csound is not user-friendly.  If developers and others in the community spent
a full year working towards improving the user-experience, while putting on
hold everything else Csound related, this would be time well spent.  People
are easily turned off the number of hoops they have to jump through -
whether its issues with Python, or just rendering a file.  Csound is
supposed to be an instrument of musical expression, not a technical hurdle.

In my humble opinion.  :)

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