Hi.
I'm running a Python program, and when the user hits 'play' it calls a
separate Python script (with a higher priority) that runs a Csound
instance. I'd like to change this setup so the user may specify some
instruments to be performed through MIDI, through various devices,
with the notes still triggered by the main Csound instance.
The original setup uses a single callback port for communication
between the Python program and the audio engine. To make the MIDI
Csound instances work that way would be pretty complicated: I could
either send the main audio engine the port numbers for each of the
MIDI scripts, have them all wait for connection, and send the messages
directly; or I could set up ports connecting each MIDI script to the
main Python program, then the audio engine sends messages to the main
program when it needs MIDI notes activated.

I also checked out insremote, but I get segmentation violations. It's
also not clear to me how to use insremote for another local instance,
which is mentioned in the manual, but:
insremote "127.0.0.1, "127.0.0.1", 11
don't seem to work. Also, if I create one master and several clients,
all on the same machine, how can I differentiate between the clients?
Thanks for any help.

-Chuckk

I was just playing around with the OSC opcodes today and after a
little hickup at the start it works very well. Perhaps you could try
using that?

2010/1/25 Chuckk Hubbard :
> Hi.
> I'm running a Python program, and when the user hits 'play' it calls a
> separate Python script (with a higher priority) that runs a Csound
> instance. I'd like to change this setup so the user may specify some
> instruments to be performed through MIDI, through various devices,
> with the notes still triggered by the main Csound instance.
> The original setup uses a single callback port for communication
> between th


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Why don't you run them from the same python program and share data using python?

Cheers,
Andrés

On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
 wrote:
> Hi.
> I'm running a Python program, and when the user hits 'play' it calls a
> separate Python script (with a higher priority) that runs a Csound
> instance. I'd like to change this setup so the user may specify some
> instruments to be performed through MIDI, through various devices,
> with the notes still triggered by the main Csound instance.
> The original setup uses a single callback port for communication
> between the Python program and the audio engine. To make the MIDI
> Csound instances work that way would be pretty complicated: I could
> either send the main audio engine the port numbers for each of the
> MIDI scripts, have them all wait for connection, and send the messages
> directly; or I could set up ports connecting each MIDI script to the
> main Python program, then the audio engine sends messages to the main
> program when it needs MIDI notes activated.
>
> I also checked out insremote, but I get segmentation violations. It's
> also not clear to me how to use insremote for another local instance,
> which is mentioned in the manual, but:
> insremote "127.0.0.1, "127.0.0.1", 11
> don't seem to work. Also, if I create one master and several clients,
> all on the same machine, how can I differentiate between the clients?
> Thanks for any help.
>
> -Chuckk
> --
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Andres, thanks for the suggestion.

That's what I'm thinking of now, as subprocesses can be sent a pipe as
stdin, so all the MIDI scripts could be subprocesses of the audio
engine (although maybe they should have lower priorities). But that
leaves the question of how the instance of Csound tells Python what
notes to send when and where. A string channel? The problem I see is
that exporting a variable this way just sets it, it doesn't send a
one-time message. It would need to change, then change back
immediately, but making sure that the message was received first.

-Chuckk


On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
> Why don't you run them from the same python program and share data using python?
>
> Cheers,
> Andrés
>
> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>  wrote:
>> Hi.
>> I'm running a Python program, and when the user hits 'play' it calls a
>> separate Python script (with a higher priority) that runs a Csound
>> instance. I'd like to change this setup so the user may specify some
>> instruments to be performed through MIDI, through various devices,
>> with the notes still triggered by the main Csound instance.
>> The original setup uses a single callback port for communication
>> between the Python program and the audio engine. To make the MIDI
>> Csound instances work that way would be pretty complicated: I could
>> either send the main audio engine the port numbers for each of the
>> MIDI scripts, have them all wait for connection, and send the messages
>> directly; or I could set up ports connecting each MIDI script to the
>> main Python program, then the audio engine sends messages to the main
>> program when it needs MIDI notes activated.
>>
>> I also checked out insremote, but I get segmentation violations. It's
>> also not clear to me how to use insremote for another local instance,
>> which is mentioned in the manual, but:
>> insremote "127.0.0.1, "127.0.0.1", 11
>> don't seem to work. Also, if I create one master and several clients,
>> all on the same machine, how can I differentiate between the clients?
>> Thanks for any help.
>>
>> -Chuckk
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

I'm not sure if its possible in python, but in the C API, you can
register callbacks, so the function is called whenever the
invalue/outvalue opcode is called.
That way you don't need to worry about synchronization.

However, if you need to send very complex data structures, then OSC
might be better....

Cheers,
Andrés

On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
 wrote:
> Hi Andres, thanks for the suggestion.
>
> That's what I'm thinking of now, as subprocesses can be sent a pipe as
> stdin, so all the MIDI scripts could be subprocesses of the audio
> engine (although maybe they should have lower priorities). But that
> leaves the question of how the instance of Csound tells Python what
> notes to send when and where. A string channel? The problem I see is
> that exporting a variable this way just sets it, it doesn't send a
> one-time message. It would need to change, then change back
> immediately, but making sure that the message was received first.
>
> -Chuckk
>
>
> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>> Why don't you run them from the same python program and share data using python?
>>
>> Cheers,
>> Andrés
>>
>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>  wrote:
>>> Hi.
>>> I'm running a Python program, and when the user hits 'play' it calls a
>>> separate Python script (with a higher priority) that runs a Csound
>>> instance. I'd like to change this setup so the user may specify some
>>> instruments to be performed through MIDI, through various devices,
>>> with the notes still triggered by the main Csound instance.
>>> The original setup uses a single callback port for communication
>>> between the Python program and the audio engine. To make the MIDI
>>> Csound instances work that way would be pretty complicated: I could
>>> either send the main audio engine the port numbers for each of the
>>> MIDI scripts, have them all wait for connection, and send the messages
>>> directly; or I could set up ports connecting each MIDI script to the
>>> main Python program, then the audio engine sends messages to the main
>>> program when it needs MIDI notes activated.
>>>
>>> I also checked out insremote, but I get segmentation violations. It's
>>> also not clear to me how to use insremote for another local instance,
>>> which is mentioned in the manual, but:
>>> insremote "127.0.0.1, "127.0.0.1", 11
>>> don't seem to work. Also, if I create one master and several clients,
>>> all on the same machine, how can I differentiate between the clients?
>>> Thanks for any help.
>>>
>>> -Chuckk
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks for the suggestion, it looks like a good idea, if I can figure
out the arguments for Python. I tried something like the cb.py/cb.csd
examples, both with chnexport and chnset, but even using i-rate
variables, they constantly call the callback on every k cycle. I have
a feeling outvalue will do the same. Any ideas, anyone, how to use
channel callbacks only at i-rate?

