[Csnd-dev] OSC opcode suggestion

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Csnd-dev] OSC opcode suggestion

Dave Seidel
In the app I'm working on, I am using OSC for a bunch of controls. At this point, I have 19 different OSC endpoints that I need to track, and I'm doing those in an instrument with a series of if statements calling OSClisten in a kgoto loop (to read queued messages, as recommended in the manual). This works fine, but on all the k-cycles where there are no incoming OSC messages, the instrument has no choice but to do this same series of calls to OSClisten. Likewise, if there's only one message to process, I still have to check the other 16 endpoints. This seems like wasted effort, which will only get worse if/when I add additional OSC endpoints.

Not knowing the internals of the OSC code, it occurs ti me that it *might* be possible to have a new opcode (maybe OSCqueue or something) that either returns 1 if there are pending incoming messages to process, or perhaps would return the number of pending messages at that moment. With this, the instrument that makes all the OSClisten calls could be made much more efficient, as it would be possible to skip over all the OSClisten calls when there's nothing to read.

Is this feasible? I thought I would ask here first before entering a ticket, and only enter a formal feature request if it's possible.

(To put this in context relative to MIDI processing, my MIDI version of the app used slider16 or slider32 (depending on which hardware controller I was using), which allows tracking of multiple MIDI controls in a single opcode call. This doesn't seem like a feasible approach for OSC, since there's no guarantee that an OSC interface will have the same configuration for every control.)

- Dave
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd-dev] OSC opcode suggestion

jpff
I like the idea but it is not as easy as you suggest.  When a nessage
arrives it is checked to see if it matches any pattern, and if so is
placed on a queue for that listener.  There is no global counter nor
global list.
   Each listener only sees its ouwn queue, and if empty it returns fairly
quickly

static int32_t OSC_list(CSOUND *csound, OSCLISTEN *p)
{
     OSC_PAT *m;

     /* quick check for empty queue */
     if (p->c.patterns == NULL) {
       *p->kans = 0;
       return OK;
     }
     ..... data has arrived.....

Thinking alous/active typing..

I suppose one could add a global counter but not obvious where and it
would need to be incremented in the receiver and decremented in each
listener.  Perhaps a field in the csound structure?  Maybe I will try an
experiment to see if it is any use.


On Fri, 17 Aug 2018, Dave Seidel wrote:

> In the app I'm working on, I am using OSC for a bunch of controls. At this
> point, I have 19 different OSC endpoints that I need to track, and I'm doing
> those in an instrument with a series of if statements calling OSClisten in a
> kgoto loop (to read queued messages, as recommended in the manual). This works
> fine, but on all the k-cycles where there are no incoming OSC messages, the
> instrument has no choice but to do this same series of calls to OSClisten.
> Likewise, if there's only one message to process, I still have to check the
> other 16 endpoints. This seems like wasted effort, which will only get worse
> if/when I add additional OSC endpoints.
> Not knowing the internals of the OSC code, it occurs ti me that it *might* be
> possible to have a new opcode (maybe OSCqueue or something) that either
> returns 1 if there are pending incoming messages to process, or perhaps would
> return the number of pending messages at that moment. With this, the
> instrument that makes all the OSClisten calls could be made much more
> efficient, as it would be possible to skip over all the OSClisten calls when
> there's nothing to read.
>
> Is this feasible? I thought I would ask here first before entering a ticket,
> and only enter a formal feature request if it's possible.
>
> (To put this in context relative to MIDI processing, my MIDI version of the
> app used slider16 or slider32 (depending on which hardware controller I was
> using), which allows tracking of multiple MIDI controls in a single opcode
> call. This doesn't seem like a feasible approach for OSC, since there's no
> guarantee that an OSC interface will have the same configuration for every
> control.)
>
> - Dave
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd-dev] OSC opcode suggestion

jpff
In reply to this post by Dave Seidel
Just a follow-up after off-line discussions.

There is an experimental opcode OSCcount that returns the number of
pending OSC message waiting to be processed.  It needsa little more
testing but the omens are good.  I will document in the manual as soon as
I get confirmation that it works OK and is useful.

===John ff

On Fri, 17 Aug 2018, Dave Seidel wrote:

> In the app I'm working on, I am using OSC for a bunch of controls. At this
> point, I have 19 different OSC endpoints that I need to track, and I'm doing
> those in an instrument with a series of if statements calling OSClisten in a
> kgoto loop (to read queued messages, as recommended in the manual). This works
> fine, but on all the k-cycles where there are no incoming OSC messages, the
> instrument has no choice but to do this same series of calls to OSClisten.
> Likewise, if there's only one message to process, I still have to check the
> other 16 endpoints. This seems like wasted effort, which will only get worse
> if/when I add additional OSC endpoints.
> Not knowing the internals of the OSC code, it occurs ti me that it *might* be
> possible to have a new opcode (maybe OSCqueue or something) that either
> returns 1 if there are pending incoming messages to process, or perhaps would
> return the number of pending messages at that moment. With this, the
> instrument that makes all the OSClisten calls could be made much more
> efficient, as it would be possible to skip over all the OSClisten calls when
> there's nothing to read.
>
> Is this feasible? I thought I would ask here first before entering a ticket,
> and only enter a formal feature request if it's possible.
>
> (To put this in context relative to MIDI processing, my MIDI version of the
> app used slider16 or slider32 (depending on which hardware controller I was
> using), which allows tracking of multiple MIDI controls in a single opcode
> call. This doesn't seem like a feasible approach for OSC, since there's no
> guarantee that an OSC interface will have the same configuration for every
> control.)
>
> - Dave
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd-dev] OSC opcode suggestion

Dave Seidel
I've been testing this, and it seems to be working well. My instrument is now only calling OSClisten if there's a >0 number of pending messages because I call OCScount first. In my OSC UI, I have a "reset" button the re-initializes all controls to their default values, which causes 18 OSC messages to be sent in quick succession -- John's new opcode is reporting the correct number of pending messages, and I am able to process them all. Same with moving a slider, which send a series of messages. Of course single messages are handled properly as well.

Along with John's other recent change (the alternate form of OSClisten), the OSC capabilities of Csound are getting better and better -- more efficient, and more friendly for coders. Thanks John!!!

- Dave

On Sat, Aug 18, 2018 at 12:10 PM jpff <[hidden email]> wrote:
Just a follow-up after off-line discussions.

There is an experimental opcode OSCcount that returns the number of
pending OSC message waiting to be processed.  It needsa little more
testing but the omens are good.  I will document in the manual as soon as
I get confirmation that it works OK and is useful.

===John ff

On Fri, 17 Aug 2018, Dave Seidel wrote:

> In the app I'm working on, I am using OSC for a bunch of controls. At this
> point, I have 19 different OSC endpoints that I need to track, and I'm doing
> those in an instrument with a series of if statements calling OSClisten in a
> kgoto loop (to read queued messages, as recommended in the manual). This works
> fine, but on all the k-cycles where there are no incoming OSC messages, the
> instrument has no choice but to do this same series of calls to OSClisten.
> Likewise, if there's only one message to process, I still have to check the
> other 16 endpoints. This seems like wasted effort, which will only get worse
> if/when I add additional OSC endpoints.
> Not knowing the internals of the OSC code, it occurs ti me that it *might* be
> possible to have a new opcode (maybe OSCqueue or something) that either
> returns 1 if there are pending incoming messages to process, or perhaps would
> return the number of pending messages at that moment. With this, the
> instrument that makes all the OSClisten calls could be made much more
> efficient, as it would be possible to skip over all the OSClisten calls when
> there's nothing to read.
>
> Is this feasible? I thought I would ask here first before entering a ticket,
> and only enter a formal feature request if it's possible.
>
> (To put this in context relative to MIDI processing, my MIDI version of the
> app used slider16 or slider32 (depending on which hardware controller I was
> using), which allows tracking of multiple MIDI controls in a single opcode
> call. This doesn't seem like a feasible approach for OSC, since there's no
> guarantee that an OSC interface will have the same configuration for every
> control.)
>
> - Dave
>
>


--
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd-dev] OSC opcode suggestion

Dave Seidel
I will write the manual page for OSCcount, if no one minds.

On Sat, Aug 18, 2018, 1:13 PM Dave Seidel <[hidden email]> wrote:
I've been testing this, and it seems to be working well. My instrument is now only calling OSClisten if there's a >0 number of pending messages because I call OCScount first. In my OSC UI, I have a "reset" button the re-initializes all controls to their default values, which causes 18 OSC messages to be sent in quick succession -- John's new opcode is reporting the correct number of pending messages, and I am able to process them all. Same with moving a slider, which send a series of messages. Of course single messages are handled properly as well.

Along with John's other recent change (the alternate form of OSClisten), the OSC capabilities of Csound are getting better and better -- more efficient, and more friendly for coders. Thanks John!!!

- Dave

On Sat, Aug 18, 2018 at 12:10 PM jpff <[hidden email]> wrote:
Just a follow-up after off-line discussions.

There is an experimental opcode OSCcount that returns the number of
pending OSC message waiting to be processed.  It needsa little more
testing but the omens are good.  I will document in the manual as soon as
I get confirmation that it works OK and is useful.

===John ff

On Fri, 17 Aug 2018, Dave Seidel wrote:

