Would it be possible to access the csound API from Python, when Python
is run via the py opcodes in Csound?
So for example (pseudo code):

pyinit
instr 1
pyruni "csound.SetChannel(channelName, value)"
endin

It would be very useful to be able to send data back and forth between
Csound and Python, in a more flexible manner than what the pycallN
opcodes allows.

all best
Oeyvind


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 -- that may be possible. I will check tonight.

If not, I think I will create new dynamic language opcodes, where the
entire opcode is written in Python or Lua. In these cases the csound
object would be callable from the opcode functions.

Regards,
Mike

On Tue, Feb 8, 2011 at 2:23 AM, Oeyvind Brandtsegg
 wrote:
> Would it be possible to access the csound API from Python, when Python
> is run via the py opcodes in Csound?
> So for example (pseudo code):
>
> pyinit
> instr 1
> pyruni "csound.SetChannel(channelName, value)"
> endin
>
> It would be very useful to be able to send data back and forth between
> Csound and Python, in a more flexible manner than what the pycallN
> opcodes allows.
>
> all best
> Oeyvind
>
>
> 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"

That sounds super.
Oeyvind

2011/2/8 Michael Gogins :
> I'm not sure -- that may be possible. I will check tonight.
>
> If not, I think I will create new dynamic language opcodes, where the
> entire opcode is written in Python or Lua. In these cases the csound
> object would be callable from the opcode functions.
>
> Regards,
> Mike
>
> On Tue, Feb 8, 2011 at 2:23 AM, Oeyvind Brandtsegg
>  wrote:
>> Would it be possible to access the csound API from Python, when Python
>> is run via the py opcodes in Csound?
>> So for example (pseudo code):
>>
>> pyinit
>> instr 1
>> pyruni "csound.SetChannel(channelName, value)"
>> endin
>>
>> It would be very useful to be able to send data back and forth between
>> Csound and Python, in a more flexible manner than what the pycallN
>> opcodes allows.
>>
>> all best
>> Oeyvind
>>
>>
>> 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"

I looked at the code, it does not currently support accessing the
Csound object from within Python opcodes.

The options as I seem them are:

(1) Csound could certainly be instantiated from the Python code in a
Python opcode. We could add a method to the API to return the
instances of Csound created in the current thread.

(2) The existing Python opcodes could be re-written so that a Python
wrapper to the running instance of Csound is always passed into the
code, perhaps just as an object in module scope.

(3) We could introduce new opcodes that would be written in pure
Python or other dynamic languages. They would have opcode callbacks
that have a Csound object parameter just as the C opcodes do. Frankly
I think this is the best option as it allows the user to pretty much
do anything and I think it is fairly intuitive. These opcodes could
also be implemented as new opcodes in the regular CsInstruments
section that would take, as arguments, the name, intypes, outtypes,
and code text (in multiple lines) of the opcode. Something like this:

pythonopcode"name", "intypes", "outtypes", rates, {{
def irate(csound, intypes, outtypes, state):
  dosomething
  outtypes[0] = x
}}

The intypes, outtypes, and state parameters contain lists of input and
output parameters and a dictionary for opcode state. Alternatively the
opcode code would inherit from a special Python opcode base class
similar to the OpcodeBase.hpp code.

Well, let me know what you think.

Regards,
Mike

On Tue, Feb 8, 2011 at 8:19 AM, Oeyvind Brandtsegg
 wrote:
> That sounds super.
> Oeyvind
>
> 2011/2/8 Michael Gogins :
>> I'm not sure -- that may be possible. I will check tonight.
>>
>> If not, I think I will create new dynamic language opcodes, where the
>> entire opcode is written in Python or Lua. In these cases the csound
>> object would be callable from the opcode functions.
>>
>> Regards,
>> Mike
>>
>> On Tue, Feb 8, 2011 at 2:23 AM, Oeyvind Brandtsegg
>>  wrote:
>>> Would it be possible to access the csound API from Python, when Python
>>> is run via the py opcodes in Csound?
>>> So for example (pseudo code):
>>>
>>> pyinit
>>> instr 1
>>> pyruni "csound.SetChannel(channelName, value)"
>>> endin
>>>
>>> It would be very useful to be able to send data back and forth between
>>> Csound and Python, in a more flexible manner than what the pycallN
>>> opcodes allows.
>>>
>>> all best
>>> Oeyvind
>>>
>>>
>>> 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"
>
>



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

dear mike,

