Recording mode improvements for sequence editor

[unclewalter]

Is your feature request related to a problem? Please describe.
There are a couple of pain points I've found when using the recorder feature.

The first is needing manually add the record source for each one at a time. I have 50 variables available for recording and on my current project some have had to get added on the fly and extremely tedious. The cumulative time burn really adds up when you have other people waiting you in the room.

The second is the big one, the record arm is not really a record arm. So if I'm tracking to timecode for instance, say synced to another person's Pro Tools machine, we have to arm each parameter one at a time (because I can't just multi-select and arm), we hit play and get a take of the parameters I want to animate, then I have tell the pro tools op not to hit play so as not to overwrite what we just did while I got through and disarm every single parameter one at a time, then they can hit play so we see what we did. If we need to do another take, we're back into rec arming one at a time before I can do another take. So many times we've found ourselves overwriting data accidentally because of this because the process is quite error prone when you need to work quickly.

Finally, if a drop in on a record take somewhere, the first point it adds will sometimes ramp from the previous point rather than just recording the state in the time recording was happening. So for instance, if I recorded a take from 1:00 - 1:30 and the parameter had a point at 0:30 at 0.5, instead of going from 0.5 to the first value recorded at 1:00, it will ramp slowly from 0.5 at 0:30 to the first value recorded at 1:00, which is a very undesirable behaviour. The record take should only have an effect the time being recorded, not what happens in between. If I want that ramp, I can just delete one point. That should never happen by default.

Describe the solution you'd like
For the first item I think it would be great to have the default behaviour be to record the target value if it's unassigned.

For the record arm, in a more idiomatic sense, it should function only when a record button his enabled in the transport. The ideal would be, I have a record button in the transport, and the armed tracks are only recorded on playback when it's in record mode. Then when playback stops, it's no longer in record mode. Kinda like a how Pro Tools does it or how you can auto-disarm individual tracks parameters.

The ramp issue may be a bug. Today was a bit of a blur dealing with some pretty unhappy collaborators given the the above.

Additional context
In this project, we're using Chataigne to synchronise a whole bunch of sprite movements in Resolume that are pixel mapped to a bunch of custom fixtures around the space via OSC in sync with some sound design that is being worked on in Pro Tools. I'm puppeteering those movements and effect changes using a MIDI controller to build content.

Running Mac OS Sonoma 14.8.3 and Chataigne 1.10.0

[benkuper]

Hello, and thank you for your feedback.

1st feedback, i don't even understand it, but it seems you were not prepared to have to do 50 recordings. There are many ways to automate this process if you know you're gonna have to do it. "Default behaviour to record the target" > which target are you talking about ? your setup is unknown to people who will read this (i don't mean your artistic project, but the way you build your file)

Second point : yes, a main record button would be a nice addition.
In the meantime, you can definitely have one boolean custom variable controlling all 50 "arm" parameters at once, and even a midi controller switching it. or even pro tools feedback controlling this state so you really automate the thing. Again, this is what preparation is about. Chataigne doesn't "have it all" by default (i'm only one person making 99% of it), but it's always been designed to let users compensate as much as possible for what's missing.

The ramp problem : yes it is a bug. or just a "not perfect" recording when in bezier recording mode. You could also be in linear with a very low tolerance and have all the points recorded. You could also use the Parrot if you don't want to edit data but just spit out exactly what you recorded

So again, thank you for the feedback, and i'll kindly ignore the "unhappy collaborators" comment. If you discover on site that the tools you used are not doing what you need, then you just didn't spend enough time before to test and prepare (and/or change tool).
I have no problem saying that Chataigne has problems, but i'm not fond of reading stuff like "your software made my collaborators unhappy".

[calebwest-SS]

As Ben said, none of these are really bugs. I have dealt with all of these problems, with clever (I believe) setups and scripting, using the program for hundreds of animatronic axes with thousands of keys each, and set up a system so that the person programming the axes doesn't have to get into the layer settings at all, just a dashboard to select the layer and a couple buttons on a MIDI fader bank.
Chataigne is a framework, not a catch-all solution for every problem. It is up to you to build processes that work for you, and test them and understand the constraints that you will face "in the room" with the artists and collaborators looking over your shoulder. If you are finding it not working, feature requests are fine and great, but the combative nature is not likely to help your case.

I'm genuinely sorry you had a rough time of it, but like Ben said, testing workflows before you get in the room, and making or finding tools that do what you need are step 1 of finding success.

It sounds like I've done something very similar to what you're trying to do. Because of the nature of my work and my company, I unfortunately cannot share exactly specifics of my setup, but, speaking theoretically, here's how you could approach the problems above:

1. Make a custom variable as an enum that points to each of your possible mapped variables, set up a multiplex to map the variable to the recorder. Using custom variables, or if you can code, custom modules or scripting, as an intermediary layer is your friend here.

2. Auto-disarm is a thing that sounds like it will take much of the 'recording over' away. You can also play with the "Record Send Mode" parameter so that you see what you are programming live, rather than having to play it right back. I've also done wonderful things like an automatic arm when I touch a fader, and disarm when I release, on a per-axis basis. The motor fader tracks with the previously recorded data, and I can just jump in a tweak live.
   Also, like ben said, map all the record arms to one custom variable boolean, put it in a dashboard, or even just put all 50 layer arms in a single dashboard, so that you don't have to click back and forth all the time. I use dashboards all the time for things like this, where I find myself clicking back and forth all the time. It's tedious to set up the first time, but then you just have it.
   Example: I have a file with a bunch of network modules. Each one I have to change the network interface for each computer I move the file to. Made a dashboard that has all those specific things just in a line, and it takes a lot of pain away. You could kill your arming and input mapping

3. I would argue with Ben here, and say that the ramping you described is not a bug. That's exactly what I expect to happen, which is that the output holds its value, and moves to the next one. When I program by just manually adding points, that's just what I need. If you need it to stay where it was, then you need to start recording from that point, and jump up from there. You can script that if you want, or do it manually. If you need the two parts to be separated, then make two sequences.

There are people on the Discord, including myself, who can help you if you present these problems, and work with you to construct workflows. Github is not a productive place for ranting.

Like Ben said, Chataigne is by no means perfect. There is always room for improvement, and looking forward to version 2, I hope to be able to help develop and test the core software. But, the thing I like most about it is that with work, and testing, I can make it much closer to perfect for my own use cases. And if there's things that really need to be fixed in the software, the code is right there. Get in and fix it.

[unclewalter]

Okay. First of all, I'm sorry for the unhappy collaborators comment. That was out-of-line. It has been a week and I shouldn't have lashed out. For that, I do sincerely apologise. I really do appreciate what you do and the software. Chataigne has solved many problems for me. I didn't mean to come across as combative. Feedback I'm giving because I really want to see this software succeed because there's really not much out there like it and I want to be able to recommend it to other creatives who want to be able to venture into the world of deeper, more integrated, creative show control without needing to re-invent the wheel or constantly think like a software engineer in order to achieve their creative goal. As it is, it has already solved a lot of problems for me, and I want to see it do the same for others.

I do want to address the general note about being prepared. So I did have a file prepared with all the automations for the specific parameters I thought I'd need to capture. That was the 50 parameters I'd already prepared. I'd even set up arm and disarm automations for those as well as dashboards, the whole kit. It took a long time, but I did come in as prepared as I could.

The problem tends to be, especially during creative developments, is when people want to try stuff and add things or we discover that one approach isn't working aesthetically and we need to be able to pivot quickly, the ability to change and add new things to a setup is important. I had prepared a system in Chataigne and I tried to capture all the possible scenarios I might face with Resolume and the rest of the control system. But especially in these scenarios, people often throw curveballs or sometimes might find a particular approach needs to altered, which might involve a mass re-map or adding of new parameters. It's not the same problem as Calebs example with animatronic axes. They're defined because the thing is physically built. But with some things, making these kinds of changes on the fly is quite important. Being quickly responsive to change in a creative environment is absolutely essential for the tool to be artist-friendly.

There's a bit to address in your both your comments.

1st feedback, i don't even understand it, but it seems you were not prepared to have to do 50 recordings. There are many ways to automate this process if you know you're gonna have to do it. "Default behaviour to record the target" > which target are you talking about ? your setup is unknown to people who will read this (i don't mean your artistic project, but the way you build your file)

The setup had was that I have some custom variables mapped to Resolume OSC addresses, those variables are also controlled by MIDI CC. So I could change things live and see the result as I was doing it, that's fine. But then adding them to a sequence is a two process when I think, in a lot of cases, it probably doesn't need to be. That being adding a mapping to a variable and then adding the same variable mapping to the recorder feels redundant. Now I understand there are plenty of scenarios where it makes more sense for the record source to be different to the output of the mapping, but at the same time, having it blank by default, I don't think is necessary since it only has an effect when track is armed. So as a point of reducing friction, my suggestion is to have a default, which, of course, you can choose to override rather than it defaulting to blank.

Make a custom variable as an enum that points to each of your possible mapped variables, set up a multiplex to map the variable to the recorder. Using custom variables, or if you can code, custom modules or scripting, as an intermediary layer is your friend here.

This is not far off the approach I did take, but the added overhead of the indirection and when new things (especially multiple) need to be added, along with some of the sharp corners I mentioned, didn't really help in my case. But perhaps I need to go deeper into how that works. Some of the docs appear still appear to be WIP so maybe I need to spend some time in the Discord to get some more clarity on how some of this works.

I would argue with Ben here, and say that the ramping you described is not a bug. That's exactly what I expect to happen, which is that the output holds its value, and moves to the next one. When I program by just manually adding points, that's just what I need. If you need it to stay where it was, then you need to start recording from that point, and jump up from there. You can script that if you want, or do it manually. If you need the two parts to be separated, then make two sequences.

For your animatronic use case, the ramp makes total sense. Lest you end up with some very expensive noises coming out of your machinery from the sharp transition. One spicy way to check the kD of your PID loop suppose... But I don't think it's universally applicable. Perhaps, this behaviour needs to be an optional? What you're describing is definitely more work than necessary just to eliminate the issue of dropping in on a recording having unintended side effects in-between of the places that have been recorded. If I want a long ramp from the end of one recording drop in and beginning of another, it's far quicker to delete the corner transition point than it is to add one and have it at exactly the same level as the previous or running a recording between the points. In my case, that could be as long as 5 minutes.

In the meantime, you can definitely have one boolean custom variable controlling all 50 "arm" parameters at once, and even a midi controller switching it. or even pro tools feedback controlling this state so you really automate the thing. Again, this is what preparation is about. Chataigne doesn't "have it all" by default (i'm only one person making 99% of it), but it's always been designed to let users compensate as much as possible for what's missing.

Unfortunately that one boolean variable solution doesn't really address the problem. It's not that I need to arm and disarm everything at once. It's that I need to need to arm, say 5 or 10 parameters, record a take, then in a another pass, record another 5 or 10 parameters, then play back, step back and see the result without my hands on the tools, go back and cut the take again. Some of those parameters might not be next each other on the timeline or dashboard layout. Neither a boolean for every disarm nor the auto-disarm really address that problem as the former solution is too blunt, and the latter requires re-arming those parameters every new take, which increases the time taken between takes. So I have to build out automations for those groups parameters, assuming it will always be those groups being armed in disarmed together. But then, when new parameters get added to address a new creative need that emerges, with that comes all of that extra task overhead with every new take.

I understand Chataigne doesn't "have it all", it's not what I'm asking for. But what I am asking for is that the parts of the workflow, such as a record arm, which has very established conventions around how it works ever since the invention of the tape machine, to be consistent with those conventions. They exist that way for a reason. I know of no tape machine or DAW that records all armed tracks on playback without the user explicitly hitting record. And there absolutely no tape machine that operates that way. Even knowing that going in, which I did, this behaviour turned out to be a massive footgun when combined with timecode and the addition of parameters being added on the fly. What I ultimately did was a global disarm on my dashboard so if I needed to cut a new take right away, I could with all that needed armed. And then I could disarm for playback.

The bottom line is this: I should be clear. Chataigne, despite the issues, is still one of my favourite pieces of software. It is has solved many problems for me, which is why I am so passionate about improving it. But I think there are some points of friction that, if addressed, could seriously elevate this great piece of software to something that is far more artist-friendly. And that's ultimately what I want for the benefit of everyone who uses Chataigne. A lot of what has been offered here is great for people who think like developers. I write plenty of code solve unique problems on projects all the time and I enjoy writing code to do cool things. But I don't really enjoy doing so in service of wheel re-invention. Sometimes, I just need to think about the nail rather than the hammer, especially with creative work. Especially in situation where I need to be agile and I don't have the opportunity stop and write a script solve a new problem. It's why I use Chataigne in the first place so I don't need to write yet another Go app or NodeJS or OpenFrameworks thing, when I don't need to.

I apologise for the tone in how I raised the issues and I really do appreciate the work you do. I look forward to v2. Thanks for your responses.

[benkuper]

Thanks for your reply, it is much appreciated :)
Also i think your feedbacks are valuable and definitely ideas that would make the software even better. food for thoughts for V2 ! Also, hopefully more people onboard for collaborating on the core code, meaning more "end user with picky taste" features :)