Hey,

I've been looking for a straightforward multitrack timeline tool that can send automation values, but I couldn't find anything that works for me. So, I created a little TCL app to do just that.

Currently, it's still a work in progress and I don't know if it is worth developing the idea further. I'm trying to figure out what values to send, especially when it comes to dealing with single points. I'm not entirely sure how useful it will be in the end, but I thought I'd share my progress in case anyone else is looking for something similar.

Send me your thoughts.

@flextUser Changing your mind about avoiding Tcl? It and Tk are pretty great for these quick little apps.

In pd we have arrays and data structures for doing this natively. Data structures where pretty much designed for doing just this sort of thing and more, the manual has a section on it. But I do see some worth in a standalone application which does just control curves and nothing else. What does it use for a clock?

@oid "Changing your mind about avoiding Tcl?" Haha, yes!
So for the clock I use [after], not very precise (?), like most of the performers I know
I know structures well, I've used them for some graphics like interactive bars for visualizing data from sensors.

@flextUser after is probably accurate enough for most uses of these sorts of control curves. If you made this into a gui plugin you could use plugin-dispatch to communicate between the plugin and patch to cut out the UDP and if you wanted you could also clock it from pd as well then and have local patch saving. There is a plugin on the iem git (probably in deken as well) called plugin-dispatch-receiver if memory serves which shows how to use this barely documented/known feature if you need it. While it seems a little round about for something you can do with arrays or data structures this way it has some advantages which would be a fair amount of work with those methods, like easy window resizing which resizes the curves to suit. Luapd is also an option, but is slower than pd abstractions or Tcl/Tk in my experience, shouldn't be a problem with the limited amount of redrawing which this would require, perhaps a brief lag on loading curves if you have a lot of tracks/points visible.

@flextUSer Neat! I see that you are using netreceive so it is really a standalone app? You could use OSC and make it a bit more compatible with other applications IMHO.

Also I am sure you are aware, but share for people searching for sequencer, trigger, timeline etc https://www.iannix.org/en/whatisiannix/

@EEight

It's a TCL script that can be run with Wish (found in Pd/bin). OSC would be overkill for this, but it's still an option. Yes, Iannix is great, it also saves its data in a text format, which is perfect for long-term archival of works.

@oid said:

plugin-dispatch

Thanks for the suggestions!
I was unable to locate the plugin-dispatch-receiver, though.

@flextUser My memory did not serve, it is post2receiver, not plugin-dispatch-receiver. But all you do is something like this in a patch or abstraction;

[plugin-dispatch <name-of-proc-to-run> <args to proc>(
|
[s pd]

So if we sent [plugin-dispatch plugin-proc $0receive( to [s pd] and had a proc like:

proc plugin-proc {arg} {
    set ::send-sym $arg
}

then you could send from tcl to a patch with pdsend "$::send-sym <msg>" and it would send msg to the appropriate receive in the patch which could be an abstraction that registers itself with your plugin and tells it which track to send, [multitime 2] would get track 2 or create track 2 if it does not exist and so on. You could also use [hcs/sys_gui] for sending from patch to the Tcl but my tendency is only to use it when I need its bang on complete feature.

@oid Excellent!
@EEight

BTW, I just created a public repo here:

github timeline