Hi,
There might be different functionality, as some things might be
possible in Python (as host/main) that is impossible or very hard to
do in Python via the py opcodes. But it looks to me as if you ask if
there will be a difference in performance(?) To my best knowledge, for
the same functionality, there is the same amount of work that needs to
be done by the CPU etc, and the efficiency of the audio processing
will be the same for both approaches.

A little more detail, that might matter (most likely at a later stage).
When you run Csound via the API from Python, you can run Csound in a
separate thread (the performance thread). This will let Csound run its
ksmps blocks independently of Python timing. This can give more
efficient audio processing. Then again, if you need very tight
synchronization between the two, you will have more control if you
trigger each ksmps period from Python. The choice between these two
ways of running Csound under Python may depend on specific issues in
your  program. Luckily it is relatively easy to change from one method
to the other if you discover that you need to change.

Oeyvind

2014-09-12 5:34 GMT+02:00 forrest curo <treegestalt@gmail.com>:
> It's really hard for me to see what's happening... Steven Yi in some of his
> csound api examples talks about python programs processing notes and
> control-values at block boundaries... and that sounds almost equivalent to
> having a k-rate python opcode running a python script within a csound
> program.
>
> And then there's the buffer... At k-rate times/second the csound program
> puts a  block of values into the buffer, hopefully staying ahead of the need
> to send those values onward to dac at audio-rate. (Else getting
> 'buffer-underrun' errors. bleh!)
>
> Meanwhile: It's completing all the k-rate calculations for one cycle, then
> producing a series of audio-rate values based on that, then repeating.
>
> Whichever the calling program might be, it's doing its work in those gaps
> between sending out the audio values, hopefully before the buffer values
> from last time quite run dry.
>
> Are there significant differences in functionality depending on which is
> running which?
>
> Forrest Curo
> San Diego

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp


Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

That is about correct yes.  All good.
Oeyvind

15. sep. 2014 00:51 skrev "forrest curo" <treegestalt@gmail.com> følgende:

Thanks, that makes sense!

So I could run Csound from Python in a perfomance thread and get the most-efficient possible audio-processing that way;

and if I then sent some message from a Python routine to an instrument, that message would arrive between k-rate passes, but wouldn't be acted-upon until the next time the performance thread went through a k-rate cycle... Is that all you meant by "more control" via "triggering each ksmps period from Python"?

