Steven -

Your explanation makes sense, and is no doubt what is happening.

I doubt that in the case we are discussing, anyone actually expects the 
result that occurs - in this example, kamp increases to infinite amplitude 
with many thousands of samples out of range (according to Console output). 
In addition, I feel sure noone has ever used OSClisten this way.

A simple change in OSClisten to (re-)set the value of kamp to its 
*unchanged* value each k-cycle (if indeed unchanged) would rectify the 
situation. To my knowledge, this is what occurs with other input values in 
opcodes including MIDI and chnget. There would be no change to OSClisten's 
format or behavior other than to cover this case.

Does anyone see a problem with this proposal?

It would certainly simplify porting .csd's designed for MIDI or chngets, to 
OSC control. The several "workaround" alternatives, such as the one Russell 
suggests, require additional coding changes.

Art Hunkins

----- Original Message ----- 
From: "Steven Yi" 
To: "csound users' discussions" 
Sent: Tuesday, May 19, 2015 7:38 PM
Subject: Re: [Csnd] OSClisten Issue


> Hi Art,
>
> I looked a little into this and I think what is happening is that with
> OSClisten, it sets the value to kamp only when a change is found (so
> kans will be 1 in those cases). In the cases where no changes were
> found, it does not set the value to kamp, and the previous value will
> be there.  In that case, when you get to the:
>
> kamp = kamp * 12000
>
> line, it will multiply the previous value of kamp there, instead of
> the last value received from OSClisten.  That would explain why the
> other two versions work.
>
> I don't really use OSC much myself, so don't have much of an opinion
> on any changes, but thought the above worth mentioning.
>
> steven
>
> On Tue, May 19, 2015 at 7:10 PM, Art Hunkins  wrote:
>> I've been working intensively on Android with OSClisten, receiving OSC 
>> data
>> from TouchOSC GUIs (Layouts). I've no idea whether or not this issue
>> pertains to other situations or platforms, though I suspect it does.
>>
>> It is this:
>>
>> The following code works:
>> kamp   init     0
>> kans    OSClisten gichan, "/1/slider1", "f", kamp
>> aout    lfo      kamp * 12000, 440, 1
>>         outs     aout, aout
>>
>> So does this:
>> kamp   init     0
>> kans    OSClisten gichan, "/1/slider1", "f", kamp
>> kamp2 = kamp * 12000
>> aout    lfo      kamp2, 440, 1
>>         outs     aout, aout
>>
>> But this (which I use all the time, and which works fine in the context 
>> of
>> chnget and MIDI input) does not:
>> kamp   init     0
>> kans    OSClisten gichan, "/1/slider1", "f", kamp
>> kamp = kamp * 12000
>> aout    lfo      kamp, 440, 1
>>         outs     aout, aout
>>
>> The problem seems to be that an OSC k-time variable (here kamp) cannot be
>> redefined. I feel sure this has something to do with the special way that
>> OSC data are stored/handled that is different from how MIDI and chnget
>> variables are treated.
>>
>> Is there any possibility that an alternative to the convoluted OSClisten
>> opcode could be written that:
>> 1) would more ressemble other control inputs - and have its output
>> variable(s) on the left;
>> 2) have its output stored in such a way as to allow it to be redefined at
>> k-time?
>>
>> For those of us who'd like to offer OSC realtime control as an option to
>> both MIDI and frontends (etc.) that use chnget, such an alternative would 
>> be
>> welcome indeed. (I've had to do extensive editing of .csds to work around 
>> #2
>> above.)
>>
>> Art Hunkins
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Csound-users mailing list
>> Csound-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-users
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here 


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Seems reasonable to me at least, maybe go ahead and file an issue in
the tracker and someone can look into it further.

