[Feature Request] mtr - mc.function for display and editing of event data
It would be super helpful to be able to create a binding of [mtr] and [mc.function], where [mc.function] acts as an editor for [mtr]- something like [jit.matrix] and [jit.cellblock], where changes in one object directly inform the other object about changes in the common data structure.
mc.function could visualise the event data of several tracks of [mtr] over time and should be able to modify them and also add new events or delete events.
At the moment it seems a very hard road to accomplish this by parsing the dump dict sending "xyc" -messages to [mc.function] and patching back from [mc.function] to the [mtr] with "addevent", "cleareventat", ....etc.
Details:
It should be possible to bind specific [mc.function] objects to specific [mtr] tracks.
wow, this is an excellent feature-request(and very well-written out, too).
+1 👍
I wouldn't hold my breath. Notice that mtr and function have different underlying data structures and represent different concepts. mtr keeps a set of discrete successive values (not only numbers!) and time intervals, function represents continuous multi-segment envelope. Converting between the two is possible to some extent, but to have one as an editor for the other – IDK...
In Touchdesigner keyframe automation of a parameter is a simple sequence of
a) Right-Click the parameter to automate
b) Choose an automation clip (you can have several clips, with different parameter and recording lengths)
c) Draw the automation curve.
While I try to port my projects to TouchDesigner I keep thinking about MAX potentials, but I just can’t develop the required narratives in my work without a keyframe editor https://cycling74.com/forums/editor-for-keyframe-animation .
Yes, [mtr] and [mc.function] are designed as different concepts but they share some common requirements and features and their combination as described above would yield a viable solution if implemented in MAX’ architecture - sure data types have to be restricted and the time format and interpolation features need consideration.
I can’t use MAX for Live for my project because Live consumes already 15%-30% of GPU (GeForce RTX2080) resources, so the Jitter machine and the audio machine have to be seperate computers. Also the automation curves in Live are quite clumsy and don’t allow an overlay view of several curves.
This is a concept study for a keyframe editor using [mc.function]. Drawback is that the frame rate drops if you record fast parameter changes. If efficiently implemented in MAX’ architecture similar to [mtr] and in combination with a @subscribemode like in [pattrstorage] or @bindto in [mtr] this would be a super helpful tool.
Note that mtr accepts a dictionary to set its track content, which is basically the same format as the dump output. So if you can mangle function's output into a dictionary that mtr likes, and vice versa, you would have an editor. JS would be useful for this conversion. I would avoid trying to do it with the individual event messages.
Hello David,
May I ask for some more support from Cycling'74 regarding the JS implementation? I am clearly not an expert with dictionaries and would need some example code for this and how to set points in mc.function via JS.
Also I hesitate to invest time on a JS implementation, because there are some important things unclear or maybe impossible with [mtr @bindto ] like e.g. its incompatibility to [pattrstorage @subscribemode 1] https://cycling74.com/forums/-sharing-looping-gestures-with-mtr/replies/1#reply-5fa1d534cf19d0282883484b which severely limits my use cases (>100 parameters in a patch)
and there are also bugs in [mtr] Max 8.1.8 .
Both of these bugs have been fixed for a forthcoming release. It's a pretty big ask to make a JS example. I do know there has been some work on JS interacting with mtr but I am not sure when it will be made publicly available. I will research the pattrstorage subscribemode issue.
Our basic sentiment is that what you're trying to do is worthwhile, but supporting it in a comprehensive way represents a major effort. We're in the very early stages of evaluating how we want to approach such a project. So at the very least we appreciate your trying to push the envelope here; it is having an influence on our long-term thinking.
Thank you, I really appreciate your response. Just for the sake of completeness. I first started with Ableton Live and I got stuck here https://cycling74.com/forums/set-keyframes-from-m4l-device - missing LOM functionality to edit automation curves in Live.
But from my experience with TouchDesigner (and to be clear, there are a lot of reasons I prefer to use Max) it is a significantly more fluid and creative working if you have a key frame editor inside the programming application and not to rely on Live or other programs for this.
[mtr] and [mc.function] ... their combination as described above would yield a viable solution if implemented in MAX’ architecture
I agree. This would already help a lot....
got stuck here https://cycling74.com/forums/set-keyframes-from-m4l-device - missing LOM functionality to edit automation curves in Live.
.... and in conjunction with a decent keyframe tool in Ableton Live it would be a comprehensive solution.
Maybe the attached JS code helps a little bit on your question how to access the dict, but I am not sure what is the best way to set a curve in mc.function within JS.
What remains a challenge to me is how to pass breakpoints to [mc.function]?
Thank you very much PUAKOALA for the JS code. I modified it in order to adapt [mtr] events to stepped curves in mc.function as a proof of concept. Adaption to data types and more tracks should not be a major problem, but the current patch truncates the list from js and I don't know a way without [zl.group].
Let's see if the new js mtr tutorials will help https://cycling74.com/tutorials/the-javascript-mtr-connection-part-1 .
Just a little summary , before I put this topic aside (too many obstacles).
a) Displaying [mtr] dict content in [mc.function] works.
b) Timing stability if using [mc.function] for playback instead of [mtr] not fully tested. Most probably [mtr] is suited better for playback of many tracks (e.g. 100 tracks which also requires at least 2 [mc.function] objects with 50 curves each).
c) [mtr] outputs events and currently does not offer interpolated output (like linear interpolation or curves).
d) [mtr] interface is not well designed for use with many tracks - e.g. 'touch' does not allow to specify track numbers like it is possible e.g. for 'mute'. So you have to connect patch cords to every track inlet for sending 'touch'. Same with 'cleareventat', 'deleteeventat', 'addevent'.
e) @bindto is currently not compatible with [pattrstorage @subscribemode], making it hard to use with large patches that rely on pattrstorage organisation
e) 'touch' functionality doesn't offer a mode to record to a track that contains no events (and so is not playing)
f) playhead logic of previously posted patch for display of time progress adapted to horizontal zoom settings appears quite fragile. 'cursor' from [mc.function] slows down performance dramatically.
g) mtr-dict handling and mc.function list handling quite complex if both directions are required (e.g. to delete, insert breakpoints in [mc.function] and pass changes to [mtr], requires [mc.function] mousereport logic and switches that send messages to specific [mtr] inlets or a list comparison algorithm or JSON.stringify headaches).
h) No concept for mutlislider data (lists with >64 values, [mc.function] restricted to 64 channels).
h) Continuative feature requests may include handling of automation curves in clips - so maybe it is a faster achievable goal to have a mtr-dict export via UDP to Ableton Live - which still is unclear how to accomplish, because of missing or not documented LOM-functionality.
just a rough sketch (probably buggy) regarding 'cleareventat', 'deleteeventat', 'addevent'
...this looks quite ugly, but I couldn't find something more elegant without using more objects like [mousestate].
Summary:
[mc.function] interface with respect to report of breakpoint modification is cumbersome
[mtr] interface is not well designed for use with many tracks - e.g. 'touch' does not allow to specify track numbers like it is possible e.g. for 'mute'. So you have to connect patch cords to every track inlet for sending 'touch'. Same with 'cleareventat', 'deleteeventat', 'addevent'.