-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce NodeProxies #313
Comments
Currently deep in reimplementing Supriya's internals, so a bit of a vague response... I'm not opposed to implementing something in the spirit JITlib, but I need to understand much more concretely what it's actually doing. Some of the behavior concerns treating various types of entities interchangeably (synths, patterns, functions) and providing means of seamlessly connecting and crossfading between them. Other parts of the behavior seem to be UX affordances for live coding: how can we allow users to type as little as possible in a live-coding situation to create maximum impact? An implementation in Supriya starts by teasing those two categories apart through a close reading of the code, with a couple principles in mind:
Basically, we have to implement what's under the hood, as verbose as it needs to be in order to be clear, before we think about whether we want user-level code to use context managers, or subscripting, or magically converting name bindings to JITlib operations. FWIW, my gut sense is that subscripting is the winner because it's the least implicit, assumes no global state, doesn't add magic or additional methods to SynthDefs or UGens, and will play the best with Python's typing tools. Supriya's never going to be as "pithy" as sclang; that's just not one of my guiding principles 😅 |
Yes, this is indeed just some of the behavior, which happened to be useful. It is a consequence of not having to decide in advance. One of the main things that may not be apparent immediately is being able to refactor temporal co-dependencies on the fly. It removes the classification of inputs and outputs, and before and after. Here is a paper that describes the core ideas: http://wertlos.org/~rohrhuber/articles/Algorithms_Today.pdf |
Thanks @telephon, that's very helpful 🤔 |
@capital-G Are you still interested in pursuing this? The big refactor just wrapped up in #323 (although documentation is still in progress), so new features are unblocked. |
Hey @josiah-wolf-oberholtzer, thanks for the reminder. Yes, I think NodeProxies would be a great addition to supriya as they are me my preferred "dialect" and it would be interesting what Python enables in regards of live coding (e.g. having dynamic classes, language server with inspection, network access and the whole ecosystem etc.). I mainly have 2 questions:
|
Cheers! |
It I were you, I'd try to implement the core ideas:
|
Let's talk through API design / implementation a little bit. Here's the example at the top of the original ProxySpace
And here's what I want this to look like in Python:
Yes, this is a little more verbose, but we're never going to be as concise as sclang. That's not one of my goals. I'll expand on the numbered points in the comments for my Python version.
We can talk about relaxing this restriction once the initial feature is done -
Lemme know if you have any questions! |
Is your feature request related to a problem? Please describe.
I enjoy the JITlib approach to sclang with Ndefs, Pdefs etc, so something like this is possible
I checked out supriya really quickly and I did not find anything like this immediately.
The basic idea is that you can not loose a handle to a running synth by overwriting a variable - instead by overwriting a variable you also overwrite/replace it on the server.
Describe the solution you'd like
I still don't have a concise idea how this could be best implemented, I see this issue more as design process or discussion.
I think we can change the idea of NodeProxies to be more pythonic, having the best of both worlds.
A quick Idea that came to my mind is by using a subscriptable class (of which one could have multiple or in a recursive/nested manner?), attaching each node as element of a class instead of having independent objects (like in the SC implementation).
I think all the necessary lifting could be done in the
__getitem__
and__setitem__
methods, albeit the (internal) wiring of Ndefs can be really tricky sometimes.An alternative could be looking at ProxySpace in SuperCollider.
The problem of a ProxySpace is that every function will be treated as a NodeProxy, so defining a function like
~myFunc = {"foo".postln}
results in an error as a String is not something used on the synth.Using Python I don't see a problem in this case.
One could use e.g. a context manager for proxyspace
Or maybe make a tabula rasa and create something pythonic from the ground up?
I would really enjoy contributing to this project - maybe we can have some discussion here how to implement this and then I can do a first draft? :)
Additional context
Kudos to the programming style!
The text was updated successfully, but these errors were encountered: