I'm currently working on an algorithmic program that requires  
manipulating tables and arrays in various ways. I've been struck by  
how difficult it has been for me to work with fairly simple data  
constructs currently supported by Csound.

I imagine that this has been understood for a long time, and the  
notion of somehow including python with Csound has been the technical  
solution.

My problem with this solution is that as I read postings on this list,  
I get the impression that the integration of python with Csound is not  
robust. It seems that there are version-skew issues and other  
installation issues. Because of those I've been afraid to invest time  
in using python as an extension of Csound.

So I'm wondering why Csound was never extended to handle such things as:

arrays (2, 3 or more dimensions) that can be accessed like kvar(2,3,4).

records (aka objects) that can be accessed like  
recordfoo.subrecordA.kvar(2,3,4)

...and why other common language constructs have not been added, such  
as:

while...do
for
subroutine(a,b,c)

Is there some history about all this?

best,
Lou Cohen



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

I wish I had more time to implement this...

https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays

Cheers,
Andres

On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin  wrote:
> You can fake records within Csound, but it isn't pretty.  :)
> http://csound.noisepages.com/2009/12/making-records/
> Jake
> --
> The Csound Blog - http://csoundblog.com/
> Slipmat - http://slipmat.noisepages.com/
>
> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen  wrote:
>>
>> I'm currently working on an algorithmic program that requires manipulating
>> tables and arrays in various ways. I've been struck by how difficult it has
>> been for me to work with fairly simple data constructs currently supported
>> by Csound.
>>
>> I imagine that this has been understood for a long time, and the notion of
>> somehow including python with Csound has been the technical solution.
>>
>> My problem with this solution is that as I read postings on this list, I
>> get the impression that the integration of python with Csound is not robust.
>> It seems that there are version-skew issues and other installation issues.
>> Because of those I've been afraid to invest time in using python as an
>> extension of Csound.
>>
>> So I'm wondering why Csound was never extended to handle such things as:
>>
>> arrays (2, 3 or more dimensions) that can be accessed like kvar(2,3,4).
>>
>> records (aka objects) that can be accessed like
>> recordfoo.subrecordA.kvar(2,3,4)
>>
>> ...and why other common language constructs have not been added, such as:
>>
>> while...do
>> for
>> subroutine(a,b,c)
>>
>> Is there some history about all this?
>>
>> best,
>> Lou Cohen
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>


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

One of the main reasons for starting the new-parser hare was to make it
feasible for language developements.  However some of the suggestions are
semantically problematic and some are a great deal of work.

Not everyone can or wishes to work on python or java.  If I want real
processing i use C usually because I do not have a nice LISP available.

Perhaps we ought to face up to these questions in Hannover.

==John ff

> It's funny---I usually would curse at stuff like the really cave-man like
> primitiveness of the Csound spec that it doesn't have arrays, only tables;
> but then again, somehow working with those limitations is kind of a fun
> challenge. I'm of both minds, too---Csound should have arrays, ideally.
>
> I can see why people want to integrate Python more fully, so these things
> can be handled easily. I'm a total Python devotee!
>
> AKJ
>
> On Fri, Jun 3, 2011 at 9:40 AM, Andres Cabrera
> wrote:
>
>> I wish I had more time to implement this...
>>
>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>
>> Cheers,
>> Andres
>>
>> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin 
>> wrote:
>> > You can fake records within Csound, but it isn't pretty.  :)
>> > http://csound.noisepages.com/2009/12/making-records/
>> > Jake
>> > --
>> > The Csound Blog - http://csoundblog.com/
>> > Slipmat - http://slipmat.noisepages.com/
>> >
>> > On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen  wrote:
>> >>
>> >> I'm currently working on an algorithmic program that requires
>> manipulating
>> >> tables and arrays in various ways. I've been struck by how difficult
>> it
>> has
>> >> been for me to work with fairly simple data constructs currently
>> supported
>> >> by Csound.
>> >>
>> >> I imagine that this has been understood for a long time, and the
>> notion
>> of
>> >> somehow including python with Csound has been the technical solution.
>> >>
>> >> My problem with this solution is that as I read postings on this
>> list, I
>> >> get the impression that the integration of python with Csound is not
>> robust.
>> >> It seems that there are version-skew issues and other installation
>> issues.
>> >> Because of those I've been afraid to invest time in using python as
>> an
>> >> extension of Csound.
>> >>
>> >> So I'm wondering why Csound was never extended to handle such things
>> as:
>> >>
>> >> arrays (2, 3 or more dimensions) that can be accessed like
>> kvar(2,3,4).
>> >>
>> >> records (aka objects) that can be accessed like
>> >> recordfoo.subrecordA.kvar(2,3,4)
>> >>
>> >> ...and why other common language constructs have not been added, such
>> as:
>> >>
>> >> while...do
>> >> for
>> >> subroutine(a,b,c)
>> >>
>> >> Is there some history about all this?
>> >>
>> >> best,
>> >> Lou Cohen
>> >>
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe
>> >> csound"
>> >>
>> >
>> >
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
> --
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>




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

Andres,

That proposal would be a great help if implemented! Of course it's not  
impossible to write UDOs that convert ftables into multi-dimensional  
arrays, and I've done that; it's just clumsy to use, compared to the  
more conventional notation such as kvar(4,5) or kvar(kindex1, kindex2).

-Lou


On Jun 3, 2011, at 10:40 AM, Andres Cabrera wrote:

> I wish I had more time to implement this...
>
> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>
> Cheers,
> Andres
>
> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin  
>  wrote:
>> You can fake records within Csound, but it isn't pretty.  :)
>> http://csound.noisepages.com/2009/12/making-records/
>> Jake
>> --
>> The Csound Blog - http://csoundblog.com/
>> Slipmat - http://slipmat.noisepages.com/
>>
>> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen   
>> wrote:
>>>
>>> I'm currently working on an algorithmic program that requires  
>>> manipulating
>>> tables and arrays in various ways. I've been struck by how  
>>> difficult it has
>>> been for me to work with fairly simple data constructs currently  
>>> supported
>>> by Csound.
>>>
>>> I imagine that this has been understood for a long time, and the  
>>> notion of
>>> somehow including python with Csound has been the technical  
>>> solution.
>>>
>>> My problem with this solution is that as I read postings on this  
>>> list, I
>>> get the impression that the integration of python with Csound is  
>>> not robust.
>>> It seems that there are version-skew issues and other installation  
>>> issues.
>>> Because of those I've been afraid to invest time in using python  
>>> as an
>>> extension of Csound.
>>>
>>> So I'm wondering why Csound was never extended to handle such  
>>> things as:
>>>
>>> arrays (2, 3 or more dimensions) that can be accessed like  
>>> kvar(2,3,4).
>>>
>>> records (aka objects) that can be accessed like
>>> recordfoo.subrecordA.kvar(2,3,4)
>>>
>>> ...and why other common language constructs have not been added,  
>>> such as:
>>>
>>> while...do
>>> for
>>> subroutine(a,b,c)
>>>
>>> Is there some history about all this?
>>>
>>> best,
>>> Lou Cohen
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/? 
>>> group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



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

There's also the linear algebra opcodes to use for arrays:

http://csounds.com/manual/html/linearalgebraopcodes.html



On Fri, Jun 3, 2011 at 10:54 AM, Louis Cohen  wrote:
> Andres,
>
> That proposal would be a great help if implemented! Of course it's not
> impossible to write UDOs that convert ftables into multi-dimensional arrays,
> and I've done that; it's just clumsy to use, compared to the more
> conventional notation such as kvar(4,5) or kvar(kindex1, kindex2).
>
> -Lou
>
>
> On Jun 3, 2011, at 10:40 AM, Andres Cabrera wrote:
>
>> I wish I had more time to implement this...
>>
>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>
>> Cheers,
>> Andres
>>
>> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin 
>> wrote:
>>>
>>> You can fake records within Csound, but it isn't pretty.  :)
>>> http://csound.noisepages.com/2009/12/making-records/
>>> Jake
>>> --
>>> The Csound Blog - http://csoundblog.com/
>>> Slipmat - http://slipmat.noisepages.com/
>>>
>>> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen  wrote:
>>>>
>>>> I'm currently working on an algorithmic program that requires
>>>> manipulating
>>>> tables and arrays in various ways. I've been struck by how difficult it
>>>> has
>>>> been for me to work with fairly simple data constructs currently
>>>> supported
>>>> by Csound.
>>>>
>>>> I imagine that this has been understood for a long time, and the notion
>>>> of
>>>> somehow including python with Csound has been the technical solution.
>>>>
>>>> My problem with this solution is that as I read postings on this list, I
>>>> get the impression that the integration of python with Csound is not
>>>> robust.
>>>> It seems that there are version-skew issues and other installation
>>>> issues.
>>>> Because of those I've been afraid to invest time in using python as an
>>>> extension of Csound.
>>>>
>>>> So I'm wondering why Csound was never extended to handle such things as:
>>>>
>>>> arrays (2, 3 or more dimensions) that can be accessed like kvar(2,3,4).
>>>>
>>>> records (aka objects) that can be accessed like
>>>> recordfoo.subrecordA.kvar(2,3,4)
>>>>
>>>> ...and why other common language constructs have not been added, such
>>>> as:
>>>>
>>>> while...do
>>>> for
>>>> subroutine(a,b,c)
>>>>
>>>> Is there some history about all this?
>>>>
>>>> best,
>>>> Lou Cohen
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


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

I understand that this could be a monumental project. As with other  
software overhauls, perhaps the best approach would be:

1. hammer out the syntax of all proposed extensions, agree on it
2. pick the easiest remaining extension and add it in
3. take stock of the project, having learned from the first attempt
4. kgoto 1. if absolutely necessary, or maybe kgoto 2.

-Lou

On Jun 3, 2011, at 10:49 AM, jpff@cs.bath.ac.uk wrote:

> One of the main reasons for starting the new-parser hare was to make  
> it
> feasible for language developements.  However some of the  
> suggestions are
> semantically problematic and some are a great deal of work.
>
> Not everyone can or wishes to work on python or java.  If I want real
> processing i use C usually because I do not have a nice LISP  
> available.
>
> Perhaps we ought to face up to these questions in Hannover.
>
> ==John ff
>
>> It's funny---I usually would curse at stuff like the really cave- 
>> man like
>> primitiveness of the Csound spec that it doesn't have arrays, only  
>> tables;
>> but then again, somehow working with those limitations is kind of a  
>> fun
>> challenge. I'm of both minds, too---Csound should have arrays,  
>> ideally.
>>
>> I can see why people want to integrate Python more fully, so these  
>> things
>> can be handled easily. I'm a total Python devotee!
>>
>> AKJ
>>
>> On Fri, Jun 3, 2011 at 9:40 AM, Andres Cabrera
>> wrote:
>>
>>> I wish I had more time to implement this...
>>>
>>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>
>>> Cheers,
>>> Andres
>>>
>>> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin >> >
>>> wrote:
>>>> You can fake records within Csound, but it isn't pretty.  :)
>>>> http://csound.noisepages.com/2009/12/making-records/
>>>> Jake
>>>> --
>>>> The Csound Blog - http://csoundblog.com/
>>>> Slipmat - http://slipmat.noisepages.com/
>>>>
>>>> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen   
>>>> wrote:
>>>>>
>>>>> I'm currently working on an algorithmic program that requires
>>> manipulating
>>>>> tables and arrays in various ways. I've been struck by how  
>>>>> difficult
>>> it
>>> has
>>>>> been for me to work with fairly simple data constructs currently
>>> supported
>>>>> by Csound.
>>>>>
>>>>> I imagine that this has been understood for a long time, and the
>>> notion
>>> of
>>>>> somehow including python with Csound has been the technical  
>>>>> solution.
>>>>>
>>>>> My problem with this solution is that as I read postings on this
>>> list, I
>>>>> get the impression that the integration of python with Csound is  
>>>>> not
>>> robust.
>>>>> It seems that there are version-skew issues and other installation
>>> issues.
>>>>> Because of those I've been afraid to invest time in using python  
>>>>> as
>>> an
>>>>> extension of Csound.
>>>>>
>>>>> So I'm wondering why Csound was never extended to handle such  
>>>>> things
>>> as:
>>>>>
>>>>> arrays (2, 3 or more dimensions) that can be accessed like
>>> kvar(2,3,4).
>>>>>
>>>>> records (aka objects) that can be accessed like
>>>>> recordfoo.subrecordA.kvar(2,3,4)
>>>>>
>>>>> ...and why other common language constructs have not been added,  
>>>>> such
>>> as:
>>>>>
>>>>> while...do
>>>>> for
>>>>> subroutine(a,b,c)
>>>>>
>>>>> Is there some history about all this?
>>>>>
>>>>> best,
>>>>> Lou Cohen
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/? 
>>> group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>> --
>> Aaron Krister Johnson
>> http://www.akjmusic.com
>> http://www.untwelve.org
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/? 
>> group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



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

Steven,

I considered the linear algebra opcodes but decided I couldn't use  
them easily because they deliver array elements as named variables.  
Therefore there was no easy way to use an index to access them. I  
might have considered some sort of string manipulation to convert from  
a numerical index to a variable name, but it seemed that my code would  
be too hard to work with.

I took the UDO approach instead, converting a one-dimensional table  
into an array and storing and retrieving from it with a UDO that took  
my index as a parameter. Of course I needed additional parameters,  
such as the ftable number and the shape of the array, and this is one  
reason why I wrote my initial posting to this list.

-Lou

On Jun 3, 2011, at 11:00 AM, Steven Yi wrote:

> There's also the linear algebra opcodes to use for arrays:
>
> http://csounds.com/manual/html/linearalgebraopcodes.html
>
>
>
> On Fri, Jun 3, 2011 at 10:54 AM, Louis Cohen   
> wrote:
>> Andres,
>>
>> That proposal would be a great help if implemented! Of course it's  
>> not
>> impossible to write UDOs that convert ftables into multi- 
>> dimensional arrays,
>> and I've done that; it's just clumsy to use, compared to the more
>> conventional notation such as kvar(4,5) or kvar(kindex1, kindex2).
>>
>> -Lou
>>
>>
>> On Jun 3, 2011, at 10:40 AM, Andres Cabrera wrote:
>>
>>> I wish I had more time to implement this...
>>>
>>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>
>>> Cheers,
>>> Andres
>>>
>>> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin >> >
>>> wrote:
>>>>
>>>> You can fake records within Csound, but it isn't pretty.  :)
>>>> http://csound.noisepages.com/2009/12/making-records/
>>>> Jake
>>>> --
>>>> The Csound Blog - http://csoundblog.com/
>>>> Slipmat - http://slipmat.noisepages.com/
>>>>
>>>> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen   
>>>> wrote:
>>>>>
>>>>> I'm currently working on an algorithmic program that requires
>>>>> manipulating
>>>>> tables and arrays in various ways. I've been struck by how  
>>>>> difficult it
>>>>> has
>>>>> been for me to work with fairly simple data constructs currently
>>>>> supported
>>>>> by Csound.
>>>>>
>>>>> I imagine that this has been understood for a long time, and the  
>>>>> notion
>>>>> of
>>>>> somehow including python with Csound has been the technical  
>>>>> solution.
>>>>>
>>>>> My problem with this solution is that as I read postings on this  
>>>>> list, I
>>>>> get the impression that the integration of python with Csound is  
>>>>> not
>>>>> robust.
>>>>> It seems that there are version-skew issues and other installation
>>>>> issues.
>>>>> Because of those I've been afraid to invest time in using python  
>>>>> as an
>>>>> extension of Csound.
>>>>>
>>>>> So I'm wondering why Csound was never extended to handle such  
>>>>> things as:
>>>>>
>>>>> arrays (2, 3 or more dimensions) that can be accessed like  
>>>>> kvar(2,3,4).
>>>>>
>>>>> records (aka objects) that can be accessed like
>>>>> recordfoo.subrecordA.kvar(2,3,4)
>>>>>
>>>>> ...and why other common language constructs have not been added,  
>>>>> such
>>>>> as:
>>>>>
>>>>> while...do
>>>>> for
>>>>> subroutine(a,b,c)
>>>>>
>>>>> Is there some history about all this?
>>>>>
>>>>> best,
>>>>> Lou Cohen
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/? 
>>> group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



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

I would have no problem using python as the language extension to  
csound if the integration were transparent to me. But as I read about  
difficulties people have had, I felt that in order to control my  
environment I would have to much more savvy than I am today about how  
software gets installed on my system.

For me, the be "freed to be more creative ..." means not having to  
think about putting binaries in system directories.

I guess "freedom" means different things to different people.

-Lou

On Jun 3, 2011, at 11:02 AM, Anthony Palomba wrote:

