Like this:

./csound test.csd -odac 2> >(nc -u 127.0.0.1 10000)

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 24 Nov 2017, at 20:49, Victor Lazzarini  wrote:
> 
> You might be able to pipe stdout via netcat if you need it.
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
> On 24 Nov 2017, at 20:39, Hlöðver Sigurðsson  wrote:
> 
>> Good to know, thanks!
>> 
>> On 24 November 2017 at 21:34, Victor Lazzarini  wrote:
>> Csound doesn’t send them via UDP. The only thing it can send at the moment is channel data.
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>> On 24 Nov 2017, at 20:24, Hlöðver Sigurðsson  wrote:
>> 
>>> Short question thereof,
>>> I'm trying to get the stdout/stderr messages from a csound instance via UDP. Is csound sending these messages to the udp client, or maybe I'm doing something wrong in my emacs network process because I don't seem to be getting any messages, only able send them.
>>

Nice, I'm working on reimplementing the csound repl in my emacs package. I'd like to offer the possibility of connecting client to csound udp server as well as spawning csound instance and connect to it automatically. So where the csound process is external to emacs is when I'd want to get the stdout sent over the udp. I'd see this as a user guide to pipe to netcat, but I would also coin the suggestion of implicitly send this data over udp as supercollider server does. Personally I don't see myself using this much, but this opens up the possibility of networked music where print statements would be for example seen by all clients (as it would with the piping method).

On 25 November 2017 at 12:25, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Like this:

./csound test.csd -odac 2> >(nc -u 127.0.0.1 10000)

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 24 Nov 2017, at 20:49, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>
> You might be able to pipe stdout via netcat if you need it.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
> On 24 Nov 2017, at 20:39, Hlöðver Sigurðsson <hlolli@GMAIL.COM> wrote:
>
>> Good to know, thanks!
>>
>> On 24 November 2017 at 21:34, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>> Csound doesn’t send them via UDP. The only thing it can send at the moment is channel data.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> On 24 Nov 2017, at 20:24, Hlöðver Sigurðsson <hlolli@GMAIL.COM> wrote:
>>
>>> Short question thereof,
>>> I'm trying to get the stdout/stderr messages from a csound instance via UDP. Is csound sending these messages to the udp client, or maybe I'm doing something wrong in my emacs network process because I don't seem to be getting any messages, only able send them.
>>>
>>> Best,
>>> Hlöðver
>>

actually, this can be done independently of the server. I’ll see about it.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 25 Nov 2017, at 13:04, Hlöðver Sigurðsson  wrote:
> 
> It would be a nice end-user experience, yes. The details of it I don't know what would make most sense. To print both on server and client or just client. I'd vote for both but open for ideas, just to throw my idea out there :)
> 
> On 25 November 2017 at 14:01, Victor Lazzarini  wrote:
> So you’d like the UDP server to send all console messages itself to a given address?
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
> On 25 Nov 2017, at 12:48, Hlöðver Sigurðsson  wrote:
> 
>> Nice, I'm working on reimplementing the csound repl in my emacs package. I'd like to offer the possibility of connecting client to csound udp server as well as spawning csound instance and connect to it automatically. So where the csound process is external to emacs is when I'd want to get the stdout sent over the udp. I'd see this as a user guide to pipe to netcat, but I would also coin the suggestion of implicitly send this data over udp as supercollider server does. Personally I don't see myself using this much, but this opens up the possibility of networked music where print statements would be for example seen by all clients (as it would with the piping method).
>> 
>> On 25 November 2017 at 12:25, Victor Lazzarini  wrote:
>> Like this:
>> 
>> ./csound test.csd -odac 2> >(nc -u 127.0.0.1 10000)
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>> > On 24 Nov 2017, at 20:49, Victor Lazzarini  wrote:
>> >
>> > You might be able to pipe stdout via netcat if you need it.
>> >
>> > Victor Lazzarini
>> > Dean of Arts, Celtic Studies, and Philosophy
>> > Maynooth University
>> > Ireland
>> >
>> > On 24 Nov 2017, at 20:39, Hlöðver Sigurðsson  wrote:
>> >
>> >> Good to know, thanks!
>> >>
>> >> On 24 November 2017 at 21:34, Victor Lazzarini  wrote:
>> >> Csound doesn’t send them via UDP. The only thing it can send at the moment is channel data.
>> >>
>> >> Victor Lazzarini
>> >> Dean of Arts, Celtic Studies, and Philosophy
>> >> Maynooth University
>> >> Ireland
>> >>
>> >> On 24 Nov 2017, at 20:24, Hlöðver Sigurðsson  wrote:
>> >>
>> >>> Short question thereof,
>> >>> I'm trying to get the stdout/stderr messages from a csound instance via UDP. Is csound sending these messages to the udp client, or maybe I'm doing something wrong in my emacs network process because I don't seem to be getting any messages, only able send them.
>> >>>
>> >>> Best,
>> >>> Hlöðver
>> >>
>> 
>> 
> 