-Chuckk

On Mon, Jan 25, 2010 at 11:57 PM, Andres Cabrera  wrote:
> Hi,
>
> I'm not sure if its possible in python, but in the C API, you can
> register callbacks, so the function is called whenever the
> invalue/outvalue opcode is called.
> That way you don't need to worry about synchronization.
>
> However, if you need to send very complex data structures, then OSC
> might be better....
>
> Cheers,
> Andrés
>
> On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
>  wrote:
>> Hi Andres, thanks for the suggestion.
>>
>> That's what I'm thinking of now, as subprocesses can be sent a pipe as
>> stdin, so all the MIDI scripts could be subprocesses of the audio
>> engine (although maybe they should have lower priorities). But that
>> leaves the question of how the instance of Csound tells Python what
>> notes to send when and where. A string channel? The problem I see is
>> that exporting a variable this way just sets it, it doesn't send a
>> one-time message. It would need to change, then change back
>> immediately, but making sure that the message was received first.
>>
>> -Chuckk
>>
>>
>> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>>> Why don't you run them from the same python program and share data using python?
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>>  wrote:
>>>> Hi.
>>>> I'm running a Python program, and when the user hits 'play' it calls a
>>>> separate Python script (with a higher priority) that runs a Csound
>>>> instance. I'd like to change this setup so the user may specify some
>>>> instruments to be performed through MIDI, through various devices,
>>>> with the notes still triggered by the main Csound instance.
>>>> The original setup uses a single callback port for communication
>>>> between the Python program and the audio engine. To make the MIDI
>>>> Csound instances work that way would be pretty complicated: I could
>>>> either send the main audio engine the port numbers for each of the
>>>> MIDI scripts, have them all wait for connection, and send the messages
>>>> directly; or I could set up ports connecting each MIDI script to the
>>>> main Python program, then the audio engine sends messages to the main
>>>> program when it needs MIDI notes activated.
>>>>
>>>> I also checked out insremote, but I get segmentation violations. It's
>>>> also not clear to me how to use insremote for another local instance,
>>>> which is mentioned in the manual, but:
>>>> insremote "127.0.0.1, "127.0.0.1", 11
>>>> don't seem to work. Also, if I create one master and several clients,
>>>> all on the same machine, how can I differentiate between the clients?
>>>> Thanks for any help.
>>>>
>>>> -Chuckk
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

The opcodes work at k-rate, so the callbacks will be made at k-rate.
I've been thinking of adding an i-rate version of these opcodes...
You could make a conditional statement so they are used in
initialization (they will produce a value then as well), and skip them
during performance.

Cheers,
Andrés

On Tue, Jan 26, 2010 at 11:13 AM, Chuckk Hubbard
 wrote:
> Thanks for the suggestion, it looks like a good idea, if I can figure
> out the arguments for Python. I tried something like the cb.py/cb.csd
> examples, both with chnexport and chnset, but even using i-rate
> variables, they constantly call the callback on every k cycle. I have
> a feeling outvalue will do the same. Any ideas, anyone, how to use
> channel callbacks only at i-rate?
>
> -Chuckk
>
> On Mon, Jan 25, 2010 at 11:57 PM, Andres Cabrera  wrote:
>> Hi,
>>
>> I'm not sure if its possible in python, but in the C API, you can
>> register callbacks, so the function is called whenever the
>> invalue/outvalue opcode is called.
>> That way you don't need to worry about synchronization.
>>
>> However, if you need to send very complex data structures, then OSC
>> might be better....
>>
>> Cheers,
>> Andrés
>>
>> On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
>>  wrote:
>>> Hi Andres, thanks for the suggestion.
>>>
>>> That's what I'm thinking of now, as subprocesses can be sent a pipe as
>>> stdin, so all the MIDI scripts could be subprocesses of the audio
>>> engine (although maybe they should have lower priorities). But that
>>> leaves the question of how the instance of Csound tells Python what
>>> notes to send when and where. A string channel? The problem I see is
>>> that exporting a variable this way just sets it, it doesn't send a
>>> one-time message. It would need to change, then change back
>>> immediately, but making sure that the message was received first.
>>>
>>> -Chuckk
>>>
>>>
>>> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>>>> Why don't you run them from the same python program and share data using python?
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>>>  wrote:
>>>>> Hi.
>>>>> I'm running a Python program, and when the user hits 'play' it calls a
>>>>> separate Python script (with a higher priority) that runs a Csound
>>>>> instance. I'd like to change this setup so the user may specify some
>>>>> instruments to be performed through MIDI, through various devices,
>>>>> with the notes still triggered by the main Csound instance.
>>>>> The original setup uses a single callback port for communication
>>>>> between the Python program and the audio engine. To make the MIDI
>>>>> Csound instances work that way would be pretty complicated: I could
>>>>> either send the main audio engine the port numbers for each of the
>>>>> MIDI scripts, have them all wait for connection, and send the messages
>>>>> directly; or I could set up ports connecting each MIDI script to the
>>>>> main Python program, then the audio engine sends messages to the main
>>>>> program when it needs MIDI notes activated.
>>>>>
>>>>> I also checked out insremote, but I get segmentation violations. It's
>>>>> also not clear to me how to use insremote for another local instance,
>>>>> which is mentioned in the manual, but:
>>>>> insremote "127.0.0.1, "127.0.0.1", 11
>>>>> don't seem to work. Also, if I create one master and several clients,
>>>>> all on the same machine, how can I differentiate between the clients?
>>>>> Thanks for any help.
>>>>>
>>>>> -Chuckk
>>>>> --
>>>>> http://www.badmuthahubbard.com
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Andrés
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Tried that, but at least with
CsoundPerformanceThread.SetProcessCallback(), it calls the function
continuously regardless of my kgoto statement...