> "Not everyone can or wishes to work on python or java.  If I want real
> processing i use C usually because I do not have a nice LISP  
> available."
>
> But that assumes that you have access to source that does
> that numerical computation you want. You may or may not be able to
> write your own private library to do these tasks.
>
> I think the whole point of python is that I have the ability to  
> leverage
> all sorts of third party packages, like Scipy, and use them in my
> compositions and instruments.
>
> Thus freeing me to be more creative and not reproduce other peoples  
> work.
>
>
>
> -ap
>
>
>
>
> On Fri, Jun 3, 2011 at 9:49 AM,  wrote:
> One of the main reasons for starting the new-parser hare was to make  
> it
> feasible for language developements.  However some of the  
> suggestions are
> semantically problematic and some are a great deal of work.
>
> Not everyone can or wishes to work on python or java.  If I want real
> processing i use C usually because I do not have a nice LISP  
> available.
>
> Perhaps we ought to face up to these questions in Hannover.
>
> ==John ff
>
> > It's funny---I usually would curse at stuff like the really cave- 
> man like
> > primitiveness of the Csound spec that it doesn't have arrays, only  
> tables;
> > but then again, somehow working with those limitations is kind of  
> a fun
> > challenge. I'm of both minds, too---Csound should have arrays,  
> ideally.
> >
> > I can see why people want to integrate Python more fully, so these  
> things
> > can be handled easily. I'm a total Python devotee!
> >
> > AKJ
> >
> > On Fri, Jun 3, 2011 at 9:40 AM, Andres Cabrera
> > wrote:
> >
> >> I wish I had more time to implement this...
> >>
> >> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
> >>
> >> Cheers,
> >> Andres
> >>
> >> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin  >
> >> wrote:
> >> > You can fake records within Csound, but it isn't pretty.  :)
> >> > http://csound.noisepages.com/2009/12/making-records/
> >> > Jake
> >> > --
> >> > The Csound Blog - http://csoundblog.com/
> >> > Slipmat - http://slipmat.noisepages.com/
> >> >
> >> > On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen   
> wrote:
> >> >>
> >> >> I'm currently working on an algorithmic program that requires
> >> manipulating
> >> >> tables and arrays in various ways. I've been struck by how  
> difficult
> >> it
> >> has
> >> >> been for me to work with fairly simple data constructs currently
> >> supported
> >> >> by Csound.
> >> >>
> >> >> I imagine that this has been understood for a long time, and the
> >> notion
> >> of
> >> >> somehow including python with Csound has been the technical  
> solution.
> >> >>
> >> >> My problem with this solution is that as I read postings on this
> >> list, I
> >> >> get the impression that the integration of python with Csound  
> is not
> >> robust.
> >> >> It seems that there are version-skew issues and other  
> installation
> >> issues.
> >> >> Because of those I've been afraid to invest time in using  
> python as
> >> an
> >> >> extension of Csound.
> >> >>
> >> >> So I'm wondering why Csound was never extended to handle such  
> things
> >> as:
> >> >>
> >> >> arrays (2, 3 or more dimensions) that can be accessed like
> >> kvar(2,3,4).
> >> >>
> >> >> records (aka objects) that can be accessed like
> >> >> recordfoo.subrecordA.kvar(2,3,4)
> >> >>
> >> >> ...and why other common language constructs have not been  
> added, such
> >> as:
> >> >>
> >> >> while...do
> >> >> for
> >> >> subroutine(a,b,c)
> >> >>
> >> >> Is there some history about all this?
> >> >>
> >> >> best,
> >> >> Lou Cohen
> >> >>
> >> >>
> >> >>
> >> >> Send bugs reports to the Sourceforge bug tracker
> >> >>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> >> >> Discussions of bugs and features can be posted here
> >> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
> >> "unsubscribe
> >> >> csound"
> >> >>
> >> >
> >> >
> >>
> >>
> >> Send bugs reports to the Sourceforge bug tracker
> >>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> >> Discussions of bugs and features can be posted here
> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe
> >> csound"
> >>
> >>
> >
> >
> > --
> > Aaron Krister Johnson
> > http://www.akjmusic.com
> > http://www.untwelve.org
> >
> > Send bugs reports to the Sourceforge bug tracker
> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> > Discussions of bugs and features can be posted here
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe
> > csound"
> >
> >
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>
>



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

Hi Louis,

I think I'm not quite getting what you're explaining.  The following
two opcodes allow grabbing values from a vector using an index:

ivalue                      la_i_get_vr           ivr, irow
kvalue                      la_k_get_vr           ivr, krow

(the irow parameter)

One can create matrices as well to do arrays of arrays, inspect
lengths of vectors, etc.

steven


On Fri, Jun 3, 2011 at 11:29 AM, Louis Cohen  wrote:
> Steven,
>
> I considered the linear algebra opcodes but decided I couldn't use them
> easily because they deliver array elements as named variables. Therefore
> there was no easy way to use an index to access them. I might have
> considered some sort of string manipulation to convert from a numerical
> index to a variable name, but it seemed that my code would be too hard to
> work with.
>
> I took the UDO approach instead, converting a one-dimensional table into an
> array and storing and retrieving from it with a UDO that took my index as a
> parameter. Of course I needed additional parameters, such as the ftable
> number and the shape of the array, and this is one reason why I wrote my
> initial posting to this list.
>
> -Lou
>
> On Jun 3, 2011, at 11:00 AM, Steven Yi wrote:
>
>> There's also the linear algebra opcodes to use for arrays:
>>
>> http://csounds.com/manual/html/linearalgebraopcodes.html
>>
>>
>>
>> On Fri, Jun 3, 2011 at 10:54 AM, Louis Cohen  wrote:
>>>
>>> Andres,
>>>
>>> That proposal would be a great help if implemented! Of course it's not
>>> impossible to write UDOs that convert ftables into multi-dimensional
>>> arrays,
>>> and I've done that; it's just clumsy to use, compared to the more
>>> conventional notation such as kvar(4,5) or kvar(kindex1, kindex2).
>>>
>>> -Lou
>>>
>>>
>>> On Jun 3, 2011, at 10:40 AM, Andres Cabrera wrote:
>>>
>>>> I wish I had more time to implement this...
>>>>
>>>>
>>>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>>
>>>> Cheers,
>>>> Andres
>>>>
>>>> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin 
>>>> wrote:
>>>>>
>>>>> You can fake records within Csound, but it isn't pretty.  :)
>>>>> http://csound.noisepages.com/2009/12/making-records/
>>>>> Jake
>>>>> --
>>>>> The Csound Blog - http://csoundblog.com/
>>>>> Slipmat - http://slipmat.noisepages.com/
>>>>>
>>>>> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen  wrote:
>>>>>>
>>>>>> I'm currently working on an algorithmic program that requires
>>>>>> manipulating
>>>>>> tables and arrays in various ways. I've been struck by how difficult
>>>>>> it
>>>>>> has
>>>>>> been for me to work with fairly simple data constructs currently
>>>>>> supported
>>>>>> by Csound.
>>>>>>
>>>>>> I imagine that this has been understood for a long time, and the
>>>>>> notion
>>>>>> of
>>>>>> somehow including python with Csound has been the technical solution.
>>>>>>
>>>>>> My problem with this solution is that as I read postings on this list,
>>>>>> I
>>>>>> get the impression that the integration of python with Csound is not
>>>>>> robust.
>>>>>> It seems that there are version-skew issues and other installation
>>>>>> issues.
>>>>>> Because of those I've been afraid to invest time in using python as an
>>>>>> extension of Csound.
>>>>>>
>>>>>> So I'm wondering why Csound was never extended to handle such things
>>>>>> as:
>>>>>>
>>>>>> arrays (2, 3 or more dimensions) that can be accessed like
>>>>>> kvar(2,3,4).
>>>>>>
>>>>>> records (aka objects) that can be accessed like
>>>>>> recordfoo.subrecordA.kvar(2,3,4)
>>>>>>
>>>>>> ...and why other common language constructs have not been added, such
>>>>>> as:
>>>>>>
>>>>>> while...do
>>>>>> for
>>>>>> subroutine(a,b,c)
>>>>>>
>>>>>> Is there some history about all this?
>>>>>>
>>>>>> best,
>>>>>> Lou Cohen
>>>>>>
>>>>>>
>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


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

Hmm... I just realized I don't even have these opcodes on my OSX
machine. I tried to compile gmm+ which is required for these opcodes
and it failed on OSX.  I didn't see them in the OSX installer build
either.  Maybe not going to work out.

On Fri, Jun 3, 2011 at 12:41 PM, Steven Yi  wrote:
> Hi Louis,
>
> I think I'm not quite getting what you're explaining.  The following
> two opcodes allow grabbing values from a vector using an index:
>
> ivalue                      la_i_get_vr           ivr, irow
> kvalue                      la_k_get_vr           ivr, krow
>
> (the irow parameter)
>
> One can create matrices as well to do arrays of arrays, inspect
> lengths of vectors, etc.
>
> steven
>
>
> On Fri, Jun 3, 2011 at 11:29 AM, Louis Cohen  wrote:
>> Steven,
>>
>> I considered the linear algebra opcodes but decided I couldn't use them
>> easily because they deliver array elements as named variables. Therefore
>> there was no easy way to use an index to access them. I might have
>> considered some sort of string manipulation to convert from a numerical
>> index to a variable name, but it seemed that my code would be too hard to
>> work with.
>>
>> I took the UDO approach instead, converting a one-dimensional table into an
>> array and storing and retrieving from it with a UDO that took my index as a
>> parameter. Of course I needed additional parameters, such as the ftable
>> number and the shape of the array, and this is one reason why I wrote my
>> initial posting to this list.
>>
>> -Lou
>>
>> On Jun 3, 2011, at 11:00 AM, Steven Yi wrote:
>>
>>> There's also the linear algebra opcodes to use for arrays:
>>>
>>> http://csounds.com/manual/html/linearalgebraopcodes.html
>>>
>>>
>>>
>>> On Fri, Jun 3, 2011 at 10:54 AM, Louis Cohen  wrote:
>>>>
>>>> Andres,
>>>>
>>>> That proposal would be a great help if implemented! Of course it's not
>>>> impossible to write UDOs that convert ftables into multi-dimensional
>>>> arrays,
>>>> and I've done that; it's just clumsy to use, compared to the more
>>>> conventional notation such as kvar(4,5) or kvar(kindex1, kindex2).
>>>>
>>>> -Lou
>>>>
>>>>
>>>> On Jun 3, 2011, at 10:40 AM, Andres Cabrera wrote:
>>>>
>>>>> I wish I had more time to implement this...
>>>>>
>>>>>
>>>>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>>>
>>>>> Cheers,
>>>>> Andres
>>>>>
>>>>> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin 
>>>>> wrote:
>>>>>>
>>>>>> You can fake records within Csound, but it isn't pretty.  :)
>>>>>> http://csound.noisepages.com/2009/12/making-records/
>>>>>> Jake
>>>>>> --
>>>>>> The Csound Blog - http://csoundblog.com/
>>>>>> Slipmat - http://slipmat.noisepages.com/
>>>>>>
>>>>>> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen  wrote:
>>>>>>>
>>>>>>> I'm currently working on an algorithmic program that requires
>>>>>>> manipulating
>>>>>>> tables and arrays in various ways. I've been struck by how difficult
>>>>>>> it
>>>>>>> has
>>>>>>> been for me to work with fairly simple data constructs currently
>>>>>>> supported
>>>>>>> by Csound.
>>>>>>>
>>>>>>> I imagine that this has been understood for a long time, and the
>>>>>>> notion
>>>>>>> of
>>>>>>> somehow including python with Csound has been the technical solution.
>>>>>>>
>>>>>>> My problem with this solution is that as I read postings on this list,
>>>>>>> I
>>>>>>> get the impression that the integration of python with Csound is not
>>>>>>> robust.
>>>>>>> It seems that there are version-skew issues and other installation
>>>>>>> issues.
>>>>>>> Because of those I've been afraid to invest time in using python as an
>>>>>>> extension of Csound.
>>>>>>>
>>>>>>> So I'm wondering why Csound was never extended to handle such things
>>>>>>> as:
>>>>>>>
>>>>>>> arrays (2, 3 or more dimensions) that can be accessed like
>>>>>>> kvar(2,3,4).
>>>>>>>
>>>>>>> records (aka objects) that can be accessed like
>>>>>>> recordfoo.subrecordA.kvar(2,3,4)
>>>>>>>
>>>>>>> ...and why other common language constructs have not been added, such
>>>>>>> as:
>>>>>>>
>>>>>>> while...do
>>>>>>> for
>>>>>>> subroutine(a,b,c)
>>>>>>>
>>>>>>> Is there some history about all this?
>>>>>>>
>>>>>>> best,
>>>>>>> Lou Cohen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>> "unsubscribe
>>>>>>> csound"
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>


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

Steven,

I was referring to the vectorial opcodes such as vtablek.

I hadn't noticed the opcodes you've identified. Thanks for pointing  
them out. I would have used them if I had realized they were there. I  
still might switch to them.

-Lou


On Jun 3, 2011, at 12:41 PM, Steven Yi wrote:

> Hi Louis,
>
> I think I'm not quite getting what you're explaining.  The following
> two opcodes allow grabbing values from a vector using an index:
>
> ivalue                      la_i_get_vr           ivr, irow
> kvalue                      la_k_get_vr           ivr, krow
>
> (the irow parameter)
>
> One can create matrices as well to do arrays of arrays, inspect
> lengths of vectors, etc.
>
> steven
>
>
> On Fri, Jun 3, 2011 at 11:29 AM, Louis Cohen   
> wrote:
>> Steven,
>>
>> I considered the linear algebra opcodes but decided I couldn't use  
>> them
>> easily because they deliver array elements as named variables.  
>> Therefore
>> there was no easy way to use an index to access them. I might have
>> considered some sort of string manipulation to convert from a  
>> numerical
>> index to a variable name, but it seemed that my code would be too  
>> hard to
>> work with.
>>
>> I took the UDO approach instead, converting a one-dimensional table  
>> into an
>> array and storing and retrieving from it with a UDO that took my  
>> index as a
>> parameter. Of course I needed additional parameters, such as the  
>> ftable
>> number and the shape of the array, and this is one reason why I  
>> wrote my
>> initial posting to this list.
>>
>> -Lou
>>
>> On Jun 3, 2011, at 11:00 AM, Steven Yi wrote:
>>
>>> There's also the linear algebra opcodes to use for arrays:
>>>
>>> http://csounds.com/manual/html/linearalgebraopcodes.html
>>>
>>>
>>>
>>> On Fri, Jun 3, 2011 at 10:54 AM, Louis Cohen   
>>> wrote:
>>>>
>>>> Andres,
>>>>
>>>> That proposal would be a great help if implemented! Of course  
>>>> it's not
>>>> impossible to write UDOs that convert ftables into multi- 
>>>> dimensional
>>>> arrays,
>>>> and I've done that; it's just clumsy to use, compared to the more
>>>> conventional notation such as kvar(4,5) or kvar(kindex1, kindex2).
>>>>
>>>> -Lou
>>>>
>>>>
>>>> On Jun 3, 2011, at 10:40 AM, Andres Cabrera wrote:
>>>>
>>>>> I wish I had more time to implement this...
>>>>>
>>>>>
>>>>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>>>
>>>>> Cheers,
>>>>> Andres
>>>>>
>>>>> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin >>>> >
>>>>> wrote:
>>>>>>
>>>>>> You can fake records within Csound, but it isn't pretty.  :)
>>>>>> http://csound.noisepages.com/2009/12/making-records/
>>>>>> Jake
>>>>>> --
>>>>>> The Csound Blog - http://csoundblog.com/
>>>>>> Slipmat - http://slipmat.noisepages.com/
>>>>>>
>>>>>> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen   
>>>>>> wrote:
>>>>>>>
>>>>>>> I'm currently working on an algorithmic program that requires
>>>>>>> manipulating
>>>>>>> tables and arrays in various ways. I've been struck by how  
>>>>>>> difficult
>>>>>>> it
>>>>>>> has
>>>>>>> been for me to work with fairly simple data constructs currently
>>>>>>> supported
>>>>>>> by Csound.
>>>>>>>
>>>>>>> I imagine that this has been understood for a long time, and the
>>>>>>> notion
>>>>>>> of
>>>>>>> somehow including python with Csound has been the technical  
>>>>>>> solution.
>>>>>>>
>>>>>>> My problem with this solution is that as I read postings on  
>>>>>>> this list,
>>>>>>> I
>>>>>>> get the impression that the integration of python with Csound  
>>>>>>> is not
>>>>>>> robust.
>>>>>>> It seems that there are version-skew issues and other  
>>>>>>> installation
>>>>>>> issues.
>>>>>>> Because of those I've been afraid to invest time in using  
>>>>>>> python as an
>>>>>>> extension of Csound.
>>>>>>>
>>>>>>> So I'm wondering why Csound was never extended to handle such  
>>>>>>> things
>>>>>>> as:
>>>>>>>
>>>>>>> arrays (2, 3 or more dimensions) that can be accessed like
>>>>>>> kvar(2,3,4).
>>>>>>>
>>>>>>> records (aka objects) that can be accessed like
>>>>>>> recordfoo.subrecordA.kvar(2,3,4)
>>>>>>>
>>>>>>> ...and why other common language constructs have not been  
>>>>>>> added, such
>>>>>>> as:
>>>>>>>
>>>>>>> while...do
>>>>>>> for
>>>>>>> subroutine(a,b,c)
>>>>>>>
>>>>>>> Is there some history about all this?
>>>>>>>
>>>>>>> best,
>>>>>>> Lou Cohen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>> "unsubscribe
>>>>>>> csound"
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>          https://sourceforge.net/tracker/? 
>>>> group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/? 
>>> group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



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

I think they are only built for doubles versions.


