Csound Csound-dev Csound-tekno Search About

[Csnd-dev] OSC opcode suggestion

Date2018-08-17 13:44
FromDave Seidel
Subject[Csnd-dev] OSC opcode suggestion
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
Date2018-08-17 17:11
Fromjpff
SubjectRe: [Csnd-dev] OSC opcode suggestion
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
>
Date2018-08-18 17:10
Fromjpff
SubjectRe: [Csnd-dev] OSC opcode suggestion
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
>
Date2018-08-18 18:13
FromDave Seidel
SubjectRe: [Csnd-dev] OSC opcode suggestion
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 <jpff@codemist.co.uk> 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
>
>


--
Date2018-08-18 22:33
FromDave Seidel
SubjectRe: [Csnd-dev] OSC opcode suggestion
I will write the manual page for OSCcount, if no one minds.

On Sat, Aug 18, 2018, 1:13 PM Dave Seidel <dave.seidel@gmail.com> 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 <jpff@codemist.co.uk> 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
>
>


--
Date2018-08-18 23:43
FromJohn ff
SubjectRe: [Csnd-dev] OSC opcode suggestion
OK


Sent from TypeApp
On 18 Aug 2018, at 22:35, Dave Seidel <dave.seidel@gmail.com> wrote:
I will write the manual page for OSCcount, if no one minds.

On Sat, Aug 18, 2018, 1:13 PM Dave Seidel < dave.seidel@gmail.com> 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 < jpff@codemist.co.uk> 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
>
>


--
Date2018-08-19 17:30
FromDave Seidel
SubjectRe: [Csnd-dev] OSC opcode suggestion
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
Date2019-01-15 20:52
FromSigurd Saue
SubjectRe: [Csnd-dev] OSC opcode suggestion

Hi Dave,

 

I just came across this very nice example of the new OSC opcodes. Thank you for sharing! I will probably adopt some of these ideas in a current project of mine.

 

Just one question: Wouldn’t it be better to include OSCcount in the next-loop to avoid that final iteration through all the OSClisten tests after the last pending message has  been processed?

 

Sigurd

 

 

 

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> On Behalf Of Dave Seidel
Sent: Sunday, August 19, 2018 6:31 PM
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] OSC opcode suggestion

 

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

Date2019-02-24 00:09
From"Dr. Richard Boulanger"
SubjectRe: [Csnd-dev] OSC opcode suggestion
Great.  Nice additions and improvements!  Can't wait to hear the piece live at Berklee.
_____________________________________________
Dr. Richard Boulanger
Professor of Electronic Production and Design
Professional Writing and Music Technology Division
Berklee College of Music
______________________________________________
OFFICE: 1126 Boylston St., Suite 201 (EPD), Suite 208 (Boulanger)
______________________________________________


On Sat, Aug 18, 2018 at 5:34 PM Dave Seidel <dave.seidel@gmail.com> wrote:
I will write the manual page for OSCcount, if no one minds.

On Sat, Aug 18, 2018, 1:13 PM Dave Seidel <dave.seidel@gmail.com> 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 <jpff@codemist.co.uk> 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
>
>


--
Date2019-02-24 03:19
From"Dr. Richard Boulanger"
SubjectRe: [Csnd-dev] OSC opcode suggestion
Thanks John.  These will prove to be very useful to many

Dr. Richard Boulanger
Professor
Electronic Production and Design
Berklee College of Music

> On Aug 18, 2018, at 12:10 PM, jpff  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