Am I right in assuming that both sets of channel opcodes now access
the same channels, but chnget/chnset are not, and never will be
capable of using callbacks? Is there any way to let front end
developers force the use of callbacks for these opcodes if they wish?
To the end user nothing would change, but it would make life so much
easier for developers. I currently have an situation where I'm running
timer threads to check values from channels. Throw in 50 or so
channels and it becomes quite silly, having to check every channel for
a change. I thought I could cheekily replace chnget/chnsets with
invalue/outvalue on compilation but woudn't you know, the order of
parameters for outvalue is different to that of chnset!

Rory.

p.s. Andres warned me about this many years ago. How I wished I'd
listened to you Andres!

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Ok, that's not what I was expecting, but am glad to hear. No need to
change anything then. That was a freebie :)

On 11 February 2014 19:48, Michael Gogins  wrote:
> I agree, polling is the way to go.
>
> I create an alwayson instrument named "Controls" that reads each channel and
> assigns its value to a global variable. The variables are declared in global
> orchestra code just on top of the instrument that needs them, e.g.
>
> gkMyInstrumentController1 init 4
> instr MyInstrument
> something = gkMyIntrumentController
> endin
>
> instr Controls
> gkMyInstrumentController1 invalue "gkMyInstrumentController1"
> endin
>
> This could be made even more efficient by setting a timer and polling less
> often than ksmps.
>
> Hope this helps,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Feb 11, 2014 at 2:37 PM, Andres Cabrera 
> wrote:
>>
>> Ha!
>>
>> Yes, but callbacks can also be very expensive, especially if you are
>> reading from widgets. Otherwise, you need to keep a list of channels from
>> the widgets, which you read from when the callback is called.
>>
>> I've actually found the most efficient way is using the polling mechanism
>> (chnget/chnset), and have a flag that marks whether there have been changes
>> in channels, and just update the values if there is a need, rather than
>> having to write everytime when it might not be needed.
>>
>> I've actually changed a lot of examples in CsoundQt to use chnget/chnset
>> and there is a big performance improvement, as using many invalue/outcalue
>> functions incur in a lot of overhead from the function call.
>>
>> Cheers,
>> Andrés
>>
>> Cheers,
>> Andrés
>>
>>
>> On Tue, Feb 11, 2014 at 10:10 AM, Rory Walsh  wrote:
>>>
>>> Am I right in assuming that both sets of channel opcodes now access
>>> the same channels, but chnget/chnset are not, and never will be
>>> capable of using callbacks? Is there any way to let front end
>>> developers force the use of callbacks for these opcodes if they wish?
>>> To the end user nothing would change, but it would make life so much
>>> easier for developers. I currently have an situation where I'm running
>>> timer threads to check values from channels. Throw in 50 or so
>>> channels and it becomes quite silly, having to check every channel for
>>> a change. I thought I could cheekily replace chnget/chnsets with
>>> invalue/outvalue on compilation but woudn't you know, the order of
>>> parameters for outvalue is different to that of chnset!
>>>
>>> Rory.
>>>
>>> p.s. Andres warned me about this many years ago. How I wished I'd
>>> listened to you Andres!
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience.  Start now.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net