> Hmm... I just realized I don't even have these opcodes on my OSX
> machine. I tried to compile gmm+ which is required for these opcodes
> and it failed on OSX.  I didn't see them in the OSX installer build
> either.  Maybe not going to work out.
>
> On Fri, Jun 3, 2011 at 12:41 PM, Steven Yi  wrote:
>> Hi Louis,
>>
>> I think I'm not quite getting what you're explaining.  The following
>> two opcodes allow grabbing values from a vector using an index:
>>
>> ivalue                      la_i_get_vr           ivr, irow
>> kvalue                      la_k_get_vr           ivr, krow
>>
>> (the irow parameter)
>>
>> One can create matrices as well to do arrays of arrays, inspect
>> lengths of vectors, etc.
>>
>> steven
>>
>>
>> On Fri, Jun 3, 2011 at 11:29 AM, Louis Cohen  wrote:
>>> Steven,
>>>
>>> I considered the linear algebra opcodes but decided I couldn't use them
>>> easily because they deliver array elements as named variables.
>>> Therefore
>>> there was no easy way to use an index to access them. I might have
>>> considered some sort of string manipulation to convert from a numerical
>>> index to a variable name, but it seemed that my code would be too hard
>>> to
>>> work with.
>>>
>>> I took the UDO approach instead, converting a one-dimensional table
>>> into an
>>> array and storing and retrieving from it with a UDO that took my index
>>> as a
>>> parameter. Of course I needed additional parameters, such as the ftable
>>> number and the shape of the array, and this is one reason why I wrote
>>> my
>>> initial posting to this list.
>>>
>>> -Lou
>>>
>>> On Jun 3, 2011, at 11:00 AM, Steven Yi wrote:
>>>
>>>> There's also the linear algebra opcodes to use for arrays:
>>>>
>>>> http://csounds.com/manual/html/linearalgebraopcodes.html
>>>>
>>>>
>>>>
>>>> On Fri, Jun 3, 2011 at 10:54 AM, Louis Cohen 
>>>> wrote:
>>>>>
>>>>> Andres,
>>>>>
>>>>> That proposal would be a great help if implemented! Of course it's
>>>>> not
>>>>> impossible to write UDOs that convert ftables into multi-dimensional
>>>>> arrays,
>>>>> and I've done that; it's just clumsy to use, compared to the more
>>>>> conventional notation such as kvar(4,5) or kvar(kindex1, kindex2).
>>>>>
>>>>> -Lou
>>>>>
>>>>>
>>>>> On Jun 3, 2011, at 10:40 AM, Andres Cabrera wrote:
>>>>>
>>>>>> I wish I had more time to implement this...
>>>>>>
>>>>>>
>>>>>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>>>>
>>>>>> Cheers,
>>>>>> Andres
>>>>>>
>>>>>> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin
>>>>>> 
>>>>>> wrote:
>>>>>>>
>>>>>>> You can fake records within Csound, but it isn't pretty.  :)
>>>>>>> http://csound.noisepages.com/2009/12/making-records/
>>>>>>> Jake
>>>>>>> --
>>>>>>> The Csound Blog - http://csoundblog.com/
>>>>>>> Slipmat - http://slipmat.noisepages.com/
>>>>>>>
>>>>>>> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm currently working on an algorithmic program that requires
>>>>>>>> manipulating
>>>>>>>> tables and arrays in various ways. I've been struck by how
>>>>>>>> difficult
>>>>>>>> it
>>>>>>>> has
>>>>>>>> been for me to work with fairly simple data constructs currently
>>>>>>>> supported
>>>>>>>> by Csound.
>>>>>>>>
>>>>>>>> I imagine that this has been understood for a long time, and the
>>>>>>>> notion
>>>>>>>> of
>>>>>>>> somehow including python with Csound has been the technical
>>>>>>>> solution.
>>>>>>>>
>>>>>>>> My problem with this solution is that as I read postings on this
>>>>>>>> list,
>>>>>>>> I
>>>>>>>> get the impression that the integration of python with Csound is
>>>>>>>> not
>>>>>>>> robust.
>>>>>>>> It seems that there are version-skew issues and other installation
>>>>>>>> issues.
>>>>>>>> Because of those I've been afraid to invest time in using python
>>>>>>>> as an
>>>>>>>> extension of Csound.
>>>>>>>>
>>>>>>>> So I'm wondering why Csound was never extended to handle such
>>>>>>>> things
>>>>>>>> as:
>>>>>>>>
>>>>>>>> arrays (2, 3 or more dimensions) that can be accessed like
>>>>>>>> kvar(2,3,4).
>>>>>>>>
>>>>>>>> records (aka objects) that can be accessed like
>>>>>>>> recordfoo.subrecordA.kvar(2,3,4)
>>>>>>>>
>>>>>>>> ...and why other common language constructs have not been added,
>>>>>>>> such
>>>>>>>> as:
>>>>>>>>
>>>>>>>> while...do
>>>>>>>> for
>>>>>>>> subroutine(a,b,c)
>>>>>>>>
>>>>>>>> Is there some history about all this?
>>>>>>>>
>>>>>>>> best,
>>>>>>>> Lou Cohen
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>        
>>>>>>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>>> "unsubscribe
>>>>>>>> csound"
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe
>>> csound"
>>>
>>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
>




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

> Perhaps we ought to face up to these questions in Hannover.

yes! definitely.

Cheers,
Andres


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

I have the installer build for floats but I have my local build for
doubles, so I'm not sure if the installer has the la opcodes.  I do
know that I can't build gmm+ here. :(

On Fri, Jun 3, 2011 at 1:34 PM, Michael Gogins  wrote:
> The linear programming opcodes are only built for doubles because Gmm++ is
> only for doubles.
> Regards,
> Mike
>
> On Fri, Jun 3, 2011 at 1:32 PM, Andres Cabrera 
> wrote:
>>
>> > Perhaps we ought to face up to these questions in Hannover.
>>
>> yes! definitely.
>>
>> Cheers,
>> Andres
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>


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

No, they are there, but only in the doubles version (csound64 command).

Victor
On 3 Jun 2011, at 17:51, Steven Yi wrote:

> Hmm... I just realized I don't even have these opcodes on my OSX
> machine. I tried to compile gmm+ which is required for these opcodes
> and it failed on OSX.  I didn't see them in the OSX installer build
> either.  Maybe not going to work out.
>
> On Fri, Jun 3, 2011 at 12:41 PM, Steven Yi  wrote:
>> Hi Louis,
>>
>> I think I'm not quite getting what you're explaining.  The following
>> two opcodes allow grabbing values from a vector using an index:
>>
>> ivalue                      la_i_get_vr           ivr, irow
>> kvalue                      la_k_get_vr           ivr, krow
>>
>> (the irow parameter)
>>
>> One can create matrices as well to do arrays of arrays, inspect
>> lengths of vectors, etc.
>>
>> steven
>>
>>
>> On Fri, Jun 3, 2011 at 11:29 AM, Louis Cohen   
>> wrote:
>>> Steven,
>>>
>>> I considered the linear algebra opcodes but decided I couldn't use  
>>> them
>>> easily because they deliver array elements as named variables.  
>>> Therefore
>>> there was no easy way to use an index to access them. I might have
>>> considered some sort of string manipulation to convert from a  
>>> numerical
>>> index to a variable name, but it seemed that my code would be too  
>>> hard to
>>> work with.
>>>
>>> I took the UDO approach instead, converting a one-dimensional  
>>> table into an
>>> array and storing and retrieving from it with a UDO that took my  
>>> index as a
>>> parameter. Of course I needed additional parameters, such as the  
>>> ftable
>>> number and the shape of the array, and this is one reason why I  
>>> wrote my
>>> initial posting to this list.
>>>
>>> -Lou
>>>
>>> On Jun 3, 2011, at 11:00 AM, Steven Yi wrote:
>>>
>>>> There's also the linear algebra opcodes to use for arrays:
>>>>
>>>> http://csounds.com/manual/html/linearalgebraopcodes.html
>>>>
>>>>
>>>>
>>>> On Fri, Jun 3, 2011 at 10:54 AM, Louis Cohen   
>>>> wrote:
>>>>>
>>>>> Andres,
>>>>>
>>>>> That proposal would be a great help if implemented! Of course  
>>>>> it's not
>>>>> impossible to write UDOs that convert ftables into multi- 
>>>>> dimensional
>>>>> arrays,
>>>>> and I've done that; it's just clumsy to use, compared to the more
>>>>> conventional notation such as kvar(4,5) or kvar(kindex1, kindex2).
>>>>>
>>>>> -Lou
>>>>>
>>>>>
>>>>> On Jun 3, 2011, at 10:40 AM, Andres Cabrera wrote:
>>>>>
>>>>>> I wish I had more time to implement this...
>>>>>>
>>>>>>
>>>>>> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_1-Arrays
>>>>>>
>>>>>> Cheers,
>>>>>> Andres
>>>>>>
>>>>>> On Fri, Jun 3, 2011 at 3:11 PM, Jacob Joaquin >>>>> >
>>>>>> wrote:
>>>>>>>
>>>>>>> You can fake records within Csound, but it isn't pretty.  :)
>>>>>>> http://csound.noisepages.com/2009/12/making-records/
>>>>>>> Jake
>>>>>>> --
>>>>>>> The Csound Blog - http://csoundblog.com/
>>>>>>> Slipmat - http://slipmat.noisepages.com/
>>>>>>>
>>>>>>> On Fri, Jun 3, 2011 at 6:25 AM, Louis Cohen  
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> I'm currently working on an algorithmic program that requires
>>>>>>>> manipulating
>>>>>>>> tables and arrays in various ways. I've been struck by how  
>>>>>>>> difficult
>>>>>>>> it
>>>>>>>> has
>>>>>>>> been for me to work with fairly simple data constructs  
>>>>>>>> currently
>>>>>>>> supported
>>>>>>>> by Csound.
>>>>>>>>
>>>>>>>> I imagine that this has been understood for a long time, and  
>>>>>>>> the
>>>>>>>> notion
>>>>>>>> of
>>>>>>>> somehow including python with Csound has been the technical  
>>>>>>>> solution.
>>>>>>>>
>>>>>>>> My problem with this solution is that as I read postings on  
>>>>>>>> this list,
>>>>>>>> I
>>>>>>>> get the impression that the integration of python with Csound  
>>>>>>>> is not
>>>>>>>> robust.
>>>>>>>> It seems that there are version-skew issues and other  
>>>>>>>> installation
>>>>>>>> issues.
>>>>>>>> Because of those I've been afraid to invest time in using  
>>>>>>>> python as an
>>>>>>>> extension of Csound.
>>>>>>>>
>>>>>>>> So I'm wondering why Csound was never extended to handle such  
>>>>>>>> things
>>>>>>>> as:
>>>>>>>>
>>>>>>>> arrays (2, 3 or more dimensions) that can be accessed like
>>>>>>>> kvar(2,3,4).
>>>>>>>>
>>>>>>>> records (aka objects) that can be accessed like
>>>>>>>> recordfoo.subrecordA.kvar(2,3,4)
>>>>>>>>
>>>>>>>> ...and why other common language constructs have not been  
>>>>>>>> added, such
>>>>>>>> as:
>>>>>>>>
>>>>>>>> while...do
>>>>>>>> for
>>>>>>>> subroutine(a,b,c)
>>>>>>>>
>>>>>>>> Is there some history about all this?
>>>>>>>>
>>>>>>>> best,
>>>>>>>> Lou Cohen
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>>>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>>> "unsubscribe
>>>>>>>> csound"
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>>> Discussions of bugs and features can be posted here
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/? 
>>> group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie





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

I personally enjoy working with the Csound language because it
presents challenges that make me think about the way music is created.
Freedom, to me, means exploring those difficult areas in order to
create more interesting sounds with Csound.

On 6/3/11, Michael Gogins  wrote:
> Another option for you, if you have installed a reasonable C++ compiler, is
> to write your operations in C++ using something like the Eigen numerical
> programmming class library (it is header files only) as plugin opcodes. You
> can do as many opcodes as you like in one single .cpp file, without linking
> to any other libraries, and build the opcodes with one compiler command.
> This, also, will provide the best possible runtime performance.
>
> This only makes sense if you have some C/C++ programming knowledge -- but
> you don't need a lot of it. I'm prepared to help out by answering questions.
>
> Hope this helps,
> Mike
>
> On Fri, Jun 3, 2011 at 1:48 PM, Michael Gogins
> wrote:
>
>> I should add, Eigen supports both doubles and floats.
>>
>> Regards,
>> Mike
>>
>>
>> On Fri, Jun 3, 2011 at 1:45 PM, Michael Gogins
>> wrote:
>>
>>> The linear programming opcodes could be changed to use Eigen, another
>>> linear programming class library for C++, or to use ATLAS (but that
>>> requires
>>> a FORTRAN build). This is not a huge amount of work, but it's not small
>>> either.
>>>
>>> Eigen is the current state of the art in C/C++ numerical programming, as
>>> far as I can tell.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> On Fri, Jun 3, 2011 at 1:42 PM, Steven Yi  wrote:
>>>
>>>> I have the installer build for floats but I have my local build for
>>>> doubles, so I'm not sure if the installer has the la opcodes.  I do
>>>> know that I can't build gmm+ here. :(
>>>>
>>>> On Fri, Jun 3, 2011 at 1:34 PM, Michael Gogins
>>>> 
>>>> wrote:
>>>> > The linear programming opcodes are only built for doubles because
>>>> > Gmm++
>>>> is
>>>> > only for doubles.
>>>> > Regards,
>>>> > Mike
>>>> >
>>>> > On Fri, Jun 3, 2011 at 1:32 PM, Andres Cabrera 
>>>> > wrote:
>>>> >>
>>>> >> > Perhaps we ought to face up to these questions in Hannover.
>>>> >>
>>>> >> yes! definitely.
>>>> >>
>>>> >> Cheers,
>>>> >> Andres
>>>> >>
>>>> >>
>>>> >> Send bugs reports to the Sourceforge bug tracker
>>>> >>
>>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> >> Discussions of bugs and features can be posted here
>>>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> >> csound"
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Michael Gogins
>>>> > Irreducible Productions
>>>> > http://www.michael-gogins.com
>>>> > Michael dot Gogins at gmail dot com
>>>> >
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


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

i agree that it would be great to have all you wish. on the other hand,
at least in my own experience, so much is possible in csound with udo's
and a good program structure. if you would like to share some situations
of your work, i'd be curious if solutions can be found which are simple
enough.
your list should definitely be discussed on the csound conference in
hannover, as john and andrés said.

	joachim


Am 03.06.2011 15:25, schrieb Louis Cohen:
> I'm currently working on an algorithmic program that requires
> manipulating tables and arrays in various ways. I've been struck by how
> difficult it has been for me to work with fairly simple data constructs
> currently supported by Csound.
> 
> I imagine that this has been understood for a long time, and the notion
> of somehow including python with Csound has been the technical solution.
> 
> My problem with this solution is that as I read postings on this list, I
> get the impression that the integration of python with Csound is not
> robust. It seems that there are version-skew issues and other
> installation issues. Because of those I've been afraid to invest time in
> using python as an extension of Csound.
> 
> So I'm wondering why Csound was never extended to handle such things as:
> 
> arrays (2, 3 or more dimensions) that can be accessed like kvar(2,3,4).
> 
> records (aka objects) that can be accessed like
> recordfoo.subrecordA.kvar(2,3,4)
> 
> ...and why other common language constructs have not been added, such as:
> 
> while...do
> for
> subroutine(a,b,c)
> 
> Is there some history about all this?
> 
> best,
> Lou Cohen
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 


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

Basically I agree with you very much.but there is a danger in depending on external software and that is that the interface with csound consumes time, not only in programing but also in the music production work flow, which should be as transparent as possible. For that reason I developed the csound api so that csound could be embedded in ones language of greatest productivity.

On Jun 3, 2011, at 6:50 PM, Michael Gogins wrote:

> Basically I agree with you very much.but there is a danger in  
> depending on external software and that is that the interface with  
> csound consumes time, not only in programing but also in the music  
> production work flow, which should be as transparent as possible.  
> For that reason I developed the csound api so that csound could be  
> embedded in ones language of greatest productivity.

It seems that the debate is:

Should Csound's language be expanded to include at least some features  
that most other languages today have (such as arrays, records/ 
structures...)?

OR

Should Csound have good enough hooks in it so it can function as a  
module -- an extension of python or Java or other programming systems?

I don't understand the inner workings of Csound well enough to know  
which direction would be best. What I would hope for is that if the  
csound api is to be promoted as an appendage to, say python, then it  
would be:

-well documented

-installed by the click of a button

-work the same on several platforms

If this were the case, I would learn python and use python and Csound  
together. But my sense from the postings is that there have been  
problems with the interface between python and Csound. That scares me.  
I don't think I have the skills or background to solve such problems  
on my own.

The programming language I'm already most familiar with is Java. I've  
read a few articles in the Csound Journal about interfacing Java with  
the Csound api. As I recall, I would need to read long libraries of C  
code in order to effectively use the csound api with Java. I'm afraid  
that leaves me out.

As an unsophisticated user, I need the linkage between Csound and some  
other system to be automatic and well documented, and the  
documentation to use terminology and a language that's consistent with  
what I'll be using. Or I need to be able to use Csound alone.

-Lou



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

Hi,

I think arrays are very important data structures for musical usage,
they are in a way wrappers to ftables, which can drastically simplify
code and code maintenance, since it is common in DSP and music that
you want to apply the same process to a long list of values (e.g.
additive synthesis). But I think arrays also offer a very interesting
possibility in terms of computational efficiency. In music languages
in particular, where you have a constantly running loop, arrays can be
used as cues for parallelization. For example, when you pass an array
of frequencies to an oscillator, it is given that the operations are
fully independent and parallelizable. So I think arrays can offer an
advantage there as well in Csound's case.

Cheers,
Andres

On Sat, Jun 4, 2011 at 1:58 AM, Louis Cohen  wrote:
>
> On Jun 3, 2011, at 6:50 PM, Michael Gogins wrote:
>
>> Basically I agree with you very much.but there is a danger in depending on
>> external software and that is that the interface with csound consumes time,
>> not only in programing but also in the music production work flow, which
>> should be as transparent as possible. For that reason I developed the csound
>> api so that csound could be embedded in ones language of greatest
>> productivity.
>
> It seems that the debate is:
>
> Should Csound's language be expanded to include at least some features that
> most other languages today have (such as arrays, records/structures...)?
>
> OR
>
> Should Csound have good enough hooks in it so it can function as a module --
> an extension of python or Java or other programming systems?
>
> I don't understand the inner workings of Csound well enough to know which
> direction would be best. What I would hope for is that if the csound api is
> to be promoted as an appendage to, say python, then it would be:
>
> -well documented
>
> -installed by the click of a button
>
> -work the same on several platforms
>
> If this were the case, I would learn python and use python and Csound
> together. But my sense from the postings is that there have been problems
> with the interface between python and Csound. That scares me. I don't think
> I have the skills or background to solve such problems on my own.
>
> The programming language I'm already most familiar with is Java. I've read a
> few articles in the Csound Journal about interfacing Java with the Csound
> api. As I recall, I would need to read long libraries of C code in order to
> effectively use the csound api with Java. I'm afraid that leaves me out.
>
> As an unsophisticated user, I need the linkage between Csound and some other
> system to be automatic and well documented, and the documentation to use
> terminology and a language that's consistent with what I'll be using. Or I
> need to be able to use Csound alone.
>
> -Lou
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


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