On Thu, May 21, 2015 at 1:17 PM, Art Hunkins  wrote:
> Steven -
>
> Your explanation makes sense, and is no doubt what is happening.
>
> I doubt that in the case we are discussing, anyone actually expects the
> result that occurs - in this example, kamp increases to infinite amplitude
> with many thousands of samples out of range (according to Console output).
> In addition, I feel sure noone has ever used OSClisten this way.
>
> A simple change in OSClisten to (re-)set the value of kamp to its
> *unchanged* value each k-cycle (if indeed unchanged) would rectify the
> situation. To my knowledge, this is what occurs with other input values in
> opcodes including MIDI and chnget. There would be no change to OSClisten's
> format or behavior other than to cover this case.
>
> Does anyone see a problem with this proposal?
>
> It would certainly simplify porting .csd's designed for MIDI or chngets, to
> OSC control. The several "workaround" alternatives, such as the one Russell
> suggests, require additional coding changes.
>
> Art Hunkins
>
> ----- Original Message -----
> From: "Steven Yi" 
> To: "csound users' discussions" 
> Sent: Tuesday, May 19, 2015 7:38 PM
> Subject: Re: [Csnd] OSClisten Issue
>
>
>> Hi Art,
>>
>> I looked a little into this and I think what is happening is that with
>> OSClisten, it sets the value to kamp only when a change is found (so
>> kans will be 1 in those cases). In the cases where no changes were
>> found, it does not set the value to kamp, and the previous value will
>> be there.  In that case, when you get to the:
>>
>> kamp = kamp * 12000
>>
>> line, it will multiply the previous value of kamp there, instead of
>> the last value received from OSClisten.  That would explain why the
>> other two versions work.
>>
>> I don't really use OSC much myself, so don't have much of an opinion
>> on any changes, but thought the above worth mentioning.
>>
>> steven
>>
>> On Tue, May 19, 2015 at 7:10 PM, Art Hunkins  wrote:
>>> I've been working intensively on Android with OSClisten, receiving OSC
>>> data
>>> from TouchOSC GUIs (Layouts). I've no idea whether or not this issue
>>> pertains to other situations or platforms, though I suspect it does.
>>>
>>> It is this:
>>>
>>> The following code works:
>>> kamp   init     0
>>> kans    OSClisten gichan, "/1/slider1", "f", kamp
>>> aout    lfo      kamp * 12000, 440, 1
>>>         outs     aout, aout
>>>
>>> So does this:
>>> kamp   init     0
>>> kans    OSClisten gichan, "/1/slider1", "f", kamp
>>> kamp2 = kamp * 12000
>>> aout    lfo      kamp2, 440, 1
>>>         outs     aout, aout
>>>
>>> But this (which I use all the time, and which works fine in the context
>>> of
>>> chnget and MIDI input) does not:
>>> kamp   init     0
>>> kans    OSClisten gichan, "/1/slider1", "f", kamp
>>> kamp = kamp * 12000
>>> aout    lfo      kamp, 440, 1
>>>         outs     aout, aout
>>>
>>> The problem seems to be that an OSC k-time variable (here kamp) cannot be
>>> redefined. I feel sure this has something to do with the special way that
>>> OSC data are stored/handled that is different from how MIDI and chnget
>>> variables are treated.
>>>
>>> Is there any possibility that an alternative to the convoluted OSClisten
>>> opcode could be written that:
>>> 1) would more ressemble other control inputs - and have its output
>>> variable(s) on the left;
>>> 2) have its output stored in such a way as to allow it to be redefined at
>>> k-time?
>>>
>>> For those of us who'd like to offer OSC realtime control as an option to
>>> both MIDI and frontends (etc.) that use chnget, such an alternative would
>>> be
>>> welcome indeed. (I've had to do extensive editing of .csds to work around
>>> #2
>>> above.)
>>>
>>> Art Hunkins
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>> _______________________________________________
>>> Csound-users mailing list
>>> Csound-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-users
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Csound-users mailing list
>> Csound-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-users
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Actually, Art, if I understand correctly what you are suggesting, then I do
see a problem. What if someone is using OSC input to set an on/off switch,
for example? I.e.,

kans	OSClisten gichan, "/1/switch", "f", kswitch

if (kswitch == 1) then
;code to play sound 1
else
;code to play sound 2
endif

You wouldn't want the value of kswitch to be set back to 0 on every k, would
you?

