Are youseeng a cange in IP addressin the dynamic case?  Tat would be a 
problem as the init pase remembers the IP address.

I ave no dynamic IP system here so would never have noticed
==Jon ff


On Sat, 23 May 2015, David Worrall wrote:

> While we are discussing OSC opcodes, I’d like to report a bug (feature?) of
> OSCsend.
> I am aware that OSCsend is not ‘clean’ UDP - it adds OSC protocol stuff,
> however, I’ve been using it to send UDP data to known IPaddresses, ports etc
> without problems. 
> 
> OSCsend to a different machine works well. It appears responsive and not at
> all lossy.
> 
> Here’s the rub:
> (MacBook Pro early 2013, Mac OSX 10.8.6 - 10.9.2, Csound version 6.03.2
> (double samples) Jul 16 2014,  instantiated as csnd6,py)
> 
> When I OSCsend to local host (IP 127.0.0.1) it sends fine.
> But if I try to UDP-read it on the same machine, it blocks after a
> yet-to-be-determined period of time/amount of data, i.e.
> 
> The result is if I need to send UDP data to localhost to be read by another
> process on the same machine, I cannot use OSCsend.
> (It _does_ work for machines with a fixed IP, but not those with dynamic IP
> addressing.)
> 
> My workaround is to do my UDP sending independent of Csound (in my case, in
> python.)
> 
> I have no idea whether this is a bug or a feature of OSCsend. I post it here
> in case anyone else runs into a similar problem.
> 
> David
> 
> 
> 
> 
> 
> ______________________________________
> Prof. Dr. David Worrall
> International Audio Laboratories Erlangen
> Fraunhofer-Institut für Integrierte Schaltungen IIS
> Am Wolfsmantel 33
> 91058 Erlangen
> Telefon  +49 (0) 91 31 / 7 76-62 44
> Fax      +49 (0) 91 31 / 7 76-20 99
> E-Mail: david.worrall@iis.fraunhofer.de
> www: iis.fraunhofer.de 
>          audiolabs-erlangen.de/research/emerging-audio-research
> ---
> Adjunct Senior Research Fellow
> School of Music, Australian National University
> david.worrall@anu.edu.au
> 
> 
> 
> 
> 
> 
> 
> 
>

Hi, I am interested in the problem, as I've recently been working with
interprocess communication via OSC too.
It seems to me as if there are significant differences in how
different languages/libraries handles the network communication, but
as you, I haven't really gone into the gritty details to find out
exactly what/how it is different.
I am currently using OSC send in one Cabbage plugin, sending to 10
different ports on 127.0.0.1, and reading the data in individual
Cabbage plugins on other tracks. Each receiver plugin tries to open a
port on init, and if that port is already taken (by another Cabbage
plug in the same setup), it increments the port number and tries
again, eventually finding an available port to receive data from. This
seems to work fine now, haven't been running it for hours, but has
worked ok for 20-30 minutes in preliminary testing sessions. So, this
may prove that one of the things you tried actually does work fine
here. Originally, I did send each parameter with a separate OSC send.
I had 12 parameters at the time, sending to 10 ports (totalling 120
OSC sends). I had some performance issues with this, it seemed to tax
the CPU significantly. I had used "localhost" instead of "127.0.0.1"
at first, using the numeric address seemed to make it easier on the
CPU. Finally, I tried to send the messages as one packet with 12
floats instead of using 12 separate OSC sends, and that eased the CPU
even more. The reason why I had split them was that I thought it would
be better to send only when the data had changed, and that I could
limit the rate more by using separate sends for each parameter. Now I
send on every k-rate tick, and sending all 12 values to all 10 ports.
It does use approximately 2% of the CPU (i7) on my laptop. Preliminary
testing of sending the same amount of data in Max seems to be less CPU
hungry, so there is apparently some differences with regards to
implementation. Or perhaps Max would in practice send at a lower rate.
It is hard to make a truly equal test.
As another remark, I tried to patch (another, much simpler OSC stream)
OSC data from Csound into Reaper. This works nicely. However, I must
limit the rate of sending OSC data from Csound, or Reaper will choke.
I thought I was actually losing the connection (might sound similar to
what you experienced, not sure). Then I found out that it continued to
work fine if I limited the data rate. My solution was to quantize the
data and only send if the value had changed more than one quantization
step. Say, if I was sending data from RMS analysis of audio, Reaper
would choke if I sent the float value on every k-rate tick (sr 48000,
ksmps 64), but if I quantized the value to steps of 0.01 by doing
int(kparm1*100)/100), then it would work very smoothly and I would not
lose too much timing precision either.
best
Oeyvind