Done now in git: 

1) Two new command-line options
--udp-console=address:port   redirects console to a remote address:port
--udp-mirror-console=address:port  mirr


========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 25 Nov 2017, at 13:58, Victor Lazzarini  wrote:
> 
> actually, this can be done independently of the server. I’ll see about it.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 25 Nov 2017, at 13:04, Hlöðver Sigurðsson  wrote:
>> 
>> It would be a nice end-user experience, yes. The details of it I don't know what would make most sense. To print both on server and client or just client. I'd vote for both but open for ideas, just to throw my idea out there :)
>> 
>> On 25 November 2017 at 14:01, Victor Lazzarini  wrote:
>> So you’d like the UDP server to send all console messages itself to a given address?
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>> On 25 Nov 2017, at 12:48, Hlöðver Sigurðsson  wrote:
>> 
>>> Nice, I'm working on reimplementing the csound repl in my emacs package. I'd like to offer the possibility of connecting client to csound udp server as well as spawning csound instance and connect to it automatically. So where the csound process is external to emacs is when I'd want to get the stdout sent over the udp. I'd see this as a user guide to pipe to netcat, but I would also coin the suggestion of implicitly send this data over udp as supercollider server does. Personally I don't see myself using this much, but this opens up the possibility of networked music where print statements would be for example seen by all clients (as it would with the piping method).
>>> 
>>> On 25 November 2017 at 12:25, Victor Lazzarini  wrote:
>>> Like this:
>>> 
>>> ./csound test.csd -odac 2> >(nc -u 127.0.0.1 10000)
>>> 
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 24 Nov 2017, at 20:49, Victor Lazzarini  wrote:
>>>> 
>>>> You might be able to pipe stdout via netcat if you need it.
>>>> 
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>> On 24 Nov 2017, at 20:39, Hlöðver Sigurðsson  wrote:
>>>> 
>>>>> Good to know, thanks!
>>>>> 
>>>>> On 24 November 2017 at 21:34, Victor Lazzarini  wrote:
>>>>> Csound doesn’t send them via UDP. The only thing it can send at the moment is channel data.
>>>>> 
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>> On 24 Nov 2017, at 20:24, Hlöðver Sigurðsson  wrote:
>>>>> 
>>>>>> Short question thereof,
>>>>>> I'm trying to get the stdout/stderr messages from a csound instance via UDP. Is csound sending these messages to the udp client, or maybe I'm doing something wrong in my emacs network process because I don't seem to be getting any messages, only able send them.
>>>>>> 
>>>>>> Best,
>>>>>> Hlöðver
>>>>> 
>>> 
>>> 
>> 

Done now in git: 

1) Two new command-line options
--udp-console=address:port   redirects console to a remote address:port
--udp-mirror-console=address:port  mirrors the console to a remote address:port

2) API functions to start/top console redirection/mirroring to UDP

/**
   * Turns on the transmission of console messages to UDP on address addr
   * port port. If mirror is one, the messages will continue to be
   * sent to the usual destination (see csoundSetMessaggeCallback())
   * as well as to UDP.
   * returns CSOUND_SUCCESS or CSOUND_ERROR if the UDP transmission
   * could not be set up.
   */
  PUBLIC int csoundUDPConsole(CSOUND *csound, const char *addr,
			      int port, int mirror);

  /**
   * Stop transmitting console messages via UDP
   */
  PUBLIC void csoundStopUDPConsole(CSOUND *csound);


========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 25 Nov 2017, at 13:58, Victor Lazzarini  wrote:
> 
> actually, this can be done independently of the server. I’ll see about it.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 25 Nov 2017, at 13:04, Hlöðver Sigurðsson  wrote:
>> 
>> It would be a nice end-user experience, yes. The details of it I don't know what would make most sense. To print both on server and client or just client. I'd vote for both but open for ideas, just to throw my idea out there :)
>> 
>> On 25 November 2017 at 14:01, Victor Lazzarini  wrote:
>> So you’d like the UDP server to send all console messages itself to a given address?
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>> On 25 Nov 2017, at 12:48, Hlöðver Sigurðsson  wrote:
>> 
>>> Nice, I'm working on reimplementing the csound repl in my emacs package. I'd like to offer the possibility of connecting client to csound udp server as well as spawning csound instance and connect to it automatically. So where the csound process is external to emacs is when I'd want to get the stdout sent over the udp. I'd see this as a user guide to pipe to netcat, but I would also coin the suggestion of implicitly send this data over udp as supercollider server does. Personally I don't see myself using this much, but this opens up the possibility of networked music where print statements would be for example seen by all clients (as it would with the piping method).
>>> 
>>> On 25 November 2017 at 12:25, Victor Lazzarini  wrote:
>>> Like this:
>>> 
>>> ./csound test.csd -odac 2> >(nc -u 127.0.0.1 10000)
>>> 
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 24 Nov 2017, at 20:49, Victor Lazzarini  wrote:
>>>> 
>>>> You might be able to pipe stdout via netcat if you need it.
>>>> 
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>> On 24 Nov 2017, at 20:39, Hlöðver Sigurðsson  wrote:
>>>> 
>>>>> Good to know, thanks!
>>>>> 
>>>>> On 24 November 2017 at 21:34, Victor Lazzarini  wrote:
>>>>> Csound doesn’t send them via UDP. The only thing it can send at the moment is channel data.
>>>>> 
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>> On 24 Nov 2017, at 20:24, Hlöðver Sigurðsson  wrote:
>>>>> 
>>>>>> Short question thereof,
>>>>>> I'm trying to get the stdout/stderr messages from a csound instance via UDP. Is csound sending these messages to the udp client, or maybe I'm doing something wrong in my emacs network process because I don't seem to be getting any messages, only able send them.
>>>>>> 
>>>>>> Bes