-Chuckk

On Tue, Jan 26, 2010 at 2:23 PM, Andres Cabrera  wrote:
> Hi,
>
> The opcodes work at k-rate, so the callbacks will be made at k-rate.
> I've been thinking of adding an i-rate version of these opcodes...
> You could make a conditional statement so they are used in
> initialization (they will produce a value then as well), and skip them
> during performance.
>
> Cheers,
> Andrés
>
> On Tue, Jan 26, 2010 at 11:13 AM, Chuckk Hubbard
>  wrote:
>> Thanks for the suggestion, it looks like a good idea, if I can figure
>> out the arguments for Python. I tried something like the cb.py/cb.csd
>> examples, both with chnexport and chnset, but even using i-rate
>> variables, they constantly call the callback on every k cycle. I have
>> a feeling outvalue will do the same. Any ideas, anyone, how to use
>> channel callbacks only at i-rate?
>>
>> -Chuckk
>>
>> On Mon, Jan 25, 2010 at 11:57 PM, Andres Cabrera  wrote:
>>> Hi,
>>>
>>> I'm not sure if its possible in python, but in the C API, you can
>>> register callbacks, so the function is called whenever the
>>> invalue/outvalue opcode is called.
>>> That way you don't need to worry about synchronization.
>>>
>>> However, if you need to send very complex data structures, then OSC
>>> might be better....
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
>>>  wrote:
>>>> Hi Andres, thanks for the suggestion.
>>>>
>>>> That's what I'm thinking of now, as subprocesses can be sent a pipe as
>>>> stdin, so all the MIDI scripts could be subprocesses of the audio
>>>> engine (although maybe they should have lower priorities). But that
>>>> leaves the question of how the instance of Csound tells Python what
>>>> notes to send when and where. A string channel? The problem I see is
>>>> that exporting a variable this way just sets it, it doesn't send a
>>>> one-time message. It would need to change, then change back
>>>> immediately, but making sure that the message was received first.
>>>>
>>>> -Chuckk
>>>>
>>>>
>>>> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>>>>> Why don't you run them from the same python program and share data using python?
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>>>>  wrote:
>>>>>> Hi.
>>>>>> I'm running a Python program, and when the user hits 'play' it calls a
>>>>>> separate Python script (with a higher priority) that runs a Csound
>>>>>> instance. I'd like to change this setup so the user may specify some
>>>>>> instruments to be performed through MIDI, through various devices,
>>>>>> with the notes still triggered by the main Csound instance.
>>>>>> The original setup uses a single callback port for communication
>>>>>> between the Python program and the audio engine. To make the MIDI
>>>>>> Csound instances work that way would be pretty complicated: I could
>>>>>> either send the main audio engine the port numbers for each of the
>>>>>> MIDI scripts, have them all wait for connection, and send the messages
>>>>>> directly; or I could set up ports connecting each MIDI script to the
>>>>>> main Python program, then the audio engine sends messages to the main
>>>>>> program when it needs MIDI notes activated.
>>>>>>
>>>>>> I also checked out insremote, but I get segmentation violations. It's
>>>>>> also not clear to me how to use insremote for another local instance,
>>>>>> which is mentioned in the manual, but:
>>>>>> insremote "127.0.0.1, "127.0.0.1", 11
>>>>>> don't seem to work. Also, if I create one master and several clients,
>>>>>> all on the same machine, how can I differentiate between the clients?
>>>>>> Thanks for any help.
>>>>>>
>>>>>> -Chuckk
>>>>>> --
>>>>>> http://www.badmuthahubbard.com
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Andrés
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Here's a script that shows, it prints the value continuously, even
with the note turned off instantly.
Thanks, everyone, for your help so far.
-Chuckk

On Tue, Jan 26, 2010 at 2:35 PM, Chuckk Hubbard
 wrote:
> Tried that, but at least with
> CsoundPerformanceThread.SetProcessCallback(), it calls the function
> continuously regardless of my kgoto statement...
>
> -Chuckk
>
> On Tue, Jan 26, 2010 at 2:23 PM, Andres Cabrera  wrote:
>> Hi,
>>
>> The opcodes work at k-rate, so the callbacks will be made at k-rate.
>> I've been thinking of adding an i-rate version of these opcodes...
>> You could make a conditional statement so they are used in
>> initialization (they will produce a value then as well), and skip them
>> during performance.
>>
>> Cheers,
>> Andrés
>>
>> On Tue, Jan 26, 2010 at 11:13 AM, Chuckk Hubbard
>>  wrote:
>>> Thanks for the suggestion, it looks like a good idea, if I can figure
>>> out the arguments for Python. I tried something like the cb.py/cb.csd
>>> examples, both with chnexport and chnset, but even using i-rate
>>> variables, they constantly call the callback on every k cycle. I have
>>> a feeling outvalue will do the same. Any ideas, anyone, how to use
>>> channel callbacks only at i-rate?
>>>
>>> -Chuckk
>>>
>>> On Mon, Jan 25, 2010 at 11:57 PM, Andres Cabrera  wrote:
>>>> Hi,
>>>>
>>>> I'm not sure if its possible in python, but in the C API, you can
>>>> register callbacks, so the function is called whenever the
>>>> invalue/outvalue opcode is called.
>>>> That way you don't need to worry about synchronization.
>>>>
>>>> However, if you need to send very complex data structures, then OSC
>>>> might be better....
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>> On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
>>>>  wrote:
>>>>> Hi Andres, thanks for the suggestion.
>>>>>
>>>>> That's what I'm thinking of now, as subprocesses can be sent a pipe as
>>>>> stdin, so all the MIDI scripts could be subprocesses of the audio
>>>>> engine (although maybe they should have lower priorities). But that
>>>>> leaves the question of how the instance of Csound tells Python what
>>>>> notes to send when and where. A string channel? The problem I see is
>>>>> that exporting a variable this way just sets it, it doesn't send a
>>>>> one-time message. It would need to change, then change back
>>>>> immediately, but making sure that the message was received first.
>>>>>
>>>>> -Chuckk
>>>>>
>>>>>
>>>>> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>>>>>> Why don't you run them from the same python program and share data using python?
>>>>>>
>>>>>> Cheers,
>>>>>> Andrés
>>>>>>
>>>>>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>>>>>  wrote:
>>>>>>> Hi.
>>>>>>> I'm running a Python program, and when the user hits 'play' it calls a
>>>>>>> separate Python script (with a higher priority) that runs a Csound
>>>>>>> instance. I'd like to change this setup so the user may specify some
>>>>>>> instruments to be performed through MIDI, through various devices,
>>>>>>> with the notes still triggered by the main Csound instance.
>>>>>>> The original setup uses a single callback port for communication
>>>>>>> between the Python program and the audio engine. To make the MIDI
>>>>>>> Csound instances work that way would be pretty complicated: I could
>>>>>>> either send the main audio engine the port numbers for each of the
>>>>>>> MIDI scripts, have them all wait for connection, and send the messages
>>>>>>> directly; or I could set up ports connecting each MIDI script to the
>>>>>>> main Python program, then the audio engine sends messages to the main
>>>>>>> program when it needs MIDI notes activated.
>>>>>>>
>>>>>>> I also checked out insremote, but I get segmentation violations. It's
>>>>>>> also not clear to me how to use insremote for another local instance,
>>>>>>> which is mentioned in the manual, but:
>>>>>>> insremote "127.0.0.1, "127.0.0.1", 11
>>>>>>> don't seem to work. Also, if I create one master and several clients,
>>>>>>> all on the same machine, how can I differentiate between the clients?
>>>>>>> Thanks for any help.
>>>>>>>
>>>>>>> -Chuckk
>>>>>>> --
>>>>>>> http://www.badmuthahubbard.com
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Andrés
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.badmuthahubbard.com
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Andrés
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
> http://www.badmuthahubbard.com
>