2015-05-24 11:43 GMT+02:00 David Worrall :
> Hi John,
> thanks for your response.
>
> I’m not changing IP address after OSC  init - or at all after instantiating
> csound.
>
> I must admit  to not having diagnosed exactly what is causing the problem -
> which is why I listed the HW of the machine on which it is not working. In
> order to be certain, I need to put that machine on a fixed IP and then test
> it - thus eliminating it as a specific HW issue, though I suspect it is not,
> as moving the UDP activity out of csound, solves the ‘problem.
>
> I posted the issue just to alert others.
> I guess I was wondering if there is anything in OSCsend which itself would
> block a UDP read on the same port/IPaddr.
> Another test would be to see if OSClisten can ‘hear’ OSCsend on the sample
> port at IP 127.0.0.1.
>
> I have a work around and a deadline to go live, so such testing for me will
> have to wait until after the deadlines :-)
>
> D.
>
>
> On 23.05.2015, at 21:14, jpff  wrote:
>
> Are youseeng a cange in IP addressin the dynamic case?  Tat would be a
> problem as the init pase remembers the IP address.
>
> I ave no dynamic IP system here so would never have noticed
> ==Jon ff
>
>
> On Sat, 23 May 2015, David Worrall wrote:
>
> While we are discussing OSC opcodes, I’d like to report a bug (feature?) of
> OSCsend.
> I am aware that OSCsend is not ‘clean’ UDP - it adds OSC protocol stuff,
> however, I’ve been using it to send UDP data to known IPaddresses, ports etc
> without problems.
> OSCsend to a different machine works well. It appears responsive and not at
> all lossy.
> Here’s the rub:
> (MacBook Pro early 2013, Mac OSX 10.8.6 - 10.9.2, Csound version 6.03.2
> (double samples) Jul 16 2014,  instantiated as csnd6,py)
> When I OSCsend to local host (IP 127.0.0.1) it sends fine.
> But if I try to UDP-read it on the same machine, it blocks after a
> yet-to-be-determined period of time/amount of data, i.e.
> The result is if I need to send UDP data to localhost to be read by another
> process on the same machine, I cannot use OSCsend.
> (It _does_ work for machines with a fixed IP, but not those with dynamic IP
> addressing.)
> My workaround is to do my UDP sending independent of Csound (in my case, in
> python.)
> I have no idea whether this is a bug or a feature of OSCsend. I post it here
> in case anyone else runs into a similar problem.
> David
> ______________________________________
> Prof. Dr. David Worrall
> International Audio Laboratories Erlangen
> Fraunhofer-Institut für Integrierte Schaltungen IIS
> Am Wolfsmantel 33
> 91058 Erlangen
> Telefon  +49 (0) 91 31 / 7 76-62 44
> Fax      +49 (0) 91 31 / 7 76-20 99
> E-Mail: david.worrall@iis.fraunhofer.de
> www: iis.fraunhofer.de
>          audiolabs-erlangen.de/research/emerging-audio-research
> ---
> Adjunct Senior Research Fellow
> School of Music, Australian National University
> david.worrall@anu.edu.au
>
> ------------------------------------------------------------------------------
> 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
>
>
> _____________________________________
> Prof. Dr. David Worrall
> International Audio Laboratories Erlangen
> Fraunhofer-Institut für Integrierte Schaltungen IIS
> Am Wolfsmantel 33
> 91058 Erlangen
> www: iis.fraunhofer.de
>          audiolabs-erlangen.de/research/emerging-audio-research
> ---
> Adjunct Senior Research Fellow
> School of Music, Australian National University
> david.worrall@anu.edu.au
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

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