> (3) We could introduce new opcodes that would be written in pure
> Python or other dynamic languages. They would have opcode callbacks
> that have a Csound object parameter just as the C opcodes do. Frankly
> I think this is the best option as it allows the user to pretty much
> do anything and I think it is fairly intuitive. These opcodes could
> also be implemented as new opcodes in the regular CsInstruments
> section that would take, as arguments, the name, intypes, outtypes,
> and code text (in multiple lines) of the opcode. Something like this:
>
> pythonopcode "name", "intypes", "outtypes", rates, {{
> def irate(csound, intypes, outtypes, state):
>  dosomething
>  outtypes[0] = x
> }}
>
> The intypes, outtypes, and state parameters contain lists of input and
> output parameters and a dictionary for opcode state. Alternatively the
> opcode code would inherit from a special Python opcode base class
> similar to the OpcodeBase.hpp code.

sounds great -- i would certainly make good use of something like this.

--  ben



On Tue, Feb 8, 2011 at 7:36 PM, Michael Gogins  wrote:
> I looked at the code, it does not currently support accessing the
> Csound object from within Python opcodes.
>
> The options as I seem them are:
>
> (1) Csound could certainly be instantiated from the Python code in a
> Python opcode. We could add a method to the API to return the
> instances of Csound created in the current thread.
>
> (2) The existing Python opcodes could be re-written so that a Python
> wrapper to the running instance of Csound is always passed into the
> code, perhaps just as an object in module scope.
>
> (3) We could introduce new opcodes that would be written in pure
> Python or other dynamic languages. They would have opcode callbacks
> that have a Csound object parameter just as the C opcodes do. Frankly
> I think this is the best option as it allows the user to pretty much
> do anything and I think it is fairly intuitive. These opcodes could
> also be implemented as new opcodes in the regular CsInstruments
> section that would take, as arguments, the name, intypes, outtypes,
> and code text (in multiple lines) of the opcode. Something like this:
>
> pythonopcode"name", "intypes", "outtypes", rates, {{
> def irate(csound, intypes, outtypes, state):
>  dosomething
>  outtypes[0] = x
> }}
>
> The intypes, outtypes, and state parameters contain lists of input and
> output parameters and a dictionary for opcode state. Alternatively the
> opcode code would inherit from a special Python opcode base class
> similar to the OpcodeBase.hpp code.
>
> Well, let me know what you think.
>
> Regards,
> Mike
>
> On Tue, Feb 8, 2011 at 8:19 AM, Oeyvind Brandtsegg
>  wrote:
>> That sounds super.
>> Oeyvind
>>
>> 2011/2/8 Michael Gogins :
>>> I'm not sure -- that may be possible. I will check tonight.
>>>
>>> If not, I think I will create new dynamic language opcodes, where the
>>> entire opcode is written in Python or Lua. In these cases the csound
>>> object would be callable from the opcode functions.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Feb 8, 2011 at 2:23 AM, Oeyvind Brandtsegg
>>>  wrote:
>>>> Would it be possible to access the csound API from Python, when Python
>>>> is run via the py opcodes in Csound?
>>>> So for example (pseudo code):
>>>>
>>>> pyinit
>>>> instr 1
>>>> pyruni "csound.SetChannel(channelName, value)"
>>>> endin
>>>>
>>>> It would be very useful to be able to send data back and forth between
>>>> Csound and Python, in a more flexible manner than what the pycallN
>>>> opcodes allows.
>>>>
>>>> all best
>>>> Oeyvind
>>>>
>>>>
>>>> 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"
>>
>>
>
>
>
> --
> 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"

Yes, I also agree that the third option sounds very interesting.
Super super.
Oeyvind

2011/2/9 Francois PINOT :
> Hello Mike,
>
> The third option seems very interesting: it would not break backup
> compatibility and it could effectively allow to do a lot of things.
>
> Regards
>
> Francois
>
> 2011/2/9 Michael Gogins 
>>
>> I looked at the code, it does not currently support accessing the
>> Csound object from within Python opcodes.
>>
>> The options as I seem them are:
>>
>> (1) Csound could certainly be instantiated from the Python code in a
>> Python opcode. We could add a method to the API to return the
>> instances of Csound created in the current thread.
>>
>> (2) The existing Python opcodes could be re-written so that a Python
>> wrapper to the running instance of Csound is always passed into the
>> code, perhaps just as an object in module scope.
>>
>> (3) We could introduce new opcodes that would be written in pure
>> Python or other dynamic languages. They would have opcode callbacks
>> that have a Csound object parameter just as the C opcodes do. Frankly
>> I think this is the best option as it allows the user to pretty much
>> do anything and I think it is fairly intuitive. These opcodes could
>> also be implemented as new opcodes in the regular CsInstruments
>> section that would take, as arguments, the name, intypes, outtypes,
>> and code text (in multiple lines) of the opcode. Something like this:
>>
>> pythonopcode"name", "intypes", "outtypes", rates, {{
>> def irate(csound, intypes, outtypes, state):
>>  dosomething
>>  outtypes[0] = x
>> }}
>>
>> The intypes, outtypes, and state parameters contain lists of input and
>> output parameters and a dictionary for opcode state. Alternatively the
>> opcode code would inherit from a special Python opcode base class
>> similar to the OpcodeBase.hpp code.
>>
>> Well, let me know what you think.
>>
>> Regards,
>> Mike
>>
>> On Tue, Feb 8, 2011 at 8:19 AM, Oeyvind Brandtsegg
>>  wrote:
>> > That sounds super.
>> > Oeyvind
>> >
>> > 2011/2/8 Michael Gogins :
>> >> I'm not sure -- that may be possible. I will check tonight.
>> >>
>> >> If not, I think I will create new dynamic language opcodes, where the
>> >> entire opcode is written in Python or Lua. In these cases the csound
>> >> object would be callable from the opcode functions.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >> On Tue, Feb 8, 2011 at 2:23 AM, Oeyvind Brandtsegg
>> >>  wrote:
>> >>> Would it be possible to access the csound API from Python, when Python
>> >>> is run via the py opcodes in Csound?
>> >>> So for example (pseudo code):
>> >>>
>> >>> pyinit
>> >>> instr 1
>> >>> pyruni "csound.SetChannel(channelName, value)"
>> >>> endin
>> >>>
>> >>> It would be very useful to be able to send data back and forth between
>> >>> Csound and Python, in a more flexible manner than what the pycallN
>> >>> opcodes allows.
>> >>>
>> >>> all best
>> >>> Oeyvind
>> >>>
>> >>>
>> >>> 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"
>> >
>> >
>>
>>
>>
>> --
>> 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"

