I would prefer if the systems were left as they are.

Victor

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


> matt ingalls wrote:
>>> As I said in an earlier post, I do use two systems (chnset and  
>>> outvalue)
>>> in the same orchestra. The important difference is that one is a
>>> software bus and the other just calls my callback directly with an ID
>>> string and a value.
>> 
>> what i am proposing would be to merge the 2 systems so both always use  
>> the
>>   internal "channel list" within Csound but also makes the callback to  
>> the host
>> (if the host has registered one)
> 
> But then there would be no difference between them. Sometimes it's best
> to read/write the value in a controlled way directly after
> performKsmps(), and sometimes you want a callback-based system where
> 'outvalue "foo", 42' directly calls a function in my host.
> Sure, as long as you want to use only one of these methods it's no
> problem, but if you need both then it will be a problem.
> 
> Also it's really useful that the callbacks is called directly with
> outvalue, so one can send multiple values (even on the same "channel")
> in the same k-rate cycle.
> 
> I use the two systems for totally different purposes: chnget to send
> global control data from my graphical score to csound, and outvalue to
> send event-specific data for plotting of envelopes etc.
> (Merging the two systems would really complicate things for me.)
> 
> There's another important difference in that outvalue/invalue doesn't
> use a channel-list but simply passes a string to the callback to
> identify the "channel". So you can send anything in this string and it's
> up to the host to handle it, it doesn't create any internal memory-using
> channels in csound itself.
> 
> So I really think it's good to keep these separate systems. But now
> there are more than these two.. like chani/chano could perhaps be merged
> with the chnget/chnset system? (if chnset/chnget could optionally take a
> k-rate number instead of a string as channel name, but perhaps without
> the auto-declaration of channels that the i-rate (?) string names does
> now...)
> 
> -- 
> /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

so do you use both?

if they stay the same, then at least some kind of general convention  
should
be decided on.  (i'm pretty much convinced that some kind of callback  
method
is the way to go)

as Rory mentioned, the real issue at hand is to get a platform- 
independent
(and gui-toolikit-independent) solution!

-m

On Jan 28, 2008, at 11:57 AM, victor wrote:

> I would prefer if the systems were left as they are.
>
> Victor
>
> ----- Original Message -----
> From: "Jonatan Liljedahl" 
> To: "Developer discussions" 
> Sent: Monday, January 28, 2008 7:28 PM
> Subject: Re: [Cs-dev] software busses
>
>
>> matt ingalls wrote:
>>>> As I said in an earlier post, I do use two systems (chnset and
>>>> outvalue)
>>>> in the same orchestra. The important difference is that one is a
>>>> software bus and the other just calls my callback directly with  
>>>> an ID
>>>> string and a value.
>>>
>>> what i am proposing would be to merge the 2 systems so both always  
>>> use
>>> the
>>>  internal "channel list" within Csound but also makes the callback  
>>> to
>>> the host
>>> (if the host has registered one)
>>
>> But then there would be no difference between them. Sometimes it's  
>> best
>> to read/write the value in a controlled way directly after
>> performKsmps(), and sometimes you want a callback-based system where
>> 'outvalue "foo", 42' directly calls a function in my host.
>> Sure, as long as you want to use only one of these methods it's no
>> problem, but if you need both then it will be a problem.
>>
>> Also it's really useful that the callbacks is called directly with
>> outvalue, so one can send multiple values (even on the same  
>> "channel")
>> in the same k-rate cycle.
>>
>> I use the two systems for totally different purposes: chnget to send
>> global control data from my graphical score to csound, and outvalue  
>> to
>> send event-specific data for plotting of envelopes etc.
>> (Merging the two systems would really complicate things for me.)
>>
>> There's another important difference in that outvalue/invalue doesn't
>> use a channel-list but simply passes a string to the callback to
>> identify the "channel". So you can send anything in this string and  
>> it's
>> up to the host to handle it, it doesn't create any internal memory- 
>> using
>> channels in csound itself.
>>
>> So I really think it's good to keep these separate systems. But now
>> there are more than these two.. like chani/chano could perhaps be  
>> merged
>> with the chnget/chnset system? (if chnset/chnget could optionally  
>> take a
>> k-rate number instead of a string as channel name, but perhaps  
>> without
>> the auto-declaration of channels that the i-rate (?) string names  
>> does
>> now...)
>>
>> -- 
>> /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
>

matt ingalls
development@gvox.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