The manual tells me, if I understand correctly, that pyinit is not needed to run the Python opcodes when Python is using csnd6, but I'm sure that I don't understand how it's all supposed to work.

Does this mean I can "cheat" around using API callback functions by telling the Python interpreter what to do from within an orchestra, all while running Csound from that same Python interpreter?

This would open up lots of possibilities for me, but the Python script I've attached stops during the single note, right after printing once but before printing the second time.

I'd appreciate any clarification you can offer.

-Chuckk

--
http://www.badmuthahubbard.com

Not sure about the need (or lack) for pyinit -- but your example uses pycalli

which should run exactly once when the instrument is initialized.

To run periodically at k-rate you'd want pycallk, or so I understand it so far.

Forrest Curo
San Diego

Just say "No!" to oversimplification!

On Mon, Sep 1, 2014 at 12:36 PM, Chuckk Hubbard <badmuthahubbard@gmail.com> wrote:

The manual tells me, if I understand correctly, that pyinit is not needed to run the Python opcodes when Python is using csnd6, but I'm sure that I don't understand how it's all supposed to work.

Does this mean I can "cheat" around using API callback functions by telling the Python interpreter what to do from within an orchestra, all while running Csound from that same Python interpreter?

This would open up lots of possibilities for me, but the Python script I've attached stops during the single note, right after printing once but before printing the second time.

I'd appreciate any clarification you can offer.

-Chuckk

--
http://www.badmuthahubbard.com

Right, but in the output I get, it doesn't run at all. Python stops when it gets there:

>python pycall-test.py
.............................initializing csd_tester
virtual_keyboard real time MIDI plugin for Csound
0dBFS level = 32768.0
Csound version 6.03.2 (double samples) May 12 2014
libsndfile-1.0.25
BEGAN CppSound::compile()...
BEGAN CppSound::compile(2, 0213E890)...
rtaudio: PortAudio module enabled ...
using callback interface
rtmidi: PortMIDI module enabled
--Csound version 6.03.2 (double samples) May 12 2014
displays suppressed
0dBFS level = 32768.0
orch now loaded
audio buffered in 4096 sample-frame blocks
writing 16384-byte blks of shorts to test.wav (WAV)
SECTION 1:
ENDED CppSound::compile.
ENDED CppSound::compile.
.............................Running CSD
instr 1:  p1 = 1.000                      <--------------------- This should be followed by a pycalli opcode, followed by another print command.
inactive allocs returned to freespace
end of score.              overall amps:      0.0      0.0
           overall samples out of range:        0        0
0 errors in performance
8192 16384 sample blks of shorts written to test.wav (WAV)

On Mon, Sep 1, 2014 at 11:48 PM, forrest curo <treegestalt@gmail.com> wrote:

Not sure about the need (or lack) for pyinit -- but your example uses pycalli

which should run exactly once when the instrument is initialized.

To run periodically at k-rate you'd want pycallk, or so I understand it so far.

Forrest Curo
San Diego

Just say "No!" to oversimplification!

On Mon, Sep 1, 2014 at 12:36 PM, Chuckk Hubbard <badmuthahubbard@gmail.com> wrote:

The manual tells me, if I understand correctly, that pyinit is not needed to run the Python opcodes when Python is using csnd6, but I'm sure that I don't understand how it's all supposed to work.

Does this mean I can "cheat" around using API callback functions by telling the Python interpreter what to do from within an orchestra, all while running Csound from that same Python interpreter?

This would open up lots of possibilities for me, but the Python script I've attached stops during the single note, right after printing once but before printing the second time.

I'd appreciate any clarification you can offer.

-Chuckk

--
http://www.badmuthahubbard.com

--
http://www.badmuthahubbard.com

Rather than "print" (which might be 'printing' to anywhere) how about sending out some kind of network message to some other program listening for it...? That would be an easier test, received vs not-received.

Right now you know that csound was happy enough with your code to sucessfully compile it -- and noticed no errors in running it. Probably something happened in there, but didn't connect with anything you were watching.