+1
On 9 Feb 2011, at 09:09, Oeyvind Brandtsegg wrote:

> Yes, I also agree that the third option sounds very interesting.
> Super super.
> Oeyvind
>
> 2011/2/9 Francois PINOT :
>> Hello Mike,
>>
>> The third option seems very interesting: it would not break backup
>> compatibility and it could effectively allow to do a lot of things.
>>
>> Regards
>>
>> Francois
>>
>> 2011/2/9 Michael Gogins 
>>>
>>> I looked at the code, it does not currently support accessing the
>>> Csound object from within Python opcodes.
>>>
>>> The options as I seem them are:
>>>
>>> (1) Csound could certainly be instantiated from the Python code in a
>>> Python opcode. We could add a method to the API to return the
>>> instances of Csound created in the current thread.
>>>
>>> (2) The existing Python opcodes could be re-written so that a Python
>>> wrapper to the running instance of Csound is always passed into the
>>> code, perhaps just as an object in module scope.
>>>
>>> (3) We could introduce new opcodes that would be written in pure
>>> Python or other dynamic languages. They would have opcode callbacks
>>> that have a Csound object parameter just as the C opcodes do.  
>>> Frankly
>>> I think this is the best option as it allows the user to pretty much
>>> do anything and I think it is fairly intuitive. These opcodes could
>>> also be implemented as new opcodes in the regular CsInstruments
>>> section that would take, as arguments, the name, intypes, outtypes,
>>> and code text (in multiple lines) of the opcode. Something like  
>>> this:
>>>
>>> pythonopcode"name", "intypes", "outtypes", rates, {{
>>> def irate(csound, intypes, outtypes, state):
>>>  dosomething
>>>  outtypes[0] = x
>>> }}
>>>
>>> The intypes, outtypes, and state parameters contain lists of input  
>>> and
>>> output parameters and a dictionary for opcode state. Alternatively  
>>> the
>>> opcode code would inherit from a special Python opcode base class
>>> similar to the OpcodeBase.hpp code.
>>>
>>> Well, let me know what you think.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Feb 8, 2011 at 8:19 AM, Oeyvind Brandtsegg
>>>  wrote:
>>>> That sounds super.
>>>> Oeyvind
>>>>
>>>> 2011/2/8 Michael Gogins :
>>>>> I'm not sure -- that may be possible. I will check tonight.
>>>>>
>>>>> If not, I think I will create new dynamic language opcodes,  
>>>>> where the
>>>>> entire opcode is written in Python or Lua. In these cases the  
>>>>> csound
>>>>> object would be callable from the opcode functions.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On Tue, Feb 8, 2011 at 2:23 AM, Oeyvind Brandtsegg
>>>>>  wrote:
>>>>>> Would it be possible to access the csound API from Python, when  
>>>>>> Python
>>>>>> is run via the py opcodes in Csound?
>>>>>> So for example (pseudo code):
>>>>>>
>>>>>> pyinit
>>>>>> instr 1
>>>>>> pyruni "csound.SetChannel(channelName, value)"
>>>>>> endin
>>>>>>
>>>>>> It would be very useful to be able to send data back and forth  
>>>>>> between
>>>>>> Csound and Python, in a more flexible manner than what the  
>>>>>> pycallN
>>>>>> opcodes allows.
>>>>>>
>>>>>> all best
>>>>>> Oeyvind
>>>>>>
>>>>>>
>>>>>> 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"
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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"