Re: Class library translation to Python
[email protected] Fri, 31 Jul 2020 21:12:27 -0300
| Newsgroups | gmane.comp.audio.supercollider.devel |
|---|---|
| Message-ID | <CAFu0fFfg-0iLWbqJ3HXAXGRd1xve5ZWikU3EGOgUk+Y1oKR_dQ@mail.gmail.com> |
Hi Josiah El vie., 31 jul. 2020 a las 11:29, <[email protected]> escribió: > Hi Lucas, > > Sounds like a good idea to me! I started a Python client some years ago > for many of the same reasons: > https://github.com/josiah-wolf-oberholtzer/supriya > I saw your project and have an eye on it, looks very good, I never went in deep on it though. I decided to start this one because I wanted something more close to the original library, especially regarding SynthDef and Routine and I saw it wasn't easy to map it the way I'd like. I always thought of sc3 as a translation. You might be able to borrow some useful pieces from it. I was able to > reimplement some of SC's pattern system via Python generators. > Thank you, yes, Python's concept generators are what really map to SuperCollider's Routine, however, with some differences in behaviour that I managed to match. Haven't saw your implementation but I will investigate when I have time. There are many things of the implementation I don't consider final in sc3. > It also supports SynthDef compilation, RT/NRT compatibility layers, tempo > clocks, > The sc3 implementation of Server (now with mods), OSC (formatting and function defs), SynthDef and UGen is a line by line translation matching very closely SuperCollider's behaviour, Clock, AbstractFunction interface, Routine (and logical time related to bundles and latency) are also line by line, but needed a bit more of adaptation (not much and it was due to its logic being distributed between c/c++ and sclang). and - more recently - asyncio-based implementations of server and OSC logic > so you can integrate it into Python's async ecosystem. Could be helpful, > although docs are lacking. > I discarded from the start the use of the asyncio coroutines because they create it's own control loop with low time resolution, I don't know if it's tweakable but seemed too much conflictive to adapt another library with a different model and I was afraid it will end up messing with SuperCollider's clocks and time. But I don't have the insights on that yet, will be worth to loot at what you say. I've noticed that IPython have some trouble with asyncio and printing to stdout from different threads. If you want to use continuous integration, I also figured out how to launch > scsynth in Travis-CI so you can build all pull requests there and test them > against a real SuperCollider server. > That would be great! I'm not yet in that stage, never uploaded the tests because I'm constantly breaking them by changing the interface, and I'm not very patient with them yet, and I'll do that with documentation (not working either). Regards Lucas