hello,

i am wondering if there is any interest in allowing the user to pass
strings to python via the csound opcodes (pyassign, pycall, etc.).  is
there a complication that prevents augmenting these opcodes to support
more varied datatypes?

in addition to strings, it seems like it would be interesting if one
could pass signals and/or pvs streams to python for processing or
feature retrieval.  since a lot of C libraries come with SWIG
wrappings these days, one could, for instance, pass data to a
python-wrapped libxtract to get a whole host of audio features
currently unavailable in csound.

as these kinds of requests might not be possible to implement in the
near future, could anyone tell me if working directly with the csound
API for python (something i know little about) would allow me more
freedom in passing string/vector data between the csound module and
python code?

thanks,
—  ben


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"

Using the Python API enables you to work with score events, arate
signals, krate signals, and tables. Then, in Csound, there are opcodes
permitting data to be copied between fsigs and tables. This is not
ideal, but may lend itself to a workaround.

If you could be more specific about what you would like to do, perhaps
we can augment the API (including the Python API).

Regards,
Mike

On Thu, Nov 25, 2010 at 6:09 AM, Francois PINOT  wrote:
> I wrote an article about using the csound API in real-time from a Python
> console, with the numpy module. The article focuses on score events but I
> think it could give you ideas for what you want. The article will be
> published soon in the next release of the Csound Journal.
>
> Regards
>
> Francois
>
> 2010/11/25 ben hackbarth 
>>
>> hello,
>>
>> i am wondering if there is any interest in allowing the user to pass
>> strings to python via the csound opcodes (pyassign, pycall, etc.).  is
>> there a complication that prevents augmenting these opcodes to support
>> more varied datatypes?
>>
>> in addition to strings, it seems like it would be interesting if one
>> could pass signals and/or pvs streams to python for processing or
>> feature retrieval.  since a lot of C libraries come with SWIG
>> wrappings these days, one could, for instance, pass data to a
>> python-wrapped libxtract to get a whole host of audio features
>> currently unavailable in csound.
>>
>> as these kinds of requests might not be possible to implement in the
>> near future, could anyone tell me if working directly with the csound
>> API for python (something i know little about) would allow me more
>> freedom in passing string/vector data between the csound module and
>> python code?
>>
>> thanks,
>> —  ben
>>
>>
>> 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"

françois: thanks, i look forward to your article.

michael: within csound, my idea situation would be twofold.

first, i would like to be able to pass strings to python with pycall.
so, something like

SfileName = "/tmp/data.xml"
pycalli   "readXmlData", SfileName


second, i would like to be able to pass signals and spectral data.  so imagine:

asig   diskin2   "voice.wav", 1, 1
kPitch, kPitchness    py2call  "calcYIN", asig

fSigIn   pvsanal	asig, ifftsize, ioverlap, iwinsize, iwinshape
kMfcc0, kMfcc1, kMfcc2, kMfcc3, kMfcc4   py5call  "calcMfcc", fSigIn

... or even passing python spectral data for manipulation...
fsigOut   py1call  "oddPatrials", fSigIn
aOddPatrials     pvsynth      fsigOut

passing through python to do these kinds of calculations would
certainly not be as fast as writing C code to accomplish the same
task.  but, it would be much easier to prototype and much speedier
than the current scenario which involves 1) writing asig/fsig to a
table, 2) writing the table to a file, 3) reading the file into
python.  doing this for a frame by frame analysis is not realistic
right now, IMO.  perhaps there is better way of accomplishing the same
task that i'm unaware of?

thanks,
—  ben



On Thu, Nov 25, 2010 at 6:52 PM, Michael Gogins
 wrote:
