{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?

{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.