| Newsgroups |
gmane.comp.audio.supercollider.user |
| Message-ID |
<[email protected]> |
BTW, which language are you using for your custom client?
On 15.03.2021 03:25, [email protected] wrote:
>> My client is sending and listening on the same port (57110) as scsynth.
> Generally, only a single application can/should listen on a given port
> (on the same machine).
>
>> Is the implication that I need to provide code in sclang to accept my
>> osc requests and pass them to scsynth?
> No, just open a socket, bind it to any free port ("0" will let the OS
> pick one for you) and use that to send/receive messages to/from the
> Server. Scsynth remembers the source address of incoming OSC packets and
> uses it for sending replies.
>
> Christof
>
> On 15.03.2021 02:55, [email protected] wrote:
>> My client is sending and listening on the same port (57110) as
>> scsynth. This configuration works if scsynth is on a different
>> machine, but as you say, not if on the same machine. Is the
>> implication that I need to provide code in sclang to accept my osc
>> requests and pass them to scsynth? As a test, I tried sending
>> requests to 57120, but nothing seems to happen.
>>
>> On Sun, Mar 14, 2021, at 6:31 PM, [email protected] wrote:
>>> What's the port of your client? Note that it must be different from the
>>> port(s) used by the scsynth instance(s) (57110 by default). For
>>> example,
>>> sclang listens on 57120 by default.
>>>
>>> Christof
>>>
>>> On 14.03.2021 23:13, [email protected] wrote:
>>>> I've got what I suspect is a gap in my knowledge about either
>>>> socket programming or how SC works. I'm writing a somewhat special
>>>> purpose client since I'm a wind synth player and most midi software
>>>> is keyboard oriented. I started the project about the same time
>>>> that I'd updated my development machine to MacOS Big Sur which
>>>> wasn't initially supported by SC. No problem, I had a linux box
>>>> that I installed SC on and communicated across the local net and
>>>> everything worked fine. It turns out that that was a real piece of
>>>> luck from the point of view of making progress. Now that SC
>>>> supports Big Sur, I installed it on my development mac and thought
>>>> everything would just work like it did with a remote, but no such
>>>> luck.
>>>>
>>>> Simple OSC commands (i.e. commands that don't require a response
>>>> from SC) work fine, but for commands that respond like d_loadDir,
>>>> d_load, status, etc a weird thing happens. The command succeeds, SC
>>>> responds, but SC gets the response which is not a valid SC OSC
>>>> command, responds with a fail, which SC reads, and on and on
>>>> deadlocked sending fail messages and responding to itself.
>>>>
>>>> Here's what I mean from the log (I've enabled dumpOSC to print the
>>>> dialog):
>>>>
>>>> [ "/d_loadDir", "/music/supercollider/synthdefs" ] // my command
>>>> [ "/done", "/d_loadDir"
>>>> ] // SC initial
>>>> correct response
>>>> FAILURE IN SERVER: /done Command not found // SC reads the
>>>> response and fails it
>>>> [ "/fail", "/done", "Command not found" ] //
>>>> over and over
>>>> FAILURE IN SERVER: /fail Command not found
>>>> [ "/fail", "/fail", "Command not found" ]
>>>> FAILURE IN SERVER: /fail Command not found
>>>> ...
>>>>
>>>> Sorry if this is totally obvious. Like I said at the start, I
>>>> suspect I'm missing some key piece of the puzzle. What seems to be
>>>> happening is that SC is listening on 57110, but then responds on
>>>> the same port, but since it's listening to that port it accepts
>>>> it's own response as a new command. As I also mentioned, when SC is
>>>> running on a separate machine, it all works fine. How do other
>>>> clients deal with this? Obviously, for the purpose of developing my
>>>> client I can keep working with the remote, but ultimately I'd
>>>> prefer the client and SC to be on the same machine.
>>>>
>>>> Regards,
>>>> Bill
>>>>
>>>> _______________________________________________
>>>> sc-users mailing list
>>>>
>>>> info (subscription, etc.):
>>>> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
>>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>>> _______________________________________________
>>> sc-users mailing list
>>>
>>> info (subscription, etc.):
>>> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
>>>
>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>>>
>> _______________________________________________
>> sc-users mailing list
>>
>> info (subscription, etc.):
>> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.):
> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/