> Using the Python API enables you to work with score events, arate
> signals, krate signals, and tables. Then, in Csound, there are opcodes
> permitting data to be copied between fsigs and tables. This is not
> ideal, but may lend itself to a workaround.
>
> If you could be more specific about what you would like to do, perhaps
> we can augment the API (including the Python API).
>
> Regards,
> Mike
>
> On Thu, Nov 25, 2010 at 6:09 AM, Francois PINOT  wrote:
>> I wrote an article about using the csound API in real-time from a Python
>> console, with the numpy module. The article focuses on score events but I
>> think it could give you ideas for what you want. The article will be
>> published soon in the next release of the Csound Journal.
>>
>> Regards
>>
>> Francois
>>
>> 2010/11/25 ben hackbarth 
>>>
>>> hello,
>>>
>>> i am wondering if there is any interest in allowing the user to pass
>>> strings to python via the csound opcodes (pyassign, pycall, etc.).  is
>>> there a complication that prevents augmenting these opcodes to support
>>> more varied datatypes?
>>>
>>> in addition to strings, it seems like it would be interesting if one
>>> could pass signals and/or pvs streams to python for processing or
>>> feature retrieval.  since a lot of C libraries come with SWIG
>>> wrappings these days, one could, for instance, pass data to a
>>> python-wrapped libxtract to get a whole host of audio features
>>> currently unavailable in csound.
>>>
>>> as these kinds of requests might not be possible to implement in the
>>> near future, could anyone tell me if working directly with the csound
>>> API for python (something i know little about) would allow me more
>>> freedom in passing string/vector data between the csound module and
>>> python code?
>>>
>>> thanks,
>>> —  ben
>>>
>>>
>>> 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"

fantastic francois, thank you.  it seems like the python API is the way to go...

—  ben



On Fri, Nov 26, 2010 at 2:21 PM, Francois PINOT  wrote:
> You can access the internal buffer of a Csound ftable from python like this:
>
> import ctypes
> import csnd
>
> def getTableBuffer(cs, num):
>     """Return a buffer pointing to the stored data of an ftable or raise an
> exception"""
>     if cs.TableLength(num) > 0:
>         tbl = csnd.CsoundMYFLTArray()
>         tblSize = cs.GetTable(tbl.GetPtr(), num) + 1  # don't forget the
> guard point!
>         if csnd.csoundGetSizeOfMYFLT() == 8:
>             myflt = ctypes.c_double
>         else:
>             myflt = ctypes.c_float
>         return ctypes.ARRAY(myflt,
> tblSize).from_address(tbl.GetPtr(0).__long__())
>     else:
>         raise(ValueError("ftable number %d does not exist!" % (num)))
>
> cs = csnd.Csound()
> cs.compile("my.csd")
>
> tblBuffer = getTableBuffer(cs, 1)
>
> If "my.csd" creates ftable #1, the code above allows you to have a direct
> access to the ftable data buffer from a python ctypes_array. That is, the
> data are not copied and you can access them from python with instructions
> like this:
>
> tblBuffer[n1:n2] = ...
> size = len(tblBuffer)
> etc.
>
> Furthermore, if you use numpy, you can wrap the above ctypes_array into a
> numpy array like this:
>
> import numpy
> tblArray = numpy.frombuffer(tblBuffer)
>
> This is explained in more details in my article
>
> Regards
>
> Francois
>
>
> 2010/11/26 ben hackbarth 
>>
>> françois: thanks, i look forward to your article.
>>
>> michael: within csound, my idea situation would be twofold.
>>
>> first, i would like to be able to pass strings to python with pycall.
>> so, something like
>>
>> SfileName = "/tmp/data.xml"
>> pycalli   "readXmlData", SfileName
>>
>>
>> second, i would like to be able to pass signals and spectral data.  so
>> imagine:
>>
>> asig   diskin2   "voice.wav", 1, 1
>> kPitch, kPitchness    py2call  "calcYIN", asig
>>
>> fSigIn   pvsanal        asig, ifftsize, ioverlap, iwinsize, iwinshape
>> kMfcc0, kMfcc1, kMfcc2, kMfcc3, kMfcc4   py5call  "calcMfcc", fSigIn
>>
>> ... or even passing python spectral data for manipulation...
>> fsigOut   py1call  "oddPatrials", fSigIn
>> aOddPatrials     pvsynth      fsigOut
>>
>> passing through python to do these kinds of calculations would
>> certainly not be as fast as writing C code to accomplish the same
>> task.  but, it would be much easier to prototype and much speedier
>> than the current scenario which involves 1) writing asig/fsig to a
>> table, 2) writing the table to a file, 3) reading the file into
>> python.  doing this for a frame by frame analysis is not realistic
>> right now, IMO.  perhaps there is better way of accomplishing the same
>> task that i'm unaware of?
>>
>> thanks,
>> —  ben
>>
>>
>>
>> On Thu, Nov 25, 2010 at 6:52 PM, Michael Gogins
>>  wrote:
>> > Using the Python API enables you to work with score events, arate
>> > signals, krate signals, and tables. Then, in Csound, there are opcodes
>> > permitting data to be copied between fsigs and tables. This is not
>> > ideal, but may lend itself to a workaround.
>> >
>> > If you could be more specific about what you would like to do, perhaps
>> > we can augment the API (including the Python API).
>> >
>> > Regards,
>> > Mike
>> >
>> > On Thu, Nov 25, 2010 at 6:09 AM, Francois PINOT 
>> > wrote:
>> >> I wrote an article about using the csound API in real-time from a
>> >> Python
>> >> console, with the numpy module. The article focuses on score events but
>> >> I
>> >> think it could give you ideas for what you want. The article will be
>> >> published soon in the next release of the Csound Journal.
>> >>
>> >> Regards
>> >>
>> >> Francois
>> >>
>> >> 2010/11/25 ben hackbarth 
>> >>>
>> >>> hello,
>> >>>
>> >>> i am wondering if there is any interest in allowing the user to pass
>> >>> strings to python via the csound opcodes (pyassign, pycall, etc.).  is
>> >>> there a complication that prevents augmenting these opcodes to support
>> >>> more varied datatypes?
>> >>>
>> >>> in addition to strings, it seems like it would be interesting if one
>> >>> could pass signals and/or pvs streams to python for processing or
>> >>> feature retrieval.  since a lot of C libraries come with SWIG
>> >>> wrappings these days, one could, for instance, pass data to a
>> >>> python-wrapped libxtract to get a whole host of audio features
>> >>> currently unavailable in csound.
>> >>>
>> >>> as these kinds of requests might not be possible to implement in the
>> >>> near future, could anyone tell me if working directly with the csound
>> >>> API for python (something i know little about) would allow me more
>> >>> freedom in passing string/vector data between the csound module and
>> >>> python code?
>> >>>
>> >>> thanks,
>> >>> —  ben
>> >>>
>> >>>
>> >>> 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"

