{RK, 04-sep-2017}
I am attaching a small SC document that illustrates the principle of "Electric Wind" as a little installation. I tend to use NodeProxy as a convenient way to dynamically alter processing chains, etc. (It's used in the attached file, but not in any dynamic way.)
Judging from the videos {HH: Mellite tutorials}, it strikes me that I might use Mellite timeline, etc to assemble fixed realizations of dynamic materials. So, it would be really helpful to see if a relatively seamless access to NodeProxy might be devised. I don't know how you implement the signal paths in Mellite so this might be a topic of discussion.
Then my approach might be to treat Patterns as providing real-time manipulation of materials given a fixed manipulation in Mellite. Or, perhaps the issue here is for me to understand more about ScalaCollider and work there.
{origin: email, keywords: [nodeproxy, dsp]}
{HHR, 11-jan-2018}
Talking about software environments and programming languages would be particularly interesting with Ron, who has a long history of engaging in these systems, having created a real-time computer music system Formula himself (with David P Anderson) in the 90s, and having influenced and designed parts of SuperCollider's pattern system. So I was very excited when Ron agreed to dive a bit into my own system Mellite, which is an environment built around a real-time sound synthesis system based on SuperCollider, albeit implemented in a different language (Scala). It would be an open-ended endeavor, because Mellite is considered experimental, with documentation trickling in but still rudimentary, with some features incomplete or buggy, etc.
The following is also an interesting tiny note that shows what happens when one idiosyncratic system is encountered by another user:
{RK, 07-sep-2017} "BTW: why is the track index significant and why not show its time position?"
This strangeness in Mellite results from the fact that the graphical views and editors are modelled on top of a generic object system, which in turn drew some inspiration from SuperCollider's SmallTalk inherited object inspectors, which are automatically generated GUIs from object properties. In SoundProcesses (the object system behind Mellite), an object is "configurable" through an attribute map, a key-value dictionary with keys being strings given by convention, and values being other objects. In the GUI, you can open the attribute map for any object, this is independent of the type of object. So in the timeline editor, when you select an object, you can view its attributes, which would include, for example, the object's name, perhaps its color if it was given, a sound file associated with a region, etc. The timeline itself is an object type, which associates time spans with objects. Anything beyond that is a "convention" of the GUI editor. Mellite's timeline editor introduces vertical positions and extents for object; this is not defined by the timeline object as such, but simply a convention of storing track-index and track-height in an object's attribute map. The time span, in contrast, is a key stored only in the timeline, not part of the positioned object, and therefore it does not appear in the attribute map. Obviously, a refined editor would provide an observer view for textual representation and editing of the time span.
{HHR, 11-jan-2018}
We were in a somehow symmetric situation. Although I know SuperCollider quite well, I have never really worked much with Patterns. So I had to start to understand their design; on the other hand, in this and the following conversation it was clear that Ron was trying to approach Mellite and understand what its design paradigms were, its decisions and limitations, and if and how one could go from SuperCollider to Mellite.