Re: [sc-dev] Main-recvOSCmessage different in 3.4 vs 3.5 [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [sc-dev] Main-recvOSCmessage different in 3.4 vs 3.5 To: "sc-dev@xxxxxxxxxxxxxxxx" Subject: Re: [sc-dev] Main-recvOSCmessage different in 3.4 vs 3.5 From: Scott Wilson Date: Sat, 31 Dec 2011 16:32:55 +0000 In-reply-to: List-id: SuperCollider developers mailing list References: Reply-to: sc-dev@xxxxxxxxxxxxxxxx Sender: owner-sc-dev@xxxxxxxxxxxxxxxx On 31 Dec 2011, at 16:17, felix wrote: There is actually a lot of code out there that does use recvOSCfunc directly. Most of it should be using OSCresponder or OSCresponderNode All of it is broken by this change. I don't think its reasonable to ask everybody to dig through years and years of files and change it just because the arg order got changed arbitrarily. random google search: http://strasheela.sourceforge.net/strasheela/examples/Realtime-Examples/Simple-Counterpoint.sc The situation I am doing is that I need to respond to all incoming messages regardless of the cmdName, and OSCresponder doesn't do that. Its for ServerLog which logs all responses from the server. Also I can't quite figure out why port was added at all. NetAddr is passed in and it has the port number ! Because there is a difference between sending port and receiving port. S. Instance of NetAddr { (143CF5F0, gc=50, fmt=00, flg=00, set=02) instance variables [4] addr : Integer 2130706433 port : Integer 57110 hostname : nil socket : nil } here's that strasheela example: // receiving and playback of Strasheela notes
thisProcess.recvOSCfunc = { arg time, addr, msg;
if ( addr.port != 57110, // ignore scsynth messages so the recvPort is entirely superflous, and breaks existing code. I think it was a simple mistake to add it and we should reverse that change. The number of people that would break by reversing it is, AFAICT very small compared to those being broken currently. .. http://soundcloud.com/crucialfelix http://github.com/crucialfelix . On Sat, Dec 31, 2011 at 4:10 PM, Scott Wilson wrote: On 31 Dec 2011, at 14:42, felix wrote: I suppose the question at this point is how many people actually use recvOSCfunc directly (probably not many), whether they have changed their code already, and whether it is more collective work for you to change the class lib and them to change their code, or for you to just adjust your code. To take advantage of recvPort everyone will have to make some changes in any case, and there will be some incompatibilities with 3.5 somewhere or other. Or course the proper solution to that would be a version sensitive Quarks system, but I'm flogging a dead–or at least long suffering–horse here, so I'll assume that's not coming in time to deal with your issue. As far as the arg order goes, I think the order passed to recvOSCfunc is dumb anyway, so I accept that putting recvPort last might be less dumb than respecting the 'logic' of the old order, which puts the one always needed arg last. So for myself I don't mind if you change it for the sake of backwards compatibility. If you want to change the order in recvOSCmessage as well (I suppose it's possible somebody is overriding this somewhere), then in addition to correcting it everywhere recvOSCfunc is used in Common, you will also need to alter the primitive. S. .. http://soundcloud.com/crucialfelix http://github.com/crucialfelix . References: [sc-dev] Main-recvOSCmessage different in 3.4 vs 3.5 From: felix Re: [sc-dev] Main-recvOSCmessage different in 3.4 vs 3.5 From: Scott Wilson Re: [sc-dev] Main-recvOSCmessage different in 3.4 vs 3.5 From: felix Prev by Date: Re: [sc-dev] Main-recvOSCmessage different in 3.4 vs 3.5 Next by Date: [sc-dev] SF.net SVN: quarks:[2134] splines Previous by thread: Re: [sc-dev] Main-recvOSCmessage different in 3.4 vs 3.5 Next by thread: [sc-dev] SF.net Git: supercollider branch, master, updated. b37ab78fe34e8bd9c2b4c43981ee63b6ad5bc586 Index(es): Date Thread
