"automation items"

[James HE]

By assigning the appropriate action in the action list, (and using a MIDI loopback) you can use a MIDI item with CC's as an "automation item". (upcoming 14 bit cc drawing makes this a lot sexier.)




on track 3, I am using ReacontrolMIDI instead of an item. on track 4, I set track 4 to be a slave of BOTH track 3 and track 1. (this is just to illustrate some potential d/VCA applications)


What the GIF is not showing is that I am sending the MIDI to a "hardware" out, and back in - to a "control" enabled device. ( I use MAPLE MIDI, but there are a lot of options here.)

It's not exactly elegant - you need to have the cc on the right channel and the right cc.
This can be routed by a plug in, which may be easier;
A MIDI router plugin with the alias; "Track 32 PAN" - for example

And also, assigning the cc's in the action list, is, well...

A lot of work needs to be done to figure out, and setup the CC's in the action list.

If anyone is interested in possibly using this, I'd love some input about how this list can be organized. If we can get together a mapping that makes sense, anyone can just load up the REAPER KeyMap file and have access to this. (along with some FX presets / chains)

I started with channel 2, cc 32 here for track one. I figure maybe channel 1 would be good for "selected track" actions - FX parameters, SEND levels, etc.

The 14bit cc's are 32-64, so we have plenty to play with over 16 channels. We can define Volume, Pan, Width. Also Mute and solo, but I'm not sure if these would be so useful.

Maybe...

channel 2 cc 32 - 64 for Volume Tracks 1-32
channel 3 cc 32 - 64 for Pan tracks 1-32
....
and so on


64 tracks would be sufficient, for me at least.



I can't exactly decide if this is worth the effort. What do ya' think?

[James HE]

almost forgot...

anyone know a way to manually edit a REAPER KeyMAp file to set these values?

wiggling 512 knobs with the mouse seems like no fun at all.

[James HE]

hmm... maybe you can put a FX on the item itself - which would route to the appropriate cc(s)?

[Win Conway]

Cool idea, but not automation items
Automation is envelope based and this is bar/step based no ?

For example
point 1 at 0
Point 2 at 1/127/whatever
IE a fade

Thats two points to create a fade using an envelope, not so with CC bars

Also sending out to a MIDI loopback adds latency that native automation does not

Personally i would stick to the DC offset audio item i came up with years ago, still by far and away the best (Least effort too) way to fake automation items

Like i said though cool idea

[Banned]

What we still really need is being able to use MIDI to control things internally, directly, without the need for clumsy conversion and routing.

Originally Posted by James HE

[...] The 14bit cc's are 32-64, so we have plenty to play with over 16 channels. We can define Volume, Pan, Width. Also Mute and solo, but I'm not sure if these would be so useful. [...]

Maybe...

channel 2 cc 32 - 64 for Volume Tracks 1-32
channel 3 cc 32 - 64 for Pan tracks 1-32
....
and so on [...].

To be slightly more precise: the 14bit cc's are CC# 0 to 31 PLUS 32 to 64, for a total of 32 CC# PAIRS per channel. So you'd need e.g.

channel 2 cc 0-31 + 32-64 for Volume Tracks 1-32
channel 3 cc 0-31 + 32-64 for Pan Tracks 1-32
...
and so on.

[James HE]

Originally Posted by gpunk_w

Cool idea, but not automation items
Automation is envelope based and this is bar/step based no ?

For example
point 1 at 0
Point 2 at 1/127/whatever
IE a fade

Thats two points to create a fade using an envelope, not so with CC bars

Also sending out to a MIDI loopback adds latency that native automation does not

Personally i would stick to the DC offset audio item i came up with years ago, still by far and away the best (Least effort too) way to fake automation items

Like i said though cool idea

I was noticing latency as well, but wasn't sure how much of it was just graphic - or the fact that my cc's were just 7 bit in this example.

Track 3 here, using ReaControl MIDI does look a lot smoother. Using that method is more interesting to me, as it creates a way for Track grouping to work with automation.

Will need to experiment a bit more here.

[Banned]

Originally Posted by James HE

I was noticing latency as well, but wasn't sure how much of it was just graphic - or the fact that my cc's were just 7 bit in this example. [...]

The external MIDI routing does not only add latency, it also may add significant jitter - which is even worse than a perfectly predictable fixed amount of latency, as it can't be corrected / compensated for.

[Jeffos]

Nice James like gpunk & Banned said, you will get latency with "virtual" cables like MAPLE MIDI though. You can replace them with MIDItoReaControlPath for an easier config and to get rid of this latency.
You also need to disable anticipative FX processing for the tracks with this kind of automation items reside (MIDItoReaControlPath does this for you).
You'll get a good timing but this won't be sample accurate - but that should be ok most of the time though.

Originally Posted by gpunk_w

Cool idea, but not automation items
Automation is envelope based and this is bar/step based no ?

for me an automation item is something you can copy/paste, stretch, split, etc.. It could be made of anything: MIDI, envelope points, or why not OSC data, no?

Originally Posted by Banned

The external MIDI routing does not only add latency, it also may add significant jitter - which is even worse than a perfectly predictable fixed amount of latency, as it can't be corrected / compensated for.

I can confirm latency for external MIDI routing but not jitter (on Win). How are you testing this Banned?