I think it's important to recognize the fundamental differences between
chnget, MIDI, and OSC. With chnget, you're initiating the action (to
retrieve a value from somewhere - a GUI, or another application). With MIDI
and OSC, on the other hand, the external device (or application) is
initiating the action. It sends you a new value whenever something has
changed. Hence, you always have to be ready to receive it and you have to
assume that the value you received represents the current state of the
external device. With midictrl, the result variable is not reset on every k
- it just holds its value until a new midi control message is received. The
beauty of OSClisten is that you get a trigger (kans) whenever a new value is
received. If you use that trigger, your code can be very efficient. In
contrast, with both chnget and midictrl, unless you use the changed opcode
to generate a trigger when the input variable has changed, you end up having
to recalculate all the code that depends on that variable on every k. 

Russell

> -----Original Message-----
> From: Art Hunkins [mailto:abhunkin@uncg.edu]
> Sent: Thursday, May 21, 2015 12:18 PM
> To: csound users' discussions
> Subject: Re: [Csnd] OSClisten Issue
> 
> Steven -
> 
> Your explanation makes sense, and is no doubt what is happening.
> 
> I doubt that in the case we are discussing, anyone actually expects the
> result that occurs - in this example, kamp increases to infinite amplitude
> with many thousands of samples out of range (according to Console output).
> In addition, I feel sure noone has ever used OSClisten this way.
> 
> A simple change in OSClisten to (re-)set the value of kamp to its
> *unchanged* value each k-cycle (if indeed unchanged) would rectify the
> situation. To my knowledge, this is what occurs with other input values in
> opcodes including MIDI and chnget. There would be no change to OSClisten's
> format or behavior other than to cover this case.
> 
> Does anyone see a problem with this proposal?
> 
> It would certainly simplify porting .csd's designed for MIDI or chngets,
> to
> OSC control. The several "workaround" alternatives, such as the one
> Russell
> suggests, require additional coding changes.
> 
> Art Hunkins
> 
> ----- Original Message -----
> From: "Steven Yi" 
> To: "csound users' discussions" 
> Sent: Tuesday, May 19, 2015 7:38 PM
> Subject: Re: [Csnd] OSClisten Issue
> 
> 
> > Hi Art,
> >
> > I looked a little into this and I think what is happening is that with
> > OSClisten, it sets the value to kamp only when a change is found (so
> > kans will be 1 in those cases). In the cases where no changes were
> > found, it does not set the value to kamp, and the previous value will
> > be there.  In that case, when you get to the:
> >
> > kamp = kamp * 12000
> >
> > line, it will multiply the previous value of kamp there, instead of
> > the last value received from OSClisten.  That would explain why the
> > other two versions work.
> >
> > I don't really use OSC much myself, so don't have much of an opinion
> > on any changes, but thought the above worth mentioning.
> >
> > steven
> >
> > On Tue, May 19, 2015 at 7:10 PM, Art Hunkins  wrote:
> >> I've been working intensively on Android with OSClisten, receiving OSC
> >> data
> >> from TouchOSC GUIs (Layouts). I've no idea whether or not this issue
> >> pertains to other situations or platforms, though I suspect it does.
> >>
> >> It is this:
> >>
> >> The following code works:
> >> kamp   init     0
> >> kans    OSClisten gichan, "/1/slider1", "f", kamp
> >> aout    lfo      kamp * 12000, 440, 1
> >>         outs     aout, aout
> >>
> >> So does this:
> >> kamp   init     0
> >> kans    OSClisten gichan, "/1/slider1", "f", kamp
> >> kamp2 = kamp * 12000
> >> aout    lfo      kamp2, 440, 1
> >>         outs     aout, aout
> >>
> >> But this (which I use all the time, and which works fine in the context
> >> of
> >> chnget and MIDI input) does not:
> >> kamp   init     0
> >> kans    OSClisten gichan, "/1/slider1", "f", kamp
> >> kamp = kamp * 12000
> >> aout    lfo      kamp, 440, 1
> >>         outs     aout, aout
> >>
> >> The problem seems to be that an OSC k-time variable (here kamp) cannot
> be
> >> redefined. I feel sure this has something to do with the special way
> that
> >> OSC data are stored/handled that is different from how MIDI and chnget
> >> variables are treated.
> >>
> >> Is there any possibility that an alternative to the convoluted
> OSClisten
> >> opcode could be written that:
> >> 1) would more ressemble other control inputs - and have its output
> >> variable(s) on the left;
> >> 2) have its output stored in such a way as to allow it to be redefined
> at
> >> k-time?
> >>
> >> For those of us who'd like to offer OSC realtime control as an option
> to
> >> both MIDI and frontends (etc.) that use chnget, such an alternative
> would
> >> be
> >> welcome indeed. (I've had to do extensive editing of .csds to work
> around
> >> #2
> >> above.)
> >>
> >> Art Hunkins
> >>
> >>
> >> -----------------------------------------------------------------------
> -------
> >> One dashboard for servers and applications across Physical-Virtual-
> Cloud
> >> Widest out-of-the-box monitoring support with 50+ applications
> >> Performance metrics, stats and reports that give you Actionable
> Insights
> >> Deep dive visibility with transaction tracing using APM Insight.
> >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >> _______________________________________________
> >> Csound-users mailing list
> >> Csound-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/csound-users
> >> Send bugs reports to
> >>         https://github.com/csound/csound/issues
> >> Discussions of bugs and features can be posted here
> >
> > ------------------------------------------------------------------------
> ------
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Csound-users mailing list
> > Csound-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-users
> > Send bugs reports to
> >        https://github.com/csound/csound/issues
> > Discussions of bugs and features can be posted here
> 
> 
> --------------------------------------------------------------------------
> ----
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I agree with Russel on this,
the different input sources (OSC, midi, chn) behave in different ways,
and the way OSC now works in Csound lets us use the trigger to decide
if something need to be processed. For your initial example, Art,
perhaps you could do
if kans > 0 then
kamp = kamp * 12000
endif