They won’t do anything else, they are just console redirection, nothing in particular to do with the server or anything else. You still need to give
other flags as required. The messages you copied just look like you are not sending legal orchestras to Csound.

Try

csound —port=10000 —udp-console=127.0.0.1:10001

then 

nc -ul 127.0.0.1 10001

to get the console

and 

nc -u 127.0.0.1 10000 

to send in code.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 1 Dec 2017, at 19:38, Hlöðver Sigurðsson  wrote:
> 
> Too busy and sick last days, but now I've tested it a bit, and --udp-mirror-console is acting strange, printing endlessly error messages (see below),
> neither --udp-console nor --udp-mirror-console ignite "scorless operation", with the difference that --udo-mirror-console will complain that no orchestra
> was given but --udp-console will not make such complaints. I'm not receiving the terminal messages when I do start with a provided .csd file,
> but I'm going to double check with node.js in case the emacs network senitel is just wrongly configured, post again in a bit...
> 
> 
> error: syntax error, unexpected T_IDENT  (token "untyped") line 5:
> >>>Unexpected untyped <<<
> Unexpected untyped word Unexpected when expecting a variable
> Parsing failed due to invalid input!
> Stopping on parser failure
> 
> error: syntax error, unexpected T_IDENT  (token "failed") line 5:
> >>>Parsing failed <<<
> Unexpected untyped word Parsing when expecting a variable
> Parsing failed due to invalid input!
> Stopping on parser failure
> 
> error: syntax error, unexpected T_IDENT  (token "on") line 5:
> >>>Stopping on <<<
> Unexpected untyped word Stopping when expecting a variable
> Parsing failed due to invalid input!
> Stopping on parser failure
> 
> error: syntax error, unexpected T_IDENT  (token "error") line 6:
> >>>syntax error <<<
> Unexpected untyped word syntax when expecting a variable
> Parsing failed due to invalid input!
> Stopping on parser failure
> 
> error: syntax error, unexpected T_OPCODE  (token "line") line 5:
> >>> line <<<
> Parsing failed due to invalid input!
> Stopping on parser failure
> 
> error: syntax error, unexpected T_IDENT  (token "error") line 6:
> >>>syntax error <<<
> Unexpected untyped word syntax when expecting a variable
> Parsing failed due to invalid input!
> Stopping on parser failure
> 
> error: syntax error, unexpected T_OPCODE  (token "line") line 5:
> >>> line <<<
> Parsing failed due to invalid input!
> Stopping on parser failure
> 
> error: syntax error, unexpected S_BITSHIFT_LEFT  (token "<<") line 5:
> >>> << <<<
> Parsing failed due to invalid input!
> Stopping on parser failure
> 
> error: syntax error, unexpected T_IDENT  (token "failed") line 5:
> >>>Parsing failed <<<
> Unexpected untyped word Parsing when expecting a variable
> Parsing failed due to invalid input!
> Stopping on parser failure
> 
> 
> On 25 November 2017 at 22:16, Hlöðver Sigurðsson  wrote:
> That was quick, nice!
> 
> On my way to a birthday party. test this tomorrow.
> 
> On 25 November 2017 at 21:22, Victor Lazzarini  wrote:
> Done now in git:
> 
> 1) Two new command-line options
> --udp-console=address:port   redirects console to a remote address:port
> --udp-mirror-console=address:port  mirrors the console to a remote address:port
> 
> 2) API functions to start/top console redirection/mirroring to UDP
> 
> /**
>    * Turns on the transmission of console messages to UDP on address addr
>    * port port. If mirror is one, the messages will continue to be
>    * sent to the usual destination (see csoundSetMessaggeCallback())
>    * as well as to UDP.
>    * returns CSOUND_SUCCESS or CSOUND_ERROR if the UDP transmission
>    * could not be set up.
>    */
>   PUBLIC int csoundUDPConsole(CSOUND *csound, const char *addr,
>                               int port, int mirror);
> 
>   /**
>    * Stop transmitting console messages via UDP
>    */
>   PUBLIC void csoundStopUDPConsole(CSOUND *csound);
> 
> 
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
> 
> > On 25 Nov 2017, at 13:58, Victor Lazzarini  wrote:
> >
> > actually, this can be done independently of the server. I’ll see about it.
> > ========================
> > Prof. Victor Lazzarini
> > Dean of Arts, Celtic Studies, and Philosophy,
> > Maynooth University,
> > Maynooth, Co Kildare, Ireland
> > Tel: 00 353 7086936
> > Fax: 00 353 1 7086952
> >
> >> On 25 Nov 2017, at 13:04, Hlöðver Sigurðsson  wrote:
> >>
> >> It would be a nice end-user experience, yes. The details of it I don't know what would make most sense. To print both on server and client or just client. I'd vote for both but open for ideas, just to throw my idea out there :)
> >>
> >> On 25 November 2017 at 14:01, Victor Lazzarini  wrote:
> >> So you’d like the UDP server to send all console messages itself to a given address?
> >>
> >> Victor Lazzarini
> >> Dean of Arts, Celtic Studies, and Philosophy
> >> Maynooth University
> >> Ireland
> >>
> >> On 25 Nov 2017, at 12:48, Hlöðver Sigurðsson  wrote:
> >>
> >>> Nice, I'm working on reimplementing the csound repl in my emacs package. I'd like to offer the possibility of connecting client to csound udp server as well as spawning csound instance and connect to it automatically. So where the csound process is external to emacs is when I'd want to get the stdout sent over the udp. I'd see this as a user guide to pipe to netcat, but I would also coin the suggestion of implicitly send this data over udp as supercollider server does. Personally I don't see myself using this much, but this opens up the possibility of networked music where print statements would be for example seen by all clients (as it would with the piping method).
> >>>
> >>> On 25 November 2017 at 12:25, Victor Lazzarini  wrote:
> >>> Like this:
> >>>
> >>> ./csound test.csd -odac 2> >(nc -u 127.0.0.1 10000)
> >>>
> >>> ========================
> >>> Prof. Victor Lazzarini
> >>> Dean of Arts, Celtic Studies, and Philosophy,
> >>> Maynooth University,
> >>> Maynooth, Co Kildare, Ireland
> >>> Tel: 00 353 7086936
> >>> Fax: 00 353 1 7086952
> >>>
> >>>> On 24 Nov 2017, at 20:49, Victor Lazzarini  wrote:
> >>>>
> >>>> You might be able to pipe stdout via netcat if you need it.
> >>>>
> >>>> Victor Lazzarini
> >>>> Dean of Arts, Celtic Studies, and Philosophy
> >>>> Maynooth University
> >>>> Ireland
> >>>>
> >>>> On 24 Nov 2017, at 20:39, Hlöðver Sigurðsson  wrote:
> >>>>
> >>>>> Good to know, thanks!
> >>>>>
> >>>>> On 24 November 2017 at 21:34, Victor Lazzarini  wrote:
> >>>>> Csound doesn’t send them via UDP. The only thing it can send at the moment is channel data.
> >>>>>
> >>>>> Victor Lazzarini
> >>>>> Dean of Arts, Celtic Studies, and Philosophy
> >>>>> Maynooth University
> >>>>> Ireland
> >>>>>
> >>>>> On 24 Nov 2017, at 20:24, Hlöðver Sigurðsson  wrote:
> >>>>>
> >>>>>> Short question thereof,
> >>>>>> I'm trying to get the stdout/stderr messages from a csound instance via UDP. Is csound sending these messages to the udp client, or maybe I'm doing something wrong in my emacs network process because I don't seem to be getting any messages, only able send them.
> >>>>>>
> >>>>>> Best,
> >>>>>> Hlöðver
> >>>>>
> >>>

