Re: Class library translation to Python
[email protected] Fri, 31 Jul 2020 21:31:26 -0300
| Newsgroups | gmane.comp.audio.supercollider.devel |
|---|---|
| Message-ID | <CAFu0fFfbC=TvVVsg_ObW-9ziTAJka9hB5H40BydtxRuMGwPp8Q@mail.gmail.com> |
Hi Christof El vie., 31 jul. 2020 a las 11:20, <[email protected]> escribió: > Hi, > > this sounds very interesting! How does it compare to the already > existing Python implementions > (https://supercollider.github.io/community/systems-interfacing-with-sc)? > Except for Supriya they are not very close to what I want or the idea I have for an alternative client. > I haven't tried any of them, but at least python-supercollider > (https://github.com/ideoforms/python-supercollider) and supriya > This one and FoxDot, for example, don't compile SynthDefs, the only one that does is Supriya and now sc3 with different approaches. > (https://github.com/josiah-wolf-oberholtzer/supriya) seem to be in > active development. > > > There are many undecided things yet, I'm trying a different approach > > for patterns now because event and event streams are less practical in > > Python. > What's the problem with Python coroutines? > https://docs.python.org/3/library/asyncio-task.html > The problem is that SuperCollider's concept of coroutines is different in essential aspects. SuperCollider's (co)routines are Python's generators with a special scheduling model. Asyncio coroutines wait on objects while SuperCollider's Routine reschedules constantly, it waits only on time not actions or states. Then there are Condition and FlowVar (currently broken in sc3) that implements what asyncio does by default. Also there is a problem with it having its own scheduler as mentioned in the previous email. Regards Lucas