I realize you would like to avoid this, but in my opinion, this is how
OSC works and it seems natural that it needs to be handled so.
In the same manner as we need  to put OSClisten in a loop reading off
messages until kans is zero.

2015-05-21 22:37 GMT+02:00 Russell Pinkston :
> Actually, Art, if I understand correctly what you are suggesting, then I do
> see a problem. What if someone is using OSC input to set an on/off switch,
> for example? I.e.,
>
> kans    OSClisten gichan, "/1/switch", "f", kswitch
>
> if (kswitch == 1) then
> ;code to play sound 1
> else
> ;code to play sound 2
> endif
>
> You wouldn't want the value of kswitch to be set back to 0 on every k, would
> you?
>
> I think it's important to recognize the fundamental differences between
> chnget, MIDI, and OSC. With chnget, you're initiating the action (to
> retrieve a value from somewhere - a GUI, or another application). With MIDI
> and OSC, on the other hand, the external device (or application) is
> initiating the action. It sends you a new value whenever something has
> changed. Hence, you always have to be ready to receive it and you have to
> assume that the value you received represents the current state of the
> external device. With midictrl, the result variable is not reset on every k
> - it just holds its value until a new midi control message is received. The
> beauty of OSClisten is that you get a trigger (kans) whenever a new value is
> received. If you use that trigger, your code can be very efficient. In
> contrast, with both chnget and midictrl, unless you use the changed opcode
> to generate a trigger when the input variable has changed, you end up having
> to recalculate all the code that depends on that variable on every k.
>
> Russell
>
>> -----Original Message-----
>> From: Art Hunkins [mailto:abhunkin@uncg.edu]
>> Sent: Thursday, May 21, 2015 12:18 PM
>> To: csound users' discussions
>> Subject: Re: [Csnd] OSClisten Issue
>>
>> Steven -
>>
>> Your explanation makes sense, and is no doubt what is happening.
>>
>> I doubt that in the case we are discussing, anyone actually expects the
>> result that occurs - in this example, kamp increases to infinite amplitude
>> with many thousands of samples out of range (according to Console output).
>> In addition, I feel sure noone has ever used OSClisten this way.
>>
>> A simple change in OSClisten to (re-)set the value of kamp to its
>> *unchanged* value each k-cycle (if indeed unchanged) would rectify the
>> situation. To my knowledge, this is what occurs with other input values in
>> opcodes including MIDI and chnget. There would be no change to OSClisten's
>> format or behavior other than to cover this case.
>>
>> Does anyone see a problem with this proposal?
>>
>> It would certainly simplify porting .csd's designed for MIDI or chngets,
>> to
>> OSC control. The several "workaround" alternatives, such as the one
>> Russell
>> suggests, require additional coding changes.
>>
>> Art Hunkins
>>
>> ----- Original Message -----
>> From: "Steven Yi" 
>> To: "csound users' discussions" 
>> Sent: Tuesday, May 19, 2015 7:38 PM
>> Subject: Re: [Csnd] OSClisten Issue
>>
>>
>> > Hi Art,
>> >
>> > I looked a little into this and I think what is happening is that with
>> > OSClisten, it sets the value to kamp only when a change is found (so
>> > kans will be 1 in those cases). In the cases where no changes were
>> > found, it does not set the value to kamp, and the previous value will
>> > be there.  In that case, when you get to the:
>> >
>> > kamp = kamp * 12000
>> >
>> > line, it will multiply the previous value of kamp there, instead of
>> > the last value received from OSClisten.  That would explain why the
>> > other two versions work.
>> >
>> > I don't really use OSC much myself, so don't have much of an opinion
>> > on any changes, but thought the above worth mentioning.
>> >
>> > steven
>> >
>> > On Tue, May 19, 2015 at 7:10 PM, Art Hunkins  wrote:
>> >> I've been working intensively on Android with OSClisten, receiving OSC
>> >> data
>> >> from TouchOSC GUIs (Layouts). I've no idea whether or not this issue
>> >> pertains to other situations or platforms, though I suspect it does.
>> >>
>> >> It is this:
>> >>
>> >> The following code works:
>> >> kamp   init     0
>> >> kans    OSClisten gichan, "/1/slider1", "f", kamp
>> >> aout    lfo      kamp * 12000, 440, 1
>> >>         outs     aout, aout
>> >>
>> >> So does this:
>> >> kamp   init     0
>> >> kans    OSClisten gichan, "/1/slider1", "f", kamp
>> >> kamp2 = kamp * 12000
>> >> aout    lfo      kamp2, 440, 1
>> >>         outs     aout, aout
>> >>
>> >> But this (which I use all the time, and which works fine in the context
>> >> of
>> >> chnget and MIDI input) does not:
>> >> kamp   init     0
>> >> kans    OSClisten gichan, "/1/slider1", "f", kamp
>> >> kamp = kamp * 12000
>> >> aout    lfo      kamp, 440, 1
>> >>         outs     aout, aout
>> >>
>> >> The problem seems to be that an OSC k-time variable (here kamp) cannot
>> be
>> >> redefined. I feel sure this has something to do with the special way
>> that
>> >> OSC data are stored/handled that is different from how MIDI and chnget
>> >> variables are treated.
>> >>
>> >> Is there any possibility that an alternative to the convoluted
>> OSClisten
>> >> opcode could be written that:
>> >> 1) would more ressemble other control inputs - and have its output
>> >> variable(s) on the left;
>> >> 2) have its output stored in such a way as to allow it to be redefined
>> at
>> >> k-time?
>> >>
>> >> For those of us who'd like to offer OSC realtime control as an option
>> to
>> >> both MIDI and frontends (etc.) that use chnget, such an alternative
>> would
>> >> be
>> >> welcome indeed. (I've had to do extensive editing of .csds to work
>> around
>> >> #2
>> >> above.)
>> >>
>> >> Art Hunkins
>> >>
>> >>
>> >> -----------------------------------------------------------------------
>> -------
>> >> One dashboard for servers and applications across Physical-Virtual-
>> Cloud
>> >> Widest out-of-the-box monitoring support with 50+ applications
>> >> Performance metrics, stats and reports that give you Actionable
>> Insights
>> >> Deep dive visibility with transaction tracing using APM Insight.
>> >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> >> _______________________________________________
>> >> Csound-users mailing list
>> >> Csound-users@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-users
>> >> Send bugs reports to
>> >>         https://github.com/csound/csound/issues
>> >> Discussions of bugs and features can be posted here
>> >
>> > ------------------------------------------------------------------------
>> ------
>> > One dashboard for servers and applications across Physical-Virtual-Cloud
>> > Widest out-of-the-box monitoring support with 50+ applications
>> > Performance metrics, stats and reports that give you Actionable Insights
>> > Deep dive visibility with transaction tracing using APM Insight.
>> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> > _______________________________________________
>> > Csound-users mailing list
>> > Csound-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-users
>> > Send bugs reports to
>> >        https://github.com/csound/csound/issues
>> > Discussions of bugs and features can be posted here
>>
>>
>> --------------------------------------------------------------------------
>> ----
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Csound-users mailing list
>> Csound-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-users
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Ah, I do think I misunderstood. You want OSClisten to behave like midictrl,
in that the output k-variable for a midictrl opcode will be reset on every k
to the last value Csound received from that midi controller. The output
variable(s) for OSClisten, on the other hand, will only get set when an OSC
message is received. But that's a very efficient approach and it means that
OSClisten doesn't have to maintain an internal copy of every input
parameter, some of which might be strings. 