Good. The two things are completely independent. Users can set the console to a remote location even
if they are not running the server.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 1 Dec 2017, at 20:07, Hlöðver Sigurðsson  wrote:
> 
> ahh not bad, I thought the server would become duplex, send/receive on same port. This works on netcat, so I should have everything I need to proceed.
> This may be a better solution for csound front-end developers actually, not sure if parallel, I'm developing Clojurescript repl with duplex socket server, and in non-blocking node land, this can be very painful at times.
> Let know if I bump into problems!
> 
> On 1 December 2017 at 20:46, Victor Lazzarini  wrote:
> They won’t do anything else, they are just console redirection, nothing in particular to do with the server or anything else. You still need to give
> other flags as required. The messages you copied just look like you are not sending legal orchestras to Csound.
> 
> Try
> 
> csound —port=10000 —udp-console=127.0.0.1:10001
> 
> then
> 
> nc -ul 127.0.0.1 10001
> 
> to get the console
> 
> and
> 
> nc -u 127.0.0.1 10000
> 
> to send in code.
> 
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
> 
> > On 1 Dec 2017, at 19:38, Hlöðver Sigurðsson  wrote:
> >
> > Too busy and sick last days, but now I've tested it a bit, and --udp-mirror-console is acting strange, printing endlessly error messages (see below),
> > neither --udp-console nor --udp-mirror-console ignite "scorless operation", with the difference that --udo-mirror-console will complain that no orchestra
> > was given but --udp-console will not make such complaints. I'm not receiving the terminal messages when I do start with a provided .csd file,
> > but I'm going to double check with node.js in case the emacs network senitel is just wrongly configured, post again in a bit...
> >
> >
> > error: syntax error, unexpected T_IDENT  (token "untyped") line 5:
> > >>>Unexpected untyped <<<
> > Unexpected untyped word Unexpected when expecting a variable
> > Parsing failed due to invalid input!
> > Stopping on parser failure
> >
> > error: syntax error, unexpected T_IDENT  (token "failed") line 5:
> > >>>Parsing failed <<<
> > Unexpected untyped word Parsing when expecting a variable
> > Parsing failed due to invalid input!
> > Stopping on parser failure
> >
> > error: syntax error, unexpected T_IDENT  (token "on") line 5:
> > >>>Stopping on <<<
> > Unexpected untyped word Stopping when expecting a variable
> > Parsing failed due to invalid input!
> > Stopping on parser failure
> >
> > error: syntax error, unexpected T_IDENT  (token "error") line 6:
> > >>>syntax error <<<
> > Unexpected untyped word syntax when expecting a variable
> > Parsing failed due to invalid input!
> > Stopping on parser failure
> >
> > error: syntax error, unexpected T_OPCODE  (token "line") line 5:
> > >>> line <<<
> > Parsing failed due to invalid input!
> > Stopping on parser failure
> >
> > error: syntax error, unexpected T_IDENT  (token "error") line 6:
> > >>>syntax error <<<
> > Unexpected untyped word syntax when expecting a variable
> > Parsing failed due to invalid input!
> > Stopping on parser failure
> >
> > error: syntax error, unexpected T_OPCODE  (token "line") line 5:
> > >>> line <<<
> > Parsing failed due to invalid input!
> > Stopping on parser failure
> >
> > error: syntax error, unexpected S_BITSHIFT_LEFT  (token "<<") line 5:
> > >>> << <<<
> > Parsing failed due to invalid input!
> > Stopping on parser failure
> >
> > error: syntax error, unexpected T_IDENT  (token "failed") line 5:
> > >>>Parsing failed <<<
> > Unexpected untyped word Parsing when expecting a variable
> > Parsing failed due to invalid input!
> > Stopping on parser failure
> >
> >
> > On 25 November 2017 at 22:16, Hlöðver Sigurðsson  wrote:
> > That was quick, nice!
> >
> > On my way to a birthday party. test this tomorrow.
> >
> > On 25 November 2017 at 21:22, Victor Lazzarini  wrote:
> > Done now in git:
> >
> > 1) Two new command-line options
> > --udp-console=address:port   redirects console to a remote address:port
> > --udp-mirror-console=address:port  mirrors the console to a remote address:port
> >
> > 2) API functions to start/top console redirection/mirroring to UDP
> >
> > /**
> >    * Turns on the transmission of console messages to UDP on address addr
> >    * port port. If mirror is one, the messages will continue to be
> >    * sent to the usual destination (see csoundSetMessaggeCallback())
> >    * as well as to UDP.
> >    * returns CSOUND_SUCCESS or CSOUND_ERROR if the UDP transmission
> >    * could not be set up.
> >    */
> >   PUBLIC int csoundUDPConsole(CSOUND *csound, const char *addr,
> >                               int port, int mirror);
> >
> >   /**
> >    * Stop transmitting console messages via UDP
> >    */
> >   PUBLIC void csoundStopUDPConsole(CSOUND *csound);
> >
> >
> > ========================
> > Prof. Victor Lazzarini
> > Dean of Arts, Celtic Studies, and Philosophy,
> > Maynooth University,
> > Maynooth, Co Kildare, Ireland
> > Tel: 00 353 7086936
> > Fax: 00 353 1 7086952
> >
> > > On 25 Nov 2017, at 13:58, Victor Lazzarini  wrote:
> > >
> > > actually, this can be done independently of the server. I’ll see about it.
> > > ========================
> > > Prof. Victor Lazzarini
> > > Dean of Arts, Celtic Studies, and Philosophy,
> > > Maynooth University,
> > > Maynooth, Co Kildare, Ireland
> > > Tel: 00 353 7086936
> > > Fax: 00 353 1 7086952
> > >
> > >> On 25 Nov 2017, at 13:04, Hlöðver Sigurðsson  wrote:
> > >>
> > >> It would be a nice end-user experience, yes. The details of it I don't know what would make most sense. To print both on server and client or just client. I'd vote for both but open for ideas, just to throw my idea out there :)
> > >>
> > >> On 25 November 2017 at 14:01, Victor Lazzarini  wrote:
> > >> So you’d like the UDP server to send all console messages itself to a given address?
> > >>
> > >> Victor Lazzarini
> > >> Dean of Arts, Celtic Studies, and Philosophy
> > >> Maynooth University
> > >> Ireland
> > >>
> > >> On 25 Nov 2017, at 12:48, Hlöðver Sigurðsson  wrote:
> > >>
> > >>> Nice, I'm working on reimplementing the csound repl in my emacs package. I'd like to offer the possibility of connecting client to csound udp server as well as spawning csound instance and connect to it automatically. So where the csound process is external to emacs is when I'd want to get the stdout sent over the udp. I'd see this as a user guide to pipe to netcat, but I would also coin the suggestion of implicitly send this data over udp as supercollider server does. Personally I don't see myself using this much, but this opens up the possibility of networked music where print statements would be for example seen by all clients (as it would with the piping method).
> > >>>
> > >>> On 25 November 2017 at 12:25, Victor Lazzarini  wrote:
> > >>> Like this:
> > >>>
> > >>> ./csound test.csd -odac 2> >(nc -u 127.0.0.1 10000)
> > >>>
> > >>> ========================
> > >>> Prof. Victor Lazzarini
> > >>> Dean of Arts, Celtic Studies, and Philosophy,
> > >>> Maynooth University,
> > >>> Maynooth, Co Kildare, Ireland
> > >>> Tel: 00 353 7086936
> > >>> Fax: 00 353 1 7086952
> > >>>
> > >>>> On 24 Nov 2017, at 20:49, Victor Lazzarini  wrote:
> > >>>>
> > >>>> You might be able to pipe stdout via netcat if you need it.
> > >>>>
> > >>>> Victor Lazzarini
> > >>>> Dean of Arts, Celtic Studies, and Philosophy
> > >>>> Maynooth University
> > >>>> Ireland
> > >>>>
> > >>>> On 24 Nov 2017, at 20:39, Hlöðver Sigurðsson  wrote:
> > >>>>
> > >>>>> Good to know, thanks!
> > >>>>>
> > >>>>> On 24 November 2017 at 21:34, Victor Lazzarini  wrote:
> > >>>>> Csound doesn’t send them via UDP. The only thing it can send at the moment is channel data.
> > >>>>>
> > >>>>> Victor Lazzarini
> > >>>>> Dean of Arts, Celtic Studies, and Philosophy
> > >>>>> Maynooth University
> > >>>>> Ireland
> > >>>>>
> > >>>>> On 24 Nov 2017, at 20:24, Hlöðver Sigurðsson  wrote:
> > >>>>>
> > >>>>>> Short question thereof,
> > >>>>>> I'm trying to get the stdout/stderr messages from a csound instance via UDP. Is csound sending these messages to the udp client, or maybe I'm doing something wrong in my emacs network process because I don't seem to be getting any messages, only able send them.
> > >>>>>>
> > >>>>>> Best,
> > >>>>>> Hlöðver
> > >>>>>
> > >>>
> > >>>
> > >>
> > >
> >

