Quite a long time passed from my last words regarding Kairos, so let me update you about what’s going on.
The latest concepts and ideas I shared with you (at node and in the post) were mostly regarding a timeline tool that had this new feature of dynamic keyframes.
Obviously during summer development many things changed.
I’ve been in Berlin in august, for a development session dedicated to kairos.
Devvvvs were just great and fully supportive. together we dig into the software I had in mind, trying to abstract things and finding the strong principles to look for.
From the very beginning I realized that the software I had in mind wasn’t just a timeline.
Due to the fact that I urgently need the software for production, I changed plans and, instead of going for a timeline tool, I prioritized the development of another mode of kairos: the Matrix.
You can think at this Matrix mode as the Session View of ableton live. it’s basically the same thing.
Each parameter controlled with kairos is a column of the matrix (“channels” in ableton).
the rows represent some sort of “scenes”.
Each matrix cell contains a state (static or dynamic) of that parameter.
you can then click on a cell and trigger live its state, exactly like triggering the audio/midi clips in the ableton session view.
I decided to prioritize this Matrix mode because is the simplest way to define-design the state (scene/preset) of an entire parametric system. A preset is a row of the matrix, meaning a cell, empty or not, for each kairos parameter (column).
A timeline is already something more: it’s a way to organize over time different states (-scenes-presets) of a parameter.
In kairos the state of a parameter is define by a DataSource.
DataSources are the building blocks of your Kairos scene (eg. you may put DataSources into the Matrix cells).
A DataSource can be of different types:
It’s a static value for the parameter. It can be anything: a value, a spread of values, a color palette, etc…
Every data you can imagine which is static, stored in memory, not dynamically generated.
obviously there will be an editor to design each Static DataSource
Any State that is dynamically generated. eg:
- LFO (obvs in a spreadable fashion)
- Audio Analysis
- Kinect Data
- Particle System
Each Dynamic DataSource will have it’s own control UI, sort of inspektor, like the ctrl window of VST plugins (distort/reverb/…) in the sound editing softwares.
A DataSource can take another DataSource Output as input, manipulate it and return it transformed. These kind of DataSources can be called Filters. eg.
- Linear Filter
Containers are very interesting DataSources: thet take a set of DataSources as Input plus a Model, a set of settings (specific for every container) that tells the container how to handle the incoming DataSources.
If you abstract enough, you can basically see most of the features of an advanced software like Ableton Live as a collection of Containers:
let’s take the timeline.
timeline container takes a Model that describes the keyframes position and all their settings (interpolation, dynamic/static, …). Then it takes also a spread of DataSources which might be the Dynamic DataSources available in the system that will be assigned to some dynamic keyframes.
The timeline container then has some functionalities to handle these contents, like some interpolation functions.
It takes the incoming dynamic DataSources. dispatch them to the assigned dynamic keyframes, then apply the interpolation between the relevant keyframes in order to give the final sample value.
Conceiving the Timeline as a DataSource (Container) allows to use it anywhere in kairos as you would do with any other DataSource (static value, an LFO, a SoundAnalysis value,…). You can put it into a Cell of the matrix, or even in a keyframe of another timeline (in this case it would become a clip, that you could instantiate as many times as you like).
I’ve got already a list of Containers that I’ll develop in the next future:
- Sampler 1D (Timeline)
- Sampler 2D-3D-… (Delaunay Sampling)
- Distance Field 1D-2D-3d-… (distance based sampling)
- Switcher (like a multiFlipFlop)
By abstracting the software to this level it’s much easier to think at it in a modular way.
Another example is the matrix itself:
Each column can be seen as a Switcher Container in which you choose between different options (cells) to set the state of the parameter assigned to that column (multiFlipFlop behaviour that controls a Switch).
To achieve this kind of freedom, in which you are able to create DataSources, place them anywhere, enchain them, nest one into each other, and so on… a really simple, flexible but robust interface was needed.
@gregsn and @Elias did a great job in building a c# interface that we then implemented in vl.
This interface allows to patch some functionalities that are wrapped as Nodes, with Input and Outputs.
These nodes behave following a Pull model, like the nodes and patches in vvvv.
This means that if you don’t ask for their output value from bottom, they don’t get evaluated.
You are able to create DataSources on runtime, registering them into an engine, making them immediately available for other DataSources to be used.
Basically, this system makes the user a meta-patcher, able to create nodes and connect them in runtime without recompiling.
This is great. This is already in place.
Another aspect that I started to look at together with devvvvs is the UI.
I didn’t want to spend time in building a “static” UI for Kairos (Such a boooooring thing… hihihi), specially after focusing so much on modularization at all levels of the software.
Since the topic is very appealing for the vvvv/vl community in general, we set down at devvvvs place thinking to a nice way to achieve a good multi purpose modular UI library.
And @tonfilm kicked in, as you probably noticed from his post.
This is certainly a good opportunity for all of you to contribute to kairos development and, in general, to the development of a super cool and handy UI editor library.
I started creating some of the basic UI elements (like slider, Toggle/Push/Bang buttons, multiButtons, …) but we need to add many more.
You are welcome to partecipate!
So, at the end of this biblical post,
I’m sorry to disappoint those of you who were just waiting for a timeline tool in september. It simply won’t happen. :)
What is already happening it’s way more than a timeliner. it’s a flexible system that allows to manage realtime data in a nice new way.
Trust me, the wait is worth ;)
For all of you that offered support in development, I would love an hand on the UI part, as I said previously in the post. Let’s push it forward!