-- 
http://www.badmuthahubbard.com

Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

Oh, yes, chnset nad chnget are not callback based. You would need to
use chnsend and chnrecv (which I'm not sure how well they are
working), or invalue/outvalue which are callback based.

A bit of a mess, really...

Cheers,
Andrés

On Tue, Jan 26, 2010 at 1:01 PM, Chuckk Hubbard
 wrote:
> Here's a script that shows, it prints the value continuously, even
> with the note turned off instantly.
> Thanks, everyone, for your help so far.
> -Chuckk
>
> On Tue, Jan 26, 2010 at 2:35 PM, Chuckk Hubbard
>  wrote:
>> Tried that, but at least with
>> CsoundPerformanceThread.SetProcessCallback(), it calls the function
>> continuously regardless of my kgoto statement...
>>
>> -Chuckk
>>
>> On Tue, Jan 26, 2010 at 2:23 PM, Andres Cabrera  wrote:
>>> Hi,
>>>
>>> The opcodes work at k-rate, so the callbacks will be made at k-rate.
>>> I've been thinking of adding an i-rate version of these opcodes...
>>> You could make a conditional statement so they are used in
>>> initialization (they will produce a value then as well), and skip them
>>> during performance.
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Tue, Jan 26, 2010 at 11:13 AM, Chuckk Hubbard
>>>  wrote:
>>>> Thanks for the suggestion, it looks like a good idea, if I can figure
>>>> out the arguments for Python. I tried something like the cb.py/cb.csd
>>>> examples, both with chnexport and chnset, but even using i-rate
>>>> variables, they constantly call the callback on every k cycle. I have
>>>> a feeling outvalue will do the same. Any ideas, anyone, how to use
>>>> channel callbacks only at i-rate?
>>>>
>>>> -Chuckk
>>>>
>>>> On Mon, Jan 25, 2010 at 11:57 PM, Andres Cabrera  wrote:
>>>>> Hi,
>>>>>
>>>>> I'm not sure if its possible in python, but in the C API, you can
>>>>> register callbacks, so the function is called whenever the
>>>>> invalue/outvalue opcode is called.
>>>>> That way you don't need to worry about synchronization.
>>>>>
>>>>> However, if you need to send very complex data structures, then OSC
>>>>> might be better....
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>> On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
>>>>>  wrote:
>>>>>> Hi Andres, thanks for the suggestion.
>>>>>>
>>>>>> That's what I'm thinking of now, as subprocesses can be sent a pipe as
>>>>>> stdin, so all the MIDI scripts could be subprocesses of the audio
>>>>>> engine (although maybe they should have lower priorities). But that
>>>>>> leaves the question of how the instance of Csound tells Python what
>>>>>> notes to send when and where. A string channel? The problem I see is
>>>>>> that exporting a variable this way just sets it, it doesn't send a
>>>>>> one-time message. It would need to change, then change back
>>>>>> immediately, but making sure that the message was received first.
>>>>>>
>>>>>> -Chuckk
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>>>>>>> Why don't you run them from the same python program and share data using python?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andrés
>>>>>>>
>>>>>>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>>>>>>  wrote:
>>>>>>>> Hi.
>>>>>>>> I'm running a Python program, and when the user hits 'play' it calls a
>>>>>>>> separate Python script (with a higher priority) that runs a Csound
>>>>>>>> instance. I'd like to change this setup so the user may specify some
>>>>>>>> instruments to be performed through MIDI, through various devices,
>>>>>>>> with the notes still triggered by the main Csound instance.
>>>>>>>> The original setup uses a single callback port for communication
>>>>>>>> between the Python program and the audio engine. To make the MIDI
>>>>>>>> Csound instances work that way would be pretty complicated: I could
>>>>>>>> either send the main audio engine the port numbers for each of the
>>>>>>>> MIDI scripts, have them all wait for connection, and send the messages
>>>>>>>> directly; or I could set up ports connecting each MIDI script to the
>>>>>>>> main Python program, then the audio engine sends messages to the main
>>>>>>>> program when it needs MIDI notes activated.
>>>>>>>>
>>>>>>>> I also checked out insremote, but I get segmentation violations. It's
>>>>>>>> also not clear to me how to use insremote for another local instance,
>>>>>>>> which is mentioned in the manual, but:
>>>>>>>> insremote "127.0.0.1, "127.0.0.1", 11
>>>>>>>> don't seem to work. Also, if I create one master and several clients,
>>>>>>>> all on the same machine, how can I differentiate between the clients?
>>>>>>>> Thanks for any help.
>>>>>>>>
>>>>>>>> -Chuckk
>>>>>>>> --
>>>>>>>> http://www.badmuthahubbard.com
>>>>>>>>
>>>>>>>>
>>>>>>>> Send bugs reports to this list.
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Andrés
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.badmuthahubbard.com
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Andrés
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>
>
>
> --
> http://www.badmuthahubbard.com
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Substituting:
chnsend "num", ginum
in place of chnset still gives me hundreds of callbacks a second. I
have the feeling that SetProcessCallback is inherently k-rate, no?
Even taking out all references to any channel opcode, and running
'turnoff' doesn't slow it down. I'll need to figure out another
callback function.

