[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] call-backs, co-routines and inversion of control
- To: "sc-dev@xxxxxxxxxxxxxxxx" <sc-dev@xxxxxxxxxxxxxxxx>
- Subject: Re: [sc-dev] call-backs, co-routines and inversion of control
- From: Jonatan Liljedahl <lijon@xxxxxxxxxxxx>
- Date: Tue, 8 Jan 2013 10:52:39 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nDecLckEnMVsov4i8xG9aXHXMHOyy5kYi+MiT7Aybro=; b=VLf6wYZ8PYc0frr1T0eWDSva66zgRbFI33L3hhC0aU6TZQkDp5RpfHmfz/15GuJJwJ tUqufw3KYqDNS+86ODzEMkbGnYsN6gvgifqTrnfcSLV16w9ZNH72M0CymWUG/tupM4TK sKvgy/hf7VVIQcNJpBFvVyGKEAyU+lzlN9DthMZnZsk9cJUJCTLG32D75frxDPjSXPMa Ti+5oHXSFE4kJDUSUua3buZGfj0ImP13bo0W3LxgkUox2/1BWjThim5SboQ2lJ+BBKWS RN52oFc2uUHoDQHs4JhR4AfWZECsBREw0gBvaqyiBVg8ccx2JzO6e5zoSNVW7MGlfARu OpPw==
- In-reply-to: <9B4BB402-C236-4830-B5B4-0B08A40731BE@friendlyvirus.org>
- List-id: SuperCollider developers mailing list <sc-devel.create.ucsb.edu>
- References: <778221C9-492A-4DB9-BA09-EB1DEEAECB49@friendlyvirus.org> <50ABBC37.email@example.com> <A145DF2F-0446-498D-86EE-E5A8C9D7582E@bham.ac.uk> <1F4DC433-1998-48B1-BF7D-B139E2E6A88E@musikundmedien.net> <CALfiFhD_XXFG62jVvHE9D4wdKviZ8NMjXSdB1+7Sh8k+qfU5Jg@mail.gmail.com> <0D25C620-C6F3-4FA0-9386-F643B48B87E0@musikundmedien.net> <6970E904-41EB-4F4B-976F-7B8B25930B10@friendlyvirus.org> <2901865F-E435-4187-9EE8-88649F84CADA@musikundmedien.net> <CAFniQ7W4kKUsgmR1KwB+VL9O=LGB__wM2UgW=CP56QLB-9BhbQ@mail.gmail.com> <97E72E9E-6576-49D4-A51E-12C58EAA6B6F@musikundmedien.net> <CAFniQ7XbX_tuMVs7Oc1dKGy6aM8KotXYbY_3nPg=cfX3_XCJPQ@mail.gmail.com> <C3DC6B65-7432-4F81-97EB-DCDAF0D92EC8@musikundmedien.net> <79E883CF-EBAF-41BF-BC17-75146B15A206@friendlyvirus.org> <E3730DCA-1B98-42DF-AFA0-6FF6084D2436@musikundmedien.net> <E0FCBEE0-D9BF-4656-963C-5E3EA9E20045@musikundmedien.net> <1C65DD7F-62FC-4374-8F58-592533FC2880@friendlyvirus.org> <9F3E5205-3976-4A5D-946A-58BF3317E230@friendlyvirus.org> <A8AD02EE-FCB9-4891-B301-D5A8893346EE@musikundmedien.net> <9B4BB402-C236-4830-B5B4-0B08A40731BE@friendlyvirus.org>
- Reply-to: sc-dev@xxxxxxxxxxxxxxxx
- Sender: owner-sc-dev@xxxxxxxxxxxxxxxx
On Tue, Jan 8, 2013 at 12:59 AM, Miguel Negrao
> A 06/01/2013, às 22:37, Julian Rohrhuber escreveu:
>> I still have those commits sitting around which would arguably make a good first step for a later more thorough implementation of this behaviour. I'd like to either push it or throw it away, because later on it will become useless - any suggestions? It currently mainly lacks an appropriately differentiated latency implementation (but this is the case with the current s.bind, too, so it doesn't take anything away.
>> For reference, here is the patch.
> I think it would be a good idea to commit this, because it already allows to have completely automatic syncing for the end user. The only issue perhaps is that it will not keep the old behavior of the the bind method, since it will always sync on each async action, but from what I was told, all the async actions are run in sequence in the server anyway, so it doesn’t make much difference perhaps.
But wouldn't that make a difference in the sclang context? If s.bind
now always syncs at the end, and previously did not? One might want to
send a bundle, do some langside stuff while the server is working, and
only then wait on a sync.
I haven't studied the code and don't know exactly what changes here,
but if indeed the behavior of s.bind/makeBundle is changed in this
regard, then I really think you should put it in a topic branch. That
way we can test it more, experiment with it and develop it without
risk for introducing regressions in the master branch.
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml