| Newsgroups |
gmane.comp.audio.supercollider.user |
| Message-ID |
<[email protected]> |
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/