Interval Algebra and Event Scheduling?

[smoge]

Continuing the discussion from Different note durations not in sync:

Jumping off from a conversation on syncing events, I’ve been wondering if anyone here has dabbled with applying Interval Algebra for event scheduling, either in SuperCollider or elsewhere. I’m curious about your experiences and any insights about it.

In SuperCollider, event timing is intricately managed through patterns. This neat setup keeps our event timings tight, arranging when and for how long each event plays. They can be extended with synchronization across different sequences or voices (earlier discussions), although not a trivial case in this system.

In SC, generating Non-Real-Time (NRT) scores or using constraint-based rules in real-time, exploring different concepts of time is not as developed as Patterns.

Something I think about sometimes is how a pattern-based approach to timing is conceptually different from the qualitative relationships between time intervals, which is a less precise and focus on a more intuitive logic.

Imagine a scenario involving three distinct musical events—A, B, and C—each with unique temporal relationships:

• Event A serves as the reference event, spreading throughout a bar.

• Event B begins after the start of Event A and ends before Event A’s termination, illustrating A during B relationship.

• Event C begins towards the end of Event B and concludes concurrently with Event A, representing an interplay where B overlaps C and simultaneously, C finishes A.

This is where something like Allen’s Interval Algebra could be relevant (at least as a reference), considering events “from the other side”. It’s like examining the whole story of how events “meet,” overlap, or follow each other.

Basic relations look like this:

More interesting than the relations between two events, would be a model of a network of intervals ( an IntervalGraph). It could calculate or adapt the timing of events to meet the determined relationships, where each event relates with the others. This could be a tool for analysis, or rules for generating events.

References:

• Allen’s Interval Algebra
• Allen, James F. “Maintaining knowledge about temporal intervals”

[scztt]

Of course implementing these concepts at an API level is relative straightforward, and would be clearly useful (the OSequence quark can do some of these things, and could implement the rest of them very easily).

But I think what you’re pointing to is probably something more like a constraint system, where you specify sets of relations between events (constraints) and then generate a solution that satisfies all the constraints. This could be a super valuable project, and probably something that could be musically very interesting as well.

FWIW I do a bit of stuff along these lines with the pattern/event system - but it’s only currently possible by setting a very high \latency, and then doing things like using a negative \lag parameter to schedule things “back in time”. So e.g. you can do an “A finishes B” where the end is at time=10 by having both events play at time=10, and then setting \lag, { 0.0 - ~sustain.value } for A and B (e.g. move them back in time by their duration so that they both end at time=10.

The high latency trick has some side-effects that make it hard to work with, so I don’t really do this often, but it allows some very cool things - for example, playing several long events of different durations, and synchronizing the peak of their envelopes to the same time.

[smoge]

@scztt

But I think what you’re pointing to is probably something more like a constraint system, where you specify sets of relations between events (constraints) and then generate a solution that satisfies all the constraints. This could be a super valuable project, and probably something that could be musically very interesting as well.

Thank you

Yes, that’s the idea. It will be a sort of constraint system.

One curious thing is that list comprehensions are implemented in SC as Routines: Comprehension -> [Event]. (LC in SC is a Routine, and can even be lazy evaluated.)

A naive implementation of a function that generates an IntervalGraph could go the other way around, building it with a list comprehension.

generateGraph :: [Event] -> IntervalGraph
generateGraph events =
  let findRelations e = [(e, e', rel) | e' <- events, e /= e', Just rel <- [determineRelationship (snd $ eventInterval e) (snd $ eventInterval e')]]
      eventInterval (Event _ interval) = interval
  in concatMap findRelations events  

The algorithm described in the article is very clever, with some binary operations that I suppose are much more efficient. Later, I will take a better look at it…

@scztt

The high latency trick has some side-effects that make it hard to work with, so I don’t really do this often, but it allows some very cool things - for example, playing several long events of different durations, and synchronizing the peak of their envelopes to the same time.

This kind of thing is pretty interesting, especially in real-time. Would it be possible to avoid latency with some trick imposing some logic on the streams?

[amindfv]

I haven’t done anything like this in sclang, but with Vivid I’ve done lots of fun Supercollider experiments with PTM.

It seems like it might be similar to what you’re looking for.

A few years ago I played some livecode sets using only basic PTM operations.

[cian]

This is the kind of stuff where you really want a logic programming language. Look in to MiniKanren, or MicroKanren - which are two embeddable logic programming languages (a bit like prolog) that probably exist for your favourite programming language (unless it’s SuperCollider, in which case I don’t think it does).

[cian]

Incidentally Paul Hudak wrote an implementation in Haskell of many of his ideas (sadly uncompleted by his death - but one of his students has extended it) applied to music… I believe there’s a book as well.