/R
> -----Original Message-----
> From: Russell Pinkston [mailto:pinkstonrf@austin.utexas.edu]
> Sent: Thursday, May 21, 2015 3:37 PM
> To: 'Art Hunkins'; 'csound users' discussions'
> Subject: Re: [Csnd] OSClisten Issue
> 
> Actually, Art, if I understand correctly what you are suggesting, then I
> do
> see a problem. What if someone is using OSC input to set an on/off switch,
> for example? I.e.,
> 
> kans	OSClisten gichan, "/1/switch", "f", kswitch
> 
> if (kswitch == 1) then
> ;code to play sound 1
> else
> ;code to play sound 2
> endif
> 
> You wouldn't want the value of kswitch to be set back to 0 on every k,
> would
> you?
> 
> I think it's important to recognize the fundamental differences between
> chnget, MIDI, and OSC. With chnget, you're initiating the action (to
> retrieve a value from somewhere - a GUI, or another application). With
> MIDI
> and OSC, on the other hand, the external device (or application) is
> initiating the action. It sends you a new value whenever something has
> changed. Hence, you always have to be ready to receive it and you have to
> assume that the value you received represents the current state of the
> external device. With midictrl, the result variable is not reset on every
> k
> - it just holds its value until a new midi control message is received.
> The
> beauty of OSClisten is that you get a trigger (kans) whenever a new value
> is
> received. If you use that trigger, your code can be very efficient. In
> contrast, with both chnget and midictrl, unless you use the changed opcode
> to generate a trigger when the input variable has changed, you end up
> having
> to recalculate all the code that depends on that variable on every k.
> 
> Russell
> 
> > -----Original Message-----
> > From: Art Hunkins [mailto:abhunkin@uncg.edu]
> > Sent: Thursday, May 21, 2015 12:18 PM
> > To: csound users' discussions
> > Subject: Re: [Csnd] OSClisten Issue
> >
> > Steven -
> >
> > Your explanation makes sense, and is no doubt what is happening.
> >
> > I doubt that in the case we are discussing, anyone actually expects the
> > result that occurs - in this example, kamp increases to infinite
> amplitude
> > with many thousands of samples out of range (according to Console
> output).
> > In addition, I feel sure noone has ever used OSClisten this way.
> >
> > A simple change in OSClisten to (re-)set the value of kamp to its
> > *unchanged* value each k-cycle (if indeed unchanged) would rectify the
> > situation. To my knowledge, this is what occurs with other input values
> in
> > opcodes including MIDI and chnget. There would be no change to
> OSClisten's
> > format or behavior other than to cover this case.
> >
> > Does anyone see a problem with this proposal?
> >
> > It would certainly simplify porting .csd's designed for MIDI or chngets,
> > to
> > OSC control. The several "workaround" alternatives, such as the one
> > Russell
> > suggests, require additional coding changes.
> >
> > Art Hunkins
> >
> > ----- Original Message -----
> > From: "Steven Yi" 
> > To: "csound users' discussions" 
> > Sent: Tuesday, May 19, 2015 7:38 PM
> > Subject: Re: [Csnd] OSClisten Issue
> >
> >
> > > Hi Art,
> > >
> > > I looked a little into this and I think what is happening is that with
> > > OSClisten, it sets the value to kamp only when a change is found (so
> > > kans will be 1 in those cases). In the cases where no changes were
> > > found, it does not set the value to kamp, and the previous value will
> > > be there.  In that case, when you get to the:
> > >
> > > kamp = kamp * 12000
> > >
> > > line, it will multiply the previous value of kamp there, instead of
> > > the last value received from OSClisten.  That would explain why the
> > > other two versions work.
> > >
> > > I don't really use OSC much myself, so don't have much of an opinion
> > > on any changes, but thought the above worth mentioning.
> > >
> > > steven
> > >
> > > On Tue, May 19, 2015 at 7:10 PM, Art Hunkins 
> wrote:
> > >> I've been working intensively on Android with OSClisten, receiving
> OSC
> > >> data
> > >> from TouchOSC GUIs (Layouts). I've no idea whether or not this issue
> > >> pertains to other situations or platforms, though I suspect it does.
> > >>
> > >> It is this:
> > >>
> > >> The following code works:
> > >> kamp   init     0
> > >> kans    OSClisten gichan, "/1/slider1", "f", kamp
> > >> aout    lfo      kamp * 12000, 440, 1
> > >>         outs     aout, aout
> > >>
> > >> So does this:
> > >> kamp   init     0
> > >> kans    OSClisten gichan, "/1/slider1", "f", kamp
> > >> kamp2 = kamp * 12000
> > >> aout    lfo      kamp2, 440, 1
> > >>         outs     aout, aout
> > >>
> > >> But this (which I use all the time, and which works fine in the
> context
> > >> of
> > >> chnget and MIDI input) does not:
> > >> kamp   init     0
> > >> kans    OSClisten gichan, "/1/slider1", "f", kamp
> > >> kamp = kamp * 12000
> > >> aout    lfo      kamp, 440, 1
> > >>         outs     aout, aout
> > >>
> > >> The problem seems to be that an OSC k-time variable (here kamp)
> cannot
> > be
> > >> redefined. I feel sure this has something to do with the special way
> > that
> > >> OSC data are stored/handled that is different from how MIDI and
> chnget
> > >> variables are treated.
> > >>
> > >> Is there any possibility that an alternative to the convoluted
> > OSClisten
> > >> opcode could be written that:
> > >> 1) would more ressemble other control inputs - and have its output
> > >> variable(s) on the left;
> > >> 2) have its output stored in such a way as to allow it to be
> redefined
> > at
> > >> k-time?
> > >>
> > >> For those of us who'd like to offer OSC realtime control as an option
> > to
> > >> both MIDI and frontends (etc.) that use chnget, such an alternative
> > would
> > >> be
> > >> welcome indeed. (I've had to do extensive editing of .csds to work
> > around
> > >> #2
> > >> above.)
> > >>
> > >> Art Hunkins
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> --
> > -------
> > >> One dashboard for servers and applications across Physical-Virtual-
> > Cloud
> > >> Widest out-of-the-box monitoring support with 50+ applications
> > >> Performance metrics, stats and reports that give you Actionable
> > Insights
> > >> Deep dive visibility with transaction tracing using APM Insight.
> > >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > >> _______________________________________________
> > >> Csound-users mailing list
> > >> Csound-users@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/csound-users
> > >> Send bugs reports to
> > >>         https://github.com/csound/csound/issues
> > >> Discussions of bugs and features can be posted here
> > >
> > > ----------------------------------------------------------------------
> --
> > ------
> > > One dashboard for servers and applications across Physical-Virtual-
> Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable
> Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > _______________________________________________
> > > Csound-users mailing list
> > > Csound-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/csound-users
> > > Send bugs reports to
> > >        https://github.com/csound/csound/issues
> > > Discussions of bugs and features can be posted here
> >
> >
> > ------------------------------------------------------------------------
> --
> > ----
> > One dashboard for servers and applications across Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > _______________________________________________
> > Csound-users mailing list
> > Csound-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-users
> > Send bugs reports to
> >         https://github.com/csound/csound/issues
> > Discussions of bugs and features can be posted here
> 
> 
> --------------------------------------------------------------------------
> ----
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here