[A python print statement inside an instance of csound inside a python api -- Where _does_ that print to, anyway? Running the pycode examples in csoundqt didn't put the output anyplace I could find it either! Native csound print opcodes print to the console in a running instance of [csound6~] but I'm guessing that the python command wouldn't.]

Forrest Curo

(still guessing.)

Forrest Curo

On Mon, Sep 1, 2014 at 2:01 PM, Chuckk Hubbard <badmuthahubbard@gmail.com> wrote:

Right, but in the output I get, it doesn't run at all. Python stops when it gets there:

>python pycall-test.py
.............................initializing csd_tester
virtual_keyboard real time MIDI plugin for Csound
0dBFS level = 32768.0
Csound version 6.03.2 (double samples) May 12 2014
libsndfile-1.0.25
BEGAN CppSound::compile()...
BEGAN CppSound::compile(2, 0213E890)...
rtaudio: PortAudio module enabled ...
using callback interface
rtmidi: PortMIDI module enabled
--Csound version 6.03.2 (double samples) May 12 2014
displays suppressed
0dBFS level = 32768.0
orch now loaded
audio buffered in 4096 sample-frame blocks
writing 16384-byte blks of shorts to test.wav (WAV)
SECTION 1:
ENDED CppSound::compile.
ENDED CppSound::compile.
.............................Running CSD
instr 1:  p1 = 1.000                      <--------------------- This should be followed by a pycalli opcode, followed by another print command.
inactive allocs returned to freespace
end of score.              overall amps:      0.0      0.0
           overall samples out of range:        0        0
0 errors in performance
8192 16384 sample blks of shorts written to test.wav (WAV)

On Mon, Sep 1, 2014 at 11:48 PM, forrest curo <treegestalt@gmail.com> wrote:

Not sure about the need (or lack) for pyinit -- but your example uses pycalli

which should run exactly once when the instrument is initialized.

To run periodically at k-rate you'd want pycallk, or so I understand it so far.

Forrest Curo
San Diego

Just say "No!" to oversimplification!

On Mon, Sep 1, 2014 at 12:36 PM, Chuckk Hubbard <badmuthahubbard@gmail.com> wrote:

The manual tells me, if I understand correctly, that pyinit is not needed to run the Python opcodes when Python is using csnd6, but I'm sure that I don't understand how it's all supposed to work.

Does this mean I can "cheat" around using API callback functions by telling the Python interpreter what to do from within an orchestra, all while running Csound from that same Python interpreter?

This would open up lots of possibilities for me, but the Python script I've attached stops during the single note, right after printing once but before printing the second time.

I'd appreciate any clarification you can offer.

-Chuckk

--
http://www.badmuthahubbard.com

--
http://www.badmuthahubbard.com

Rather than "print" (which might be 'printing' to anywhere) how about sending out some kind of network message to some other program listening for it...? That would be an easier test, received vs not-received.

Right now you know that csound was happy enough with your code to sucessfully compile it -- and noticed no errors in running it. Probably something happened in there, but didn't connect with anything you were watching.

[A python print statement inside an instance of csound inside a python api -- Where _does_ that print to, anyway? Running the pycode examples in csoundqt didn't put the output anyplace I could find it either! Native csound print opcodes print to the console in a running instance of [csound6~] but I'm guessing that the python command wouldn't.]

Forrest Curo

(still guessing.)

Forrest Curo

On Mon, Sep 1, 2014 at 2:01 PM, Chuckk Hubbard <badmuthahubbard@gmail.com> wrote:

Right, but in the output I get, it doesn't run at all. Python stops when it gets there:

>python pycall-test.py
.............................initializing csd_tester
virtual_keyboard real time MIDI plugin for Csound
0dBFS level = 32768.0
Csound version 6.03.2 (double samples) May 12 2014
libsndfile-1.0.25
BEGAN CppSound::compile()...
BEGAN CppSound::compile(2, 0213E890)...
rtaudio: PortAudio module enabled ...
using callback interface
rtmidi: PortMIDI module enabled
--Csound version 6.03.2 (double samples) May 12 2014
displays suppressed
0dBFS level = 32768.0
orch now loaded
audio buffered in 4096 sample-frame blocks
writing 16384-byte blks of shorts to test.wav (WAV)
SECTION 1:
ENDED CppSound::compile.
ENDED CppSound::compile.
.............................Running CSD
instr 1:  p1 = 1.000                      <--------------------- This should be followed by a pycalli opcode, followed by another print command.
inactive allocs returned to freespace
end of score.              overall amps:      0.0      0.0
           overall samples out of range:        0        0
0 errors in performance
8192 16384 sample blks of shorts written to test.wav (WAV)

On Mon, Sep 1, 2014 at 11:48 PM, forrest curo <treegestalt@gmail.com> wrote:

Not sure about the need (or lack) for pyinit -- but your example uses pycalli

which should run exactly once when the instrument is initialized.

To run periodically at k-rate you'd want pycallk, or so I understand it so far.

Forrest Curo
San Diego

Just say "No!" to oversimplification!

On Mon, Sep 1, 2014 at 12:36 PM, Chuckk Hubbard <badmuthahubbard@gmail.com> wrote:

The manual tells me, if I understand correctly, that pyinit is not needed to run the Python opcodes when Python is using csnd6, but I'm sure that I don't understand how it's all supposed to work.

Does this mean I can "cheat" around using API callback functions by telling the Python interpreter what to do from within an orchestra, all while running Csound from that same Python interpreter?

This would open up lots of possibilities for me, but the Python script I've attached stops during the single note, right after printing once but before printing the second time.

I'd appreciate any clarification you can offer.

-Chuckk

--
http://www.badmuthahubbard.com

--
http://www.badmuthahubbard.com

That's a good point. Obviously, printing is not my final goal. Let me try something else. Thanks for the suggestion!


-Chuckk

On Tue, Sep 2, 2014 at 1:17 AM, forrest curo <treegestalt@gmail.com> wrote:

Rather than "print" (which might be 'printing' to anywhere) how about sending out some kind of network message to some other program listening for it...? That would be an easier test, received vs not-received.

Right now you know that csound was happy enough with your code to sucessfully compile it -- and noticed no errors in running it. Probably something happened in there, but didn't connect with anything you were watching.

[A python print statement inside an instance of csound inside a python api -- Where _does_ that print to, anyway? Running the pycode examples in csoundqt didn't put the output anyplace I could find it either! Native csound print opcodes print to the console in a running instance of [csound6~] but I'm guessing that the python command wouldn't.]

Forrest Curo

(still guessing.)

Forrest Curo

On Mon, Sep 1, 2014 at 2:01 PM, Chuckk Hubbard <badmuthahubbard@gmail.com> wrote:

Right, but in the output I get, it doesn't run at all. Python stops when it gets there:

>python pycall-test.py
.............................initializing csd_tester
virtual_keyboard real time MIDI plugin for Csound
0dBFS level = 32768.0
Csound version 6.03.2 (double samples) May 12 2014
libsndfile-1.0.25
BEGAN CppSound::compile()...
BEGAN CppSound::compile(2, 0213E890)...
rtaudio: PortAudio module enabled ...
using callback interface
rtmidi: PortMIDI module enabled
--Csound version 6.03.2 (double samples) May 12 2014
displays suppressed
0dBFS level = 32768.0
orch now loaded
audio buffered in 4096 sample-frame blocks
writing 16384-byte blks of shorts to test.wav (WAV)
SECTION 1:
ENDED CppSound::compile.
ENDED CppSound::compile.
.............................Running CSD
instr 1:  p1 = 1.000                      <--------------------- This should be followed by a pycalli opcode, followed by another print command.
inactive allocs returned to freespace
end of score.              overall amps:      0.0      0.0
           overall samples out of range:        0        0
0 errors in performance
8192 16384 sample blks of shorts written to test.wav (WAV)

On Mon, Sep 1, 2014 at 11:48 PM, forrest curo <treegestalt@gmail.com> wrote:

Not sure about the need (or lack) for pyinit -- but your example uses pycalli

which should run exactly once when the instrument is initialized.

To run periodically at k-rate you'd want pycallk, or so I understand it so far.

Forrest Curo
San Diego

Just say "No!" to oversimplification!

On Mon, Sep 1, 2014 at 12:36 PM, Chuckk Hubbard <badmuthahubbard@gmail.com> wrote:

The manual tells me, if I understand correctly, that pyinit is not needed to run the Python opcodes when Python is using csnd6, but I'm sure that I don't understand how it's all supposed to work.

Does this mean I can "cheat" around using API callback functions by telling the Python interpreter what to do from within an orchestra, all while running Csound from that same Python interpreter?

This would open up lots of possibilities for me, but the Python script I've attached stops during the single note, right after printing once but before printing the second time.

I'd appreciate any clarification you can offer.

-Chuckk

--
http://www.badmuthahubbard.com

--
http://www.badmuthahubbard.com

--
http://www.badmuthahubbard.com

I haven't read evverything in the thread, so sorry if I'm answering
the wrong question,
but it seems to me the crash may have to do with the combination of
performanceThread and py opcodes.
My hunch is that the threading goes haywire.
But you could run pyinit in Csound, still using Python as the host like this:
(merged your example with Steven Yi's example3.py from his talk in Boston)

#!/usr/bin/env python

import csnd6
import os
import time

def increment(counter):
    counter += 1
    return counter

def counterprint(counter):
    print 'counter = %d%s' % (counter, os.linesep)

counter = 0
counterprint(counter)

csdorc = '''
sr = 44100
ksmps = 16
nchnls = 2

pyinit

instr 1
print p1

pyruni "message = 400000000"
pyruni "print message"

print p2
endin
'''

csdsco = '''
f0 10 10 1
i1 0 5
'''
c = csnd6.Csound()
c.SetOption("-m0d")  # Using SetOption() to configure Csound
                      # Note: use only one commandline flag at a time
c.CompileOrc(csdorc)     # Compile the Csound Orchestra string
c.ReadScore(csdsco)      # Compile the Csound SCO String
c.Start()  # When compiling from strings, this call is necessary
before doing any performing

counterprint(counter)
print "........................ Perf Thread"
counter = increment(counter)
counterprint(counter)

while (c.PerformKsmps() == 0):
  pass

#c.Perform()  # Run Csound to completion
c.Stop()
print '** stopping csound'

counter = increment(counter)
counterprint(counter)

#*** eof***

best
Oeyvind

2014-09-02 16:37 GMT+02:00 Chuckk Hubbard <badmuthahubbard@gmail.com>:

> Hello again.
> I've tried several methods of checking whether the csnd6 module is calling
> the Python callable, and I see no sign that it is.
> Here is a pared-down version that crashes Python about 50% of the time for
> me. If I include "pyinit" in the orchestra header, it prints the
> "........40000000" message, if I don't include pyinit it doesn't print. The
> Csound manual explicitly says that 'pyinit' isn't necessary if Csound is run
> from the Python API. Regardless, it would be much less disturbing if it
> didn't crash Python. Can anyone confirm?
> Thanks.
>
> -Chuckk
>
>
>
>
>
> On Tue, Sep 2, 2014 at 9:48 AM, Chuckk Hubbard <badmuthahubbard@gmail.com>
> wrote:
>>
>> That's a good point. Obviously, printing is not my final goal. Let me try
>> something else. Thanks for the suggestion!
>>
>>
>> -Chuckk
>>
>>
>> On Tue, Sep 2, 2014 at 1:17 AM, forrest curo <treegestalt@gmail.com>
>> wrote:
>>>
>>> Rather than "print" (which might be 'printing' to anywhere) how about
>>> sending out some kind of network message to some other program listening for
>>> it...? That would be an easier test, received vs not-received.
>>>
>>> Right now you know that csound was happy enough with your code to
>>> sucessfully compile it -- and noticed no errors in running it. Probably
>>> something happened in there, but didn't connect with anything you were
>>> watching.
>>>
>>> [A python print statement inside an instance of csound inside a python
>>> api -- Where _does_ that print to, anyway? Running the pycode examples in
>>> csoundqt didn't put the output anyplace I could find it either! Native
>>> csound print opcodes print to the console in a running instance of
>>> [csound6~] but I'm guessing that the python command wouldn't.]
>>>
>>> Forrest Curo
>>> (still guessing.)
>>>
>>> Forrest Curo
>>>
>>>
>>> On Mon, Sep 1, 2014 at 2:01 PM, Chuckk Hubbard
>>> <badmuthahubbard@gmail.com> wrote:
>>>>
>>>> Right, but in the output I get, it doesn't run at all. Python stops when
>>>> it gets there:
>>>>
>>>> >python pycall-test.py
>>>> .............................initializing csd_tester
>>>> virtual_keyboard real time MIDI plugin for Csound
>>>> 0dBFS level = 32768.0
>>>> Csound version 6.03.2 (double samples) May 12 2014
>>>> libsndfile-1.0.25
>>>> BEGAN CppSound::compile()...
>>>> BEGAN CppSound::compile(2, 0213E890)...
>>>> rtaudio: PortAudio module enabled ...
>>>> using callback interface
>>>> rtmidi: PortMIDI module enabled
>>>> --Csound version 6.03.2 (double samples) May 12 2014
>>>> displays suppressed
>>>> 0dBFS level = 32768.0
>>>> orch now loaded
>>>> audio buffered in 4096 sample-frame blocks
>>>> writing 16384-byte blks of shorts to test.wav (WAV)
>>>> SECTION 1:
>>>> ENDED CppSound::compile.
>>>> ENDED CppSound::compile.
>>>> .............................Running CSD
>>>> instr 1:  p1 = 1.000                      <--------------------- This
>>>> should be followed by a pycalli opcode, followed by another print command.
>>>> inactive allocs returned to freespace
>>>> end of score.              overall amps:      0.0      0.0
>>>>            overall samples out of range:        0        0
>>>> 0 errors in performance
>>>> 8192 16384 sample blks of shorts written to test.wav (WAV)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Sep 1, 2014 at 11:48 PM, forrest curo <treegestalt@gmail.com>
>>>> wrote:
>>>>>
>>>>> Not sure about the need (or lack) for pyinit -- but your example uses
>>>>> pycalli
>>>>>
>>>>> which should run exactly once when the instrument is initialized.
>>>>>
>>>>> To run periodically at k-rate you'd want pycallk, or so I understand it
>>>>> so far.
>>>>>
>>>>> Forrest Curo
>>>>> San Diego
>>>>> Just say "No!" to oversimplification!
>>>>>
>>>>>
>>>>> On Mon, Sep 1, 2014 at 12:36 PM, Chuckk Hubbard
>>>>> <badmuthahubbard@gmail.com> wrote:
>>>>>>
>>>>>> The manual tells me, if I understand correctly, that pyinit is not
>>>>>> needed to run the Python opcodes when Python is using csnd6, but I'm sure
>>>>>> that I don't understand how it's all supposed to work.
>>>>>> Does this mean I can "cheat" around using API callback functions by
>>>>>> telling the Python interpreter what to do from within an orchestra, all
>>>>>> while running Csound from that same Python interpreter?
>>>>>>
>>>>>> This would open up lots of possibilities for me, but the Python script
>>>>>> I've attached stops during the single note, right after printing once but
>>>>>> before printing the second time.
>>>>>>
>>>>>> I'd appreciate any clarification you can offer.
>>>>>>
>>>>>> -Chuckk
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.badmuthahubbard.com
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>
>
>
>
> --
> http://www.badmuthahubbard.com

--

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"

I haven't read evverything in the thread, so sorry if I'm answering
the wrong question,
but it seems to me the crash may have to do with the combination of
performanceThread and py opcodes.
My hunch is that the threading goes haywire.
But you could run pyinit in Csound, still using Python as the host like this:
(merged your example with Steven Yi's example3.py from his talk in Boston)

#!/usr/bin/env python

import csnd6
import os
import time

def increment(counter):
    counter += 1
    return counter

def counterprint(counter):
    print 'counter = %d%s' % (counter, os.linesep)

counter = 0
counterprint(counter)

csdorc = '''
sr = 44100
ksmps = 16
nchnls = 2

pyinit

instr 1
print p1

pyruni "message = 400000000"
pyruni "print message"

print p2
endin
'''

csdsco = '''
f0 10 10 1
i1 0 5
'''
c = csnd6.Csound()
c.SetOption("-m0d")  # Using SetOption() to configure Csound
                      # Note: use only one commandline flag at a time
c.CompileOrc(csdorc)     # Compile the Csound Orchestra string
c.ReadScore(csdsco)      # Compile the Csound SCO String
c.Start()  # When compiling from strings, this call is necessary
before doing any performing

counterprint(counter)
print "........................ Perf Thread"
counter = increment(counter)
counterprint(counter)

while (c.PerformKsmps() == 0):
  pass

#c.Perform()  # Run Csound to completion
c.Stop()
print '** stopping csound'

counter = increment(counter)
counterprint(counter)

#*** eof***

best
Oeyvind

2014-09-02 16:37 GMT+02:00 Chuckk Hubbard <badmuthahubbard@gmail.com>:

> Hello again.
> I've tried several methods of checking whether the csnd6 module is calling
> the Python callable, and I see no sign that it is.
> Here is a pared-down version that crashes Python about 50% of the time for
> me. If I include "pyinit" in the orchestra header, it prints the
> "........40000000" message, if I don't include pyinit it doesn't print. The
> Csound manual explicitly says that 'pyinit' isn't necessary if Csound is run
> from the Python API. Regardless, it would be much less disturbing if it
> didn't crash Python. Can anyone confirm?
> Thanks.
>
> -Chuckk
>
>
>
>
>
> On Tue, Sep 2, 2014 at 9:48 AM, Chuckk Hubbard <badmuthahubbard@gmail.com>
> wrote:
>>
>> That's a good point. Obviously, printing is not my final goal. Let me try
>> something else. Thanks for the suggestion!
>>
>>
>> -Chuckk
>>
>>
>> On Tue, Sep 2, 2014 at 1:17 AM, forrest curo <treegestalt@gmail.com>
>> wrote:
>>>
>>> Rather than "print" (which might be 'printing' to anywhere) how about
>>> sending out some kind of network message to some other program listening for
>>> it...? That would be an easier test, received vs not-received.
>>>
>>> Right now you know that csound was happy enough with your code to
>>> sucessfully compile it -- and noticed no errors in running it. Probably
>>> something happened in there, but didn't connect with anything you were
>>> watching.
>>>
>>> [A python print statement inside an instance of csound inside a python
>>> api -- Where _does_ that print to, anyway? Running the pycode examples in
>>> csoundqt didn't put the output anyplace I could find it either! Native
>>> csound print opcodes print to the console in a running instance of
>>> [csound6~] but I'm guessing that the python command wouldn't.]
>>>
>>> Forrest Curo
>>> (still guessing.)
>>>
>>> Forrest Curo
>>>
>>>
>>> On Mon, Sep 1, 2014 at 2:01 PM, Chuckk Hubbard
>>> <badmuthahubbard@gmail.com> wrote:
>>>>
>>>> Right, but in the output I get, it doesn't run at all. Python stops when
>>>> it gets there:
>>>>
>>>> >python pycall-test.py
>>>> .............................initializing csd_tester
>>>> virtual_keyboard real time MIDI plugin for Csound
>>>> 0dBFS level = 32768.0
>>>> Csound version 6.03.2 (double samples) May 12 2014
>>>> libsndfile-1.0.25
>>>> BEGAN CppSound::compile()...
>>>> BEGAN CppSound::compile(2, 0213E890)...
>>>> rtaudio: PortAudio module enabled ...
>>>> using callback interface
>>>> rtmidi: PortMIDI module enabled
>>>> --Csound version 6.03.2 (double samples) May 12 2014
>>>> displays suppressed
>>>> 0dBFS level = 32768.0
>>>> orch now loaded
>>>> audio buffered in 4096 sample-frame blocks
>>>> writing 16384-byte blks of shorts to test.wav (WAV)
>>>> SECTION 1:
>>>> ENDED CppSound::compile.
>>>> ENDED CppSound::compile.
>>>> .............................Running CSD
>>>> instr 1:  p1 = 1.000                      <--------------------- This
>>>> should be followed by a pycalli opcode, followed by another print command.
>>>> inactive allocs returned to freespace
>>>> end of score.              overall amps:      0.0      0.0
>>>>            overall samples out of range:        0        0
>>>> 0 errors in performance
>>>> 8192 16384 sample blks of shorts written to test.wav (WAV)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Sep 1, 2014 at 11:48 PM, forrest curo <treegestalt@gmail.com>
>>>> wrote:
>>>>>
>>>>> Not sure about the need (or lack) for pyinit -- but your example uses
>>>>> pycalli
>>>>>
>>>>> which should run exactly once when the instrument is initialized.
>>>>>
>>>>> To run periodically at k-rate you'd want pycallk, or so I understand it
>>>>> so far.
>>>>>
>>>>> Forrest Curo
>>>>> San Diego
>>>>> Just say "No!" to oversimplification!
>>>>>
>>>>>
>>>>> On Mon, Sep 1, 2014 at 12:36 PM, Chuckk Hubbard
>>>>> <badmuthahubbard@gmail.com> wrote:
>>>>>>
>>>>>> The manual tells me, if I understand correctly, that pyinit is not
>>>>>> needed to run the Python opcodes when Python is using csnd6, but I'm sure
>>>>>> that I don't understand how it's all supposed to work.
>>>>>> Does this mean I can "cheat" around using API callback functions by
>>>>>> telling the Python interpreter what to do from within an orchestra, all
>>>>>> while running Csound from that same Python interpreter?
>>>>>>
>>>>>> This would open up lots of possibilities for me, but the Python script
>>>>>> I've attached stops during the single note, right after printing once but
>>>>>> before printing the second time.
>>>>>>
>>>>>> I'd appreciate any clarification you can offer.
>>>>>>
>>>>>> -Chuckk
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.badmuthahubbard.com
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>
>
>
>
> --
> http://www.badmuthahubbard.com

--

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"

Hi Chuck,
I do recognize this kind of problem, and I've struggled with similar
problems in my own work.
I think there is no hard and fast method to solve it, it depends on
your priorities, what is most important (timing precision vs
performance could be one such dimension).

One possible solution could be to use Csound as the main/host, then
send OSC from Csound (to Python or to another Csound instance). This
way you could get access to more midi ports even from Csound (by
multiple instances). Also, the processes would run separately,
allowing each one to get a different priority if you need to do that.
However, when things run in the same thread it is much easier to
synchronize. For example using performKsmps, as you then have a clock
source that is tightly synchronized to the audio loop. The bad thing
is of course if you have a method call that takes a long time to
return you get dropouts. If you split into different processes, you
will still have pretty good synchronization as long as nothing
processor heavy is going on. When that happens, the CPU-heavy process
could lag behind temporarily. For example playing some notes late. For
me, audio dropouts are worse than getting a few note events late. Both
are very bad indeed, but if I have to choose what to do in the worst
case scenario, I'd go for a late note. So my latest take on it is
sending OSC from Csound to Python, (each running as separate programs)
calculating whatever needs calculating, then sending OSC back to
Csound to trigger new note events. You might get timing jitter of a
few ksmps periods for new events. So perhaps one could imagine a tight
loop sync (e.g. using py opcodes, still running Csound as the host)
and another loose timing loop (based on OSC).
There are many options, and the specific needs of your application
would determine what compromises you can live with.

Btw, Forest, I've never experienced lost events between Csound and
Python. If you have several writes to a control channel during one
ksmps loop, you would lose control data items (only keeping the last
one as far as I understand. But if you have several events (e.g.
csound.inputMessage()), all of them will be kept, and all instantiated
on the next k-rate boundary.

best
Oeyvind

2014-09-02 23:24 GMT+02:00 Chuckk Hubbard <badmuthahubbard@gmail.com>:

> Thanks, Oeyvind.
> I've taken a long hiatus from working on my program. I've been taken on as
> banjo player for a Romanian pop star (Loredana Groza), so I've kind of moved
> in a different direction than anyone would ever have expected! But not at
> all a bad direction.
> The actual program I'm trying to change is far more complicated. I don't
> recall what problems I ran into while deciding which method to use to run my
> csds, but I chose the performance thread for a reason. It may have had to do
> with having to use a loop in the main program to listen for messages from
> the Csound instance telling it to move the onscreen cursor, but at a lower
> priority than the Csound audio. If using the py opcodes causes problems with
> Performance Thread, I'm sure that something other than the py opcodes will
> be simpler than rewriting the code I used to run Csound.
>
> The goal is to send MIDI messages using Pygame, not Csound (since Csound
> cannot handle multiple rt MIDI out devices), but keep Csound for the timing
> and in case users want to mix Csound instruments with MIDI. It's just
> intonation, as you may recall, so 16 channels is not enough. I wrestled with
> trying to find some way to get i-time events in Csound to call functions in
> the Python host for a good while, but I finally gave up. I was thinking
> there might be something in Csound 6 that would make it easier. Any other
> ideas you have would be appreciated!
>
> -Chuckk
>
>
>
>
>
> On Tue, Sep 2, 2014 at 11:07 PM, Oeyvind Brandtsegg
> <oyvind.brandtsegg@ntnu.no> wrote:
>>
>> I haven't read evverything in the thread, so sorry if I'm answering
>> the wrong question,
>> but it seems to me the crash may have to do with the combination of
>> performanceThread and py opcodes.
>> My hunch is that the threading goes haywire.
>> But you could run pyinit in Csound, still using Python as the host like
>> this:
>> (merged your example with Steven Yi's example3.py from his talk in Boston)
>>
>> #!/usr/bin/env python
>>
>> import csnd6
>> import os
>> import time
>>
>> def increment(counter):
>>     counter += 1
>>     return counter
>>
>> def counterprint(counter):
>>     print 'counter = %d%s' % (counter, os.linesep)
>>
>> counter = 0
>> counterprint(counter)
>>
>> csdorc = '''
>> sr = 44100
>> ksmps = 16
>> nchnls = 2
>>
>> pyinit
>>
>> instr 1
>> print p1
>>
>> pyruni "message = 400000000"
>> pyruni "print message"
>>
>> print p2
>> endin
>> '''
>>
>> csdsco = '''
>> f0 10 10 1
>> i1 0 5
>> '''
>> c = csnd6.Csound()
>> c.SetOption("-m0d")  # Using SetOption() to configure Csound
>>                       # Note: use only one commandline flag at a time
>> c.CompileOrc(csdorc)     # Compile the Csound Orchestra string
>> c.ReadScore(csdsco)      # Compile the Csound SCO String
>> c.Start()  # When compiling from strings, this call is necessary
>> before doing any performing
>>
>> counterprint(counter)
>> print "........................ Perf Thread"
>> counter = increment(counter)
>> counterprint(counter)
>>
>> while (c.PerformKsmps() == 0):
>>   pass
>>
>> #c.Perform()  # Run Csound to completion
>> c.Stop()
>> print '** stopping csound'
>>
>> counter = increment(counter)
>> counterprint(counter)
>>
>> #*** eof***
>>
>> best
>> Oeyvind
>>
>> 2014-09-02 16:37 GMT+02:00 Chuckk Hubbard <badmuthahubbard@gmail.com>:
>> > Hello again.
>> > I've tried several methods of checking whether the csnd6 module is
>> > calling
>> > the Python callable, and I see no sign that it is.
>> > Here is a pared-down version that crashes Python about 50% of the time
>> > for
>> > me. If I include "pyinit" in the orchestra header, it prints the
>> > "........40000000" message, if I don't include pyinit it doesn't print.
>> > The
>> > Csound manual explicitly says that 'pyinit' isn't necessary if Csound is
>> > run
>> > from the Python API. Regardless, it would be much less disturbing if it
>> > didn't crash Python. Can anyone confirm?
>> > Thanks.
>> >
>> > -Chuckk
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Sep 2, 2014 at 9:48 AM, Chuckk Hubbard
>> > <badmuthahubbard@gmail.com>
>> > wrote:
>> >>
>> >> That's a good point. Obviously, printing is not my final goal. Let me
>> >> try
>> >> something else. Thanks for the suggestion!
>> >>
>> >>
>> >> -Chuckk
>> >>
>> >>
>> >> On Tue, Sep 2, 2014 at 1:17 AM, forrest curo <treegestalt@gmail.com>
>> >> wrote:
>> >>>
>> >>> Rather than "print" (which might be 'printing' to anywhere) how about
>> >>> sending out some kind of network message to some other program
>> >>> listening for
>> >>> it...? That would be an easier test, received vs not-received.
>> >>>
>> >>> Right now you know that csound was happy enough with your code to
>> >>> sucessfully compile it -- and noticed no errors in running it.
>> >>> Probably
>> >>> something happened in there, but didn't connect with anything you were
>> >>> watching.
>> >>>
>> >>> [A python print statement inside an instance of csound inside a python
>> >>> api -- Where _does_ that print to, anyway? Running the pycode examples
>> >>> in
>> >>> csoundqt didn't put the output anyplace I could find it either! Native
>> >>> csound print opcodes print to the console in a running instance of
>> >>> [csound6~] but I'm guessing that the python command wouldn't.]
>> >>>
>> >>> Forrest Curo
>> >>> (still guessing.)
>> >>>
>> >>> Forrest Curo
>> >>>
>> >>>
>> >>> On Mon, Sep 1, 2014 at 2:01 PM, Chuckk Hubbard
>> >>> <badmuthahubbard@gmail.com> wrote:
>> >>>>
>> >>>> Right, but in the output I get, it doesn't run at all. Python stops
>> >>>> when
>> >>>> it gets there:
>> >>>>
>> >>>> >python pycall-test.py
>> >>>> .............................initializing csd_tester
>> >>>> virtual_keyboard real time MIDI plugin for Csound
>> >>>> 0dBFS level = 32768.0
>> >>>> Csound version 6.03.2 (double samples) May 12 2014
>> >>>> libsndfile-1.0.25
>> >>>> BEGAN CppSound::compile()...
>> >>>> BEGAN CppSound::compile(2, 0213E890)...
>> >>>> rtaudio: PortAudio module enabled ...
>> >>>> using callback interface
>> >>>> rtmidi: PortMIDI module enabled
>> >>>> --Csound version 6.03.2 (double samples) May 12 2014
>> >>>> displays suppressed
>> >>>> 0dBFS level = 32768.0
>> >>>> orch now loaded
>> >>>> audio buffered in 4096 sample-frame blocks
>> >>>> writing 16384-byte blks of shorts to test.wav (WAV)
>> >>>> SECTION 1:
>> >>>> ENDED CppSound::compile.
>> >>>> ENDED CppSound::compile.
>> >>>> .............................Running CSD
>> >>>> instr 1:  p1 = 1.000                      <--------------------- This
>> >>>> should be followed by a pycalli opcode, followed by another print
>> >>>> command.
>> >>>> inactive allocs returned to freespace
>> >>>> end of score.              overall amps:      0.0      0.0
>> >>>>            overall samples out of range:        0        0
>> >>>> 0 errors in performance
>> >>>> 8192 16384 sample blks of shorts written to test.wav (WAV)
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Mon, Sep 1, 2014 at 11:48 PM, forrest curo <treegestalt@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Not sure about the need (or lack) for pyinit -- but your example
>> >>>>> uses
>> >>>>> pycalli
>> >>>>>
>> >>>>> which should run exactly once when the instrument is initialized.
>> >>>>>
>> >>>>> To run periodically at k-rate you'd want pycallk, or so I understand
>> >>>>> it
>> >>>>> so far.
>> >>>>>
>> >>>>> Forrest Curo
>> >>>>> San Diego
>> >>>>> Just say "No!" to oversimplification!
>> >>>>>
>> >>>>>
>> >>>>> On Mon, Sep 1, 2014 at 12:36 PM, Chuckk Hubbard
>> >>>>> <badmuthahubbard@gmail.com> wrote:
>> >>>>>>
>> >>>>>> The manual tells me, if I understand correctly, that pyinit is not
>> >>>>>> needed to run the Python opcodes when Python is using csnd6, but
>> >>>>>> I'm sure
>> >>>>>> that I don't understand how it's all supposed to work.
>> >>>>>> Does this mean I can "cheat" around using API callback functions by
>> >>>>>> telling the Python interpreter what to do from within an orchestra,
>> >>>>>> all
>> >>>>>> while running Csound from that same Python interpreter?
>> >>>>>>
>> >>>>>> This would open up lots of possibilities for me, but the Python
>> >>>>>> script
>> >>>>>> I've attached stops during the single note, right after printing
>> >>>>>> once but
>> >>>>>> before printing the second time.
>> >>>>>>
>> >>>>>> I'd appreciate any clarification you can offer.
>> >>>>>>
>> >>>>>> -Chuckk
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> http://www.badmuthahubbard.com
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> http://www.badmuthahubbard.com
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> http://www.badmuthahubbard.com
>> >
>> >
>> >
>> >
>> > --
>> > http://www.badmuthahubbard.com
>>
>>
>>
>> --
>>
>> 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"
>>
>>
>>
>
>
>
> --
> http://www.badmuthahubbard.com



--

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"