Csound has been developped over years, being itself derived from earlier 
Music n programs. As such, it is an invaluable piece of software, 
providing in the same tool all the electronic music techniques 
developped during the last 50 years: additive synthesis, substractive 
synthetis, frequency modulation, physical modelling, algorithmic 
synthesis, etc.

Since the last 20 years or so, people have added to csound features they 
needed. So now we have different layers to solve the same kind of 
problem each one with its qualities and its pecularities. For example, 
global vars, the zak system and the recent inlet outlet system. 
Moreover, some opcodes which were introduced for high quality 
diferred-time synthesis can now be used in real-time thanks to the 
technical development of personnal computers (e.g. poscil vs oscil).

I think this complexity is inherent in the development of open-source 
software. It reflects the different motivations of people involved in 
the process and the different layers of tehcnical problems over time.

That's why open-source software need high quality documentation. The 
Csound API lacks this documentation. More precisely, I would say that if 
you're a programmer, you'll find your way reading the source code 
comments in the csound.h file. But a bunch of good examples of the API 
use in different languages would be welcome.

We need too technical discussions around the API to clarify some points 
or decisions. For example why the coundInitialize function argc and argv 
arguments are not actually used by this function? When the csoundDestroy 
function is called, its CSOUND * pointer is not cleared while the 
corresponding csound instance is deleted, resulting in a dangling 
pointer which can be dangerous for the host program. Etc.

I think that the new parser and the multicore technique are actual 
priorities in the development of csound. Those two points represent a 
lot of hard work.

So maybe a better understanding and use of existing tools like the API 
would be an easier solution than introducing full arrays technique into 
the language?

Francois


Le 04/06/2011 02:58, Louis Cohen a écrit :
>
> On Jun 3, 2011, at 6:50 PM, Michael Gogins wrote:
>
>> Basically I agree with you very much.but there is a danger in 
>> depending on external software and that is that the interface with 
>> csound consumes time, not only in programing but also in the music 
>> production work flow, which should be as transparent as possible. For 
>> that reason I developed the csound api so that csound could be 
>> embedded in ones language of greatest productivity.
>
> It seems that the debate is:
>
> Should Csound's language be expanded to include at least some features 
> that most other languages today have (such as arrays, 
> records/structures...)?
>
> OR
>
> Should Csound have good enough hooks in it so it can function as a 
> module -- an extension of python or Java or other programming systems?
>
> I don't understand the inner workings of Csound well enough to know 
> which direction would be best. What I would hope for is that if the 
> csound api is to be promoted as an appendage to, say python, then it 
> would be:
>
> -well documented
>
> -installed by the click of a button
>
> -work the same on several platforms
>
> If this were the case, I would learn python and use python and Csound 
> together. But my sense from the postings is that there have been 
> problems with the interface between python and Csound. That scares me. 
> I don't think I have the skills or background to solve such problems 
> on my own.
>
> The programming language I'm already most familiar with is Java. I've 
> read a few articles in the Csound Journal about interfacing Java with 
> the Csound api. As I recall, I would need to read long libraries of C 
> code in order to effectively use the csound api with Java. I'm afraid 
> that leaves me out.
>
> As an unsophisticated user, I need the linkage between Csound and some 
> other system to be automatic and well documented, and the 
> documentation to use terminology and a language that's consistent with 
> what I'll be using. Or I need to be able to use Csound alone.
>
> -Lou
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
> "unsubscribe csound"
>


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

On Jun 4, 2011, at 2:10 PM, Michael Gogins wrote:

> Granted, the API document is pretty rudimentary, but it does have  
> one page that attempts to explain the various facets of the API. The  
> rest is Doxygen generated. It completely specifies all C/C++  
> functions and types in the API, but the rest is pretty sparse.

This is certainly a problem for me. I have no idea how to translate  
this information into what I would need to access the API via Java.

Currently I have not installed a development system on my Mac that  
would allow me to navigate these C/C++ sources, and of course I would  
need to learn how to use that development system as well.

-Lou



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

I too would like to see the API documented.  I have tried to use it and
the lack of explanation defeated me every time.
==John ff

>     I would like to second this. I have had multiple attempts at
> interpreting
> the API documentation and have hit a brick wall each time.  Granted, I'm
> not a
> software engineer, but I have progressed with Csound to the point where I
> am
> interested in seeing what is possible via the API.  I feel that there are
> other
> users in the same boat who know that they could do more with Csound and
> the API,
> but they don't have the tools to utilize it effectively.
>
>
>    Should the API be more friendly to less experienced programmers and
> open the
> door to more possibilites, or do users like me have no business mucking
> with
> stuff they don't understand? I think this is a question that should be
> considered as Csound progresses into the future.
>
>
> Mark
>
>
>
>
> ________________________________
> From: Jacob Joaquin 
> To: csound@lists.bath.ac.uk
> Sent: Sat, June 4, 2011 2:04:19 PM
> Subject: Re: [Csnd] Csound programming language
>
> The API documentation is geared towards software engineers, not computer
> musicians.
>
>
> Jake
>
> --
> The Csound Blog - http://csoundblog.com/
> Slipmat - http://slipmat.noisepages.com/
>
>
>
> On Sat, Jun 4, 2011 at 11:33 AM, Michael Gogins 
> wrote:
>
> Java, by design, specifies types and functions in somewhat the same way as
> C and
> C++. So, C++ API documentation should be helpful to a Java programmer.
>>
>>
>>I would be interested to know more about how you would like to use
>> Csound, and I
>>would also like to know what your typical music production workflow(s)
>> is(are).
>>This is a deep subject and there is much that remains to be done.
>>
>>
>>Regards,
>>Mike
>>
>>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>




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

I think at least for a scripting language like python it would be great 
to have a better api documentation for the average user. Perhaps not 
just documentation either but some sort of step-by-step tutorial.

I imagine a python tutorial with the csound api as it's main focus.

Best,

Peiman

On 07/06/2011 14:16, jpff@cs.bath.ac.uk wrote:
> I too would like to see the API documented.  I have tried to use it and
> the lack of explanation defeated me every time.
> ==John ff
>
>>      I would like to second this. I have had multiple attempts at
>> interpreting
>> the API documentation and have hit a brick wall each time.  Granted, I'm
>> not a
>> software engineer, but I have progressed with Csound to the point where I
>> am
>> interested in seeing what is possible via the API.  I feel that there are
>> other
>> users in the same boat who know that they could do more with Csound and
>> the API,
>> but they don't have the tools to utilize it effectively.
>>
>>
>>     Should the API be more friendly to less experienced programmers and
>> open the
>> door to more possibilites, or do users like me have no business mucking
>> with
>> stuff they don't understand? I think this is a question that should be
>> considered as Csound progresses into the future.
>>
>>
>> Mark
>>
>>
>>
>>
>> ________________________________
>> From: Jacob Joaquin
>> To: csound@lists.bath.ac.uk
>> Sent: Sat, June 4, 2011 2:04:19 PM
>> Subject: Re: [Csnd] Csound programming language
>>
>> The API documentation is geared towards software engineers, not computer
>> musicians.
>>
>>
>> Jake
>>
>> --
>> The Csound Blog - http://csoundblog.com/
>> Slipmat - http://slipmat.noisepages.com/
>>
>>
>>
>> On Sat, Jun 4, 2011 at 11:33 AM, Michael Gogins
>> wrote:
>>
>> Java, by design, specifies types and functions in somewhat the same way as
>> C and
>> C++. So, C++ API documentation should be helpful to a Java programmer.
>>>
>>> I would be interested to know more about how you would like to use
>>> Csound, and I
>>> would also like to know what your typical music production workflow(s)
>>> is(are).
>>> This is a deep subject and there is much that remains to be done.
>>>
>>>
>>> Regards,
>>> Mike
>>>
>>>
>> Send bugs reports to the Sourceforge bug tracker
>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



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

I have to raise a heretical voice here. My heart invariably sinks 
whenever I learn that documentation is based on Doxygen. It leads 
(without any exception I have so far found) to the classic linear and 
actually terse list of functions (and in the general case lots of mostly 
alphabetically ordered lists). As "reference documentation" that is no 
doubt important (it is a glorified index, in effect), but that is not 
the same as "full documentation". The API has a design philosophy and a 
design architecture, not least to do with the way Csound works; there is 
at least some degree of hierarchy - essential functions and other 
objects (and why they are essential), essential ordering (and why...), 
and auxiliary functions that are needed for particular tasks. All of 
that needs to be documented in dedicated prose, with examples, no doubt 
cross-referenced to the reference documentation. And as noted elsewhere, 
with further discussion as required for the various other languagas such 
as Python,  Java, etc.

In short, the documentation has to teach, guide and explain. It ius par 
of the task of "outreach" for the Csound user community as a whole. To 
me, adding comments to a header file, however copiously, is not 
synonymous with "fully documented", it is just that - a set of comments 
attached to a piece of code. And it of course does nothing for the 
readability of the header file itself.

Sadly it is not something I can take on - it does need to be done by 
those with the most experience of designing and using the API in all the 
various ways supported. So I am as much in need as everybody else!

Doxygen is clearly a clever and powerful system; but it is also fast 
becoming the processed white bread and monosodium glutamate of the 
industry, used everywhere but not as nourishing as it should be, and 
definitely not something one can live on!


Richard Dobson



On 07/06/2011 14:43, Michael Gogins wrote:
> The API documentation is generated by Doxygen from comments in the code,
> plus an additional introductory page. Despite what some people have said
> about the API documentation system, this is a standard method for ensuring
> the consistency and correctness of API reference type documentation and it
> is widely used in the software business.
>
> Anyone who wishes to improve the API documentation may easily do so by
> updating the comments in the code, or by editing the introductory page.
>
..


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

I'm with Michael on this one. The current doxygen API reference manual
is consistent with any other API I've used, even if it does require
some little work. I just think it needs to be made available online in
html form as the manual is. A wiki would be even better,  another case
for using the sourceforge wiki more.

Rory.


On 7 June 2011 14:43, Michael Gogins  wrote:
> The API documentation is generated by Doxygen from comments in the code,
> plus an additional introductory page. Despite what some people have said
> about the API documentation system, this is a standard method for ensuring
> the consistency and correctness of API reference type documentation and it
> is widely used in the software business.
> Anyone who wishes to improve the API documentation may easily do so by
> updating the comments in the code, or by editing the introductory page.
> Whenever either the comments or the introduction are updated, the API
> documentation also is automatically updated and goes into the Windows
> installer. I do not maintain the other installers and do not know what kind
> of API documentation, if any, goes into them.
> Putting another system in place because of perceived shortcomings to this
> system would be a serious mistake and lead to duplication of effort,
> contradictory information, etc. The best way to improve the API
> documentation is for those with a serious interest in doing so... to improve
> the comments in the code, to add to them, and to edit the introductory page
> (which could expand without problems to pages or a chapter).
> All of this is possible to anyone with access to Csound's GIT repository.
> I personally have enough interest in doing this to ensure that some sort of
> API documentation does at least exist -- there was none before I took a hand
> -- but I do not have a lot of time to devote to improving it.
> Regards,
> Mike
>
> On Tue, Jun 7, 2011 at 9:16 AM,  wrote:
>>
>> I too would like to see the API documented.  I have tried to use it and
>> the lack of explanation defeated me every time.
>> ==John ff
>>
>> >     I would like to second this. I have had multiple attempts at
>> > interpreting
>> > the API documentation and have hit a brick wall each time.  Granted, I'm
>> > not a
>> > software engineer, but I have progressed with Csound to the point where
>> > I
>> > am
>> > interested in seeing what is possible via the API.  I feel that there
>> > are
>> > other
>> > users in the same boat who know that they could do more with Csound and
>> > the API,
>> > but they don't have the tools to utilize it effectively.
>> >
>> >
>> >    Should the API be more friendly to less experienced programmers and
>> > open the
>> > door to more possibilites, or do users like me have no business mucking
>> > with
>> > stuff they don't understand? I think this is a question that should be
>> > considered as Csound progresses into the future.
>> >
>> >
>> > Mark
>> >
>> >
>> >
>> >
>> > ________________________________
>> > From: Jacob Joaquin 
>> > To: csound@lists.bath.ac.uk
>> > Sent: Sat, June 4, 2011 2:04:19 PM
>> > Subject: Re: [Csnd] Csound programming language
>> >
>> > The API documentation is geared towards software engineers, not computer
>> > musicians.
>> >
>> >
>> > Jake
>> >
>> > --
>> > The Csound Blog - http://csoundblog.com/
>> > Slipmat - http://slipmat.noisepages.com/
>> >
>> >
>> >
>> > On Sat, Jun 4, 2011 at 11:33 AM, Michael Gogins
>> > 
>> > wrote:
>> >
>> > Java, by design, specifies types and functions in somewhat the same way
>> > as
>> > C and
>> > C++. So, C++ API documentation should be helpful to a Java programmer.
>> >>
>> >>
>> >>I would be interested to know more about how you would like to use
>> >> Csound, and I
>> >>would also like to know what your typical music production workflow(s)
>> >> is(are).
>> >>This is a deep subject and there is much that remains to be done.
>> >>
>> >>
>> >>Regards,
>> >>Mike
>> >>
>> >>
>> > Send bugs reports to the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>> >
>> >
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>


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

I took a look at the API Reference PDF link on Sourceforge.  To me,
it's more than a little confusing. For Doxygen generated docs, I find
the HTML generated version to the be the most useful, where there are
frames and the organization of things is easy to follow.  Also, the
API Reference has a lot of things tied in for CsoundVST, which I think
muddies what one would do for using the Csound API (and I believe is
out of date anyways).

My take is, we should be using the HTML version of the Doxygen docs.
After that, we need to have a central guide to using the API, whether
that's the sourceforge wiki, or in the Csound Manual, or what.  I also
don't think it's an either-or, but rather we need both.




On Tue, Jun 7, 2011 at 10:23 AM, Rory Walsh  wrote:
> I'm with Michael on this one. The current doxygen API reference manual
> is consistent with any other API I've used, even if it does require
> some little work. I just think it needs to be made available online in
> html form as the manual is. A wiki would be even better,  another case
> for using the sourceforge wiki more.
>
> Rory.
>
>
> On 7 June 2011 14:43, Michael Gogins  wrote:
>> The API documentation is generated by Doxygen from comments in the code,
>> plus an additional introductory page. Despite what some people have said
>> about the API documentation system, this is a standard method for ensuring
>> the consistency and correctness of API reference type documentation and it
>> is widely used in the software business.
>> Anyone who wishes to improve the API documentation may easily do so by
>> updating the comments in the code, or by editing the introductory page.
>> Whenever either the comments or the introduction are updated, the API
>> documentation also is automatically updated and goes into the Windows
>> installer. I do not maintain the other installers and do not know what kind
>> of API documentation, if any, goes into them.
>> Putting another system in place because of perceived shortcomings to this
>> system would be a serious mistake and lead to duplication of effort,
>> contradictory information, etc. The best way to improve the API
>> documentation is for those with a serious interest in doing so... to improve
>> the comments in the code, to add to them, and to edit the introductory page
>> (which could expand without problems to pages or a chapter).
>> All of this is possible to anyone with access to Csound's GIT repository.
>> I personally have enough interest in doing this to ensure that some sort of
>> API documentation does at least exist -- there was none before I took a hand
>> -- but I do not have a lot of time to devote to improving it.
>> Regards,
>> Mike
>>
>> On Tue, Jun 7, 2011 at 9:16 AM,  wrote:
>>>
>>> I too would like to see the API documented.  I have tried to use it and
>>> the lack of explanation defeated me every time.
>>> ==John ff
>>>
>>> >     I would like to second this. I have had multiple attempts at
>>> > interpreting
>>> > the API documentation and have hit a brick wall each time.  Granted, I'm
>>> > not a
>>> > software engineer, but I have progressed with Csound to the point where
>>> > I
>>> > am
>>> > interested in seeing what is possible via the API.  I feel that there
>>> > are
>>> > other
>>> > users in the same boat who know that they could do more with Csound and
>>> > the API,
>>> > but they don't have the tools to utilize it effectively.
>>> >
>>> >
>>> >    Should the API be more friendly to less experienced programmers and
>>> > open the
>>> > door to more possibilites, or do users like me have no business mucking
>>> > with
>>> > stuff they don't understand? I think this is a question that should be
>>> > considered as Csound progresses into the future.
>>> >
>>> >
>>> > Mark
>>> >
>>> >
>>> >
>>> >
>>> > ________________________________
>>> > From: Jacob Joaquin 
>>> > To: csound@lists.bath.ac.uk
>>> > Sent: Sat, June 4, 2011 2:04:19 PM
>>> > Subject: Re: [Csnd] Csound programming language
>>> >
>>> > The API documentation is geared towards software engineers, not computer
>>> > musicians.
>>> >
>>> >
>>> > Jake
>>> >
>>> > --
>>> > The Csound Blog - http://csoundblog.com/
>>> > Slipmat - http://slipmat.noisepages.com/
>>> >
>>> >
>>> >
>>> > On Sat, Jun 4, 2011 at 11:33 AM, Michael Gogins
>>> > 
>>> > wrote:
>>> >
>>> > Java, by design, specifies types and functions in somewhat the same way
>>> > as
>>> > C and
>>> > C++. So, C++ API documentation should be helpful to a Java programmer.
>>> >>
>>> >>
>>> >>I would be interested to know more about how you would like to use
>>> >> Csound, and I
>>> >>would also like to know what your typical music production workflow(s)
>>> >> is(are).
>>> >>This is a deep subject and there is much that remains to be done.
>>> >>
>>> >>
>>> >>Regards,
>>> >>Mike
>>> >>
>>> >>
>>> > Send bugs reports to the Sourceforge bug tracker
>>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> > Discussions of bugs and features can be posted here
>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> > csound"
>>> >
>>> >
>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


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