It sounds like that would only matter if I were trying to use Python to directly control an audio-rate signal, something that csound is far better suited for. For changing pitches or amplitudes, key-changes or crescendos etc via a pygame GUI, a fraction-of-a-second ought to be plenty precise enough (if I've got this right.)

On Sun, Sep 14, 2014 at 1:35 PM, Oeyvind Brandtsegg <oyvind.brandtsegg@ntnu.no> wrote:

Hi,
There might be different functionality, as some things might be
possible in Python (as host/main) that is impossible or very hard to
do in Python via the py opcodes. But it looks to me as if you ask if
there will be a difference in performance(?) To my best knowledge, for
the same functionality, there is the same amount of work that needs to
be done by the CPU etc, and the efficiency of the audio processing
will be the same for both approaches.

A little more detail, that might matter (most likely at a later stage).
When you run Csound via the API from Python, you can run Csound in a
separate thread (the performance thread). This will let Csound run its
ksmps blocks independently of Python timing. This can give more
efficient audio processing. Then again, if you need very tight
synchronization between the two, you will have more control if you
trigger each ksmps period from Python. The choice between these two
ways of running Csound under Python may depend on specific issues in
your  program. Luckily it is relatively easy to change from one method
to the other if you discover that you need to change.

Oeyvind

2014-09-12 5:34 GMT+02:00 forrest curo <treegestalt@gmail.com>:
> It's really hard for me to see what's happening... Steven Yi in some of his
> csound api examples talks about python programs processing notes and
> control-values at block boundaries... and that sounds almost equivalent to
> having a k-rate python opcode running a python script within a csound
> program.
>
> And then there's the buffer... At k-rate times/second the csound program
> puts a  block of values into the buffer, hopefully staying ahead of the need
> to send those values onward to dac at audio-rate. (Else getting
> 'buffer-underrun' errors. bleh!)
>
> Meanwhile: It's completing all the k-rate calculations for one cycle, then
> producing a series of audio-rate values based on that, then repeating.
>
> Whichever the calling program might be, it's doing its work in those gaps
> between sending out the audio values, hopefully before the buffer values
> from last time quite run dry.
>
> Are there significant differences in functionality depending on which is
> running which?
>
> Forrest Curo
> San Diego

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp


Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hey folks,

If I might jump in and ask a related question...

What is the state of python csound integration?

For a long time I have had a dream of being able to access opcodes from python and have my python script be my orc and score. Currently the csound python interface only lets you load a .csd files and then send events to it. You can not build the signal chain, or modify it, in real time.

I know there was work done to the parser that would allow this to happen. So can someone tell me if we have arrived at the point where we can truly integrate python and csound?

Thanks,
Anthony

On Mon, Sep 15, 2014 at 1:26 PM, Oeyvind Brandtsegg <oyvind.brandtsegg@ntnu.no> wrote:

That is about correct yes.  All good.
Oeyvind

15. sep. 2014 00:51 skrev "forrest curo" <treegestalt@gmail.com> følgende:

Thanks, that makes sense!

So I could run Csound from Python in a perfomance thread and get the most-efficient possible audio-processing that way;

and if I then sent some message from a Python routine to an instrument, that message would arrive between k-rate passes, but wouldn't be acted-upon until the next time the performance thread went through a k-rate cycle... Is that all you meant by "more control" via "triggering each ksmps period from Python"?

It sounds like that would only matter if I were trying to use Python to directly control an audio-rate signal, something that csound is far better suited for. For changing pitches or amplitudes, key-changes or crescendos etc via a pygame GUI, a fraction-of-a-second ought to be plenty precise enough (if I've got this right.)

On Sun, Sep 14, 2014 at 1:35 PM, Oeyvind Brandtsegg <oyvind.brandtsegg@ntnu.no> wrote:

Hi,
There might be different functionality, as some things might be
possible in Python (as host/main) that is impossible or very hard to
do in Python via the py opcodes. But it looks to me as if you ask if
there will be a difference in performance(?) To my best knowledge, for
the same functionality, there is the same amount of work that needs to
be done by the CPU etc, and the efficiency of the audio processing
will be the same for both approaches.

A little more detail, that might matter (most likely at a later stage).
When you run Csound via the API from Python, you can run Csound in a
separate thread (the performance thread). This will let Csound run its
ksmps blocks independently of Python timing. This can give more
efficient audio processing. Then again, if you need very tight
synchronization between the two, you will have more control if you
trigger each ksmps period from Python. The choice between these two
ways of running Csound under Python may depend on specific issues in
your  program. Luckily it is relatively easy to change from one method
to the other if you discover that you need to change.

Oeyvind

2014-09-12 5:34 GMT+02:00 forrest curo <treegestalt@gmail.com>:
> It's really hard for me to see what's happening... Steven Yi in some of his
> csound api examples talks about python programs processing notes and
> control-values at block boundaries... and that sounds almost equivalent to
> having a k-rate python opcode running a python script within a csound
> program.
>
> And then there's the buffer... At k-rate times/second the csound program
> puts a  block of values into the buffer, hopefully staying ahead of the need
> to send those values onward to dac at audio-rate. (Else getting
> 'buffer-underrun' errors. bleh!)
>
> Meanwhile: It's completing all the k-rate calculations for one cycle, then
> producing a series of audio-rate values based on that, then repeating.
>
> Whichever the calling program might be, it's doing its work in those gaps
> between sending out the audio values, hopefully before the buffer values
> from last time quite run dry.
>
> Are there significant differences in functionality depending on which is
> running which?
>
> Forrest Curo
> San Diego

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp


Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"