Re: Class library translation to Python

It may be worth considering PyPy for this project?
I believe it's possible to do a green thread implementation in PyPy that is
a much closer match to how SuperCollider Routines/Threads work (though I
think you'll be stuck doing the lowest level scheduling bits in C++
regardless). Also, the PyPy garbage collector is a better candidate for
timing-sensitive use cases like patterns than the regular Python GC.
Supposedly the max pause times are in the low hundreds of milliseconds -
not fantastic, but okay enough to run the normal pattern use-cases. I think
the GC is much more configurable, so there may be ways to optimized this
for SC as well.

PyPy is build on RPython - a JIT compilation / language-building tool? -
which people have used to implement versions of e.g. Ruby and Smalltalk. It
would be possible - (with a lot of work :) ) - to use RPython to interpret
SuperCollider source directly, and call back and forth between Python and
SuperCollider code. In my mind, RPython or Graalvm are probably the two
most likely paths we have of rescuing the SuperCollider language from being
unmaintained in the long-long term.

- S

On Sat, Aug 1, 2020 at 3:57 AM <[email protected]> wrote:

>
>
> El vie., 31 jul. 2020 a las 21:31, Lucas Samaruga (<
> [email protected]>) escribió:
>
>> Hi Christof
>>
>>> > 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.
>>
>
> For the sake of clarity, note that I get this far with patterns the
> SuperCollider way:
>
> ```
> from sc3.all import *
>
> s.boot()
>
> @synthdef
> def ping(freq=440, amp=0.05):
>     sig = SinOsc(freq) * amp
>     env = EnvGen.kr(Env.perc(0.2), done_action=Done.FREE_SELF)
>     Out(0, (sig * env).dup())
>
> p = Pbind({
>     'instrument': 'ping',
>     'freq': Pseq([440, Pseq([880, 1100], repeats=2), 770], repeats=5),
>     'amp': 0.01,
>     'dur': 0.2
> })
>
> # p.play()
> ```
> I will not discard that, but do feel that the implementation of patterns
> could be different in a more affordable way, especially when things get
> complicated regarding resource management.
>
>