-Chuckk

On Tue, Jan 26, 2010 at 3:57 PM, Andres Cabrera  wrote:
> Hi,
>
> Oh, yes, chnset nad chnget are not callback based. You would need to
> use chnsend and chnrecv (which I'm not sure how well they are
> working), or invalue/outvalue which are callback based.
>
> A bit of a mess, really...
>
> Cheers,
> Andrés
>
> On Tue, Jan 26, 2010 at 1:01 PM, Chuckk Hubbard
>  wrote:
>> Here's a script that shows, it prints the value continuously, even
>> with the note turned off instantly.
>> Thanks, everyone, for your help so far.
>> -Chuckk
>>
>> On Tue, Jan 26, 2010 at 2:35 PM, Chuckk Hubbard
>>  wrote:
>>> Tried that, but at least with
>>> CsoundPerformanceThread.SetProcessCallback(), it calls the function
>>> continuously regardless of my kgoto statement...
>>>
>>> -Chuckk
>>>
>>> On Tue, Jan 26, 2010 at 2:23 PM, Andres Cabrera  wrote:
>>>> Hi,
>>>>
>>>> The opcodes work at k-rate, so the callbacks will be made at k-rate.
>>>> I've been thinking of adding an i-rate version of these opcodes...
>>>> You could make a conditional statement so they are used in
>>>> initialization (they will produce a value then as well), and skip them
>>>> during performance.
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>> On Tue, Jan 26, 2010 at 11:13 AM, Chuckk Hubbard
>>>>  wrote:
>>>>> Thanks for the suggestion, it looks like a good idea, if I can figure
>>>>> out the arguments for Python. I tried something like the cb.py/cb.csd
>>>>> examples, both with chnexport and chnset, but even using i-rate
>>>>> variables, they constantly call the callback on every k cycle. I have
>>>>> a feeling outvalue will do the same. Any ideas, anyone, how to use
>>>>> channel callbacks only at i-rate?
>>>>>
>>>>> -Chuckk
>>>>>
>>>>> On Mon, Jan 25, 2010 at 11:57 PM, Andres Cabrera  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm not sure if its possible in python, but in the C API, you can
>>>>>> register callbacks, so the function is called whenever the
>>>>>> invalue/outvalue opcode is called.
>>>>>> That way you don't need to worry about synchronization.
>>>>>>
>>>>>> However, if you need to send very complex data structures, then OSC
>>>>>> might be better....
>>>>>>
>>>>>> Cheers,
>>>>>> Andrés
>>>>>>
>>>>>> On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
>>>>>>  wrote:
>>>>>>> Hi Andres, thanks for the suggestion.
>>>>>>>
>>>>>>> That's what I'm thinking of now, as subprocesses can be sent a pipe as
>>>>>>> stdin, so all the MIDI scripts could be subprocesses of the audio
>>>>>>> engine (although maybe they should have lower priorities). But that
>>>>>>> leaves the question of how the instance of Csound tells Python what
>>>>>>> notes to send when and where. A string channel? The problem I see is
>>>>>>> that exporting a variable this way just sets it, it doesn't send a
>>>>>>> one-time message. It would need to change, then change back
>>>>>>> immediately, but making sure that the message was received first.
>>>>>>>
>>>>>>> -Chuckk
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>>>>>>>> Why don't you run them from the same python program and share data using python?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Andrés
>>>>>>>>
>>>>>>>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>>>>>>>  wrote:
>>>>>>>>> Hi.
>>>>>>>>> I'm running a Python program, and when the user hits 'play' it calls a
>>>>>>>>> separate Python script (with a higher priority) that runs a Csound
>>>>>>>>> instance. I'd like to change this setup so the user may specify some
>>>>>>>>> instruments to be performed through MIDI, through various devices,
>>>>>>>>> with the notes still triggered by the main Csound instance.
>>>>>>>>> The original setup uses a single callback port for communication
>>>>>>>>> between the Python program and the audio engine. To make the MIDI
>>>>>>>>> Csound instances work that way would be pretty complicated: I could
>>>>>>>>> either send the main audio engine the port numbers for each of the
>>>>>>>>> MIDI scripts, have them all wait for connection, and send the messages
>>>>>>>>> directly; or I could set up ports connecting each MIDI script to the
>>>>>>>>> main Python program, then the audio engine sends messages to the main
>>>>>>>>> program when it needs MIDI notes activated.
>>>>>>>>>
>>>>>>>>> I also checked out insremote, but I get segmentation violations. It's
>>>>>>>>> also not clear to me how to use insremote for another local instance,
>>>>>>>>> which is mentioned in the manual, but:
>>>>>>>>> insremote "127.0.0.1, "127.0.0.1", 11
>>>>>>>>> don't seem to work. Also, if I create one master and several clients,
>>>>>>>>> all on the same machine, how can I differentiate between the clients?
>>>>>>>>> Thanks for any help.
>>>>>>>>>
>>>>>>>>> -Chuckk
>>>>>>>>> --
>>>>>>>>> http://www.badmuthahubbard.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Send bugs reports to this list.
>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrés
>>>>>>>>
>>>>>>>>
>>>>>>>> Send bugs reports to this list.
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> http://www.badmuthahubbard.com
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Andrés
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.badmuthahubbard.com
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Andrés
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Oh! I'm not talking about the process callback, I'm talking about
channel data callbacks. If you register those, they will be called
directly by the invalue/outvalue opcodes.

Do you want to move this thread to the developer list? It might be a
little too heavy for the user list...

Cheers,
Andrés

On Tue, Jan 26, 2010 at 2:09 PM, Chuckk Hubbard
 wrote:
> Substituting:
> chnsend "num", ginum
> in place of chnset still gives me hundreds of callbacks a second. I
> have the feeling that SetProcessCallback is inherently k-rate, no?
> Even taking out all references to any channel opcode, and running
> 'turnoff' doesn't slow it down. I'll need to figure out another
> callback function.
>
> -Chuckk
>
> On Tue, Jan 26, 2010 at 3:57 PM, Andres Cabrera  wrote:
>> Hi,
>>
>> Oh, yes, chnset nad chnget are not callback based. You would need to
>> use chnsend and chnrecv (which I'm not sure how well they are
>> working), or invalue/outvalue which are callback based.
>>
>> A bit of a mess, really...
>>
>> Cheers,
>> Andrés
>>
>> On Tue, Jan 26, 2010 at 1:01 PM, Chuckk Hubbard
>>  wrote:
>>> Here's a script that shows, it prints the value continuously, even
>>> with the note turned off instantly.
>>> Thanks, everyone, for your help so far.
>>> -Chuckk
>>>
>>> On Tue, Jan 26, 2010 at 2:35 PM, Chuckk Hubbard
>>>  wrote:
>>>> Tried that, but at least with
>>>> CsoundPerformanceThread.SetProcessCallback(), it calls the function
>>>> continuously regardless of my kgoto statement...
>>>>
>>>> -Chuckk
>>>>
>>>> On Tue, Jan 26, 2010 at 2:23 PM, Andres Cabrera  wrote:
>>>>> Hi,
>>>>>
>>>>> The opcodes work at k-rate, so the callbacks will be made at k-rate.
>>>>> I've been thinking of adding an i-rate version of these opcodes...
>>>>> You could make a conditional statement so they are used in
>>>>> initialization (they will produce a value then as well), and skip them
>>>>> during performance.
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>> On Tue, Jan 26, 2010 at 11:13 AM, Chuckk Hubbard
>>>>>  wrote:
>>>>>> Thanks for the suggestion, it looks like a good idea, if I can figure
>>>>>> out the arguments for Python. I tried something like the cb.py/cb.csd
>>>>>> examples, both with chnexport and chnset, but even using i-rate
>>>>>> variables, they constantly call the callback on every k cycle. I have
>>>>>> a feeling outvalue will do the same. Any ideas, anyone, how to use
>>>>>> channel callbacks only at i-rate?
>>>>>>
>>>>>> -Chuckk
>>>>>>
>>>>>> On Mon, Jan 25, 2010 at 11:57 PM, Andres Cabrera  wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm not sure if its possible in python, but in the C API, you can
>>>>>>> register callbacks, so the function is called whenever the
>>>>>>> invalue/outvalue opcode is called.
>>>>>>> That way you don't need to worry about synchronization.
>>>>>>>
>>>>>>> However, if you need to send very complex data structures, then OSC
>>>>>>> might be better....
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andrés
>>>>>>>
>>>>>>> On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
>>>>>>>  wrote:
>>>>>>>> Hi Andres, thanks for the suggestion.
>>>>>>>>
>>>>>>>> That's what I'm thinking of now, as subprocesses can be sent a pipe as
>>>>>>>> stdin, so all the MIDI scripts could be subprocesses of the audio
>>>>>>>> engine (although maybe they should have lower priorities). But that
>>>>>>>> leaves the question of how the instance of Csound tells Python what
>>>>>>>> notes to send when and where. A string channel? The problem I see is
>>>>>>>> that exporting a variable this way just sets it, it doesn't send a
>>>>>>>> one-time message. It would need to change, then change back
>>>>>>>> immediately, but making sure that the message was received first.
>>>>>>>>
>>>>>>>> -Chuckk
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>>>>>>>>> Why don't you run them from the same python program and share data using python?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Andrés
>>>>>>>>>
>>>>>>>>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>>>>>>>>  wrote:
>>>>>>>>>> Hi.
>>>>>>>>>> I'm running a Python program, and when the user hits 'play' it calls a
>>>>>>>>>> separate Python script (with a higher priority) that runs a Csound
>>>>>>>>>> instance. I'd like to change this setup so the user may specify some
>>>>>>>>>> instruments to be performed through MIDI, through various devices,
>>>>>>>>>> with the notes still triggered by the main Csound instance.
>>>>>>>>>> The original setup uses a single callback port for communication
>>>>>>>>>> between the Python program and the audio engine. To make the MIDI
>>>>>>>>>> Csound instances work that way would be pretty complicated: I could
>>>>>>>>>> either send the main audio engine the port numbers for each of the
>>>>>>>>>> MIDI scripts, have them all wait for connection, and send the messages
>>>>>>>>>> directly; or I could set up ports connecting each MIDI script to the
>>>>>>>>>> main Python program, then the audio engine sends messages to the main
>>>>>>>>>> program when it needs MIDI notes activated.
>>>>>>>>>>
>>>>>>>>>> I also checked out insremote, but I get segmentation violations. It's
>>>>>>>>>> also not clear to me how to use insremote for another local instance,
>>>>>>>>>> which is mentioned in the manual, but:
>>>>>>>>>> insremote "127.0.0.1, "127.0.0.1", 11
>>>>>>>>>> don't seem to work. Also, if I create one master and several clients,
>>>>>>>>>> all on the same machine, how can I differentiate between the clients?
>>>>>>>>>> Thanks for any help.
>>>>>>>>>>
>>>>>>>>>> -Chuckk
>>>>>>>>>> --
>>>>>>>>>> http://www.badmuthahubbard.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Send bugs reports to this list.
>>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrés
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Send bugs reports to this list.
>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://www.badmuthahubbard.com
>>>>>>>>
>>>>>>>>
>>>>>>>> Send bugs reports to this list.
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Andrés
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.badmuthahubbard.com
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Andrés
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Substituting:
chnsend "num", ginum
in place of chnset still gives me hundreds of callbacks a second. I
have the feeling that SetProcessCallback is inherently k-rate, no?
Even taking out all references to any channel opcode, and running
'turnoff' doesn't slow it down. I'll need to figure out another
callback function.

