{hhr, 13-aug-2018}

Integration of Perspectives / Paradigms

I am starting to grow multiple sub-systems which can only be rudimentarily interfaced. There is real-time sound synthesis (Proc), offline signal processing (FScape), pattern programs, widget/expression programs. And I am contemplating adding logic programming using, for example, the JaCoP constraints solver library as back-end. Naturally, there are boundaries between these things; for example, a logical problem needs a “universe” to post its constraints to, so there must be a level of containment or atomicity. On the other hand, it should be simple to move from a constraint variable to an expression or a pattern (perhaps iterating over the possible solutions).

{hhr, 08-aug-2018}

Identity of Objects | What is an Object Copy?

This is a very interesting topic. At first sight, one can distinguish between ‘shallow’ and ‘deep’ object copies, where a shallow copy would share any containing objects with the ‘original’. What what is a ‘containing object’? For example, a Proc—one could place the contents of the graph variable in the new graph variable, and put the same entries in the attribute map. But if one edits and replaces the contents of the graph variable, original and copy would diverge. For the attribute map, one would probably want to distinguish between variables as well. For example, one could assume there is a StringObj.Var for the name, and one could now either move the same variable to the copy, or allocate a fresh copy and place the contents of the original variable in the new variable, with the same effect that the objects would diverge as soon as a renaming is performed on either of them. But what if we wanted to precisely link the two objects in terms of their name? It seems a thorough solution must involve the user and their judgment what should be copied and what linked.

{hhr, 08-aug-2018}

Object History | Multi-User Collaboration

Except for my initial experiments with (Inde)terminus as part of the ZKM studio residency 2013, little work has continued with respect to the history preserving confluently persistent workspaces, and how they could feed back into the compositional process themselves. Obviously, one has to “flatten” the meta-level in some way to make this productive, i.e. produce a form of operational closure regarding the history of objects as possible inputs to the composition. One might want something like an Expr for the number of edits, the time stamps of the edits, and so forth.

A somewhat related issue is to open the system for collaborative editing, attaching some form of user-identifier to the transactions, and possibly allowing concurrent editing over a network?

Open Research Questions

{kind: title}

{hhr, 03-apr-2018}

Tracing Granularity

I am probably going to introduce some form of coarse registration of user interface elements, for example, editor settings which are persisted only if the editor closes.

Also, remember that in the sonification editor of SysSon, “dialing” a jog widget yields a lot of transactions, which one may actually want to collapse in fewer write operations.

So it seems we may want to think about an “eventually durable” model. Now patterns come into play, with perhaps a statefully-persisted stream object next to them. This might again want to have a dedicated granularity of writing to disk.

{hhr, 23-jan-2018}

Permeability of Systems

SP 3 is constructed around a system type S which can be, for example, in-memory or persisted to (stored on) disk in multiple ways. One problem of the current implementation is that movement between systems is difficult. For example, every system S has an in-memory fall-back S#I, but there is no simple way to cast an Obj[S#I] such that it can be integrated with a data structure on S, such as AuralAttribute[S].

In several occasions, it would be useful to construct ad-hoc objects Obj[S#I] and mix them with structures that rely on a “main” system transaction S#Tx.

On the other hand, the type system has no notion that two workspaces with the same system type constitute a boundary in terms of requiring object-copy when moving from one workspace to the other.

{kind: fragment, function: [brainstorming, documentation], keywords: [_, permeability, system, transaction, object]}

{hhr, 03-apr-2018}

Implementing wr_t_ng m_ch_n_

These things would be to consider:

  • stateful stream (pattern) as replacement for ‘motion’
  • we need an OSC actor object
  • consequently, a way to ‘activate’ objects irrespective of server boot status; i.e. a sort of ‘transport’ mechanism that does not rely on the obj → aural-obj translation.
  • we need distributed communication
  • probably also a mechanism to transmit / update workspaces across the network

Eventually, the possibility to control relays etc.

{hhr, 08-aug-2018}

This question returned in the implementation of the Widget abstraction which requires that we are capable of writing “expression programs”. Since early, SP has the Expr abstract to represent expressions, i.e. objects that evaluate to an immutable value such as a number, and these expressions can be composed using for example unary and binary expressions. From the point of view of constructing these composed expressions in Mellite, there was never a dedicated editor, and also it seemed the granularity was too fine—it does not make sense to treat each atom in an expression “structure” as its own separately stored and versioned object. Consequently, in SP 3.21, I added Ex which is the type of immutable expression “UGens” or “Graph Elements”, that can then be interfaced to Expr is necessary. Now one can write expression structures as part of an immutable expression graph, using another internal DSL.

{kind: fragment, function: [evolve, info, method], keywords: [_, implementation, widget, expression, DSL]}

{hhr, 08-aug-2018}

An interesting development will be “enforced” by Dotty/Scala 3, scheduled for 2020, as abstract type projections have been removed, and much stronger emphasis is on the support of path (value) dependent types.

{hhr, 08-aug-2018}

The same questions arose for Körper, where in “alpha” I implemented an OscNode object and a simple auto-start mechanism with predefined “runners” for the “activation” of these types of objects. SP 3.21 has an official interface for runners but only few are implemented for now, and Mllt does not have a visual control for running processes yet.

---

meta: true

author: hhr

function: [brainstorming, description, experiment]

keywords: [SoundProcesses, Mellite, software, apparatus]

---

{hhr, 10-oct-2018}

And again in patterns. One has expand[S] to produce a Stream[S], with the underlying idea that a stream can have persistent state. But in the regular case, we would want Stream[S#I]. On the other hand, we may need access to the “invoking” Pattern[S], for example to look at its attribute map. So we necessarily need to system parameters here if we want to handle all three cases.

{kind: fragment, function: [evolve, info], keywords: [_, patterns, stream]}