It's the initial index.html that is the most important one for
beginners. After that people can search for more information about
whatever functions they come across in the opening introductory pages.
I wasn't aware there was a pdf version floating about. I imagine it's
nowhere near as easy to navigate as the html one? Is the html version
available online too somewhere? I think it should be mad available on
sourceforge as a zip containing the html.

Rory.


On 7 June 2011 16:37, Steven Yi  wrote:
> I took a look at the API Reference PDF link on Sourceforge.  To me,
> it's more than a little confusing. For Doxygen generated docs, I find
> the HTML generated version to the be the most useful, where there are
> frames and the organization of things is easy to follow.  Also, the
> API Reference has a lot of things tied in for CsoundVST, which I think
> muddies what one would do for using the Csound API (and I believe is
> out of date anyways).
>
> My take is, we should be using the HTML version of the Doxygen docs.
> After that, we need to have a central guide to using the API, whether
> that's the sourceforge wiki, or in the Csound Manual, or what.  I also
> don't think it's an either-or, but rather we need both.
>
>
>
>
> On Tue, Jun 7, 2011 at 10:23 AM, Rory Walsh  wrote:
>> I'm with Michael on this one. The current doxygen API reference manual
>> is consistent with any other API I've used, even if it does require
>> some little work. I just think it needs to be made available online in
>> html form as the manual is. A wiki would be even better,  another case
>> for using the sourceforge wiki more.
>>
>> Rory.
>>
>>
>> On 7 June 2011 14:43, Michael Gogins  wrote:
>>> The API documentation is generated by Doxygen from comments in the code,
>>> plus an additional introductory page. Despite what some people have said
>>> about the API documentation system, this is a standard method for ensuring
>>> the consistency and correctness of API reference type documentation and it
>>> is widely used in the software business.
>>> Anyone who wishes to improve the API documentation may easily do so by
>>> updating the comments in the code, or by editing the introductory page.
>>> Whenever either the comments or the introduction are updated, the API
>>> documentation also is automatically updated and goes into the Windows
>>> installer. I do not maintain the other installers and do not know what kind
>>> of API documentation, if any, goes into them.
>>> Putting another system in place because of perceived shortcomings to this
>>> system would be a serious mistake and lead to duplication of effort,
>>> contradictory information, etc. The best way to improve the API
>>> documentation is for those with a serious interest in doing so... to improve
>>> the comments in the code, to add to them, and to edit the introductory page
>>> (which could expand without problems to pages or a chapter).
>>> All of this is possible to anyone with access to Csound's GIT repository.
>>> I personally have enough interest in doing this to ensure that some sort of
>>> API documentation does at least exist -- there was none before I took a hand
>>> -- but I do not have a lot of time to devote to improving it.
>>> Regards,
>>> Mike
>>>
>>> On Tue, Jun 7, 2011 at 9:16 AM,  wrote:
>>>>
>>>> I too would like to see the API documented.  I have tried to use it and
>>>> the lack of explanation defeated me every time.
>>>> ==John ff
>>>>
>>>> >     I would like to second this. I have had multiple attempts at
>>>> > interpreting
>>>> > the API documentation and have hit a brick wall each time.  Granted, I'm
>>>> > not a
>>>> > software engineer, but I have progressed with Csound to the point where
>>>> > I
>>>> > am
>>>> > interested in seeing what is possible via the API.  I feel that there
>>>> > are
>>>> > other
>>>> > users in the same boat who know that they could do more with Csound and
>>>> > the API,
>>>> > but they don't have the tools to utilize it effectively.
>>>> >
>>>> >
>>>> >    Should the API be more friendly to less experienced programmers and
>>>> > open the
>>>> > door to more possibilites, or do users like me have no business mucking
>>>> > with
>>>> > stuff they don't understand? I think this is a question that should be
>>>> > considered as Csound progresses into the future.
>>>> >
>>>> >
>>>> > Mark
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > ________________________________
>>>> > From: Jacob Joaquin 
>>>> > To: csound@lists.bath.ac.uk
>>>> > Sent: Sat, June 4, 2011 2:04:19 PM
>>>> > Subject: Re: [Csnd] Csound programming language
>>>> >
>>>> > The API documentation is geared towards software engineers, not computer
>>>> > musicians.
>>>> >
>>>> >
>>>> > Jake
>>>> >
>>>> > --
>>>> > The Csound Blog - http://csoundblog.com/
>>>> > Slipmat - http://slipmat.noisepages.com/
>>>> >
>>>> >
>>>> >
>>>> > On Sat, Jun 4, 2011 at 11:33 AM, Michael Gogins
>>>> > 
>>>> > wrote:
>>>> >
>>>> > Java, by design, specifies types and functions in somewhat the same way
>>>> > as
>>>> > C and
>>>> > C++. So, C++ API documentation should be helpful to a Java programmer.
>>>> >>
>>>> >>
>>>> >>I would be interested to know more about how you would like to use
>>>> >> Csound, and I
>>>> >>would also like to know what your typical music production workflow(s)
>>>> >> is(are).
>>>> >>This is a deep subject and there is much that remains to be done.
>>>> >>
>>>> >>
>>>> >>Regards,
>>>> >>Mike
>>>> >>
>>>> >>
>>>> > Send bugs reports to the Sourceforge bug tracker
>>>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> > Discussions of bugs and features can be posted here
>>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> > csound"
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


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

The pdf link should be removed. The api doc had been html for years.

I would be happy to host the API at cSounds.com.  We have a new webmaster and are planning a number of updates and improvements.

Dr.B.

Sent from my iPhone.

On Jun 7, 2011, at 10:23 AM, Rory Walsh  wrote:

> I'm with Michael on this one. The current doxygen API reference manual
> is consistent with any other API I've used, even if it does require
> some little work. I just think it needs to be made available online in
> html form as the manual is. A wiki would be even better,  another case
> for using the sourceforge wiki more.
> 
> Rory.
> 
> 
> On 7 June 2011 14:43, Michael Gogins  wrote:
>> The API documentation is generated by Doxygen from comments in the code,
>> plus an additional introductory page. Despite what some people have said
>> about the API documentation system, this is a standard method for ensuring
>> the consistency and correctness of API reference type documentation and it
>> is widely used in the software business.
>> Anyone who wishes to improve the API documentation may easily do so by
>> updating the comments in the code, or by editing the introductory page.
>> Whenever either the comments or the introduction are updated, the API
>> documentation also is automatically updated and goes into the Windows
>> installer. I do not maintain the other installers and do not know what kind
>> of API documentation, if any, goes into them.
>> Putting another system in place because of perceived shortcomings to this
>> system would be a serious mistake and lead to duplication of effort,
>> contradictory information, etc. The best way to improve the API
>> documentation is for those with a serious interest in doing so... to improve
>> the comments in the code, to add to them, and to edit the introductory page
>> (which could expand without problems to pages or a chapter).
>> All of this is possible to anyone with access to Csound's GIT repository.
>> I personally have enough interest in doing this to ensure that some sort of
>> API documentation does at least exist -- there was none before I took a hand
>> -- but I do not have a lot of time to devote to improving it.
>> Regards,
>> Mike
>> 
>> On Tue, Jun 7, 2011 at 9:16 AM,  wrote:
>>> 
>>> I too would like to see the API documented.  I have tried to use it and
>>> the lack of explanation defeated me every time.
>>> ==John ff
>>> 
>>>>     I would like to second this. I have had multiple attempts at
>>>> interpreting
>>>> the API documentation and have hit a brick wall each time.  Granted, I'm
>>>> not a
>>>> software engineer, but I have progressed with Csound to the point where
>>>> I
>>>> am
>>>> interested in seeing what is possible via the API.  I feel that there
>>>> are
>>>> other
>>>> users in the same boat who know that they could do more with Csound and
>>>> the API,
>>>> but they don't have the tools to utilize it effectively.
>>>> 
>>>> 
>>>>    Should the API be more friendly to less experienced programmers and
>>>> open the
>>>> door to more possibilites, or do users like me have no business mucking
>>>> with
>>>> stuff they don't understand? I think this is a question that should be
>>>> considered as Csound progresses into the future.
>>>> 
>>>> 
>>>> Mark
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ________________________________
>>>> From: Jacob Joaquin 
>>>> To: csound@lists.bath.ac.uk
>>>> Sent: Sat, June 4, 2011 2:04:19 PM
>>>> Subject: Re: [Csnd] Csound programming language
>>>> 
>>>> The API documentation is geared towards software engineers, not computer
>>>> musicians.
>>>> 
>>>> 
>>>> Jake
>>>> 
>>>> --
>>>> The Csound Blog - http://csoundblog.com/
>>>> Slipmat - http://slipmat.noisepages.com/
>>>> 
>>>> 
>>>> 
>>>> On Sat, Jun 4, 2011 at 11:33 AM, Michael Gogins
>>>> 
>>>> wrote:
>>>> 
>>>> Java, by design, specifies types and functions in somewhat the same way
>>>> as
>>>> C and
>>>> C++. So, C++ API documentation should be helpful to a Java programmer.
>>>>> 
>>>>> 
>>>>> I would be interested to know more about how you would like to use
>>>>> Csound, and I
>>>>> would also like to know what your typical music production workflow(s)
>>>>> is(are).
>>>>> This is a deep subject and there is much that remains to be done.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Mike
>>>>> 
>>>>> 
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>> 
>> 
>> 
>> 
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 


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

On Jun 4, 2011, at 2:33 PM, Michael Gogins wrote:

> I would be interested to know more about how you would like to use  
> Csound, and I would also like to know what your typical music  
> production workflow(s) is(are). This is a deep subject and there is  
> much that remains to be done.
>
> Regards,
> Mike

Mike, I've been thinking about your request for a few days, and I'm  
ready to describe generally how I use csound. If this doesn't answer  
your question, I'll be happy to discuss things in more detail.

I use csound for two different purposes:

1. Real-time support for live improvisation
2. Composition of "fixed" pieces.

Within activity 2, I use two methods to sequence notes (or sounds):
a. I generate thousands of score events with an application I wrote in  
Java.
b. I generate thousands of score events from within one or more  
instruments in my orchestra.

For real-time support I rely heavily on MacCsound to provide widgets  
for a control surface. In one such project, I had in excess of a 100  
widgets that I rapidly controlled with a trackball. For each widget I  
also displayed some sort of data to tell me the state of the  
parameters I was controlling.

In another real-time project, the MacCsound display is much more  
simple, because the real control of sound is via a wiimote/nunchuck  
hand-held game controller. The controller sends bluetooth signals to  
Osculator, running on my Mac Laptop. Osculator sends and receives OSC  
messages to and from my csd running under MacCsound.

In either case these realtime csds generate sound in mono, stereo or  
quad, based on a macro definition that I can easily edit.

In the case of these real-time programs the hard part of creating them  
is long over. This initial work provided many challenges to me  
regarding how to start events, how to stop events, and how to control  
these events while they were playing. I wanted to be able to cause  
many events to play at once and I believe that I've solved all those  
sequencing problems pretty well.

New work on these programs amounts to adding a new sound or modifying  
an existing one, so in general these are not very challenging tasks.  
The real challenge is to conceive of interesting sounds.

For sound-generation I rely heavily on granular synthesis, additive  
synthesis and playback of samples. I do not use signal processing. I  
do not pan or spatially position sounds - I send discrete signals to  
each speaker. I use little or no reverb. I use a delay line in my  
realtime work but not for creating repeated rhythms. Instead, a sound  
may repeat exactly once, at a random time after it first sounds,  
usually several seconds later and usually on a different channel than  
it was originally heard on. This allows me to get some sound going,  
then switch gears to start up another sound while the initial sound  
still appears to be playing.

For the compositions of fixed pieces, each one is different and there  
are new challenges all the time. The most recent challenge, which  
ended up requiring the use of a 3-dimensional array, was based on the  
musical problem of having several notes playing simultaneously while  
each note played ornaments from time to time during its life. I wanted  
the ornaments to be specified as the music progressed and I wanted  
each instrument to play different ornaments at different times and at  
different speeds. I thought my solution would involve local ftables,  
and I posted a message asking about such a feature. I ended up  
deciding to use several (global) ftables, and to divide each ftable  
into subtables, and to guarantee that each active instrument would use  
a different set of subtables. This is a work in progress and was  
conceptually awkward and error-prone, but I've got it working. Arrays  
would have been great for dealing with this problem.

To write a composition I step through a few phases:

PLANNING
Here I decide overall structure of the composition and many aspects  
that will determine the overall nature of the piece. I always use a  
spreadsheet (OpenOffice, of course) for this planning. The features of  
the spreadsheet that I use are:

- tabular nature (rows, columns)
- ability to quickly compute durations, ratios, sums etc.
- ability to generate random numbers
- ability to export some tabular information as .csv files.

I sometimes convert the .csv files into text that I can include in my  
orchestra, mainly to define ftables. I do this conversion with a small  
program that I wrote in Java.

CODING/EDITING
I use MacCsound for this. It's obviously not a full-featured editor,  
but I can use it. When I need multiple views of the same code, I drag  
the csd into a jEdit buffer. I have two monitors connected to my Mac  
Pro, so there's plenty of room to see what I need to. I depend on a  
browser to navigate the csound manual to check for syntax and  
semantics of opcodes that might be new to me. I used to depend heavily  
on the Csound book but I don't need it much any longer. It was  
invaluable when I was getting started. I don't use the Csound journal  
much because so much of the new Csound work is related to signal  
processing, which I don't use.

DEBUGGING
I make heavy use of print, printk and printk2. Since many of my  
instruments have a lot of branching and looping, I need a way to  
easily see the values of variables and also what part of the logic the  
print messages are coming from. I do this by printing an easy-to-see  
constant in front of a group of messages, like this:

printk 1, 999999
printk 1, kvar1
printk 1, kvar2
etc.

Elsewhere in my code I might have

printk 1, 888888
printk 1. kvar1
printk 1, kvar2

In this way I can follow the logic of the code.

Once I think the code is working I comment out the print instructions  
but usually do not delete them. This clutters up the code but  
potentially saves me time later on. I try to write tons of comments.

SOUND PRODUCTION
I generally run the code in real-time to listen to it. This is easy to  
do with MacCsound (and of course with QuteCsound.) I may run it  
hundreds of times, tweaking code and parameters before I think I've  
got the sound I want. Then I run it to generate a mono sound file. If  
the composition is to have multiple tracks (and mine always do) I  
generate multiple mono files, each with different parameter values. Or  
if there's a lot of randomness in the code I might just run exactly  
the same code multiple times, if it results in substantially different  
sound files.

I mix these using a commercial audio program. It used to be Digital  
Performer; now it's Logic Pro.

If the result is a quadraphonic file, I use the Macintosh's utility  
"Compressor" to generate a dolby 5.1 file, usually with 4 channels. I  
use Logic to generate stereo full-resolution audio, and also mp3,  
which I post on my website (www.jolc.net.)

I hope this information helps.

best,
Lou Cohen




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

I was going to say the same :-)

I have written documentation for three open source projects and a 
commercial product, and I didn't use Doxygen for them, only DocBook, 
even though they are meant for developers, because I myself prefer 
documentation that starts with how to get started, gives examples, 
explains things together that should be used together and tells what the 
purpose is, keeps the more advanced stuff for the end, etc.

E.g. when I browsed the documentation, I was intrigued by BUZZ, but 
after reading the page I just don't understand what it does or how to 
use it. Granted, I didn't take that much time to look at the API, but 
the BUZZ page tells you very little.

But I think writing documentation like I mean above would take a lot of 
time.

Mark

Richard Dobson wrote:
> I have to raise a heretical voice here. My heart invariably sinks 
> whenever I learn that documentation is based on Doxygen. It leads 
> (without any exception I have so far found) to the classic linear and 
> actually terse list of functions (and in the general case lots of 
> mostly alphabetically ordered lists). As "reference documentation" 
> that is no doubt important (it is a glorified index, in effect), but 
> that is not the same as "full documentation". The API has a design 
> philosophy and a design architecture, not least to do with the way 
> Csound works; there is at least some degree of hierarchy - essential 
> functions and other objects (and why they are essential), essential 
> ordering (and why...), and auxiliary functions that are needed for 
> particular tasks. All of that needs to be documented in dedicated 
> prose, with examples, no doubt cross-referenced to the reference 
> documentation. And as noted elsewhere, with further discussion as 
> required for the various other languagas such as Python,  Java, etc.
>
> In short, the documentation has to teach, guide and explain. It ius 
> par of the task of "outreach" for the Csound user community as a 
> whole. To me, adding comments to a header file, however copiously, is 
> not synonymous with "fully documented", it is just that - a set of 
> comments attached to a piece of code. And it of course does nothing 
> for the readability of the header file itself.
>
> Sadly it is not something I can take on - it does need to be done by 
> those with the most experience of designing and using the API in all 
> the various ways supported. So I am as much in need as everybody else!
>
> Doxygen is clearly a clever and powerful system; but it is also fast 
> becoming the processed white bread and monosodium glutamate of the 
> industry, used everywhere but not as nourishing as it should be, and 
> definitely not something one can live on!
>
>
> Richard Dobson
>
>
>
> On 07/06/2011 14:43, Michael Gogins wrote:
>> The API documentation is generated by Doxygen from comments in the code,
>> plus an additional introductory page. Despite what some people have said
>> about the API documentation system, this is a standard method for 
>> ensuring
>> the consistency and correctness of API reference type documentation 
>> and it
>> is widely used in the software business.
>>
>> Anyone who wishes to improve the API documentation may easily do so by
>> updating the comments in the code, or by editing the introductory page.



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

On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:

> All right, the beginnings of an API user's guide exist. There are  
> numerous examples of API use in the examples directory. There are  
> stub tutorials in using the API in "A Csound Tutorial" and in "A  
> Csound Algorithmic Composition Tutorial" which, however, mostly  
> concerns CsoundAC. Both of these are in the Csound GIT repository.  
> Go ahead and improve them. I wrote them, but I don't own them and I  
> would welcome improvements.

