[hhr 13-aug-2018]

Integration of Perspectives / Paradigms

We are 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'm contemplating ading 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 23-jan-2018]

Object History | Multi-User Collaboration

[hhr 08-aug-2018] Except for our 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, we have 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. We 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?

[hhr 23-jan-2018]

Identity of Objects | What is an Object Copy?

[hhr 08-aug-2018] This is a very interesting topic. At first sight, we 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` - we could place the contents of the graph variable in the new graph variable, and put the same entries in the attribute map. But if we edit and replace the contents of the graph variable, original and copy would diverge. For the attribute map, we would probably want to distinguish between variables as well. For example, we could assume there is a `StringObj.Var` for the name, and we 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.

Open Research Questions

[hhr 03-apr-2018]

Tracing Granularity

We're 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 job yields a lot of transactions, which we 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 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 Ob[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.

[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 doesn't 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, we added `Ex` which is the type of immutable expression "UGens" or "Graph Elements", that can then be interfaced to `Expr` is necessary. Now we can write expression structures as part of an immutable expression graph, using another internal 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" we 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, an Mllt does not have a visual control for running processes yet.

[hhr 10-oct-2018]

An again in patterns. We have `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.