Recording CC Values in an existing Midiclip in the Sessionview
I'm sorry, but I can't find what I'm looking for, maybe you can help me:
Using Ableton 9 on a PC with a Virus TI as Synth.
I want to record a Clip and afterwards record CC Value like LFO f.e. into that Clip. But it won't record the CC Value. I know I can record them afterwards when using the Arrangement view, but I don't manage to do this in the Clip. It only seems to work when doing at the same time, but unfortunately I need both hands for my Midikeyboard and would need another third one for the Controller.
Any solution? Am I just too stupid?
Thanks for your help!!
11 votes received1 vote
Is my question really dumb or am I seriously the only one asking this?
Maybe someone could please help me out here?
Help is much appreciated!!!!!3 years ago | 0 comments
1 vote received1 vote
no, i have the same question https://www.ableton.com/answers/virus-ti-and-in-clip-automation
and sorry for double post3 years ago | 0 comments
5 votes received1 vote
I have been combing through the net to find a solution, it says that one must simply record the CC data, but for me this didn't work — no incoming signal on my MIDI channel when twisting the encoder. However, I happened to find out that the reason my channel doesn't even receive any MIDI-data despite the incoming port and channel being set to my controller, seems to be the fact that the encoder I wish to record is assigned to a parameter through Ableton's MIDI learn feature — this seems to block off the CC information so nothing comes in on the channel. Hence to record it, I must delete the assignment first and then reassign — this isn't what you want though, especially if the intervals are set differently from the default 0-1… I therefore used the MIDI Patchbay (OSX) and a virtual driver to send the info from my controller separately from Ableton Live: I set up the "IAC Code Dummy" (I use a Livid Code controller) in my Audio & MIDI Settings and then routed "all messages" from the Code to this driver in the MIDI Patchbay application. When I now create a MIDI channel in Ableton, set its input to the IAC Code Dummy, its monitor to "Auto", arm it and fire CC data at it, then I actually receive the messages and hereby am able to record it at the same time as controlling the my devices with the encoder. Basically the whole messages was duplicated, and received from a different MIDI port. I hope this helps you guys, it certainly helped me. This may be an annoying work-around but hey…
good luck!3 years ago | 0 comments
5 votes received1 vote
this seems to have been a job half done after all, because it does not work any longer…
CC data is blocked off once assigned so one cannot record those CC values into clips which control parameters in the session. This is of course useless because one wants to hear what one records and not speculate how the encoders must be twisted during recording.
The extended work-around is outlined in the pic file in this directory here:
again, I use Livid's Code and have set banks 2 & 3 to channels 2 & 3 respectively. These are my banks/channels for custom mappings. The modus operandi a la rigmarole here is as follows: (deep breath…)
1. Setup a new IAC Driver, or use the standard IAC (Mac; Windows users must use MIDI OX application methinks) — mine is called "IAC-Treiber (Code Dummy)"
2. in MIDI Patchbay (application downloadable for Mac from the directory above), route the MIDI port of your controller to the new IAC Driver, allowing the channel your controller sends data on — and route it to a MIDI channel not used by any of your applications (Ableton primarily). If you can use several channels on your controller, set up a routing for each one to the new one (or to different ones), in my case two routings:
a) Ch. 2>4, b) Ch. 3>4
3. Setup a MIDI track in Ableton with Input set to "Auto", receiving data from the IAC Driver (Dummy) on the (new) channel you've routed your messages to (in my case: Ch. 4). Again, if you use more than one channel on your controller (i.e. a different bank), set up one MIDI track with input according to routing in MIDI Patchbay (in my case: all on Ch. 4) — if you get lost in all these steps, keep an eye on the picture file, all routings, inputs, outputs, arming etc. can be seen there (note the subtitles to the patchbay routings also).
4. Set Monitor to "Auto", route the output to the respective MIDI channel your controller uses (in my case: 2 & 3) to imitate the controller by routing it to another IAC Driver (in my case: "IAC-Treiber (Quantization)" and arm the track (i.e. the bank/channel of your controller) you wish to record on. What happens now is that Ableton receives the CC Data which is assigned to a function within it, but on a different channel than the assignment (in my case: 4) — for this reason it actually accepts the data and is thus able to record it into a clip. When playing the clip, the data is now transmitted to the actual channel your controller sends on and hereby imitates the controller movement and consecutively controls the assigned function.
Your controller of course still works. If you have a controller with endless encoders (like the Livid Code) which updates the values and you perhaps experience lag issues with the LED-ring update (values jump with great latency and low rate and their movements can't be monitored well) — use the IAC Driver you route the messages to, from the MIDI channels in Ableton (in my case: "Quantization") and route it back to your controller via MIDI Patchbay (see screenshot). This updates all LED rings directly and it seems as if everything is linked superbly without any routing.
The downside, however, is that doing all MIDI learning, recording and playing back at once or in straight workflow is slightly undermined by the routing of the MIDI Patchbay — because all your controller messages are sent to a different channel as well (as it's now set up), Ableton either arbitrarily or due to some inextricable hierarchy may respond to the incoming messages in a way you don't want… it records the dummy channel and not the actual one from your controller. The only way I've found to avoid this is by deactivating the respective routing in MIDI Patchbay, or have active when making recordings only. Of course, MIDI Patchbay needs to be running for this process to work…
I certainly hope there is or could be a more straight forward way to handle this, if anyone knows how, please drop it here for everyone… I also am unaware of this process' CPU-challenge, when transmitting tons of MIDI data among different channels and ports I sometimes experience artefacts which are recorded into Audio tracks too, but there may be ways to solve this as well.
anyway, again: good luck. These tedious work ethics get me goat and I find it strenuous and detrimental to creativity — but watcha gon do.
Controller Ch. X —> Ableton (Parameter); CC as of now not recordable
Controller Ch. X —> IAC (Dummy) Ch. Y —> Ableton (MIDI Track) —> Clip; CC now recordable (armed Clip)
Ableton (MIDI Track) —> IAC (Quantization) Ch. X
IAC (Quantization) —> Ableton (Parameter); controller imitated and henceforth automatable from a clip
IAC (Quantization) —> Controller (LED Feedback); LEDs update according to automation in clip
PS: make sure you save these channel setups in an Ableton template song to be able to recall them directly, same goes for the MIDI Patchbay file: save & load it!3 years ago | 1 comment
You need to be logged in, have a Live license, and have a username set in your account to be able to answer questions.
Give us your feedback.