But it would definitely be handy to have the python opcodes exchange
other types of data, at least strings... anyone want to do it? =)

Cheers,
Andres


On Sat, Nov 27, 2010 at 8:35 PM, ben hackbarth  wrote:
> fantastic francois, thank you.  it seems like the python API is the way to go...
>
> —  ben
>
>
>
> On Fri, Nov 26, 2010 at 2:21 PM, Francois PINOT  wrote:
>> You can access the internal buffer of a Csound ftable from python like this:
>>
>> import ctypes
>> import csnd
>>
>> def getTableBuffer(cs, num):
>>     """Return a buffer pointing to the stored data of an ftable or raise an
>> exception"""
>>     if cs.TableLength(num) > 0:
>>         tbl = csnd.CsoundMYFLTArray()
>>         tblSize = cs.GetTable(tbl.GetPtr(), num) + 1  # don't forget the
>> guard point!
>>         if csnd.csoundGetSizeOfMYFLT() == 8:
>>             myflt = ctypes.c_double
>>         else:
>>             myflt = ctypes.c_float
>>         return ctypes.ARRAY(myflt,
>> tblSize).from_address(tbl.GetPtr(0).__long__())
>>     else:
>>         raise(ValueError("ftable number %d does not exist!" % (num)))
>>
>> cs = csnd.Csound()
>> cs.compile("my.csd")
>>
>> tblBuffer = getTableBuffer(cs, 1)
>>
>> If "my.csd" creates ftable #1, the code above allows you to have a direct
>> access to the ftable data buffer from a python ctypes_array. That is, the
>> data are not copied and you can access them from python with instructions
>> like this:
>>
>> tblBuffer[n1:n2] = ...
>> size = len(tblBuffer)
>> etc.
>>
>> Furthermore, if you use numpy, you can wrap the above ctypes_array into a
>> numpy array like this:
>>
>> import numpy
>> tblArray = numpy.frombuffer(tblBuffer)
>>
>> This is explained in more details in my article
>>
>> Regards
>>
>> Francois
>>
>>
>> 2010/11/26 ben hackbarth 
>>>
>>> françois: thanks, i look forward to your article.
>>>
>>> michael: within csound, my idea situation would be twofold.
>>>
>>> first, i would like to be able to pass strings to python with pycall.
>>> so, something like
>>>
>>> SfileName = "/tmp/data.xml"
>>> pycalli   "readXmlData", SfileName
>>>
>>>
>>> second, i would like to be able to pass signals and spectral data.  so
>>> imagine:
>>>
>>> asig   diskin2   "voice.wav", 1, 1
>>> kPitch, kPitchness    py2call  "calcYIN", asig
>>>
>>> fSigIn   pvsanal        asig, ifftsize, ioverlap, iwinsize, iwinshape
>>> kMfcc0, kMfcc1, kMfcc2, kMfcc3, kMfcc4   py5call  "calcMfcc", fSigIn
>>>
>>> ... or even passing python spectral data for manipulation...
>>> fsigOut   py1call  "oddPatrials", fSigIn
>>> aOddPatrials     pvsynth      fsigOut
>>>
>>> passing through python to do these kinds of calculations would
>>> certainly not be as fast as writing C code to accomplish the same
>>> task.  but, it would be much easier to prototype and much speedier
>>> than the current scenario which involves 1) writing asig/fsig to a
>>> table, 2) writing the table to a file, 3) reading the file into
>>> python.  doing this for a frame by frame analysis is not realistic
>>> right now, IMO.  perhaps there is better way of accomplishing the same
>>> task that i'm unaware of?
>>>
>>> thanks,
>>> —  ben
>>>
>>>
>>>
>>> On Thu, Nov 25, 2010 at 6:52 PM, Michael Gogins
>>>  wrote:
>>> > Using the Python API enables you to work with score events, arate
>>> > signals, krate signals, and tables. Then, in Csound, there are opcodes
>>> > permitting data to be copied between fsigs and tables. This is not
>>> > ideal, but may lend itself to a workaround.
>>> >
>>> > If you could be more specific about what you would like to do, perhaps
>>> > we can augment the API (including the Python API).
>>> >
>>> > Regards,
>>> > Mike
>>> >
>>> > On Thu, Nov 25, 2010 at 6:09 AM, Francois PINOT 
>>> > wrote:
>>> >> I wrote an article about using the csound API in real-time from a
>>> >> Python
>>> >> console, with the numpy module. The article focuses on score events but
>>> >> I
>>> >> think it could give you ideas for what you want. The article will be
>>> >> published soon in the next release of the Csound Journal.
>>> >>
>>> >> Regards
>>> >>
>>> >> Francois
>>> >>
>>> >> 2010/11/25 ben hackbarth 
>>> >>>
>>> >>> hello,
>>> >>>
>>> >>> i am wondering if there is any interest in allowing the user to pass
>>> >>> strings to python via the csound opcodes (pyassign, pycall, etc.).  is
>>> >>> there a complication that prevents augmenting these opcodes to support
>>> >>> more varied datatypes?
>>> >>>
>>> >>> in addition to strings, it seems like it would be interesting if one
>>> >>> could pass signals and/or pvs streams to python for processing or
>>> >>> feature retrieval.  since a lot of C libraries come with SWIG
>>> >>> wrappings these days, one could, for instance, pass data to a
>>> >>> python-wrapped libxtract to get a whole host of audio features
>>> >>> currently unavailable in csound.
>>> >>>
>>> >>> as these kinds of requests might not be possible to implement in the
>>> >>> near future, could anyone tell me if working directly with the csound
>>> >>> API for python (something i know little about) would allow me more
>>> >>> freedom in passing string/vector data between the csound module and
>>> >>> python code?
>>> >>>
>>> >>> thanks,
>>> >>> —  ben
>>> >>>
>>> >>>
>>> >>> 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"
>
>


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"