Mike,

In order for me to access information about how to use the api, would  
I have to have access to the Csound GIT?

If so, I will have to learn what a GIT is (I have no idea at this  
point), and how to access it. Would that information be in the Csound  
manual?

-Lou



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

Having to learn to use GIT just to get access to the API reference
seems a tad extreme. Here's a zip, but be warned, this is slightly
behind the current API (I think, though not sure). It should give you
an idea of where the documentation is at. I plan to add to the opening
section once I get a chance.

Rory.




On 9 June 2011 13:05, Louis Cohen  wrote:
>
> On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:
>
>> All right, the beginnings of an API user's guide exist. There are numerous
>> examples of API use in the examples directory. There are stub tutorials in
>> using the API in "A Csound Tutorial" and in "A Csound Algorithmic
>> Composition Tutorial" which, however, mostly concerns CsoundAC. Both of
>> these are in the Csound GIT repository. Go ahead and improve them. I wrote
>> them, but I don't own them and I would welcome improvements.
>
> Mike,
>
> In order for me to access information about how to use the api, would I have
> to have access to the Csound GIT?
>
> If so, I will have to learn what a GIT is (I have no idea at this point),
> and how to access it. Would that information be in the Csound manual?
>
> -Lou
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>

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

Francois,

Thanks for this link.

I don't think I can use it, however.

First, I still don't know what a GIT is, but it appears to relate to  
some sort of code management tool.

Second, I see in the tree a list of items that I'm sure make sense to  
a developer, but aren't very helpful to me, for example:

CMakeLists.txt (something to do with building the binaries?)
Opcodes - interesting, but do I want it? do I have to do something in  
my Java code first before I try to use an opcode from Java?
CAN I use opcodes from Java?
Top (I have no idea what that would be)
Interfaces -- that's interesting, maybe these are interfaces to  
python, Java, etc.

When I look at java_interface.i I don't know what to do next - blob?  
history? raw? I click "blob" and I see a source file filled with  
includes. Now what do I do?

So I don't think GIT is going to help me as is.

-Lou


On Jun 9, 2011, at 8:13 AM, Francois PINOT wrote:

> Hi Louis,
>
> You can read files from Git directly within your browser: http://csound.git.sourceforge.net/git/gitweb-index.cgi 
> . Csound source files are accessed via the 'tree' link of the second  
> line and the manual files via the 'tree' link of the fourth line.
>
> Regards
>
> Francois
>
>
> 2011/6/9 Louis Cohen 
>
> On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:
>
> All right, the beginnings of an API user's guide exist. There are  
> numerous examples of API use in the examples directory. There are  
> stub tutorials in using the API in "A Csound Tutorial" and in "A  
> Csound Algorithmic Composition Tutorial" which, however, mostly  
> concerns CsoundAC. Both of these are in the Csound GIT repository.  
> Go ahead and improve them. I wrote them, but I don't own them and I  
> would welcome improvements.
>
> Mike,
>
> In order for me to access information about how to use the api,  
> would I have to have access to the Csound GIT?
>
> If so, I will have to learn what a GIT is (I have no idea at this  
> point), and how to access it. Would that information be in the  
> Csound manual?
>
> -Lou
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>
>



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

Francois,

I already have written a Java program that generates score lines -  
thousands of them. I currently output these to text and then include  
them in a csd which has relatively simple instruments to play the  
score lines.

It would be nice for me to include the logic of those simple  
instruments as Java code and play in realtime or save to audio file  
from my Java application. Then the score lines, translated  
appropriately, would directly produce the sound I'm interested in.

In this way I could expand on the logic of the instruments and use the  
power of Java to do it.

I hope this explains what I'd like to do.

BTW, I use netbeans for Java development, that is, I'm familiar with  
the netbeans IDE, which has all the functionality I need. By driving  
csound from my Java code, I would be able to debug my logic by using  
the netbeans debugging facility.

-Lou

On Jun 9, 2011, at 10:15 AM, Francois PINOT wrote:

> Could you describe me a simple program you would like to write in  
> Java using the API. Maybe I can help you to find an entry way to the  
> API?
>
> Francois
>
> 2011/6/9 Louis Cohen 
> Francois,
>
> Thanks for this link.
>
> I don't think I can use it, however.
>
> First, I still don't know what a GIT is, but it appears to relate to  
> some sort of code management tool.
>
> Second, I see in the tree a list of items that I'm sure make sense  
> to a developer, but aren't very helpful to me, for example:
>
> CMakeLists.txt (something to do with building the binaries?)
> Opcodes - interesting, but do I want it? do I have to do something  
> in my Java code first before I try to use an opcode from Java?
> CAN I use opcodes from Java?
> Top (I have no idea what that would be)
> Interfaces -- that's interesting, maybe these are interfaces to  
> python, Java, etc.
>
> When I look at java_interface.i I don't know what to do next - blob?  
> history? raw? I click "blob" and I see a source file filled with  
> includes. Now what do I do?
>
> So I don't think GIT is going to help me as is.
>
> -Lou
>
>
>
> On Jun 9, 2011, at 8:13 AM, Francois PINOT wrote:
>
> Hi Louis,
>
> You can read files from Git directly within your browser: http://csound.git.sourceforge.net/git/gitweb-index.cgi 
> . Csound source files are accessed via the 'tree' link of the second  
> line and the manual files via the 'tree' link of the fourth line.
>
> Regards
>
> Francois
>
>
> 2011/6/9 Louis Cohen 
>
> On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:
>
> All right, the beginnings of an API user's guide exist. There are  
> numerous examples of API use in the examples directory. There are  
> stub tutorials in using the API in "A Csound Tutorial" and in "A  
> Csound Algorithmic Composition Tutorial" which, however, mostly  
> concerns CsoundAC. Both of these are in the Csound GIT repository.  
> Go ahead and improve them. I wrote them, but I don't own them and I  
> would welcome improvements.
>
> Mike,
>
> In order for me to access information about how to use the api,  
> would I have to have access to the Csound GIT?
>
> If so, I will have to learn what a GIT is (I have no idea at this  
> point), and how to access it. Would that information be in the  
> Csound manual?
>
> -Lou
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>
>



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

Hi Lou,

Git is a distributed source control system and is pretty popular these
days.  We moved to it from CVS a few months back or so.

CMakeLists.txt is for building Csound with CMake instead of SCons.  I
use it for development work as you can generate Eclipse and XCode
projects from it, then work within those IDE's (as well as generating
Makefiles for commandline builds).  It's not the official build
system, but it's useful for me to work with and so it's in source
control.

As for everything else, that's just the layout of the source code
tree.  You'd see the same if you downloaded a src tarball from
sourceforge.

Regarding the API, the main files to look at are:

H/csound.h
     http://csound.git.sourceforge.net/git/gitweb.cgi?p=csound/csound5.git;a=blob;f=H/csound.h;h=d8f0cc02a6218d520624a6ec79d6cd61728de8a4;hb=HEAD

H/csound.hpp
     http://csound.git.sourceforge.net/git/gitweb.cgi?p=csound/csound5.git;a=blob;f=H/csound.hpp;h=b3dbbe462ad2f14dc2e354c9c080aa5e0f79242b;hb=HEAD

csound.h is where all of the API functions are documented.  csound.hpp
shows the definition of the Csound class that wraps the C API, and is
what you use from Java/Python/etc. if you're using a Csound object
(i.e. Csound csound = new Csound();).  You can see what functions it
wraps.  If you're using an IDE like Eclipse or Netbeans, once you have
the Java JAR file on your classpath for your project, you should have
autocomplete to see all the methods available from the Csound object.
From there you can look up documentation from the csound.h file.

For Java, look at the examples/java folder:

http://csound.git.sourceforge.net/git/gitweb.cgi?p=csound/csound5.git;a=tree;f=examples/java;h=a0815b4371be8db918741d68b84eaa05a5d76f2f;hb=HEAD

It has a fairly simple example of using the API.

steven




On Thu, Jun 9, 2011 at 8:47 AM, Louis Cohen  wrote:
> Francois,
>
> Thanks for this link.
>
> I don't think I can use it, however.
>
> First, I still don't know what a GIT is, but it appears to relate to some
> sort of code management tool.
>
> Second, I see in the tree a list of items that I'm sure make sense to a
> developer, but aren't very helpful to me, for example:
>
> CMakeLists.txt (something to do with building the binaries?)
> Opcodes - interesting, but do I want it? do I have to do something in my
> Java code first before I try to use an opcode from Java?
> CAN I use opcodes from Java?
> Top (I have no idea what that would be)
> Interfaces -- that's interesting, maybe these are interfaces to python,
> Java, etc.
>
> When I look at java_interface.i I don't know what to do next - blob?
> history? raw? I click "blob" and I see a source file filled with includes.
> Now what do I do?
>
> So I don't think GIT is going to help me as is.
>
> -Lou
>
>
> On Jun 9, 2011, at 8:13 AM, Francois PINOT wrote:
>
>> Hi Louis,
>>
>> You can read files from Git directly within your browser:
>> http://csound.git.sourceforge.net/git/gitweb-index.cgi. Csound source files
>> are accessed via the 'tree' link of the second line and the manual files via
>> the 'tree' link of the fourth line.
>>
>> Regards
>>
>> Francois
>>
>>
>> 2011/6/9 Louis Cohen 
>>
>> On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:
>>
>> All right, the beginnings of an API user's guide exist. There are numerous
>> examples of API use in the examples directory. There are stub tutorials in
>> using the API in "A Csound Tutorial" and in "A Csound Algorithmic
>> Composition Tutorial" which, however, mostly concerns CsoundAC. Both of
>> these are in the Csound GIT repository. Go ahead and improve them. I wrote
>> them, but I don't own them and I would welcome improvements.
>>
>> Mike,
>>
>> In order for me to access information about how to use the api, would I
>> have to have access to the Csound GIT?
>>
>> If so, I will have to learn what a GIT is (I have no idea at this point),
>> and how to access it. Would that information be in the Csound manual?
>>
>> -Lou
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


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

> I'm not sure to understand. Do you want your Java program to launch  
> a csound session, and generate score events that are played by your  
> instruments on the fly? What kind of real-time control do you have  
> in mind?
>
> Francois
>

First, let me be clear. This discussion is part of the larger  
discussion of whether in the future Csound's language should be  
expanded to include such features as arrays, structures, records etc.,  
or whether instead those same structures, already available in other  
languages such as python, c++ and java should be sufficient for those  
who need them, by providing access to Csound's API.

As part of that discussion, I decided to investigate how available the  
API is to me currently. So the comment you responded to was mine, that  
it didn't look to me like I could use the API in its current state  
because GIT, whatever that may be, immediately confronts me with  
terminology, file names, capabilities, and user interfaces about which  
I have no experience.

I have never programmed in c or C++, since these languages came into  
common use after my days as a professional software developer  
(1959-1975.) I learned Java recently because it seemed a good cross- 
platform choice. Perhaps other people, new to Csound and to  
programming, might also lack the knowledge that I lack.

When I posted my message that the Csound API didn't look like it was  
available to me, you asked me to "describe me a simple program you  
would like to write in Java using the API." I was not actively working  
on such a project, I was merely investigating the API to better  
understand the discussion. So I quickly described a project that I  
might consider launching, if I had confidence that I could use the  
Csound API.

Your question assumes that I know much more than I do about what is  
possible. A better way to continue the discussion might be for you to  
answer this question: what part of my hypothetical project is easy to  
do? what part is difficult? what part is unreasonable? I simply have  
no idea.

I hope this helps move our discussion forward.

-Lou



On Jun 9, 2011, at 11:12 AM, Francois PINOT wrote:

> 2011/6/9 Louis Cohen 
> Francois,
>
> I already have written a Java program that generates score lines -  
> thousands of them. I currently output these to text and then include  
> them in a csd which has relatively simple instruments to play the  
> score lines.
>
> It would be nice for me to include the logic of those simple  
> instruments as Java code and play in realtime or save to audio file  
> from my Java application. Then the score lines, translated  
> appropriately, would directly produce the sound I'm interested in.
>
> In this way I could expand on the logic of the instruments and use  
> the power of Java to do it.
>
> I hope this explains what I'd like to do.
>
> BTW, I use netbeans for Java development, that is, I'm familiar with  
> the netbeans IDE, which has all the functionality I need. By driving  
> csound from my Java code, I would be able to debug my logic by using  
> the netbeans debugging facility.
>
> -Lou
>
>
> On Jun 9, 2011, at 10:15 AM, Francois PINOT wrote:
>
> Could you describe me a simple program you would like to write in  
> Java using the API. Maybe I can help you to find an entry way to the  
> API?
>
> Francois
>
> 2011/6/9 Louis Cohen 
> Francois,
>
> Thanks for this link.
>
> I don't think I can use it, however.
>
> First, I still don't know what a GIT is, but it appears to relate to  
> some sort of code management tool.
>
> Second, I see in the tree a list of items that I'm sure make sense  
> to a developer, but aren't very helpful to me, for example:
>
> CMakeLists.txt (something to do with building the binaries?)
> Opcodes - interesting, but do I want it? do I have to do something  
> in my Java code first before I try to use an opcode from Java?
> CAN I use opcodes from Java?
> Top (I have no idea what that would be)
> Interfaces -- that's interesting, maybe these are interfaces to  
> python, Java, etc.
>
> When I look at java_interface.i I don't know what to do next - blob?  
> history? raw? I click "blob" and I see a source file filled with  
> includes. Now what do I do?
>
> So I don't think GIT is going to help me as is.
>
> -Lou
>
>
>
> On Jun 9, 2011, at 8:13 AM, Francois PINOT wrote:
>
> Hi Louis,
>
> You can read files from Git directly within your browser: http://csound.git.sourceforge.net/git/gitweb-index.cgi 
> . Csound source files are accessed via the 'tree' link of the second  
> line and the manual files via the 'tree' link of the fourth line.
>
> Regards
>
> Francois
>
>
> 2011/6/9 Louis Cohen 
>
> On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:
>
> All right, the beginnings of an API user's guide exist. There are  
> numerous examples of API use in the examples directory. There are  
> stub tutorials in using the API in "A Csound Tutorial" and in "A  
> Csound Algorithmic Composition Tutorial" which, however, mostly  
> concerns CsoundAC. Both of these are in the Csound GIT repository.  
> Go ahead and improve them. I wrote them, but I don't own them and I  
> would welcome improvements.
>
> Mike,
>
> In order for me to access information about how to use the api,  
> would I have to have access to the Csound GIT?
>
> If so, I will have to learn what a GIT is (I have no idea at this  
> point), and how to access it. Would that information be in the  
> Csound manual?
>
> -Lou
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>
>



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

With the Csound API you can create a csound session. Once the session is 
created it is waiting for events. It can compile a csd file containing 
your instruments and an 'f 7200' score statement for example for a two 
hours play. The compiled csd can be played in another thread (the API 
can manage this) so that your host program can manage its events within 
the main thread. Then your host program can send score events (i, a, f, 
e, q) as you would do from a score. If you've already written Java 
programs which generate csound scores, this should be easy for you.

The start time of the events sent by your host program can be absolute 
(from the beginning of the playing process) or relative (from the moment 
they are sent to csound).

If you think the process I just described is of interest for you, I can 
try to write a basic commented example for you.

Regards

Francois


