Csound Csound-dev Csound-tekno Search About

Re: OSClisten Issue

Date2015-05-22 00:43
From"Art Hunkins"
SubjectRe: OSClisten Issue
Yes, that's what I meant - and I assume that not only MIDIin does it this 
way, but chnget as well. (But perhaps I'm wrong.) Is there a substantial 
penalty to resetting variables each k-cycle?

One benefit of OSClisten is that it already has a built-in "changed" flag, 
which wouldn't need to be additionally programmed if you were concerned 
about efficiency (and I guess that includes all of us).

Art Hunkins

----- Original Message ----- 
From: "Russell Pinkston" 
To: "'csound users' discussions'" 
Sent: Thursday, May 21, 2015 6:02 PM
Subject: Re: [Csnd] OSClisten Issue


> 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 


------------------------------------------------------------------------------
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

Date2015-05-22 01:05
FromSteven Yi
SubjectRe: OSClisten Issue
It sounds like we should leave OSClisten alone.  There's a work around
for Art, and you can always write your own UDO that will wrap
OSClisten and provide the behavior you mentioned.  There's also the
issue of backwards compatibility; as this is more a feature request
than a bug fix, it seems we should leave it.

On Thu, May 21, 2015 at 7:43 PM, Art Hunkins  wrote:
> Yes, that's what I meant - and I assume that not only MIDIin does it this
> way, but chnget as well. (But perhaps I'm wrong.) Is there a substantial
> penalty to resetting variables each k-cycle?
>
> One benefit of OSClisten is that it already has a built-in "changed" flag,
> which wouldn't need to be additionally programmed if you were concerned
> about efficiency (and I guess that includes all of us).
>
> Art Hunkins
>
> ----- Original Message -----
> From: "Russell Pinkston" 
> To: "'csound users' discussions'" 
> Sent: Thursday, May 21, 2015 6:02 PM
> Subject: Re: [Csnd] OSClisten Issue
>
>
>> 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
>
>
> ------------------------------------------------------------------------------
> 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

Date2015-05-22 01:20
FromMichael Gogins
SubjectRe: OSClisten Issue
AttachmentsNone  None  
I think we should certainly leave the existing OSClisten as is. 

The overhead of comparing a new value with an old value every kperiod is minimal, at least, if this is done in a global instrument that is always on.

It would of course also be possible to create an new variant of OSClisten. If Art or somebody produces a UDO that behaves the way they want and looks easy to understand, we can write such a variant in C.

Regards,
Mike




-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Thu, May 21, 2015 at 8:05 PM, Steven Yi <stevenyi@gmail.com> wrote:
It sounds like we should leave OSClisten alone.  There's a work around
for Art, and you can always write your own UDO that will wrap
OSClisten and provide the behavior you mentioned.  There's also the
issue of backwards compatibility; as this is more a feature request
than a bug fix, it seems we should leave it.

On Thu, May 21, 2015 at 7:43 PM, Art Hunkins <abhunkin@uncg.edu> wrote:
> Yes, that's what I meant - and I assume that not only MIDIin does it this
> way, but chnget as well. (But perhaps I'm wrong.) Is there a substantial
> penalty to resetting variables each k-cycle?
>
> One benefit of OSClisten is that it already has a built-in "changed" flag,
> which wouldn't need to be additionally programmed if you were concerned
> about efficiency (and I guess that includes all of us).
>
> Art Hunkins
>
> ----- Original Message -----
> From: "Russell Pinkston" <pinkstonrf@austin.utexas.edu>
> To: "'csound users' discussions'" <csound-users@lists.sourceforge.net>
> Sent: Thursday, May 21, 2015 6:02 PM
> Subject: Re: [Csnd] OSClisten Issue
>
>
>> 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" <stevenyi@gmail.com>
>>> > To: "csound users' discussions" <csound-users@lists.sourceforge.net>
>>> > 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 <abhunkin@uncg.edu>
>>> 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
>
>
> ------------------------------------------------------------------------------
> 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