Well, chani and chano are numeric, so if you don't want to
deal with strings, these are more handy. Also, there is
a fundamental difference, chani and chano are independent
of each other, so data sent in chano channel 1 will not appear
in chani channel 1 (unless the host copies it).

As far as I know csoundSetChannelIOCallback()  is not
operational. Need to check its status.

So in summary, all systems are useful:

1. chnget etc: if you want Csound to manage channel lists
2. invalue etc: if you wish to manage the channel list yourself
3. chani etc: if you want to use a numeric listing (and leave
Csound to manage it)
4. pvsin etc: a version of chani/o for PVS signals
5. forget about csoundSetChannelIOCallback() for the moment.

you see, it's pretty simple :)

...enjoy!

all the best

Victor

----- Original Message ----- 
From: "Jonatan Liljedahl" 
To: "Developer discussions" 
Sent: Wednesday, January 23, 2008 7:51 PM
Subject: Re: [Cs-dev] software busses


> Yes, I actually use both in my host. chnget and chnset because then I
> can let the orchestra define channels like "pitch" or whatever and have
> them show up automatically in my host UI. this is good because my host
> can ask csound for the list of channels.
>
> and I use outvalue to let each instrument instant be able to send data
> (for plotting) to my host, and to identify themselves.. this is good
> because csound just calls a callback in my host and the channel name
> passed to this is just like an ID string, I need not keep track of it as
> a "permanent" bus.
>
> So, I see the point of keeping these two. but the other two?
>
> Rory Walsh wrote:
>> I was talking to Victor and Matt about this recently. They know more
>> than I but personally I have always used chnget and chnset because this
>> gets Csound to set up all the buses so I don't have to set up and
>> allocate channels in my host code. Matt on the other hand prefers to
>> take care of channel management himself so he prefers to use the
>> outvalue/invalue opcodes. I think Matt suggested a workable way to
>> consolidate these two mechanisms on the list a few week back.
>>
>> Rory.
>>
>>
>>
>> Jonatan Liljedahl wrote:
>>> I think the many simultaneously existing ways of sending data to and
>>> from csound is a bit confusing:
>>>
>>> There's the chani and chano opcodes, and their family of API functions
>>> like csoundChanOKGet(). these are numbered channels and not 
>>> callback-based.
>>>
>>> And then there's chnget and chnset, which uses the csoundGetChannelPtr()
>>> API. these are named channels and not callback-based.
>>>
>>> And then there's the API function csoundSetChannelIOCallback() which
>>> states (in csound.h) to be called by the opcodes chnsend and chnrecv,
>>> but those opcodes is not mentioned in the reference manual and I don't
>>> know if they actually exists in csound (haven't tried). these are named
>>> channels and callback-based.
>>>
>>> And then there's outvalue and invalue, with API functions
>>> csoundSetOutputValueCallback(), etc.. these are named channels and
>>> callback-based.
>>>
>>> So this is 4 different external software busses/channels? why?
>>>
>>> And except these busses, one can also use the csoundGetSpin/Spout() API
>>> functions for direct audio input/output.
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> -- 
> /Jonatan         [ http://kymatica.com ]
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Any chance of a pvsget/pvsset appearing on that list? I'm pretty 
frightened of the prospect of writing code to manage a list of channels 
myself. I know how to use them and how they work in layman's terms but I 
don't fully understand how they work at low-level. How could I add 
provisions to my hosts so that users can use either 'string' type 
channel mechanisms. Is it tricky to do? I could not tell if Jonatan's 
host app does this of if he use the two systems for different things.

Rory.


victor wrote:
> Well, chani and chano are numeric, so if you don't want to
> deal with strings, these are more handy. Also, there is
> a fundamental difference, chani and chano are independent
> of each other, so data sent in chano channel 1 will not appear
> in chani channel 1 (unless the host copies it).
> 
> As far as I know csoundSetChannelIOCallback()  is not
> operational. Need to check its status.
> 
> So in summary, all systems are useful:
> 
> 1. chnget etc: if you want Csound to manage channel lists
> 2. invalue etc: if you wish to manage the channel list yourself
> 3. chani etc: if you want to use a numeric listing (and leave
> Csound to manage it)
> 4. pvsin etc: a version of chani/o for PVS signals
> 5. forget about csoundSetChannelIOCallback() for the moment.
> 
> you see, it's pretty simple :)
> 
> ...enjoy!
> 
> all the best
> 
> Victor
> 
> ----- Original Message ----- 
> From: "Jonatan Liljedahl" 
> To: "Developer discussions" 
> Sent: Wednesday, January 23, 2008 7:51 PM
> Subject: Re: [Cs-dev] software busses
> 
> 
>> Yes, I actually use both in my host. chnget and chnset because then I
>> can let the orchestra define channels like "pitch" or whatever and have
>> them show up automatically in my host UI. this is good because my host
>> can ask csound for the list of channels.
>>
>> and I use outvalue to let each instrument instant be able to send data
>> (for plotting) to my host, and to identify themselves.. this is good
>> because csound just calls a callback in my host and the channel name
>> passed to this is just like an ID string, I need not keep track of it as
>> a "permanent" bus.
>>
>> So, I see the point of keeping these two. but the other two?
>>
>> Rory Walsh wrote:
>>> I was talking to Victor and Matt about this recently. They know more
>>> than I but personally I have always used chnget and chnset because this
>>> gets Csound to set up all the buses so I don't have to set up and
>>> allocate channels in my host code. Matt on the other hand prefers to
>>> take care of channel management himself so he prefers to use the
>>> outvalue/invalue opcodes. I think Matt suggested a workable way to
>>> consolidate these two mechanisms on the list a few week back.
>>>
>>> Rory.
>>>
>>>
>>>
>>> Jonatan Liljedahl wrote:
>>>> I think the many simultaneously existing ways of sending data to and
>>>> from csound is a bit confusing:
>>>>
>>>> There's the chani and chano opcodes, and their family of API functions
>>>> like csoundChanOKGet(). these are numbered channels and not 
>>>> callback-based.
>>>>
>>>> And then there's chnget and chnset, which uses the csoundGetChannelPtr()
>>>> API. these are named channels and not callback-based.
>>>>
>>>> And then there's the API function csoundSetChannelIOCallback() which
>>>> states (in csound.h) to be called by the opcodes chnsend and chnrecv,
>>>> but those opcodes is not mentioned in the reference manual and I don't
>>>> know if they actually exists in csound (haven't tried). these are named
>>>> channels and callback-based.
>>>>
>>>> And then there's outvalue and invalue, with API functions
>>>> csoundSetOutputValueCallback(), etc.. these are named channels and
>>>> callback-based.
>>>>
>>>> So this is 4 different external software busses/channels? why?
>>>>
>>>> And except these busses, one can also use the csoundGetSpin/Spout() API
>>>> functions for direct audio input/output.
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> -- 
>> /Jonatan         [ http://kymatica.com ]
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Ok, I just looked at the csound.h, I'm not that frightened any more...

Rory Walsh wrote:
> Any chance of a pvsget/pvsset appearing on that list? I'm pretty 
> frightened of the prospect of writing code to manage a list of channels 
> myself. I know how to use them and how they work in layman's terms but I 
> don't fully understand how they work at low-level. How could I add 
> provisions to my hosts so that users can use either 'string' type 
> channel mechanisms. Is it tricky to do? I could not tell if Jonatan's 
> host app does this of if he use the two systems for different things.
> 
> Rory.
> 
> 
> victor wrote:
>> Well, chani and chano are numeric, so if you don't want to
>> deal with strings, these are more handy. Also, there is
>> a fundamental difference, chani and chano are independent
>> of each other, so data sent in chano channel 1 will not appear
>> in chani channel 1 (unless the host copies it).
>>
>> As far as I know csoundSetChannelIOCallback()  is not
>> operational. Need to check its status.
>>
>> So in summary, all systems are useful:
>>
>> 1. chnget etc: if you want Csound to manage channel lists
>> 2. invalue etc: if you wish to manage the channel list yourself
>> 3. chani etc: if you want to use a numeric listing (and leave
>> Csound to manage it)
>> 4. pvsin etc: a version of chani/o for PVS signals
>> 5. forget about csoundSetChannelIOCallback() for the moment.
>>
>> you see, it's pretty simple :)
>>
>> ...enjoy!
>>
>> all the best
>>
>> Victor
>>
>> ----- Original Message ----- 
>> From: "Jonatan Liljedahl" 
>> To: "Developer discussions" 
>> Sent: Wednesday, January 23, 2008 7:51 PM
>> Subject: Re: [Cs-dev] software busses
>>
>>
>>> Yes, I actually use both in my host. chnget and chnset because then I
>>> can let the orchestra define channels like "pitch" or whatever and have
>>> them show up automatically in my host UI. this is good because my host
>>> can ask csound for the list of channels.
>>>
>>> and I use outvalue to let each instrument instant be able to send data
>>> (for plotting) to my host, and to identify themselves.. this is good
>>> because csound just calls a callback in my host and the channel name
>>> passed to this is just like an ID string, I need not keep track of it as
>>> a "permanent" bus.
>>>
>>> So, I see the point of keeping these two. but the other two?
>>>
>>> Rory Walsh wrote:
>>>> I was talking to Victor and Matt about this recently. They know more
>>>> than I but personally I have always used chnget and chnset because this
>>>> gets Csound to set up all the buses so I don't have to set up and
>>>> allocate channels in my host code. Matt on the other hand prefers to
>>>> take care of channel management himself so he prefers to use the
>>>> outvalue/invalue opcodes. I think Matt suggested a workable way to
>>>> consolidate these two mechanisms on the list a few week back.
>>>>
>>>> Rory.
>>>>
>>>>
>>>>
>>>> Jonatan Liljedahl wrote:
>>>>> I think the many simultaneously existing ways of sending data to and
>>>>> from csound is a bit confusing:
>>>>>
>>>>> There's the chani and chano opcodes, and their family of API functions
>>>>> like csoundChanOKGet(). these are numbered channels and not 
>>>>> callback-based.
>>>>>
>>>>> And then there's chnget and chnset, which uses the csoundGetChannelPtr()
>>>>> API. these are named channels and not callback-based.
>>>>>
>>>>> And then there's the API function csoundSetChannelIOCallback() which
>>>>> states (in csound.h) to be called by the opcodes chnsend and chnrecv,
>>>>> but those opcodes is not mentioned in the reference manual and I don't
>>>>> know if they actually exists in csound (haven't tried). these are named
>>>>> channels and callback-based.
>>>>>
>>>>> And then there's outvalue and invalue, with API functions
>>>>> csoundSetOutputValueCallback(), etc.. these are named channels and
>>>>> callback-based.
>>>>>
>>>>> So this is 4 different external software busses/channels? why?
>>>>>
>>>>> And except these busses, one can also use the csoundGetSpin/Spout() API
>>>>> functions for direct audio input/output.
>>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> -- 
>>> /Jonatan         [ http://kymatica.com ]
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel 
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

victor wrote:
> Well, chani and chano are numeric, so if you don't want to
> deal with strings, these are more handy. Also, there is
> a fundamental difference, chani and chano are independent
> of each other, so data sent in chano channel 1 will not appear
> in chani channel 1 (unless the host copies it).

I see, I didn't know about the independency of chani and chano. So then
chnget and chnset is almost like setting/getting a global variable,
except that it's also available to the host app?
What about outvalue and invalue, are they also independent? My feeling
is that the channel name of outvalue/invalue is more like an ID and that
it isn't actually a bus that stores values, is this right?

perhaps all this should go in some API tutorial... :)

-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It would be great for users to see the different systems in use, do you 
have time to write a brief tutorial? I'm sure Steven and James would be 
delighted to have it for the next issue of the Csound Journal. 
Alternatively, feel free to hack my basic API tutorial, it's in need of 
updating anyhow, it has some basic info but this is important stuff...



Jonatan Liljedahl wrote:
> victor wrote:
>> Well, chani and chano are numeric, so if you don't want to
>> deal with strings, these are more handy. Also, there is
>> a fundamental difference, chani and chano are independent
>> of each other, so data sent in chano channel 1 will not appear
>> in chani channel 1 (unless the host copies it).
> 
> I see, I didn't know about the independency of chani and chano. So then
> chnget and chnset is almost like setting/getting a global variable,
> except that it's also available to the host app?
> What about outvalue and invalue, are they also independent? My feeling
> is that the channel name of outvalue/invalue is more like an ID and that
> it isn't actually a bus that stores values, is this right?
> 
> perhaps all this should go in some API tutorial... :)
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Rory Walsh wrote:
> It would be great for users to see the different systems in use, do you 
> have time to write a brief tutorial? I'm sure Steven and James would be 
> delighted to have it for the next issue of the Csound Journal. 
> Alternatively, feel free to hack my basic API tutorial, it's in need of 
> updating anyhow, it has some basic info but this is important stuff...

Ok, here it is: http://kymatica.com/uploads/Main/csound_host_io.txt
Feel free to include it in your API tutorial.

-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks Jonaten, if I get a chance i will just update my introduction and 
I will include some this text in it. I would also like to show users how 
the C++ wrapper works too. It's just a matter of finding time to do it.

Rory.



Jonatan Liljedahl wrote:
> Rory Walsh wrote:
>> It would be great for users to see the different systems in use, do you 
>> have time to write a brief tutorial? I'm sure Steven and James would be 
>> delighted to have it for the next issue of the Csound Journal. 
>> Alternatively, feel free to hack my basic API tutorial, it's in need of 
>> updating anyhow, it has some basic info but this is important stuff...
> 
> Ok, here it is: http://kymatica.com/uploads/Main/csound_host_io.txt
> Feel free to include it in your API tutorial.
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net