Le 09/06/2011 19:31, Louis Cohen a écrit :
>> I'm not sure to understand. Do you want your Java program to launch a 
>> csound session, and generate score events that are played by your 
>> instruments on the fly? What kind of real-time control do you have in 
>> mind?
>>
>> Francois
>>
>
> First, let me be clear. This discussionW is part of the larger 
> discussion of whether in the future Csound's language should be 
> expanded to include such features as arrays, structures, records etc., 
> or whether instead those same structures, already available in other 
> languages such as python, c++ and java should be sufficient for those 
> who need them, by providing access to Csound's API.
>
> As part of that discussion, I decided to investigate how available the 
> API is to me currently. So the comment you responded to was mine, that 
> it didn't look to me like I could use the API in its current state 
> because GIT, whatever that may be, immediately confronts me with 
> terminology, file names, capabilities, and user interfaces about which 
> I have no experience.
>
> I have never programmed in c or C++, since these languages came into 
> common use after my days as a professional software developer 
> (1959-1975.) I learned Java recently because it seemed a good 
> cross-platform choice. Perhaps other people, new to Csound and to 
> programming, might also lack the knowledge that I lack.
>
> When I posted my message that the Csound API didn't look like it was 
> available to me, you asked me to "describe me a simple program you 
> would like to write in Java using the API." I was not actively working 
> on such a project, I was merely investigating the API to better 
> understand the discussion. So I quickly described a project that I 
> might consider launching, if I had confidence that I could use the 
> Csound API.
>
> Your question assumes that I know much more than I do about what is 
> possible. A better way to continue the discussion might be for you to 
> answer this question: what part of my hypothetical project is easy to 
> do? what part is difficult? what part is unreasonable? I simply have 
> no idea.
>
> I hope this helps move our discussion forward.
>
> -Lou
>
>
>
> On Jun 9, 2011, at 11:12 AM, Francois PINOT wrote:
>
>> 2011/6/9 Louis Cohen 
>> Francois,
>>
>> I already have written a Java program that generates score lines - 
>> thousands of them. I currently output these to text and then include 
>> them in a csd which has relatively simple instruments to play the 
>> score lines.
>>
>> It would be nice for me to include the logic of those simple 
>> instruments as Java code and play in realtime or save to audio file 
>> from my Java application. Then the score lines, translated 
>> appropriately, would directly produce the sound I'm interested in.
>>
>> In this way I could expand on the logic of the instruments and use 
>> the power of Java to do it.
>>
>> I hope this explains what I'd like to do.
>>
>> BTW, I use netbeans for Java development, that is, I'm familiar with 
>> the netbeans IDE, which has all the functionality I need. By driving 
>> csound from my Java code, I would be able to debug my logic by using 
>> the netbeans debugging facility.
>>
>> -Lou
>>
>>
>> On Jun 9, 2011, at 10:15 AM, Francois PINOT wrote:
>>
>> Could you describe me a simple program you would like to write in 
>> Java using the API. Maybe I can help you to find an entry way to the 
>> API?
>>
>> Francois
>>
>> 2011/6/9 Louis Cohen 
>> Francois,
>>
>> Thanks for this link.
>>
>> I don't think I can use it, however.
>>
>> First, I still don't know what a GIT is, but it appears to relate to 
>> some sort of code management tool.
>>
>> Second, I see in the tree a list of items that I'm sure make sense to 
>> a developer, but aren't very helpful to me, for example:
>>
>> CMakeLists.txt (something to do with building the binaries?)
>> Opcodes - interesting, but do I want it? do I have to do something in 
>> my Java code first before I try to use an opcode from Java?
>> CAN I use opcodes from Java?
>> Top (I have no idea what that would be)
>> Interfaces -- that's interesting, maybe these are interfaces to 
>> python, Java, etc.
>>
>> When I look at java_interface.i I don't know what to do next - blob? 
>> history? raw? I click "blob" and I see a source file filled with 
>> includes. Now what do I do?
>>
>> So I don't think GIT is going to help me as is.
>>
>> -Lou
>>
>>
>>
>> On Jun 9, 2011, at 8:13 AM, Francois PINOT wrote:
>>
>> Hi Louis,
>>
>> You can read files from Git directly within your browser: 
>> http://csound.git.sourceforge.net/git/gitweb-index.cgi. Csound source 
>> files are accessed via the 'tree' link of the second line and the 
>> manual files via the 'tree' link of the fourth line.
>>
>> Regards
>>
>> Francois
>>
>>
>> 2011/6/9 Louis Cohen 
>>
>> On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:
>>
>> All right, the beginnings of an API user's guide exist. There are 
>> numerous examples of API use in the examples directory. There are 
>> stub tutorials in using the API in "A Csound Tutorial" and in "A 
>> Csound Algorithmic Composition Tutorial" which, however, mostly 
>> concerns CsoundAC. Both of these are in the Csound GIT repository. Go 
>> ahead and improve them. I wrote them, but I don't own them and I 
>> would welcome improvements.
>>
>> Mike,
>>
>> In order for me to access information about how to use the api, would 
>> I have to have access to the Csound GIT?
>>
>> If so, I will have to learn what a GIT is (I have no idea at this 
>> point), and how to access it. Would that information be in the Csound 
>> manual?
>>
>> -Lou
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>> "unsubscribe csound"
>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>> "unsubscribe csound"
>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>> "unsubscribe csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
> "unsubscribe csound"
>


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

> I do understand the desire for tools to do exactly what you want at a
> particular time. But if you drill some screwdrivers into the handle of a
> communal hammer because you need to screw, soon someone's going to complain
> that the hammer doesn't swing like it used to!

Unfortunately, this is the perfect metaphor as to how Csound has
evolved as a language over the years.

Jake
-- 
The Csound Blog - http://csoundblog.com/
Slipmat - http://slipmat.noisepages.com/


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

I must tell you -- somewhat irrelevantly, as the sys admin
at a federal court -- that it might well be a good idea to
keep Reference Manual *separate* *from* User Manual.
If you don't, the former will be viewed (correctly, in my
exoerience) as hopelessly conflated -- as appears to be
increasingly the case with Csound's documentation.

Jacob Joaquin wrote:
>> I do understand the desire for tools to do exactly what you want at a
>> particular time. But if you drill some screwdrivers into the handle of a
>> communal hammer because you need to screw, soon someone's going to complain
>> that the hammer doesn't swing like it used to!
>
> Unfortunately, this is the perfect metaphor as to how Csound has
> evolved as a language over the years.
>
> Jake


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

Hence the need for the next release (or the one after) to be 
restructured as a library of modules, including perhaps, one 
exclusively devoted to backward compatibility, since that issue 
seems to be why the language has begun to bloat, even in the few 
years I've used it.  This doesn't seem unreasonable to me, since 
many other programming languages seem to have adopted that 
philosophy.  Perhaps my limited experience in these matters has 
lead me to an oversimple understanding of what makes this hard 
to achieve. I simply feel it would be a good thing to do.

Bob

On 13:59, Jacob Joaquin wrote:
>> I do understand the desire for tools to do exactly what you want at a
>> particular time. But if you drill some screwdrivers into the handle of a
>> communal hammer because you need to screw, soon someone's going to complain
>> that the hammer doesn't swing like it used to!
>
> Unfortunately, this is the perfect metaphor as to how Csound has
> evolved as a language over the years.
>
> Jake


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

David,

Of course I understand the difference between a reference manual and  
user manual. And of course I can look up all the terms I mentioned,  
such as GIT.

I was trying to make the point, not very well I guess, that if the  
only way a person with my background could use the API is essentially  
via the documentation  currently available, then I can't use it  
without entering into a steep learning curve of material that I don't  
think should be required.

I would expect a well documented API that is supposed to be usable  
from a given language, in my case Java, to be documented in way  
similar to how other libraries are documented for Java. I would expect  
an overview of the API structure, and a description of the various  
entities available to me, expressed using the vocabulary that a Java  
programmer uses, not using some other language that the library  
happened to be implemented in.

Another way to say all this is that based on taking a peek at the  
currently available documentation of the API, in my judgement it is  
not at this point available to programmers using languages other than  
C and perhaps C++, and it's not available to a serious composer but a  
casual programmer like me.

This leads back to the beginning of this thread, which related to  
whether the csound language should be expanded to provide arrays and  
other data structures, or whether those structures are already  
available through the combined use of the API and a companion language  
such as python or Java.

 From what I've now seen, I would say that it's unrealistic to expect  
any but the most sophisticated developers to be able to use the API in  
its current state. Therefore if csound is to have arrays and other  
data structures it would have to be by extending the csound language.

-Lou



On Jun 10, 2011, at 4:40 PM, DavidW wrote:

> Louis, Please read Michael's recent post again about the Reference  
> Manual.
> If you don't know what GIT is, you can look it up. Google perhaps?
> If you want some tutorials for how to use the Reference Manual, great!
> But it is not reasonable to expect the Reference Manual itself to  
> enfold it within itself - you need a tutorial introduction to it.
>
> I do understand the desire for tools to do exactly what you want at  
> a particular time. But if you drill some screwdrivers into the  
> handle of a communal hammer because you need to screw, soon  
> someone's going to complain that the hammer doesn't swing like it  
> used to!
>
> Personally, I'd like the Reference Manual to remain a reference  
> manual, and documentation from within the code is a common and  
> fruitful way of keeping it up-to-date- whether it uses Doxygen or  
> something else.
>
> Of course tutorials are also very useful.
>
> David
> On 09/06/2011, at 10:47 PM, Louis Cohen wrote:
>
>> Francois,
>>
>> Thanks for this link.
>>
>> I don't think I can use it, however.
>>
>> First, I still don't know what a GIT is, but it appears to relate  
>> to some sort of code management tool.
>>
>> Second, I see in the tree a list of items that I'm sure make sense  
>> to a developer, but aren't very helpful to me, for example:
>>
>> CMakeLists.txt (something to do with building the binaries?)
>> Opcodes - interesting, but do I want it? do I have to do something  
>> in my Java code first before I try to use an opcode from Java?
>> CAN I use opcodes from Java?
>> Top (I have no idea what that would be)
>> Interfaces -- that's interesting, maybe these are interfaces to  
>> python, Java, etc.
>>
>> When I look at java_interface.i I don't know what to do next -  
>> blob? history? raw? I click "blob" and I see a source file filled  
>> with includes. Now what do I do?
>>
>> So I don't think GIT is going to help me as is.
>>
>> -Lou
>>
>>
>> On Jun 9, 2011, at 8:13 AM, Francois PINOT wrote:
>>
>>> Hi Louis,
>>>
>>> You can read files from Git directly within your browser: http://csound.git.sourceforge.net/git/gitweb-index.cgi 
>>> . Csound source files are accessed via the 'tree' link of the  
>>> second line and the manual files via the 'tree' link of the fourth  
>>> line.
>>>
>>> Regards
>>>
>>> Francois
>>>
>>>
>>> 2011/6/9 Louis Cohen 
>>>
>>> On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:
>>>
>>> All right, the beginnings of an API user's guide exist. There are  
>>> numerous examples of API use in the examples directory. There are  
>>> stub tutorials in using the API in "A Csound Tutorial" and in "A  
>>> Csound Algorithmic Composition Tutorial" which, however, mostly  
>>> concerns CsoundAC. Both of these are in the Csound GIT repository.  
>>> Go ahead and improve them. I wrote them, but I don't own them and  
>>> I would welcome improvements.
>>>
>>> Mike,
>>>
>>> In order for me to access information about how to use the api,  
>>> would I have to have access to the Csound GIT?
>>>
>>> If so, I will have to learn what a GIT is (I have no idea at this  
>>> point), and how to access it. Would that information be in the  
>>> Csound manual?
>>>
>>> -Lou
>
> ___________________________________________
> Dr David Worrall
> Adjunct Research Fellow, School of Music,
> Australian National University
> david.worrall@anu.edu.au
> - experimental polymedia:  worrall.avatar.com.au
> - sonification:                   sonification.com.au
> - trading education:           mindthemarkets.com.au
>



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

> I was trying to make the point, not very well I guess, that if the
> only way a person with my background could use the API is essentially
> via the documentation  currently available, then I can't use it
> without entering into a steep learning curve of material that I don't
> think should be required.

Your point has been clearly stated, and you are right.

>   From what I've now seen, I would say that it's unrealistic to expect
> any but the most sophisticated developers to be able to use the API in
> its current state.

This also is true.

> Therefore if csound is to have arrays and other
> data structures it would have to be by extending the csound language.

In my experience, the csound API is not so useful. You can still use 
data structures from Java or Python to create a CSD on the fly and have 
it compiled programmatically. For real-time score generation, you can 
send OSC messages to your running Csound.

The API mostly makes it possible to establish data buses for real-time 
control of paramaters. Now, for an usual k-rate, you can also do this 
via OSC.

What the API will not allow you to do anyway is modify the orchestra 
while Csound is running. This is its main weakness in my opinion. Since 
what the API always do is setting up a full CSD, then compile it, you 
don't miss much (apart for the data buses) by not using it.

In my own system, I launch Csound as an Emacs subprocess and, when I 
want real-time control, use OSC messages attached to Squeak widgets. I 
also tried the JAVA API via Clojure, which works well: in my experience, 
there is no much difference in having data conveyed via the API buses vs 
OSC messages.


To summarize my points:
- there is no need IMO for extension of the csound language;
- we definitely need a friendly API user-guide;
- the API should allow the modification of the orchestra in real-time.

Nothing new by the way: these topics are very regularly discussed here.


Best,

Stef






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

I agree with Stéphane. I think a lot of people assume that the API
provides some kind of magic solution to Csound's shortcomings. In
truth there is little that can be achieved using the API that can't be
done via alternative means as Stéphane already alluded to. My main use
for the API is developing GUI hosts for my instruments. Even this I
could do without the API by simply starting Csound in the background
and sending MIDI/OSC messages to it. It may not be as eloquent as
using the API, but the end-user probably wouldn't be able to tell the
difference. In time it may be possible to do more with the API but for
now all it really does is provide developers with an easy way to
control Csound from a host application.

Rory.




2011/6/11 Stéphane Rollandin :
>> I was trying to make the point, not very well I guess, that if the
>> only way a person with my background could use the API is essentially
>> via the documentation  currently available, then I can't use it
>> without entering into a steep learning curve of material that I don't
>> think should be required.
>
> Your point has been clearly stated, and you are right.
>
>>  From what I've now seen, I would say that it's unrealistic to expect
>> any but the most sophisticated developers to be able to use the API in
>> its current state.
>
> This also is true.
>
>> Therefore if csound is to have arrays and other
>> data structures it would have to be by extending the csound language.
>
> In my experience, the csound API is not so useful. You can still use data
> structures from Java or Python to create a CSD on the fly and have it
> compiled programmatically. For real-time score generation, you can send OSC
> messages to your running Csound.
>
> The API mostly makes it possible to establish data buses for real-time
> control of paramaters. Now, for an usual k-rate, you can also do this via
> OSC.
>
> What the API will not allow you to do anyway is modify the orchestra while
> Csound is running. This is its main weakness in my opinion. Since what the
> API always do is setting up a full CSD, then compile it, you don't miss much
> (apart for the data buses) by not using it.
>
> In my own system, I launch Csound as an Emacs subprocess and, when I want
> real-time control, use OSC messages attached to Squeak widgets. I also tried
> the JAVA API via Clojure, which works well: in my experience, there is no
> much difference in having data conveyed via the API buses vs OSC messages.
>
>
> To summarize my points:
> - there is no need IMO for extension of the csound language;
> - we definitely need a friendly API user-guide;
> - the API should allow the modification of the orchestra in real-time.
>
> Nothing new by the way: these topics are very regularly discussed here.
>
>
> Best,
>
> Stef
>
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


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

I would have loved to use the API to further the agent research, where the
agents control the instruments.  We have the framework running but got
into trouble with ethe java API in passing and recovering audio.  There
are things for which the API would be the best solution, but the
documentation was non-existent, other then the obvious level.

==John ff


> I agree with Stéphane. I think a lot of people assume that the API
> provides some kind of magic solution to Csound's shortcomings. In
> truth there is little that can be achieved using the API that can't be
> done via alternative means as Stéphane already alluded to. My main use
> for the API is developing GUI hosts for my instruments. Even this I
> could do without the API by simply starting Csound in the background
> and sending MIDI/OSC messages to it. It may not be as eloquent as
> using the API, but the end-user probably wouldn't be able to tell the
> difference. In time it may be possible to do more with the API but for
> now all it really does is provide developers with an easy way to
> control Csound from a host application.
>




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

Sorry --

Reviewing the thread and other discussion,
I realize that nobody needed to hear this.

P.A.

-----------------------------------------------------------------------------------

I must tell you -- somewhat irrelevantly, as the sys admin
at a federal court -- that it might well be a good idea to
keep Reference Manual *separate* *from* User Manual.
If you don't, the former will be viewed (correctly, in my
exoerience) as hopelessly conflated -- as appears to be
increasingly the case with Csound's documentation.

Jacob Joaquin wrote:
>> I do understand the desire for tools to do exactly what you want at a
>> particular time. But if you drill some screwdrivers into the handle of a
>> communal hammer because you need to screw, soon someone's going to complain
>> that the hammer doesn't swing like it used to!
>
> Unfortunately, this is the perfect metaphor as to how Csound has
> evolved as a language over the years.
>
> Jake


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




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

> I would add to your list the the ability to create instruments at run-time

That is the third item in my list.

Stef


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

I use the API for two other things. One is to get the realtime output
buffer to save it to disk from the front end without having to write
any Csound code with things like fout, and the other is to run things
precisely while Csound is idle between processing blocks. For example
in QuteCsound from svn you can define a python function which is
called every control block which can modify Csound channels or the
QuteCsound instance.

Cheers,
Andres

On Sat, Jun 11, 2011 at 12:12 PM, Rory Walsh  wrote:
> I agree with Stéphane. I think a lot of people assume that the API
> provides some kind of magic solution to Csound's shortcomings. In
> truth there is little that can be achieved using the API that can't be
> done via alternative means as Stéphane already alluded to. My main use
> for the API is developing GUI hosts for my instruments. Even this I
> could do without the API by simply starting Csound in the background
> and sending MIDI/OSC messages to it. It may not be as eloquent as
> using the API, but the end-user probably wouldn't be able to tell the
> difference. In time it may be possible to do more with the API but for
> now all it really does is provide developers with an easy way to
> control Csound from a host application.
>
> Rory.
>
>
>
>
> 2011/6/11 Stéphane Rollandin :
>>> I was trying to make the point, not very well I guess, that if the
>>> only way a person with my background could use the API is essentially
>>> via the documentation  currently available, then I can't use it
>>> without entering into a steep learning curve of material that I don't
>>> think should be required.
>>
>> Your point has been clearly stated, and you are right.
>>
>>>  From what I've now seen, I would say that it's unrealistic to expect
>>> any but the most sophisticated developers to be able to use the API in
>>> its current state.
>>
>> This also is true.
>>
>>> Therefore if csound is to have arrays and other
>>> data structures it would have to be by extending the csound language.
>>
>> In my experience, the csound API is not so useful. You can still use data
>> structures from Java or Python to create a CSD on the fly and have it
>> compiled programmatically. For real-time score generation, you can send OSC
>> messages to your running Csound.
>>
>> The API mostly makes it possible to establish data buses for real-time
>> control of paramaters. Now, for an usual k-rate, you can also do this via
>> OSC.
>>
>> What the API will not allow you to do anyway is modify the orchestra while
>> Csound is running. This is its main weakness in my opinion. Since what the
>> API always do is setting up a full CSD, then compile it, you don't miss much
>> (apart for the data buses) by not using it.
>>
>> In my own system, I launch Csound as an Emacs subprocess and, when I want
>> real-time control, use OSC messages attached to Squeak widgets. I also tried
>> the JAVA API via Clojure, which works well: in my experience, there is no
>> much difference in having data conveyed via the API buses vs OSC messages.
>>
>>
>> To summarize my points:
>> - there is no need IMO for extension of the csound language;
>> - we definitely need a friendly API user-guide;
>> - the API should allow the modification of the orchestra in real-time.
>>
>> Nothing new by the way: these topics are very regularly discussed here.
>>
>>
>> Best,
>>
>> Stef
>>
>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


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

That's clever Andres. Really interesting use of the API. I'd never
have thought of that.

On Saturday, 11 June 2011, Andres Cabrera  wrote:
> I use the API for two other things. One is to get the realtime output
> buffer to save it to disk from the front end without having to write
> any Csound code with things like fout, and the other is to run things
> precisely while Csound is idle between processing blocks. For example
> in QuteCsound from svn you can define a python function which is
> called every control block which can modify Csound channels or the
> QuteCsound instance.
>
> Cheers,
> Andres
>
> On Sat, Jun 11, 2011 at 12:12 PM, Rory Walsh  wrote:
>> I agree with Stéphane. I think a lot of people assume that the API
>> provides some kind of magic solution to Csound's shortcomings. In
>> truth there is little that can be achieved using the API that can't be
>> done via alternative means as Stéphane already alluded to. My main use
>> for the API is developing GUI hosts for my instruments. Even this I
>> could do without the API by simply starting Csound in the background
>> and sending MIDI/OSC messages to it. It may not be as eloquent as
>> using the API, but the end-user probably wouldn't be able to tell the
>> difference. In time it may be possible to do more with the API but for
>> now all it really does is provide developers with an easy way to
>> control Csound from a host application.
>>
>> Rory.
>>
>>
>>
>>
>> 2011/6/11 Stéphane Rollandin :
>>>> I was trying to make the point, not very well I guess, that if the
>>>> only way a person with my background could use the API is essentially
>>>> via the documentation  currently available, then I can't use it
>>>> without entering into a steep learning curve of material that I don't
>>>> think should be required.
>>>
>>> Your point has been clearly stated, and you are right.
>>>
>>>>  From what I've now seen, I would say that it's unrealistic to expect
>>>> any but the most sophisticated developers to be able to use the API in
>>>> its current state.
>>>
>>> This also is true.
>>>
>>>> Therefore if csound is to have arrays and other
>>>> data structures it would have to be by extending the csound language.
>>>
>>> In my experience, the csound API is not so useful. You can still use data
>>> structures from Java or Python to create a CSD on the fly and have it
>>> compiled programmatically. For real-time score generation, you can send OSC
>>> messages to your running Csound.
>>>
>>> The API mostly makes it possible to establish data buses for real-time
>>> control of paramaters. Now, for an usual k-rate, you can also do this via
>>> OSC.
>>>
>>> What the API will not allow you to do anyway is modify the orchestra while
>>> Csound is running. This is its main weakness in my opinion. Since what the
>>> API always do is setting up a full CSD, then compile it, you don't miss much
>>> (apart for the data buses) by not using it.
>>>
>>> In my own system, I launch Csound as an Emacs subprocess and, when I want
>>> real-time control, use OSC messages attached to Squeak widgets. I also tried
>>> the JAVA API via Clojure, which works well: in my experience, there is no
>>> much difference in having data conveyed via the API buses vs OSC messages.
>>>
>>>
>>> To summarize my points:
>>> - there is no need IMO for extension of the csound language;
>>> - we definitely need a friendly API user-guide;
>>> - the API should allow the modification of the orchestra in real-time.
>>>
>>> Nothing new by the way: these topics are very regularly discussed here.
>>>
>>>
>>> Best,
>>>
>>> Stef
>>>
>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


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

There is a really good article in the csound journal about using the
java api, that might be a good place to get started working with it, I
was able to get a java front end working using that article as a
guide.

On Sun, Jun 12, 2011 at 10:26 AM, Michael Gogins
 wrote:
> OK, I am understanding you a bit better.
> I hope you will now understand some of the issues with what you are asking
> for.
> The various language interfaces to the Csound API are generated by SWIG,
> starting with the C API. That means, the source code for the Java API, the
> Lua API, and so on is generated by SWIG. So, this source code does not exist
> in the Csound code repository and should not ever be edited by hand. So, we
> can't put in comments in the Java API source code, etc., that Doxygen or
> some other tool would use to make a Csound API reference manual that would
> be appropriate for Java, Lua, and so on. Only for C/C++ which is what the
> API "base" is.
> I will look into the possibility of finding some tool or hack to use
> Java-specific comments with Doxygen to produce Java-specific documentation,
> or to get SWIG to put Java-specific comments into the generated Java sources
> to produce Java-specific documentation using Javadoc, but I'm not
> optimistic.
> Regards,
> Mike
>
> On Fri, Jun 10, 2011 at 9:52 PM, Louis Cohen  wrote:
>>
>> David,
>>
>> Of course I understand the difference between a reference manual and user
>> manual. And of course I can look up all the terms I mentioned, such as GIT.
>> e
>> I was trying to make the point, not very well I guess, that if the only
>> way a person with my background could use the API is essentially via the
>> documentation  currently available, then I can't use it without entering
>> into a steep learning curve of material that I don't think should be
>> required.
>>
>> I would expect a well documented API that is supposed to be usable from a
>> given language, in my case Java, to be documented in way similar to how
>> other libraries are documented for Java. I would expect an overview of the
>> API structure, and a description of the various entities available to me,
>> expressed using the vocabulary that a Java programmer uses, not using some
>> other language that the library happened to be implemented in.
>>
>> Another way to say all this is that based on taking a peek at the
>> currently available documentation of the API, in my judgement it is not at
>> this point available to programmers using languages other than C and perhaps
>> C++, and it's not available to a serious composer but a casual programmer
>> like me.
>>
>> This leads back to the beginning of this thread, which related to whether
>> the csound language should be expanded to provide arrays and other data
>> structures, or whether those structures are already available through the
>> combined use of the API and a companion language such as python or Java.
>>
>> From what I've now seen, I would say that it's unrealistic to expect any
>> but the most sophisticated developers to be able to use the API in its
>> current state. Therefore if csound is to have arrays and other data
>> structures it would have to be by extending the csound language.
>>
>> -Lou
>>
>>
>>
>> On Jun 10, 2011, at 4:40 PM, DavidW wrote:
>>
>>> Louis, Please read Michael's recent post again about the Reference
>>> Manual.
>>> If you don't know what GIT is, you can look it up. Google perhaps?
>>> If you want some tutorials for how to use the Reference Manual, great!
>>> But it is not reasonable to expect the Reference Manual itself to enfold
>>> it within itself - you need a tutorial introduction to it.
>>>
>>> I do understand the desire for tools to do exactly what you want at a
>>> particular time. But if you drill some screwdrivers into the handle of a
>>> communal hammer because you need to screw, soon someone's going to complain
>>> that the hammer doesn't swing like it used to!
>>>
>>> Personally, I'd like the Reference Manual to remain a reference manual,
>>> and documentation from within the code is a common and fruitful way of
>>> keeping it up-to-date- whether it uses Doxygen or something else.
>>>
>>> Of course tutorials are also very useful.
>>>
>>> David
>>> On 09/06/2011, at 10:47 PM, Louis Cohen wrote:
>>>
>>>> Francois,
>>>>
>>>> Thanks for this link.
>>>>
>>>> I don't think I can use it, however.
>>>>
>>>> First, I still don't know what a GIT is, but it appears to relate to
>>>> some sort of code management tool.
>>>>
>>>> Second, I see in the tree a list of items that I'm sure make sense to a
>>>> developer, but aren't very helpful to me, for example:
>>>>
>>>> CMakeLists.txt (something to do with building the binaries?)
>>>> Opcodes - interesting, but do I want it? do I have to do something in my
>>>> Java code first before I try to use an opcode from Java?
>>>> CAN I use opcodes from Java?
>>>> Top (I have no idea what that would be)
>>>> Interfaces -- that's interesting, maybe these are interfaces to python,
>>>> Java, etc.
>>>>
>>>> When I look at java_interface.i I don't know what to do next - blob?
>>>> history? raw? I click "blob" and I see a source file filled with includes.
>>>> Now what do I do?
>>>>
>>>> So I don't think GIT is going to help me as is.
>>>>
>>>> -Lou
>>>>
>>>>
>>>> On Jun 9, 2011, at 8:13 AM, Francois PINOT wrote:
>>>>
>>>>> Hi Louis,
>>>>>
>>>>> You can read files from Git directly within your browser:
>>>>> http://csound.git.sourceforge.net/git/gitweb-index.cgi. Csound source files
>>>>> are accessed via the 'tree' link of the second line and the manual files via
>>>>> the 'tree' link of the fourth line.
>>>>>
>>>>> Regards
>>>>>
>>>>> Francois
>>>>>
>>>>>
>>>>> 2011/6/9 Louis Cohen 
>>>>>
>>>>> On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:
>>>>>
>>>>> All right, the beginnings of an API user's guide exist. There are
>>>>> numerous examples of API use in the examples directory. There are stub
>>>>> tutorials in using the API in "A Csound Tutorial" and in "A Csound
>>>>> Algorithmic Composition Tutorial" which, however, mostly concerns CsoundAC.
>>>>> Both of these are in the Csound GIT repository. Go ahead and improve them. I
>>>>> wrote them, but I don't own them and I would welcome improvements.
>>>>>
>>>>> Mike,
>>>>>
>>>>> In order for me to access information about how to use the api, would I
>>>>> have to have access to the Csound GIT?
>>>>>
>>>>> If so, I will have to learn what a GIT is (I have no idea at this
>>>>> point), and how to access it. Would that information be in the Csound
>>>>> manual?
>>>>>
>>>>> -Lou
>>>
>>> ___________________________________________
>>> Dr David Worrall
>>> Adjunct Research Fellow, School of Music,
>>> Australian National University
>>> david.worrall@anu.edu.au
>>> - experimental polymedia:  worrall.avatar.com.au
>>> - sonification:                   sonification.com.au
>>> - trading education:           mindthemarkets.com.au
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>


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

I read that article some time ago. I don't remember the details, but  
as soon as I tried to import some library or other I got completely  
stopped. I may have posted a question or two to this list but I think  
the answers were over my head and I decided I just didn't know enough  
to move ahead.

Pretty much every time people have tried to help me with questions  
about the API, I come up against the same issue -- to use it I will  
have get my hands into C and to some sort of code management system  
(maybe that's what GIT is?) that I'm not familiar with.

In other words, the API is not for casual programmers. So that means  
if I need a 3 dimensional array or some other data structure for a  
csound instrument I will have to roll my own structure with UDOs and  
the existing Csound language, as I did for my current project.

This is not out of the question, but it certainly highlights some  
weaknesses in Csound's programming language -- the lack of data  
structures other than 1-dimensional arrays and single variables, the  
lack of nested control structures, such as "while", "do-until". The  
need for programming with goto, etc. Everyone has already discussed  
these.

-Lou




On Jun 12, 2011, at 2:48 PM, Brian Redfern wrote:

> There is a really good article in the csound journal about using the
> java api, that might be a good place to get started working with it, I
> was able to get a java front end working using that article as a
> guide.
>
> On Sun, Jun 12, 2011 at 10:26 AM, Michael Gogins
>  wrote:
>> OK, I am understanding you a bit better.
>> I hope you will now understand some of the issues with what you are  
>> asking
>> for.
>> The various language interfaces to the Csound API are generated by  
>> SWIG,
>> starting with the C API. That means, the source code for the Java  
>> API, the
>> Lua API, and so on is generated by SWIG. So, this source code does  
>> not exist
>> in the Csound code repository and should not ever be edited by  
>> hand. So, we
>> can't put in comments in the Java API source code, etc., that  
>> Doxygen or
>> some other tool would use to make a Csound API reference manual  
>> that would
>> be appropriate for Java, Lua, and so on. Only for C/C++ which is  
>> what the
>> API "base" is.
>> I will look into the possibility of finding some tool or hack to use
>> Java-specific comments with Doxygen to produce Java-specific  
>> documentation,
>> or to get SWIG to put Java-specific comments into the generated  
>> Java sources
>> to produce Java-specific documentation using Javadoc, but I'm not
>> optimistic.
>> Regards,
>> Mike
>>
>> On Fri, Jun 10, 2011 at 9:52 PM, Louis Cohen   
>> wrote:
>>>
>>> David,
>>>
>>> Of course I understand the difference between a reference manual  
>>> and user
>>> manual. And of course I can look up all the terms I mentioned,  
>>> such as GIT.
>>> e
>>> I was trying to make the point, not very well I guess, that if the  
>>> only
>>> way a person with my background could use the API is essentially  
>>> via the
>>> documentation  currently available, then I can't use it without  
>>> entering
>>> into a steep learning curve of material that I don't think should be
>>> required.
>>>
>>> I would expect a well documented API that is supposed to be usable  
>>> from a
>>> given language, in my case Java, to be documented in way similar  
>>> to how
>>> other libraries are documented for Java. I would expect an  
>>> overview of the
>>> API structure, and a description of the various entities available  
>>> to me,
>>> expressed using the vocabulary that a Java programmer uses, not  
>>> using some
>>> other language that the library happened to be implemented in.
>>>
>>> Another way to say all this is that based on taking a peek at the
>>> currently available documentation of the API, in my judgement it  
>>> is not at
>>> this point available to programmers using languages other than C  
>>> and perhaps
>>> C++, and it's not available to a serious composer but a casual  
>>> programmer
>>> like me.
>>>
>>> This leads back to the beginning of this thread, which related to  
>>> whether
>>> the csound language should be expanded to provide arrays and other  
>>> data
>>> structures, or whether those structures are already available  
>>> through the
>>> combined use of the API and a companion language such as python or  
>>> Java.
>>>
>>> From what I've now seen, I would say that it's unrealistic to  
>>> expect any
>>> but the most sophisticated developers to be able to use the API in  
>>> its
>>> current state. Therefore if csound is to have arrays and other data
>>> structures it would have to be by extending the csound language.
>>>
>>> -Lou
>>>
>>>
>>>
>>> On Jun 10, 2011, at 4:40 PM, DavidW wrote:
>>>
>>>> Louis, Please read Michael's recent post again about the Reference
>>>> Manual.
>>>> If you don't know what GIT is, you can look it up. Google perhaps?
>>>> If you want some tutorials for how to use the Reference Manual,  
>>>> great!
>>>> But it is not reasonable to expect the Reference Manual itself to  
>>>> enfold
>>>> it within itself - you need a tutorial introduction to it.
>>>>
>>>> I do understand the desire for tools to do exactly what you want  
>>>> at a
>>>> particular time. But if you drill some screwdrivers into the  
>>>> handle of a
>>>> communal hammer because you need to screw, soon someone's going  
>>>> to complain
>>>> that the hammer doesn't swing like it used to!
>>>>
>>>> Personally, I'd like the Reference Manual to remain a reference  
>>>> manual,
>>>> and documentation from within the code is a common and fruitful  
>>>> way of
>>>> keeping it up-to-date- whether it uses Doxygen or something else.
>>>>
>>>> Of course tutorials are also very useful.
>>>>
>>>> David
>>>> On 09/06/2011, at 10:47 PM, Louis Cohen wrote:
>>>>
>>>>> Francois,
>>>>>
>>>>> Thanks for this link.
>>>>>
>>>>> I don't think I can use it, however.
>>>>>
>>>>> First, I still don't know what a GIT is, but it appears to  
>>>>> relate to
>>>>> some sort of code management tool.
>>>>>
>>>>> Second, I see in the tree a list of items that I'm sure make  
>>>>> sense to a
>>>>> developer, but aren't very helpful to me, for example:
>>>>>
>>>>> CMakeLists.txt (something to do with building the binaries?)
>>>>> Opcodes - interesting, but do I want it? do I have to do  
>>>>> something in my
>>>>> Java code first before I try to use an opcode from Java?
>>>>> CAN I use opcodes from Java?
>>>>> Top (I have no idea what that would be)
>>>>> Interfaces -- that's interesting, maybe these are interfaces to  
>>>>> python,
>>>>> Java, etc.
>>>>>
>>>>> When I look at java_interface.i I don't know what to do next -  
>>>>> blob?
>>>>> history? raw? I click "blob" and I see a source file filled with  
>>>>> includes.
>>>>> Now what do I do?
>>>>>
>>>>> So I don't think GIT is going to help me as is.
>>>>>
>>>>> -Lou
>>>>>
>>>>>
>>>>> On Jun 9, 2011, at 8:13 AM, Francois PINOT wrote:
>>>>>
>>>>>> Hi Louis,
>>>>>>
>>>>>> You can read files from Git directly within your browser:
>>>>>> http://csound.git.sourceforge.net/git/gitweb-index.cgi. Csound  
>>>>>> source files
>>>>>> are accessed via the 'tree' link of the second line and the  
>>>>>> manual files via
>>>>>> the 'tree' link of the fourth line.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Francois
>>>>>>
>>>>>>
>>>>>> 2011/6/9 Louis Cohen 
>>>>>>
>>>>>> On Jun 9, 2011, at 7:23 AM, Michael Gogins wrote:
>>>>>>
>>>>>> All right, the beginnings of an API user's guide exist. There are
>>>>>> numerous examples of API use in the examples directory. There  
>>>>>> are stub
>>>>>> tutorials in using the API in "A Csound Tutorial" and in "A  
>>>>>> Csound
>>>>>> Algorithmic Composition Tutorial" which, however, mostly  
>>>>>> concerns CsoundAC.
>>>>>> Both of these are in the Csound GIT repository. Go ahead and  
>>>>>> improve them. I
>>>>>> wrote them, but I don't own them and I would welcome  
>>>>>> improvements.
>>>>>>
>>>>>> Mike,
>>>>>>
>>>>>> In order for me to access information about how to use the api,  
>>>>>> would I
>>>>>> have to have access to the Csound GIT?
>>>>>>
>>>>>> If so, I will have to learn what a GIT is (I have no idea at this
>>>>>> point), and how to access it. Would that information be in the  
>>>>>> Csound
>>>>>> manual?
>>>>>>
>>>>>> -Lou
>>>>
>>>> ___________________________________________
>>>> Dr David Worrall
>>>> Adjunct Research Fellow, School of Music,
>>>> Australian National University
>>>> david.worrall@anu.edu.au
>>>> - experimental polymedia:  worrall.avatar.com.au
>>>> - sonification:                   sonification.com.au
>>>> - trading education:           mindthemarkets.com.au
>>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/? 
>>> group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



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