> In the app I'm working on, I am using OSC for a bunch of controls. At this
> point, I have 19 different OSC endpoints that I need to track, and I'm doing
> those in an instrument with a series of if statements calling OSClisten in a
> kgoto loop (to read queued messages, as recommended in the manual). This works
> fine, but on all the k-cycles where there are no incoming OSC messages, the
> instrument has no choice but to do this same series of calls to OSClisten.
> Likewise, if there's only one message to process, I still have to check the
> other 16 endpoints. This seems like wasted effort, which will only get worse
> if/when I add additional OSC endpoints.
> Not knowing the internals of the OSC code, it occurs ti me that it *might* be
> possible to have a new opcode (maybe OSCqueue or something) that either
> returns 1 if there are pending incoming messages to process, or perhaps would
> return the number of pending messages at that moment. With this, the
> instrument that makes all the OSClisten calls could be made much more
> efficient, as it would be possible to skip over all the OSClisten calls when
> there's nothing to read.
>
> Is this feasible? I thought I would ask here first before entering a ticket,
> and only enter a formal feature request if it's possible.
>
> (To put this in context relative to MIDI processing, my MIDI version of the
> app used slider16 or slider32 (depending on which hardware controller I was
> using), which allows tracking of multiple MIDI controls in a single opcode
> call. This doesn't seem like a feasible approach for OSC, since there's no
> guarantee that an OSC interface will have the same configuration for every
> control.)
>
> - Dave
>
>


--
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd-dev] OSC opcode suggestion

jpff
OK


Sent from TypeApp
On 18 Aug 2018, at 22:35, Dave Seidel <[hidden email]> wrote:
I will write the manual page for OSCcount, if no one minds.

On Sat, Aug 18, 2018, 1:13 PM Dave Seidel < [hidden email]> wrote:
I've been testing this, and it seems to be working well. My instrument is now only calling OSClisten if there's a >0 number of pending messages because I call OCScount first. In my OSC UI, I have a "reset" button the re-initializes all controls to their default values, which causes 18 OSC messages to be sent in quick succession -- John's new opcode is reporting the correct number of pending messages, and I am able to process them all. Same with moving a slider, which send a series of messages. Of course single messages are handled properly as well.

Along with John's other recent change (the alternate form of OSClisten), the OSC capabilities of Csound are getting better and better -- more efficient, and more friendly for coders. Thanks John!!!

- Dave

On Sat, Aug 18, 2018 at 12:10 PM jpff < [hidden email]> wrote:
Just a follow-up after off-line discussions.

There is an experimental opcode OSCcount that returns the number of
pending OSC message waiting to be processed.  It needsa little more
testing but the omens are good.  I will document in the manual as soon as
I get confirmation that it works OK and is useful.

===John ff

On Fri, 17 Aug 2018, Dave Seidel wrote:

> In the app I'm working on, I am using OSC for a bunch of controls. At this
> point, I have 19 different OSC endpoints that I need to track, and I'm doing
> those in an instrument with a series of if statements calling OSClisten in a
> kgoto loop (to read queued messages, as recommended in the manual). This works
> fine, but on all the k-cycles where there are no incoming OSC messages, the
> instrument has no choice but to do this same series of calls to OSClisten.
> Likewise, if there's only one message to process, I still have to check the
> other 16 endpoints. This seems like wasted effort, which will only get worse
> if/when I add additional OSC endpoints.
> Not knowing the internals of the OSC code, it occurs ti me that it *might* be
> possible to have a new opcode (maybe OSCqueue or something) that either
> returns 1 if there are pending incoming messages to process, or perhaps would
> return the number of pending messages at that moment. With this, the
> instrument that makes all the OSClisten calls could be made much more
> efficient, as it would be possible to skip over all the OSClisten calls when
> there's nothing to read.
>
> Is this feasible? I thought I would ask here first before entering a ticket,
> and only enter a formal feature request if it's possible.
>
> (To put this in context relative to MIDI processing, my MIDI version of the
> app used slider16 or slider32 (depending on which hardware controller I was
> using), which allows tracking of multiple MIDI controls in a single opcode
> call. This doesn't seem like a feasible approach for OSC, since there's no
> guarantee that an OSC interface will have the same configuration for every
> control.)
>
> - Dave
>
>


--
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd-dev] OSC opcode suggestion

Dave Seidel
If anyone is curious, I have updated the Implication Organ to v2.0, which is a big change from MIDI controls to OSC controls, It uses both the new format of OSClisten and the new OSCcount opcode.


The OSC handling code is here https://github.com/DaveSeidel/music-src/blob/master/implication-organ/implication-organ.csd#L442 -- it uses a convenience opcode called _read_osc_control which is defined a few lines above.

Thanks again for all your work, John. I wanted to show that it is being used!

- Dave