-Chuckk

On Tue, Jan 26, 2010 at 3:57 PM, Andres Cabrera  wrote:
> Hi,
>
> Oh, yes, chnset nad chnget are not callback based. You would need to
> use chnsend and chnrecv (which I'm not sure how well they are
> working), or invalue/outvalue which are callback based.
>
> A bit of a mess, really...
>
> Cheers,
> Andrés
>
> On Tue, Jan 26, 2010 at 1:01 PM, Chuckk Hubbard
>  wrote:
>> Here's a script that shows, it prints the value continuously, even
>> with the note turned off instantly.
>> Thanks, everyone, for your help so far.
>> -Chuckk
>>
>> On Tue, Jan 26, 2010 at 2:35 PM, Chuckk Hubbard
>>  wrote:
>>> Tried that, but at least with
>>> CsoundPerformanceThread.SetProcessCallback(), it calls the function
>>> continuously regardless of my kgoto statement...
>>>
>>> -Chuckk
>>>
>>> On Tue, Jan 26, 2010 at 2:23 PM, Andres Cabrera  wrote:
>>>> Hi,
>>>>
>>>> The opcodes work at k-rate, so the callbacks will be made at k-rate.
>>>> I've been thinking of adding an i-rate version of these opcodes...
>>>> You could make a conditional statement so they are used in
>>>> initialization (they will produce a value then as well), and skip them
>>>> during performance.
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>> On Tue, Jan 26, 2010 at 11:13 AM, Chuckk Hubbard
>>>>  wrote:
>>>>> Thanks for the suggestion, it looks like a good idea, if I can figure
>>>>> out the arguments for Python. I tried something like the cb.py/cb.csd
>>>>> examples, both with chnexport and chnset, but even using i-rate
>>>>> variables, they constantly call the callback on every k cycle. I have
>>>>> a feeling outvalue will do the same. Any ideas, anyone, how to use
>>>>> channel callbacks only at i-rate?
>>>>>
>>>>> -Chuckk
>>>>>
>>>>> On Mon, Jan 25, 2010 at 11:57 PM, Andres Cabrera  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm not sure if its possible in python, but in the C API, you can
>>>>>> register callbacks, so the function is called whenever the
>>>>>> invalue/outvalue opcode is called.
>>>>>> That way you don't need to worry about synchronization.
>>>>>>
>>>>>> However, if you need to send very complex data structures, then OSC
>>>>>> might be better....
>>>>>>
>>>>>> Cheers,
>>>>>> Andrés
>>>>>>
>>>>>> On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
>>>>>>  wrote:
>>>>>>> Hi Andres, thanks for the suggestion.
>>>>>>>
>>>>>>> That's what I'm thinking of now, as subprocesses can be sent a pipe as
>>>>>>> stdin, so all the MIDI scripts could be subprocesses of the audio
>>>>>>> engine (although maybe they should have lower priorities). But that
>>>>>>> leaves the question of how the instance of Csound tells Python what
>>>>>>> notes to send when and where. A string channel? The problem I see is
>>>>>>> that exporting a variable this way just sets it, it doesn't send a
>>>>>>> one-time message. It would need to change, then change back
>>>>>>> immediately, but making sure that the message was received first.
>>>>>>>
>>>>>>> -Chuckk
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>>>>>>>> Why don't you run them from the same python program and share data using python?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Andrés
>>>>>>>>
>>>>>>>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>>>>>>>  wrote:
>>>>>>>>> Hi.
>>>>>>>>> I'm running a Python program, and when the user hits 'play' it calls a
>>>>>>>>> separate Python script (with a higher priority) that runs a Csound
>>>>>>>>> instance. I'd like to change this setup so the user may specify some
>>>>>>>>> instruments to be performed through MIDI, through various devices,
>>>>>>>>> with the notes still triggered by the main Csound instance.
>>>>>>>>> The original setup uses a single callback port for communication
>>>>>>>>> between the Python program and the audio engine. To make the MIDI
>>>>>>>>> Csound instances work that way would be pretty complicated: I could
>>>>>>>>> either send the main audio engine the port numbers for each of the
>>>>>>>>> MIDI scripts, have them all wait for connection, and send the messages
>>>>>>>>> directly; or I could set up ports connecting each MIDI script to the
>>>>>>>>> main Python program, then the audio engine sends messages to the main
>>>>>>>>> program when it needs MIDI notes activated.
>>>>>>>>>
>>>>>>>>> I also checked out insremote, but I get segmentation violations. It's
>>>>>>>>> also not clear to me how to use insremote for another local instance,
>>>>>>>>> which is mentioned in the manual, but:
>>>>>>>>> insremote "127.0.0.1, "127.0.0.1", 11
>>>>>>>>> don't seem to work. Also, if I create one master and several clients,
>>>>>>>>> all on the same machine, how can I differentiate between the clients?
>>>>>>>>> Thanks for any help.
>>>>>>>>>
>>>>>>>>> -Chuckk
>>>>>>>>> --
>>>>>>>>> http://www.badmuthahubbard.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Send bugs reports to this list.
>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrés
>>>>>>>>
>>>>>>>>
>>>>>>>> Send bugs reports to this list.
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> http://www.badmuthahubbard.com
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Andrés
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.badmuthahubbard.com
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Andrés
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.com
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

OK, I'll start another thread there and if it makes sense we can take
from this one.

-Chuckk

