While recovering from tooth surgery recently I started working on a little tutorial series, to do with my process as I try one more time to make a playable and editable timeline with visualization.
This might be a lifelong process so I’m not sure when I’ll end the tutorial series. But it would be good to know if this is even useful to people
I’m learning a whole lot doing this so I’m hopeful someone else might as well
Also of course if you find any mistakes or have suggestions that would be cool too.
I’m imagining that in the future there could pretty easily be a type of clip that contains a whole timeline, and there’s a lot of interesting potential for clock and randomness manipulation that I’ve just started getting into, and for how to record and deal with envelopes that I’ve not gotten into at all.
@prko That’s just a security warning, you can visit the “unsafe” blog. I’m sure it’s not a big deal.
@Eric_Sluyter That sounds like a productive and constructive way to spend your recovery time! I hope you’re feeling better now.
I’ve never particularly favored the SuperCollider qt GUI. In my live performances, my instruments are designed in such a way that the interfaces merely serve to monitor the program’s status—hardly ever requiring me to use the mouse. I’m mostly on controllers and forget about the code )))
However, my recent explorations with GUI have led me to a somewhat unexpected conclusion. There are much better ways to work with it. If you’re using sc/qt, I think a layer that automatically updates in response to state changes (a reactive layer) can improve things a lot (from my point of view, of course). Check it out about reactive programming and immediate GUI. Specially reactive layer, it’s not so hard to adapt to sc/qt/
I just thought about it reading your last paragraph:
@prko thanks for the heads up. I had to update my SSL certificate which had expired.
@smoge thanks for these concepts. I lately am into using GUI to augment what ‘user code’ can do more easily, sometimes a mouse is the most expressive way of doing something and I think arranging in a timeline is a very good example of this…
I agree. I just think the default model in sc/qt is too troublesome, and sort of the contrary of this idea. They start with a fixed model. Very soon you will need a layer just to get things organized (model-view-control), or try more dynamic models like reactive and immediate. Specially for that kind of thing
This looks very promising. There’s some overlap with my ScTimeline quark (but yours offers much more graphical options - so I find it very promising!).
I have used my own timeline more than once and found a few things useful (which may, or may not, provide some inspiration for further extensions of your timeline)
e in approach I guess)
schedule based on start_time until duration has passed
schedule based on start_time and end_time
schedule based on start_time and lasting for no_of_events
schedule based on start_beat, stop_beat
schedule based on start_beat and lasting for no_of_events
time is absolute time (no tempoclock taken into account); beat is following tempoclock changes
Further it has some basic support for start playing in the middle of the timeline and generate a plot which can be shown standalone, or can be embedded in a Layout (nothing interactive though).
Thanks @shiihs and @julian I’ll take a look at sc-timeline and clothesline quarks for inspiration at least.
My thinking about different clocks for timing events (i.e. one that is time based and one that is beat based) is that if timelines can be embedded into each other they can all have different clocks. But since for me the point of an editable visualization is to line things up with each other I think a single timeline instance should use one timing system.
I also am interested in the possibility of an event with indeterminate end time; I want to make sure that the determinism works first though!
And @smoge re code - gui continuum, I think for me the ideal scenario would be to evaluate the code that creates the timeline and then changes made to the timeline would immediately be reflected in the code, which could then of course be decoupled from the gui. The more realistic version I think at least for my abilities is that every bit of code (i.e. patterns, routines, synths, etc) is editable within the gui and then the whole thing could be exported back to a scd if desired. I’m also trying not to force any more structure on the user than necessary, i.e. no server node order or method of loading resources is dictated, so ideally everything that could be evaluated interactively is also sequenceable (even if it’s just a small part of a larger project)