Well there’s not much I can do, since I am relying on csound message callbacks, and just implementing
sending the data over UDP. Whatever comes from the csound messaging system goes over to UDP,
I am not adding any characters (I don’t think). I’ll have a look anyway.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 2 Dec 2017, at 00:10, Hlöðver Sigurðsson  wrote:
> 
> Hi Victor, can you compare if you get the following outcome:
> 
> 1. rtevent timestamps are newlined, example:
> 
> sample rate overrides: esr = 44100.0000, ekr = 344.5312, ksmps = 128
> graphics suppressed, ascii substituted
> 0dBFS level = 1.0
> orch now loaded
> audio buffered in 2048 sample-frame blocks
> UDP server started on port 6000 
> ALSA: -b 2048 not allowed on this device; using 1365 instead
> ALSA output: total buffer size: 4096, period size: 1365 
> writing 4096 sample blks of 64-bit floats to dac 
> SECTION 1:
> WARNING: 
> Buffer underrun in real-time audio output
> 
> ;; Evaluated: instr 1
>   rtevent:	   T 14.074 TT 14.074 M:
>   0.00000
>   0.00000
> 
> 
> 2. Sending tables with string parameters via score events
> So I'm sending this table
> f 3 0 16384 "wave" 1 14 0
> trough the udp it's
> "$f 3 0 16384 \"wave\" 1 14 0"
> I get
> 
>   rtevent:	   T  7.944 TT  7.944 M:
> 
> 
> csound command: Segmentation fault  0.79999
>   0.79999
> 
> ftable 3:
> UDP server on port 6000 stopped
> inactive allocs returned to freespace
> end of score.		   overall amps:
>   0.79999
>   0.79999
> 	   overall samples out of range:
>         0
>         0
> 0 errors in performance
> 
> On 1 December 2017 at 21:22, Victor Lazzarini  wrote:
> Good. The two things are completely independent. Users can set the console to a remote location even
> if they are not running the server.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
> 
> > On 1 Dec 2017, at 20:07, Hlöðver Sigurðsson  wrote:
> >
> > ahh not bad, I thought the server would become duplex, send/receive on same port. This works on netcat, so I should have everything I need to proceed.
> > This may be a better solution for csound front-end developers actually, not sure if parallel, I'm developing Clojurescript repl with duplex socket server, and in non-blocking node land, this can be very painful at times.
> > Let know if I bump into problems!
> >
> > On 1 December 2017 at 20:46, Victor Lazzarini  wrote:
> > They won’t do anything else, they are just console redirection, nothing in particular to do with the server or anything else. You still need to give
> > other flags as required. The messages you copied just look like you are not sending legal orchestras to Csound.
> >
> > Try
> >
> > csound —port=10000 —udp-console=127.0.0.1:10001
> >
> > then
> >
> > nc -ul 127.0.0.1 10001
> >
> > to get the console
> >
> > and
> >
> > nc -u 127.0.0.1 10000
> >
> > to send in code.
> >
> > ========================
> > Prof. Victor Lazzarini
> > Dean of Arts, Celtic Studies, and Philosophy,
> > Maynooth University,
> > Maynooth, Co Kildare, Ireland
> > Tel: 00 353 7086936
> > Fax: 00 353 1 7086952
> >
> > > On 1 Dec 2017, at 19:38, Hlöðver Sigurðsson  wrote:
> > >
> > > Too busy and sick last days, but now I've tested it a bit, and --udp-mirror-console is acting strange, printing endlessly error messages (see below),
> > > neither --udp-console nor --udp-mirror-console ignite "scorless operation", with the difference that --udo-mirror-console will complain that no orchestra
> > > was given but --udp-console will not make such complaints. I'm not receiving the terminal messages when I do start with a provided .csd file,
> > > but I'm going to double check with node.js in case the emacs network senitel is just wrongly configured, post again in a bit...
> > >
> > >
> > > error: syntax error, unexpected T_IDENT  (token "untyped") line 5:
> > > >>>Unexpected untyped <<<
> > > Unexpected untyped word Unexpected when expecting a variable
> > > Parsing failed due to invalid input!
> > > Stopping on parser failure
> > >
> > > error: syntax error, unexpected T_IDENT  (token "failed") line 5:
> > > >>>Parsing failed <<<
> > > Unexpected untyped word Parsing when expecting a variable
> > > Parsing failed due to invalid input!
> > > Stopping on parser failure
> > >
> > > error: syntax error, unexpected T_IDENT  (token "on") line 5:
> > > >>>Stopping on <<<
> > > Unexpected untyped word Stopping when expecting a variable
> > > Parsing failed due to invalid input!
> > > Stopping on parser failure
> > >
> > > error: syntax error, unexpected T_IDENT  (token "error") line 6:
> > > >>>syntax error <<<
> > > Unexpected untyped word syntax when expecting a variable
> > > Parsing failed due to invalid input!
> > > Stopping on parser failure
> > >
> > > error: syntax error, unexpected T_OPCODE  (token "line") line 5:
> > > >>> line <<<
> > > Parsing failed due to invalid input!
> > > Stopping on parser failure
> > >
> > > error: syntax error, unexpected T_IDENT  (token "error") line 6:
> > > >>>syntax error <<<
> > > Unexpected untyped word syntax when expecting a variable
> > > Parsing failed due to invalid input!
> > > Stopping on parser failure
> > >
> > > error: syntax error, unexpected T_OPCODE  (token "line") line 5:
> > > >>> line <<<
> > > Parsing failed due to invalid input!
> > > Stopping on parser failure
> > >
> > > error: syntax error, unexpected S_BITSHIFT_LEFT  (token "<<") line 5:
> > > >>> << <<<
> > > Parsing failed due to invalid input!
> > > Stopping on parser failure
> > >
> > > error: syntax error, unexpected T_IDENT  (token "failed") line 5:
> > > >>>Parsing failed <<<
> > > Unexpected untyped word Parsing when expecting a variable
> > > Parsing failed due to invalid input!
> > > Stopping on parser failure
> > >
> > >
> > > On 25 November 2017 at 22:16, Hlöðver Sigurðsson  wrote:
> > > That was quick, nice!
> > >
> > > On my way to a birthday party. test this tomorrow.
> > >
> > > On 25 November 2017 at 21:22, Victor Lazzarini  wrote:
> > > Done now in git:
> > >
> > > 1) Two new command-line options
> > > --udp-console=address:port   redirects console to a remote address:port
> > > --udp-mirror-console=address:port  mirrors the console to a remote address:port
> > >
> > > 2) API functions to start/top console redirection/mirroring to UDP
> > >
> > > /**
> > >    * Turns on the transmission of console messages to UDP on address addr
> > >    * port port. If mirror is one, the messages will continue to be
> > >    * sent to the usual destination (see csoundSetMessaggeCallback())
> > >    * as well as to UDP.
> > >    * returns CSOUND_SUCCESS or CSOUND_ERROR if the UDP transmission
> > >    * could not be set up.
> > >    */
> > >   PUBLIC int csoundUDPConsole(CSOUND *csound, const char *addr,
> > >                               int port, int mirror);
> > >
> > >   /**
> > >    * Stop transmitting console messages via UDP
> > >    */
> > >   PUBLIC void csoundStopUDPConsole(CSOUND *csound);
> > >
> > >
> > > ========================
> > > Prof. Victor Lazzarini
> > > Dean of Arts, Celtic Studies, and Philosophy,
> > > Maynooth University,
> > > Maynooth, Co Kildare, Ireland
> > > Tel: 00 353 7086936
> > > Fax: 00 353 1 7086952
> > >
> > > > On 25 Nov 2017, at 13:58, Victor Lazzarini  wrote:
> > > >
> > > > actually, this can be done independently of the server. I’ll see about it.
> > > > ========================
> > > > Prof. Victor Lazzarini
> > > > Dean of Arts, Celtic Studies, and Philosophy,
> > > > Maynooth University,
> > > > Maynooth, Co Kildare, Ireland
> > > > Tel: 00 353 7086936
> > > > Fax: 00 353 1 7086952
> > > >
> > > >> On 25 Nov 2017, at 13:04, Hlöðver Sigurðsson  wrote:
> > > >>
> > > >> It would be a nice end-user experience, yes. The details of it I don't know what would make most sense. To print both on server and client or just client. I'd vote for both but open for ideas, just to throw my idea out there :)
> > > >>
> > > >> On 25 November 2017 at 14:01, Victor Lazzarini  wrote:
> > > >> So you’d like the UDP server to send all console messages itself to a given address?
> > > >>
> > > >> Victor Lazzarini
> > > >> Dean of Arts, Celtic Studies, and Philosophy
> > > >> Maynooth University
> > > >> Ireland
> > > >>
> > > >> On 25 Nov 2017, at 12:48, Hlöðver Sigurðsson  wrote:
> > > >>
> > > >>> Nice, I'm working on reimplementing the csound repl in my emacs package. I'd like to offer the possibility of connecting client to csound udp server as well as spawning csound instance and connect to it automatically. So where the csound process is external to emacs is when I'd want to get the stdout sent over the udp. I'd see this as a user guide to pipe to netcat, but I would also coin the suggestion of implicitly send this data over udp as supercollider server does. Personally I don't see myself using this much, but this opens up the possibility of networked music where print statements would be for example seen by all clients (as it would with the piping method).
> > > >>>
> > > >>> On 25 November 2017 at 12:25, Victor Lazzarini  wrote:
> > > >>> Like this:
> > > >>>
> > > >>> ./csound test.csd -odac 2> >(nc -u 127.0.0.1 10000)
> > > >>>
> > > >>> ========================
> > > >>> Prof. Victor Lazzarini
> > > >>> Dean of Arts, Celtic Studies, and Philosophy,
> > > >>> Maynooth University,
> > > >>> Maynooth, Co Kildare, Ireland
> > > >>> Tel: 00 353 7086936
> > > >>> Fax: 00 353 1 7086952
> > > >>>
> > > >>>> On 24 Nov 2017, at 20:49, Victor Lazzarini  wrote:
> > > >>>>
> > > >>>> You might be able to pipe stdout via netcat if you need it.
> > > >>>>
> > > >>>> Victor Lazzarini
> > > >>>> Dean of Arts, Celtic Studies, and Philosophy
> > > >>>> Maynooth University
> > > >>>> Ireland
> > > >>>>
> > > >>>> On 24 Nov 2017, at 20:39, Hlöðver Sigurðsson  wrote:
> > > >>>>
> > > >>>>> Good to know, thanks!
> > > >>>>>
> > > >>>>> On 24 November 2017 at 21:34, Victor Lazzarini  wrote:
> > > >>>>> Csound doesn’t send them via UDP. The only thing it can send at the moment is channel data.
> > > >>>>>
> > > >>>>> Victor Lazzarini
> > > >>>>> Dean of Arts, Celtic Studies, and Philosophy
> > > >>>>> Maynooth University
> > > >>>>> Ireland
> > > >>>>>
> > > >>>>> On 24 Nov 2017, at 20:24, Hlöðver Sigurðsson  wrote:
> > > >>>>>
> > > >>>>>> Short question thereof,
> > > >>>>>> I'm trying to get the stdout/stderr messages from a csound instance via UDP. Is csound sending these messages to the udp client, or maybe I'm doing something wrong in my emacs network process because I don't seem to be getting any messages, only able send them.
> > > >>>>>>
> > > >>>>>> Best,
> > > >>>>>> Hlöðver
> > > >>>>>
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> > >
> > >
> >
> >
>