On Tue, Jan 26, 2010 at 4:40 PM, Andres Cabrera  wrote:
> Oh! I'm not talking about the process callback, I'm talking about
> channel data callbacks. If you register those, they will be called
> directly by the invalue/outvalue opcodes.
>
> Do you want to move this thread to the developer list? It might be a
> little too heavy for the user list...
>
> Cheers,
> Andrés
>
> On Tue, Jan 26, 2010 at 2:09 PM, Chuckk Hubbard
>  wrote:
>> Substituting:
>> chnsend "num", ginum
>> in place of chnset still gives me hundreds of callbacks a second. I
>> have the feeling that SetProcessCallback is inherently k-rate, no?
>> Even taking out all references to any channel opcode, and running
>> 'turnoff' doesn't slow it down. I'll need to figure out another
>> callback function.
>>
>> -Chuckk
>>
>> On Tue, Jan 26, 2010 at 3:57 PM, Andres Cabrera  wrote:
>>> Hi,
>>>
>>> Oh, yes, chnset nad chnget are not callback based. You would need to
>>> use chnsend and chnrecv (which I'm not sure how well they are
>>> working), or invalue/outvalue which are callback based.
>>>
>>> A bit of a mess, really...
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Tue, Jan 26, 2010 at 1:01 PM, Chuckk Hubbard
>>>  wrote:
>>>> Here's a script that shows, it prints the value continuously, even
>>>> with the note turned off instantly.
>>>> Thanks, everyone, for your help so far.
>>>> -Chuckk
>>>>
>>>> On Tue, Jan 26, 2010 at 2:35 PM, Chuckk Hubbard
>>>>  wrote:
>>>>> Tried that, but at least with
>>>>> CsoundPerformanceThread.SetProcessCallback(), it calls the function
>>>>> continuously regardless of my kgoto statement...
>>>>>
>>>>> -Chuckk
>>>>>
>>>>> On Tue, Jan 26, 2010 at 2:23 PM, Andres Cabrera  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The opcodes work at k-rate, so the callbacks will be made at k-rate.
>>>>>> I've been thinking of adding an i-rate version of these opcodes...
>>>>>> You could make a conditional statement so they are used in
>>>>>> initialization (they will produce a value then as well), and skip them
>>>>>> during performance.
>>>>>>
>>>>>> Cheers,
>>>>>> Andrés
>>>>>>
>>>>>> On Tue, Jan 26, 2010 at 11:13 AM, Chuckk Hubbard
>>>>>>  wrote:
>>>>>>> Thanks for the suggestion, it looks like a good idea, if I can figure
>>>>>>> out the arguments for Python. I tried something like the cb.py/cb.csd
>>>>>>> examples, both with chnexport and chnset, but even using i-rate
>>>>>>> variables, they constantly call the callback on every k cycle. I have
>>>>>>> a feeling outvalue will do the same. Any ideas, anyone, how to use
>>>>>>> channel callbacks only at i-rate?
>>>>>>>
>>>>>>> -Chuckk
>>>>>>>
>>>>>>> On Mon, Jan 25, 2010 at 11:57 PM, Andres Cabrera  wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm not sure if its possible in python, but in the C API, you can
>>>>>>>> register callbacks, so the function is called whenever the
>>>>>>>> invalue/outvalue opcode is called.
>>>>>>>> That way you don't need to worry about synchronization.
>>>>>>>>
>>>>>>>> However, if you need to send very complex data structures, then OSC
>>>>>>>> might be better....
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Andrés
>>>>>>>>
>>>>>>>> On Mon, Jan 25, 2010 at 9:18 PM, Chuckk Hubbard
>>>>>>>>  wrote:
>>>>>>>>> Hi Andres, thanks for the suggestion.
>>>>>>>>>
>>>>>>>>> That's what I'm thinking of now, as subprocesses can be sent a pipe as
>>>>>>>>> stdin, so all the MIDI scripts could be subprocesses of the audio
>>>>>>>>> engine (although maybe they should have lower priorities). But that
>>>>>>>>> leaves the question of how the instance of Csound tells Python what
>>>>>>>>> notes to send when and where. A string channel? The problem I see is
>>>>>>>>> that exporting a variable this way just sets it, it doesn't send a
>>>>>>>>> one-time message. It would need to change, then change back
>>>>>>>>> immediately, but making sure that the message was received first.
>>>>>>>>>
>>>>>>>>> -Chuckk
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Jan 25, 2010 at 10:13 PM, Andres Cabrera  wrote:
>>>>>>>>>> Why don't you run them from the same python program and share data using python?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Andrés
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 25, 2010 at 7:57 PM, Chuckk Hubbard
>>>>>>>>>>  wrote:
>>>>>>>>>>> Hi.
>>>>>>>>>>> I'm running a Python program, and when the user hits 'play' it calls a
>>>>>>>>>>> separate Python script (with a higher priority) that runs a Csound
>>>>>>>>>>> instance. I'd like to change this setup so the user may specify some
>>>>>>>>>>> instruments to be performed through MIDI, through various devices,
>>>>>>>>>>> with the notes still triggered by the main Csound instance.
>>>>>>>>>>> The original setup uses a single callback port for communication
>>>>>>>>>>> between the Python program and the audio engine. To make the MIDI
>>>>>>>>>>> Csound instances work that way would be pretty complicated: I could
>>>>>>>>>>> either send the main audio engine the port numbers for each of the
>>>>>>>>>>> MIDI scripts, have them all wait for connection, and send the messages
>>>>>>>>>>> directly; or I could set up ports connecting each MIDI script to the
>>>>>>>>>>> main Python program, then the audio engine sends messages to the main
>>>>>>>>>>> program when it needs MIDI notes activated.
>>>>>>>>>>>
>>>>>>>>>>> I also checked out insremote, but I get segmentation violations. It's
>>>>>>>>>>> also not clear to me how to use insremote for another local instance,
>>>>>>>>>>> which is mentioned in the manual, but:
>>>>>>>>>>> insremote "127.0.0.1, "127.0.0.1", 11
>>>>>>>>>>> don't seem to work. Also, if I create one master and several clients,
>>>>>>>>>>> all on the same machine, how can I differentiate between the clients?
>>>>>>>>>>> Thanks for any help.
>>>>>>>>>>>
>>>>>>>>>>> -Chuckk
>>>>>>>>>>> --
>>>>>>>>>>> http://www.badmuthahubbard.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Send bugs reports to this list.
>>>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Andrés
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Send bugs reports to this list.
>>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://www.badmuthahubbard.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Send bugs reports to this list.
>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> Andrés
>>>>>>>>
>>>>>>>>
>>>>>>>> Send bugs reports to this list.
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> http://www.badmuthahubbard.com
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Andrés
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.badmuthahubbard.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.com
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"