Score Alignment Utility

[Jacob Joaquin]

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

[Jan Jacob Hofmann]

...or this might be something for blue? This would be phantastic! I would love to have the opportunity of alignment in the score. Also changing a whole section of a single p-field.

All the best,

Jan Jacob

sound         |         movement          |          object         |          space

sonic architecture       |        site: http://www.sonicarchitecture.de  

spatial electronic composition     |    2nd order ambisonic music  

Date: Fri, 26 Jun 2009 14:21:46 -0700 (PDT)

From: Jacob Joaquin <jacobjoaquin@...>

Subject: [Csnd]  Score Alignment Utility

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

[csounder]

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@... with body  
> "unsubscribe csound"

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

[Jacob Joaquin]

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 [e-mail] with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email [e-mail] with body "unsubscribe csound"

[Dr. Richard Boulanger]

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@... with body
>>> "unsubscribe csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... 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@... with body  
> "unsubscribe csound"

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

[Jason Adams]

that looks great!  i'm new to this world and wondered why there wasn't something like that already... that said, i can't wait to try out what you have done already. 

ciao,
jAdams

---------------------------------------
Original E-mail
From: Jacob Joaquin <jacobjoaquin@...>
Date: 06/27/2009 11:59 AM
To: csound@...
Subject: [Csnd] Re: Score Alignment Utility

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@... with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... 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@... with body "unsubscribe csound"

[Stéphane Rollandin]

> 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@... with body "unsubscribe csound"

[csounder]

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@... with body  
> "unsubscribe csound"

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

[Jacob Joaquin]

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 [e-mail] with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email [e-mail] with body "unsubscribe csound"

[Stéphane Rollandin]

> 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



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

[David Worrall]

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@... with body "unsubscribe csound"

[Victor Lazzarini]

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

Victor

----- Original Message -----
From: "DavidW" <vip@...>
To: <csound@...>
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@... with body "unsubscribe
csound"=



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

[David Worrall]

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@... with body "unsubscribe csound"

[Steven Yi]

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 <vip@...> 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@... with body "unsubscribe
> csound"
>

--
Sent from my mobile device


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

[Dr. Richard Boulanger]

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@... with body
>>> "unsubscribe csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... 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@... with body  
> "unsubscribe csound"

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

[David Worrall]

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 <vip@...> 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@... with body "unsubscribe csound"

[john ffitch]

>>>>> =?UTF-8?B?U3TDqXBoYW5lIFJvbGxhbmRpbg==?=  <lecteur@...> writes:

 >> 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.

The additional columns show the difference between the written p2/p3
values and the values after warping via the score t command

==John


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

[Stéphane Rollandin]

jpff a écrit :
> The additional columns show the difference between the written p2/p3
> values and the values after warping via the score t command

aah thanks. I guess I should have asked before :)


Stef




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

[Stéphane Rollandin]

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



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

[Victor Lazzarini]

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" <vip@...>
To: <csound@...>
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@... with body "unsubscribe
> csound"

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