# How can I get smooth midi CC automation in Reaper ?



## Lim

This is getting frustrating, but every tutorial I've watched on this only refers to midi cc automation using the blocks. 

This isn't going to help me create smooth cutoff automation on a hardware synth for example, as it will be split between a maximum of 128 intervals. 

Is there anyway to draw midi automation as a line in Reaper to give my automation sound continuity ?


----------



## d.healey

I think the best you can get is


Apparently you can use ReaControlMIDI so that you can draw envelopes to generate the CC data. - http://forum.cockos.com/showthread.php?t=126104


----------



## Lim

d.healey said:


> I think the best you can get is
> 
> 
> Apparently you can use ReaControlMIDI so that you can draw envelopes to generate the CC data. - http://forum.cockos.com/showthread.php?t=126104




Yeah that's what I was on about. I actually found some Midicontrol FX plugin that Reaper has called ReaControlMidi. You can then just automate the plugin which allows the normal plugin automation applied to the midi hardware. The downside is that you can only automate up to 5 parameters at the same time on the track. This really isn't great, but for me it'll do . And yeah, those sliders, or blocks as I called them, no matter how smoothly arranged still don't allow a smooth sounding effect change because the maximum you can get is 128 on a grid. So yeah, that's not gonna make for a smooth cutoff change...

Also, the ReaControlMidi plugin was really laggy at first when I was changing the parameters, this was solved when I had it only going through one midi channel. Sorry for the essay, but I hope this might help somebody having the same problem as me.... and also thanks a lot for the reply.


----------



## EvilDragon

You can load more than one ReaControlMIDI plugins on one track and have any number of CCs automated that way...



Lim said:


> And yeah, those sliders, or blocks as I called them, no matter how smoothly arranged still don't allow a smooth sounding effect change because the maximum you can get is 128 on a grid. So yeah, that's not gonna make for a smooth cutoff change...



ReaControlMIDI doesn't fix this. Kontakt only supports regular 7-bit MIDI so it's going to sound stepped either way. If you want more precision, you should use host automation instead of MIDI CCs...


----------



## Lim

EvilDragon said:


> You can load more than one ReaControlMIDI plugins on one track and have any number of CCs automated that way...
> 
> 
> 
> ReaControlMIDI doesn't fix this. Kontakt only supports regular 7-bit MIDI so it's going to sound stepped either way. If you want more precision, you should use host automation instead of MIDI CCs...


I don't know why then, but the cutoff automation on the hardware synth I'm using sounds smooth now. If I can explain better, I selected the cutoff midi CC in ReaControlMIDI, then I clicked the automation icon on the track, and created an automation track. So, I have one midi track which is routed to sequence and automate the synth, and I use this track to record to an audio track. 

Also I'm using a Moog Little Phatty for this, not Kontakt, and my Little Phatty supports 14 bit midi. Also, I don't have a problem with the standard midi automation when I am using Kontakt. 

Also,"You can load more than one ReaControlMIDI plugins on one track and have any number of CCs automated that way...", but wouldn't that be cheating ?

Only joking! Thanks a lot for the reply dude.


----------



## EvilDragon

For Little Phatty it's a different thing, of course.


----------



## Jaybee

I'm having similar issues with Reaper. It's a complete PITA when it comes to playing in CC1 and CC11. I hate the way it draws the bars in the Piano roll, it's a nightmare to edit. I much prefer working with the envelope data where a simple action can convert and reduce points to a manageable amount to click and drag etc. 

I've tried ReaControlMIDI but it's not working for me. If I insert this on a track and try to write it wants to 'learn' the controller every time. Plus Reaper still records the ugly piano roll data at the same time so that then needs deleting. Whole thing is a mess. 

Anyone out there managed to get Reaper recording CC data straight to envelopes (and nowhere else) as a passage is recorded? I can't see how it can be done. I want to select a track, arm an envelope and record into it without having to erase duplicate data afterwards or teach it what controller I'm using. Have had a very frustrating couple of days with this very issue, trying everything I could find and nothing seems to work. 

Are there any DAWs that record faders as envelopes. Record once, set and forget? Would have to be PC based so that rules out Logic. I don't want to leave Reaper but this issue is really affecting my workflow.


----------



## EvilDragon

A few mouse modifier tweaks for MIDI editor and it becomes a lot easier to edit CCs in Reaper...


----------



## Jaybee

EvilDragon said:


> A few mouse modifier tweaks for MIDI editor and it becomes a lot easier to edit CCs in Reaper...



I'm sure they help but the flexibility in working with the smooth transitions of envelope data, ability to cut and paste points or envelopes to other tracks etc etc. far outweighs those awful blocks in the piano roll. 

Was looking at this thread earlier http://forum.cockos.com/showthread.php?t=153804 I might give that MB event filter a go. If we could block the piano roll blocks from being written and write straight to the envelope only, that would be a fix. I don't hold out any hope for Reaper supporting native write midi cc to envelopes anytime soon, it seems to have been a feature request for years :(


----------



## pmcrockett

Jaybee said:


> I'm having similar issues with Reaper. It's a complete PITA when it comes to playing in CC1 and CC11. I hate the way it draws the bars in the Piano roll, it's a nightmare to edit. I much prefer working with the envelope data where a simple action can convert and reduce points to a manageable amount to click and drag etc.
> 
> I've tried ReaControlMIDI but it's not working for me. If I insert this on a track and try to write it wants to 'learn' the controller every time. Plus Reaper still records the ugly piano roll data at the same time so that then needs deleting. Whole thing is a mess.
> 
> Anyone out there managed to get Reaper recording CC data straight to envelopes (and nowhere else) as a passage is recorded? I can't see how it can be done. I want to select a track, arm an envelope and record into it without having to erase duplicate data afterwards or teach it what controller I'm using. Have had a very frustrating couple of days with this very issue, trying everything I could find and nothing seems to work.
> 
> Are there any DAWs that record faders as envelopes. Record once, set and forget? Would have to be PC based so that rules out Logic. I don't want to leave Reaper but this issue is really affecting my workflow.



This doesn't help you in the immediate future, but for someone familiar with Reaper's API, it should be pretty straightforward to write a script that runs in the background and auto-converts recorded CC data to envelope data. I think the most difficult part would be writing a filter to reduce the number of points in the resulting envelope.

Someone might be able to do the scripting for you if you ask around. (I could potentially tackle it, but it would likely be quite a while before I could get to it.)


----------



## Jaybee

pmcrockett said:


> This doesn't help you in the immediate future, but for someone familiar with Reaper's API, it should be pretty straightforward to write a script that runs in the background and auto-converts recorded CC data to envelope data.



Yes, that's the ideal solution. I found a script that is 90% there but has issues I just can't resolve I'll detail these below in case it's glaringly obvious to anybody fluent in JS!



pmcrockett said:


> I think the most difficult part would be writing a filter to reduce the number of points in the resulting envelope.


That's the easy part  There's a stock action to reduce points. I have a custom action that combines this with others to do repetitive tasks. So after playing in my CC#1 to an envelope I draw a Time Selection round it and run the action. It converts all points to Bezier so the curves are smooth & brings up a dialogue to reduce points with a slider. Once that is done to taste it another stock action disarms the envelope and hides it, turns the track back to 'Read' etc. etc.







This and others like it are still a work in progress as I flesh out a workflow that's going to work for me.

At the end of that Reaper thread I linked to in Post #9 a guy had knocked up pretty much what we're talking about, albeit in an alpha version but never developed it further. A couple of JSFX plugins that do the following:


The Input FX plugin eats CC#1 & CC#11 data at source
The FX plugin passes new CC#1 & CC#11 to the VST/Kontakt etc... and writes directly to envelope once the track is set to touch/latch etc.

_However..there's a bug... 
_
Although the FX plugin slider shows that CC#1 is moving (when I move the Modwheel). the actual data being passed through to Kontakt/vst is CC#11 :( I have tried everything I know (which admittedly is not a great deal) to get this working as it's an ideal solution but it only ever passes CC#11 data. As I move the Modwheel I see Kontakt reporting I'm transmitting on CC#11.... if I disable the plugins I'm back to Modwheel CC#1 again.

Here's the code for both plugins. If this is something really obvious, please shout...!

*The Input FX plugin (CCenv_input)*

desc:CCEnv Input
// Companion plugin for CCEnv, this one should be placed in the Input FX on the same channel.

@init
_global.ccBuffer_11 = -1;
_global.ccBuffer_01 = -1;

@block 

while (
midirecv(mpos, msg1, msg23) ? (

status = msg1;
statusHi = (msg1 / 16) | 0;
statusLo = msg1 - (statusHi * 16); 

statusHi == 11 ? ( // CC
ccValue = (msg23/256)&$xff;
ccNum = msg23&$xff;
ccBuffer[ccNum] = ccValue;

ccNum == 11 ? (
_global.ccBuffer_11 = ccValue;
) :
ccNum == 1 ? (
_global.ccBuffer_01 = ccValue;
);
) : (
midisend(mpos, msg1, msg23);
);
);
);

*The regular FX plugin (inserted in as the first FX on a track) (CCenv)*

desc:CCEnv
// ReaControlMIDI replacement for continuous controllers
// Author: Panu Aaltio

slider1:0<0,127,1>#1 Mod Wheel
slider2:0<0,127,1>#11 Expression

@init

sentCC[11] = 0;
sentCC[1] = 0;

previousCC[11] = -1;

_global.ccBuffer_11 = -1;
_global.ccBuffer_01 = -1;

COOLDOWN_TIMER = 64;
cooldown = 0;

channel = 0;

@block

_global.ccBuffer_11 > -1 ? (
midisend(0, 11*16 + channel, 11 + _global.ccBuffer_11 * 256);

slider2 = _global.ccBuffer_11;
sentCC[11] = _global.ccBuffer_11;

cooldown = COOLDOWN_TIMER;

slider_automate(slider2);
previousCC[11] = _global.ccBuffer_11;
_global.ccBuffer_11 = -1;

);

_global.ccBuffer_01 > -1 ? (
midisend(0, 11*16 + channel, 11 + _global.ccBuffer_01 * 256);

slider1 = _global.ccBuffer_01;
sentCC[1] = _global.ccBuffer_01;

cooldown = COOLDOWN_TIMER;

slider_automate(slider1); 
_global.ccBuffer_01 = -1;
);

cooldown > 0 ? (
cooldown = cooldown - 1;

// If still ignoring envelope data, make sure old envelope doesn't come through
previousCC[11] > -1 && previousCC[11] != slider2 ? (
slider2 = previousCC[11];
slider_automate(slider2);
);
previousCC[1] > -1 && previousCC[1] != slider1 ? (
slider1 = previousCC[1];
slider_automate(slider1);
); 
);

sentCC[11] != slider2 ? (
sentCC[11] = slider2;
cooldown == 0 ? (
midisend(0, 11*16 + channel, 11 + sentCC[11] * 256);
);
);

sentCC[1] != slider1 ? (
sentCC[1] = slider1;
cooldown == 0 ? (
midisend(0, 11*16 + channel, 1 + sentCC[1] * 256);
);
);

If these plugs could transmit on CC#1 it would be a great workaround for what seems to be an age old problem with playing in MIDI CC data to envelopes in Reaper.


----------



## Jaybee

Quick update: I have found a workaround combination. It's not as elegant as if both the scripts above were working properly but it's better than nothing. 

I've placed the CCEnv_Input JS (above) in the Input FX slot of a track then ReaControlMIDI as the first FX in the regular FX slots (followed by Kontakt). CCEnv_Input is blocking the writing of CC#1 & CC#11 to the Piano Roll CC lane and ReaControlMIDI is (after setting it up & teaching it the controllers etc) passing the CC#1 & CC#11 moves to two envelopes. 

It's going to be a PITA to do this for each track in the template but needs must! Would still prefer a fix to CCEnv above to send on CC#1 as well as CC#11 though if any JS people could take a look. That's the ideal scenario because throwing a preset plugin across tracks is easy without having to configure each one (as ReaControlMIDI needs). 

At the end of the day, I'd love to move to something more refined in MIDI like Cubase, but the learning curve would be greater than sticking with Reaper which I've used for years (and have customised too) and patching up the holes with workarounds. This last week has made me yearn for the days when all I had to worry about was whether the cassette was rewound to the start in my Tascam Portastudio


----------



## EvilDragon

I think you could also block the MIDI output from being sent by Kontakt to the DAW, that could also work... (Kontakt's "Send MIDI to outside world" option). Also if you right-click the "x in/y out" button in the plugin window and go to MIDI Output, you can disable it there as well, _for that particular plugin_.


----------



## Jaybee

EvilDragon said:


> I think you could also block the MIDI output from being sent by Kontakt to the DAW, that could also work... (Kontakt's "Send MIDI to outside world" option). Also if you right-click the "x in/y out" button in the plugin window and go to MIDI Output, you can disable it there as well, _for that particular plugin_.



Just tried those but neither stop Modwheel from writing to the CC lane in the Piano Roll. This afternoon's experiments have shown me that the CCEnv_Input plug above (inserted to the input FX) is successfully stopping 1 & 11 from writing to the CC lanes. So that part of the operation works OK. 

The main CCEnv script must have a bug because (even though the CC1 slider moves) it only sends CC11 to Kontakt. i.e. Modwheel and other mapped CC11 slider both send CC11. Neither sends CC1. If I could get CCEnv to send CC1 this would be a whole lot easier than using ReaControlMIDI.


----------



## EvilDragon

Ah right because Reaper records the track's MIDI input. Set track recording mode to Record: MIDI (output) and it should work. In that case do take extra care there's no PDC induced by any effects on the track...


----------



## EvilDragon

Also, can't confirm your issue with CCEnv. CC1 slider sends CC1 to Kontakt and CC11 slider sends CC11 to Kontakt... just tested with Kontakt's MIDI monitor...


----------



## Jaybee

EvilDragon said:


> Also, can't confirm your issue with CCEnv. CC1 slider sends CC1 to Kontakt and CC11 slider sends CC11 to Kontakt... just tested with Kontakt's MIDI monitor...



Oh that's not good....on my part :(

I'm looking at the MIDI monitor in Kontakt too and as I enable both plugs the MIDI switches from CC1 to CC11. Every time.

To recap:

CCEnv_Input as Input FX and enabled
CCEnv as first FX on same track and enabled
Kontakt as 2nd FX on same track

Kontakt Midi monitor reports modwheel will only send CC11 with both plugs enabled. With an Albion strings patch on I can only see movement in Expression slider... My CC1 slider in Touch OSC from the iPad gives same results. CC11 every time.

What could cause that? Without the plugs the Modwheel and TouchOSC both send CC1 as expected.

Just unloaded Kontakt, loaded a random VST synth. 'learned' a filter knob with Modwheel and it's sending CC11 from Modwheel or touch OSC.

So, it's not Kontakt, or the controller, if these plugs are fine then something in Reaper is reacting to them and turning my CC1 in to 11... :o


----------



## Jaybee

Just to add, my CCEnv plug sliders both clearly react correctly to input on 1 & 11 but both will only transmit 11 into the next FX in line (Kontakt or a VST).


----------



## EvilDragon

Ah I forgot to put the input FX in. I see it now too. Weird. The code seems fine...


----------



## Jaybee

EvilDragon said:


> Ah I forgot to put the input FX in. I see it now too. Weird. The code seems fine...



*Mops brow*. Phew! I thought I had some deep rooted routing bug in my system.... At least you're seeing it too. 

Yep, I've been going grey with this for a few days now. It doesn't make any sense at all. As soon as they are enabled CC#1 goes walkabout.


----------



## pmcrockett

I'm not fluent in Reaper's JSFX coding, but I think CCEnv should be written as follows (corrected line in red):

desc:CCEnv
// ReaControlMIDI replacement for continuous controllers
// Author: Panu Aaltio

slider1:0<0,127,1>#1 Mod Wheel
slider2:0<0,127,1>#11 Expression

@init

sentCC[11] = 0;
sentCC[1] = 0;

previousCC[11] = -1;

_global.ccBuffer_11 = -1;
_global.ccBuffer_01 = -1;

COOLDOWN_TIMER = 64;
cooldown = 0;

channel = 0;

@block

_global.ccBuffer_11 > -1 ? (
midisend(0, 11*16 + channel, 11 + _global.ccBuffer_11 * 256);

slider2 = _global.ccBuffer_11;
sentCC[11] = _global.ccBuffer_11;

cooldown = COOLDOWN_TIMER;

slider_automate(slider2);
previousCC[11] = _global.ccBuffer_11;
_global.ccBuffer_11 = -1;

);

_global.ccBuffer_01 > -1 ? (
*midisend(0, 11*16 + channel, 1 + _global.ccBuffer_01 * 256);*

slider1 = _global.ccBuffer_01;
sentCC[1] = _global.ccBuffer_01;

cooldown = COOLDOWN_TIMER;

slider_automate(slider1); 
_global.ccBuffer_01 = -1;
);

cooldown > 0 ? (
cooldown = cooldown - 1;

// If still ignoring envelope data, make sure old envelope doesn't come through
previousCC[11] > -1 && previousCC[11] != slider2 ? (
slider2 = previousCC[11];
slider_automate(slider2);
);
previousCC[1] > -1 && previousCC[1] != slider1 ? (
slider1 = previousCC[1];
slider_automate(slider1);
); 
);

sentCC[11] != slider2 ? (
sentCC[11] = slider2;
cooldown == 0 ? (
midisend(0, 11*16 + channel, 11 + sentCC[11] * 256);
);
);

sentCC[1] != slider1 ? (
sentCC[1] = slider1;
cooldown == 0 ? (
midisend(0, 11*16 + channel, 1 + sentCC[1] * 256);
);
);

Previously, that line contained _11 + _global.ccBuffer_01 _etc. -- I believe that determines the CC number for output. Looks like a copy/paste error on the author's part.


----------



## Jaybee

pmcrockett said:


> I'm not fluent in Reaper's JSFX coding, but I think CCEnv should be written as follows (corrected line in red):
> 
> 
> _global.ccBuffer_01 > -1 ? (
> *midisend(0, 11*16 + channel, 1 + _global.ccBuffer_01 * 256);*
> 
> Previously, that line contained _11 + _global.ccBuffer_01 _etc. -- I believe that determines the CC number for output. Looks like a copy/paste error on the author's part.



*Sounds of the Hallelujah Chorus fanfare*  Yes, that was it! I scanned that code for hours looking for just such a typo and I couldn't see it for trying. 

Thank you & @EvilDragon *so* much for all your help guys. Both CC1 & CC11 faders now writing directly to envelopes and not to the Piano roll. I can now insert these plugs into my template knowing they'll just work. I think this is the nearest we can get to a native implementation of this in Reaper so it will be useful for a lot of people (like me) who can't code one themselves. 

If it's OK with you I'll update that thread over at the Reaper forum later today and put a comment on the original upload at stash.reaper.com so people can do the quick fix. 

Looking forward to a productive day getting these in the monster template now...  Cheers!!


----------



## robgb

Jaybee said:


> Looking forward to a productive day getting these in the monster template now...  Cheers!!


Been playing around with this and noticed the CCEnv_Input script cuts off all CC64 input as well. Any way around losing the sustain pedal?


----------



## pmcrockett

robgb said:


> Been playing around with this and noticed the CCEnv_Input script cuts off all CC64 input as well. Any way around losing the sustain pedal?


Bear in mind that I'm not running the script to check functionality right now -- just quickly looking at the code -- but the scripts are set up to catch CC1 and CC11 specifically, so anything else gets ignored. Modifying the code to catch CC64 as well should be a simple copy/paste affair, so here we go:

*The Input FX plugin (CCenv_input)*

desc:CCEnv Input
// Companion plugin for CCEnv, this one should be placed in the Input FX on the same channel.

@init
_global.ccBuffer_64 = -1;
_global.ccBuffer_11 = -1;
_global.ccBuffer_01 = -1;

@block 

while (
midirecv(mpos, msg1, msg23) ? (

status = msg1;
statusHi = (msg1 / 16) | 0;
statusLo = msg1 - (statusHi * 16); 

statusHi == 11 ? ( // CC
ccValue = (msg23/256)&$xff;
ccNum = msg23&$xff;
ccBuffer[ccNum] = ccValue;

ccNum == 64 ? _global.ccBuffer_64 = ccValue;
ccNum == 11 ? _global.ccBuffer_11 = ccValue;
ccNum == 1 ? _global.ccBuffer_01 = ccValue;
) : (
midisend(mpos, msg1, msg23);
);
);
);

*The regular FX plugin (inserted in as the first FX on a track) (CCenv)*

desc:CCEnv
// ReaControlMIDI replacement for continuous controllers
// Author: Panu Aaltio

slider1:0<0,127,1>#1 Mod Wheel
slider2:0<0,127,1>#11 Expression
slider3:0<0,127,1>#64 Sustain Pedal

@init

sentCC[64] = 0;
sentCC[11] = 0;
sentCC[1] = 0;

previousCC[64] = -1;
previousCC[11] = -1;
previousCC[1] = -1;

_global.ccBuffer_64 = -1;
_global.ccBuffer_11 = -1;
_global.ccBuffer_01 = -1;

COOLDOWN_TIMER = 64;
cooldown = 0;

channel = 0;

@block

_global.ccBuffer_64 > -1 ? (
midisend(0, 11*16 + channel, 64 + _global.ccBuffer_64 * 256);

slider3 = _global.ccBuffer_64;
sentCC[64] = _global.ccBuffer_64;

cooldown = COOLDOWN_TIMER;

slider_automate(slider3);
previousCC[64] = _global.ccBuffer_64;
_global.ccBuffer_64 = -1;
);

_global.ccBuffer_11 > -1 ? (
midisend(0, 11*16 + channel, 11 + _global.ccBuffer_11 * 256);

slider2 = _global.ccBuffer_11;
sentCC[11] = _global.ccBuffer_11;

cooldown = COOLDOWN_TIMER;

slider_automate(slider2);
previousCC[11] = _global.ccBuffer_11;
_global.ccBuffer_11 = -1;
);

_global.ccBuffer_01 > -1 ? (
midisend(0, 11*16 + channel, 1 + _global.ccBuffer_01 * 256);


slider1 = _global.ccBuffer_01;
sentCC[1] = _global.ccBuffer_01;

cooldown = COOLDOWN_TIMER;

slider_automate(slider1);
previousCC[1] = _global.ccBuffer_01; 
_global.ccBuffer_01 = -1;
);

cooldown > 0 ? (
cooldown = cooldown - 1;

// If still ignoring envelope data, make sure old envelope doesn't come through
previousCC[64] > -1 && previousCC[64] != slider3 ? (
slider3 = previousCC[64];
slider_automate(slider3);
);
previousCC[11] > -1 && previousCC[11] != slider2 ? (
slider2 = previousCC[11];
slider_automate(slider2);
);
previousCC[1] > -1 && previousCC[1] != slider1 ? (
slider1 = previousCC[1];
slider_automate(slider1);
); 
);

sentCC[64] != slider3 ? (
sentCC[64] = slider3;
cooldown == 0 ? (
midisend(0, 11*16 + channel, 64 + sentCC[11] * 256);
);
);

sentCC[11] != slider2 ? (
sentCC[11] = slider2;
cooldown == 0 ? (
midisend(0, 11*16 + channel, 11 + sentCC[11] * 256);
);
);

sentCC[1] != slider1 ? (
sentCC[1] = slider1;
cooldown == 0 ? (
midisend(0, 11*16 + channel, 1 + sentCC[1] * 256);
);
);

Again, I haven't actually run the modified code, just done the copy/pasting, so let me know if it doesn't work and I'll dig into it and properly bugfix it. In principle, it should be possible to create a more generalized code structure that would let the execution iterate through an arbitrary list of CC numbers without needing all this copy/paste nonsense to add new ones, but it would require substantial rewriting that I'm not inclined to attempt.

EDIT:
I may have misunderstood -- looks like the input script totally kills all CC data except what it passes to the envelope writer. My fix should put CC64 as an envelope, too, but if you'd rather just pass CC64 through as normal MIDI data, that shouldn't be too hard to set up, so let me know if that's the case.


----------



## EvilDragon

It should ideally either pass through other CCs, or do the same thing to all other CCs it's doing to #1 and #11.


----------



## robgb

Excellent, thanks. I made a little video demo for others to see what's possible:

https://vi-control.net/community/threads/reaper-cc-1-envelope.70396/


----------



## Grim_Universe

For some reason the default ControlMIDI plugin loads my CPU and I have clicks and other artifacts.. Everything is ok when I draw in MIDI editor (sometimes I just hate Reaper). I'll try this one. Thanks.
So we have to use these two plugins together or what? I just do not quite understand.


----------



## robgb

pmcrockett said:


> I may have misunderstood -- looks like the input script totally kills all CC data except what it passes to the envelope writer. My fix should put CC64 as an envelope, too, but if you'd rather just pass CC64 through as normal MIDI data, that shouldn't be too hard to set up, so let me know if that's the case.


The CC64 data records, but doesn't work on playback. Interesting. Might be better to make CC64 a pass through. But I'm an idiot when it comes to coding.


----------



## Grim_Universe

P.s. Checked it and It works perfectly without any spikes. Nice to know! I don't record a CC data frequently, so it doesn't matter, but the plugin overall is very helpful and works better than the original one. Thank you very much!
And answering to my personal question: yes, these plugins should be used together. CCenv_input first, then CCenv.


----------



## robgb

Grim_Universe said:


> For some reason the default ControlMIDI plugin loads my CPU and I have clicks and other artifacts


I have problems with ControlMIDI as well. For some reason it doesn't seem to like my modwheel. CCEnv doesn't have that problem.


----------



## EvilDragon

Grim_Universe said:


> For some reason the default ControlMIDI plugin loads my CPU and I have clicks and other artifacts.



That is weird. I mean... RCM is a plugin like any other, but all it does is just MIDI processing, this is absolutely not CPU intensive and I'm not sure how it would cause artifacts of any sorts...


----------



## Grim_Universe

@EvilDragon yes, you're absolutely right. That's weird as hell. But Reaper and MIDI are not friends. Try somehow to compose a very big project with a LOT of MIDI tracks. A project can sound perfectly in the main Reaper window, but if you'll open MIDI editor, everything will start to crackle. And the more tracks you can see in the editor, the worse the CPU load will be. It just how it works, you know? Reaper is very buggy sometimes.


----------



## EvilDragon

That's actually not a bug, it's a matter of one setting. Preferences->Audio->Buffering->[x] Anticipative FX Processing->[ ] Allow on tracks with open MIDI editors (will increase MIDI preview latency)

If you have that last checkbox disabled, that means all the tracks that are shown in the MIDI editor as visible and/or editable (AND their associated sends, if any!) get pushed onto the main audio thread for processing, slamming that core. This is in order to provide instantaneous MIDI preview as you input the notes in. If you enable this checkbox, there will be latency when inputting new notes, but you won't have any crackles. It's a tradeoff.


----------



## Grim_Universe

@EvilDragon I'll check it. Thank you!


----------



## DynamicK

robgb said:


> Excellent, thanks. I made a little video demo for others to see what's possible.


 Is the link on the Reaper Forum? Never mind I found it on here: Reaper CC 1 Envelope


----------



## robgb

DynamicK said:


> Is the link on the Reaper Forum? Never mind I found it on here: Reaper CC 1 Envelope


Link added. Thanks.


----------



## pmcrockett

So I'm now actually running the scripts instead of just looking at them, and I've noticed that CCenv_input is sporadically passing bits of MIDI data through even though it shouldn't, but I see how to fix it. (Input processing should be happening at the sample rate instead of every block.) I'll post a revision after I see if anything else needs fixing.


----------



## robgb

pmcrockett said:


> I'll post a revision after I see if anything else needs fixing.


I really need to learn how to code, but I'm sixty-two and lazy.


----------



## pmcrockett

Major overhaul of the entire thing.

CCEnv Input now has a GUI that lets you select what CCs you want to write as envelopes. Unselected CCs will be passed through as regular MIDI data. All instances of CCEnv Input will sync their CC selection state to each other. Put instances of CCEnv Input on all tracks that need them, then just leave one of the instances open to control all of them. CCEnv Input's selection state saves with the Reaper project.

CCEnv is now split into two parts to accommodate all 128 CCs (because JSFX plugins can only have 64 sliders). The sliders on the plugin screen may go off the screen on smaller monitors. I could fix this by splitting it into three or four instead of two if that's an issue for people, but I figure seeing the sliders isn't that big a deal since it's the automation lanes that are actually important.

A possible change in the future would be to allow you to decouple the instance syncing so you can choose to set/save different input configurations for different tracks.

I've not bug tested all of this too thoroughly, but it should be functional.


----------



## robgb

pmcrockett said:


> Major overhaul of the entire thing.
> 
> CCEnv Input now has a GUI that lets you select what CCs you want to write as envelopes. Unselected CCs will be passed through as regular MIDI data. All instances of CCEnv Input will sync their CC selection state to each other. Put instances of CCEnv Input on all tracks that need them, then just leave one of the instances open to control all of them. CCEnv Input's selection state saves with the Reaper project.
> 
> CCEnv is now split into two parts to accommodate all 128 CCs (because JSFX plugins can only have 64 sliders). The sliders on the plugin screen may go off the screen on smaller monitors. I could fix this by splitting it into three or four instead of two if that's an issue for people, but I figure seeing the sliders isn't that big a deal since it's the automation lanes that are actually important.
> 
> A possible change in the future would be to allow you to decouple the instance syncing so you can choose to set/save different input configurations for different tracks.
> 
> I've not bug tested all of this too thoroughly, but it should be functional.


WOW. Looking forward to checking this out. Thanks, man!


----------



## robgb

pmcrockett said:


> I've not bug tested all of this too thoroughly, but it should be functional.



Okay, pardon my French, but this is fucking brilliant. Thanks so much for taking the time to do this.


----------



## Grim_Universe

@pmcrockett very nice. Thanks! Nowadays with your plugin and MIDI compressor discovery life has become much easier


----------



## DynamicK

*@pmcrockett *Thanks for the update. Appreciated.


----------



## robgb

@pmcrockett Unfortunately, I'm finding a weird bug that I've tested and re-tested and I can't figure out what's happening. Hopefully I can explain it clearly:

I set up the JSFX as required. Works beautifully. But then I save the track with Kontakt instruments loaded to a track template.
Now, when I start a new project and call up that track template I get no sound from Kontakt at all. I check routing and all seems fine.
If I load up a SECOND instance of the very SAME track template, the sound is fine.
Huh?
If I load up a track template that doesn't contain CCEnv and CCEnv_Input, the sound is fine every time.
So the culprit seems to be CCEnv and/or CCEnv_Input conflicting with Kontakt in some way. But only when using a template and only on the first instance...
Very strange.

UPDATE:

After closer inspection I've noticed that when I load up the first instance of the track template, the volume (cc7) has defaulted to zero and the pan position (cc10) has defaulted to hard left.

When I open another template instance, volume and panning are fine.

In CCEnv_Input I'm only checking off CC1.

UPDATE 2:

I've found a workaround for now. I created a new default project template that includes an instance of Kontakt with CCEnv etc. So when I open a new project, whatever needs to be restored is immediately restored.

Then, when I open another instance of the track template it works fine.


----------



## pmcrockett

Glad people like the modifications. I learned some useful things about graphics and memory sharing in JSFX code in working on this.



robgb said:


> @pmcrockett Unfortunately, I'm finding a weird bug that I've tested and re-tested and I can't figure out what's happening. Hopefully I can explain it clearly:
> 
> I set up the JSFX as required. Works beautifully. But then I save the track with Kontakt instruments loaded to a track template.
> Now, when I start a new project and call up that track template I get no sound from Kontakt at all. I check routing and all seems fine.
> If I load up a SECOND instance of the very SAME track template, the sound is fine.
> Huh?
> If I load up a track template that doesn't contain CCEnv and CCEnv_Input, the sound is fine every time.
> So the culprit seems to be CCEnv and/or CCEnv_Input conflicting with Kontakt in some way. But only when using a template and only on the first instance...
> Very strange.
> 
> UPDATE:
> 
> After closer inspection I've noticed that when I load up the first instance of the track template, the volume (cc7) has defaulted to zero and the pan position (cc10) has defaulted to hard left.
> 
> When I open another template instance, volume and panning are fine.
> 
> In CCEnv_Input I'm only checking off CC1.
> 
> UPDATE 2:
> 
> I've found a workaround for now. I created a new default project template that includes an instance of Kontakt with CCEnv etc. So when I open a new project, whatever needs to be restored is immediately restored.
> 
> Then, when I open another instance of the track template it works fine.



Thanks for catching this. Turns out I was initializing some of the values in CCEnv wrong so the first instance added was trying to read all of the sliders even though the sliders had no data in them, and this was setting every Kontakt value controlled by a CC to 0. Should be fixed now.


----------



## robgb

pmcrockett said:


> Thanks for catching this. Turns out I was initializing some of the values in CCEnv wrong so the first instance added was trying to read all of the sliders even though the sliders had no data in them, and this was setting every Kontakt value controlled by a CC to 0. Should be fixed now.


Thanks, I'll check it out. I've since discovered that one of the problem sseems to be @tack 's Reaticulate FX I have on the same track. When I switch articulations, all of the volume sliders in Kontakt drop to zero when CCEnv is also present. Could be a conflict between the two. I'll see what happens with the new versions and let you know.


----------



## robgb

pmcrockett said:


> I learned some useful things about graphics and memory sharing in JSFX code in working on this.


I really appreciate you doing this. Unfortunately, the new version conflicts with Reaticulate. As soon as I switch articulations (which switches to a new channel), all the volume faders go to zero in Kontakt for that articulation, and the pan slider goes hard left. This doesn't happen, however, when I use the ORIGINAL version of CCEnv, etc. So clearly something in the new code is conflicting with Reaticulate, and I certainly don't expect you to figure out what it is. I will be content to use the original version of CCEnv for now. And THANKS AGAIN for all your hard work. I envy your skills.


----------



## pmcrockett

robgb said:


> I really appreciate you doing this. Unfortunately, the new version conflicts with Reaticulate. As soon as I switch articulations (which switches to a new channel), all the volume faders go to zero in Kontakt for that articulation, and the pan slider goes hard left. This doesn't happen, however, when I use the ORIGINAL version of CCEnv, etc. So clearly something in the new code is conflicting with Reaticulate, and I certainly don't expect you to figure out what it is. I will be content to use the original version of CCEnv for now. And THANKS AGAIN for all your hard work. I envy your skills.


Interesting. I'll take a look when I get a chance -- I haven't used Reaticulate yet, but my limited understanding of its design is that there shouldn't be any inherent conflicts between the two aside from bugs. CCEnv is hard-coded to channel 1, which is a holdover from the original code that may be causing problems now that the plugin has access to all CCs, so fixing that may help fix the problem.


----------



## EvilDragon

@pmcrockett: I think if you don't use JS FX sliders but instead just use variables with GUIfied sliders, you can have more than 64 parameters per script, so there's no need to split things into more than one script... Perhaps?


----------



## pmcrockett

EvilDragon said:


> @pmcrockett: I think if you don't use JS FX sliders but instead just use variables with GUIfied sliders, you can have more than 64 parameters per script, so there's no need to split things into more than one script... Perhaps?


Is there a way to expose non-slider variables as automatable from the track envelope view? It would definitely be more convenient not to use the sliders, but I couldn't find anything in the JSFX documentation to suggest this was possible, and the ability to read the automation envelopes into the plugin is essential to the way it currently functions.


----------



## tack

robgb said:


> I've since discovered that one of the problem sseems to be @tack 's Reaticulate FX I have on the same track. When I switch articulations, all of the volume sliders in Kontakt drop to zero when CCEnv is also present. Could be a conflict between the two. I'll see what happens with the new versions and let you know.


This is likely caused by chasing CC 7. In the next release we'll have the ability to chase specific CCs (and the factory banks will be selective about which CCs to chase). The interim solution to this is to send CC 7 on the relevant channels to Reaticulate so that next time it chases CCs, it'll at least chase the target levels you want.


----------



## EvilDragon

pmcrockett said:


> Is there a way to expose non-slider variables as automatable from the track envelope view? It would definitely be more convenient not to use the sliders, but I couldn't find anything in the JSFX documentation to suggest this was possible, and the ability to read the automation envelopes into the plugin is essential to the way it currently functions.



Ah, gotcha. Yeah, won't work then.


----------



## robgb

tack said:


> The interim solution to this is to send CC 7 on the relevant channels to Reaticulate so that next time it chases CCs, it'll at least chase the target levels you want.


Unfortunately, I have no clue how to do this, but I appreciate the thought.


----------



## tack

robgb said:


> Unfortunately, I have no clue how to do this, but I appreciate the thought.


Well, one lame but effective way would be to create a MIDI item, show the lane for CC7, draw in the desired value on the required MIDI channels, and then play it back so Reaticulate receives those events.

Sorry. 

It could be easier to delete the Reaticulate FX on the problematic track and re-add it. As long as it doesn't see CC7, it won't attempt to chase it. (It'll only chase CCs that it's previously observed.)


----------



## robgb

tack said:


> Well, one lame but effective way would be to create a MIDI item, show the lane for CC7, draw in the desired value on the required MIDI channels, and then play it back so Reaticulate receives those events.
> 
> Sorry.
> 
> It could be easier to delete the Reaticulate FX on the problematic track and re-add it. As long as it doesn't see CC7, it won't attempt to chase it. (It'll only chase CCs that it's previously observed.)


What's odd is that when I rebuild the track template and add the multi from scratch, then throw on Reaticulate and the CCEnv (old versions), everything seems to work fine. We'll see if this lasts.


----------



## James Marshall

I wonder if anyone else is having an issue with CCenv_input that I'm having...

I'm finding that the plugin CCenv_input doesn't seem to initialise on opening a saved project, _or_ when inserting a Track Template with tracks that use the plugin.

After opening a project I have to "Show input FX chain" on the track using CCenv_input to float the input FX chain window, and all of a sudden it starts working perfectly from then on. For me it seems to only start running if the input FX chain window is floating. 

If I open a project that's been saved with the input FX chain window floating, it works right away.

I feel I'm 99% the way there for this completely transforming how I enter CC data. Thank you so much @pmcrockett!

Sorry if my explanation is completely hopeless. If you need me to elaborate etc please let me know.


----------



## Chris Hurst

Love this.

As above, has changed the way I enter CC data for the better in my opinion.


----------



## pmcrockett

James Marshall said:


> I wonder if anyone else is having an issue with CCenv_input that I'm having...
> 
> I'm finding that the plugin CCenv_input doesn't seem to initialise on opening a saved project, _or_ when inserting a Track Template with tracks that use the plugin.
> 
> After opening a project I have to "Show input FX chain" on the track using CCenv_input to float the input FX chain window, and all of a sudden it starts working perfectly from then on. For me it seems to only start running if the input FX chain window is floating.
> 
> If I open a project that's been saved with the input FX chain window floating, it works right away.
> 
> I feel I'm 99% the way there for this completely transforming how I enter CC data. Thank you so much @pmcrockett!
> 
> Sorry if my explanation is completely hopeless. If you need me to elaborate etc please let me know.


I'll take a look at this along with the Reaticulate issue, probably on Thursday. All of the saves I performed had the plugin window visible, now that I think about it. I think the issue is that I have some of the initialization happening in the code that runs the graphics, and that code apparently doesn't execute at all unless the graphics are visible (which makes sense).


----------



## pmcrockett

@robgb I've been able to partially recreate the Reaticulate bug. Judging by what @tack has said above and what I've observed from Reaticulate's behavior, Reaticulate chases CC values based on what value it last received, which means that if CCEnv has sent any data for a particular CC, Reaticulate will use that as the chase value even if CCEnv doesn't have any actual automation recorded for that CC -- e.g. if you touch the CC10 slider in the CCEnv (CC0-CC63) plugin window, Reaticulate will use whatever value that slider sent as the chase value for pan in Kontakt. So CCEnv sliders that have not been touched at all will display 0 and will not be chased by Reaticulate because they never sent data, but sliders that have been touched and manually reset to 0 will be chased as 0 by Reaticulate, and there's no way to know which sliders are being chased and which aren't unless you remember which ones you've touched.

As tack mentioned, a work around for this is to insert a CC value on the track so Reaticulate will chase that instead of what it got from CCEnv.

The other workaround is, after setting everything up, don't touch any slider in the CCEnv (CC0-CC63) or CCEnv (CC64-CC127) window unless you're actually going to record/automate the slider. Reaticulate won't see any data coming from the unused sliders and won't latch to them.

It's also possible that there's something specific to your Reaper project/template affecting things, so let me know if you still have the problem after setting up a clean project without touching the CCEnv sliders.


----------



## pmcrockett

@James Marshall
I've fixed the bug with the plugin not initializing if the window is closed.


----------



## James Marshall

pmcrockett said:


> @James Marshall
> I've fixed the bug with the plugin not initializing if the window is closed.


Excellent! Can confirm that works for me too.

Thanks so much for looking into that and for your time, it's a great little plugin


----------



## pbattersby

I'm curious. How is it that CCenv_(CC0-CC63).jsfx, is able to properly record CC01, but ReaControlMIDI can't? What is the magic that enables this to work when it fails for me with ReaControlMIDI? In both cases I'm using CCenv_input.jsfx as an input FX, and I have record mode set to "Latch."


----------



## pmcrockett

pbattersby said:


> I'm curious. How is it that CCenv_(CC0-CC63).jsfx, is able to properly record CC01, but ReaControlMIDI can't? What is the magic that enables this to work when it fails for me with ReaControlMIDI? In both cases I'm using CCenv_input.jsfx as an input FX, and I have record mode set to "Latch."


I've not personally used ReaControlMIDI to record CC envelopes, but my understanding is that because it can't stop the CC events from being recorded and/or passing through it, you end up with the both the MIDI data and the envelope recorded unless you use something else to filter the data as well. My impression is that it's not really designed for people who want to replace CC events with envelopes as part of a permanent workflow modification.

CCEnv works by reading the CC values at input (in CCEnv Input), blocking the CCs you've selected so they won't record as MIDI on the track, and instead sending that CC data directly to CCEnv (CC0-CC63) and CCEnv (CC64-CC127) which convert the CCs to slider motion that can be recorded. CCEnv (CC0-CC63) and CCEnv (CC64-CC127) then pass the CC data equivalent of the slider motion on down the chain to the instrument. If there were no input component to the plugin, the MIDI track couldn't be bypassed while recording, and if there were no output component, there would be no way to read the envelopes during playback, but having both an input and an output component allows us to skip the MIDI track entirely for both recording and playback.

I just checked, and it's actually possible to use CCEnv Input to filter out a CC by checkingboxing it and then use ReaControlMIDI's learn feature to link that CC to its automatable CC parameter which lets you record the automation with the CC input without recording the MIDI data on the track -- so you end up in pretty much the same place as if you use CCEnv (CC0-CC63) and CCEnv (CC64-CC127), just with fewer available CCs and more setup required.


----------



## pbattersby

pmcrockett said:


> I just checked, and it's actually possible to use CCEnv Input to filter out a CC by checkingboxing it and then use ReaControlMIDI's learn feature to link that CC to its automatable CC parameter



By "checkboxing it" do you mean enabling it?

I've only just started playing with CCEnv but it seems to solve the problem (recording smooth MIDI automation) so thanks for your work on this.

The CCEnv scripts seem to work well, so I'll probably stick with it rather than continuing to struggle with ReaControlMIDI since I'm just not making any progress with getting it to recognize (learn) the MOD wheel and behave as well as CCEnv.

Will you eventually upload CCEnv to the Reaper Reapack repository or some external location? So far it seems it's only available to members of this forum as an attachment to this thread.


----------



## pmcrockett

pbattersby said:


> By "checkboxing it" do you mean enabling it?
> 
> I've only just started playing with CCEnv but it seems to solve the problem (recording smooth MIDI automation) so thanks for your work on this.
> 
> The CCEnv scripts seem to work well, so I'll probably stick with it rather than continuing to struggle with ReaControlMIDI since I'm just not making any progress with getting it to recognize (learn) the MOD wheel and behave as well as CCEnv.
> 
> Will you eventually upload CCEnv to the Reaper Reapack repository or some external location? So far it seems it's only available to members of this forum as an attachment to this thread.



Yes, by checkboxing I mean enabling.

If ReaControlMIDI isn't seeing the mod wheel as a learn source, you may need to change your MIDI controller's mode in the MIDI devices section of the preferences. You can set input devices as _enable input_ and/or _enable input for control messages_ by right clicking on them. Both can be selected at the same time for any device, and _enable input for control messages_ allows Reaper to see the device as a learn source.

As far as distribution goes, I'll probably at least put it up in the Reaper forum thread where the script originated and maybe look into Reapack. It hadn't occurred to me that putting it as a message board attachment restricted it to forum members, so in the meantime, I'll maybe find a spot to upload it that's generally accessible.


----------



## robgb

pmcrockett said:


> It's also possible that there's something specific to your Reaper project/template affecting things, so let me know if you still have the problem after setting up a clean project without touching the CCEnv sliders.


Yes, that's more than possible. But I'll try the work arounds and see what happens.


----------



## robgb

pmcrockett said:


> The other workaround is, after setting everything up, don't touch any slider in the CCEnv (CC0-CC63) or CCEnv (CC64-CC127) window unless you're actually going to record/automate the slider. Reaticulate won't see any data coming from the unused sliders and won't latch to them.


Both workarounds seem to work. I'm wondering if there's a way to "embed" certain CC values into a track template without adding a midi item (not that this is a bad thing).


----------



## robgb

pmcrockett said:


> As tack mentioned, a work around for this is to insert a CC value on the track so Reaticulate will chase that instead of what it got from CCEnv.


I've found another workaround (I think). In Kontakt I used the factory multiscript Transformer to send CC7 and CC10 to unused values (100, 101) so that they don't affect the instruments in any way. Obviously, if you do this you have to make sure your instruments don't use those new values for anything. But so far it seems to work. I tried hammering the track with CC7 and it made no difference.

The problem I had with adding a CC7 command to the track was that it set all the instrument values to the same volume, and destroyed the volume balance I had worked out for that multi.


----------



## EvilDragon

robgb said:


> I'm wondering if there's a way to "embed" certain CC values into a track template without adding a midi item (not that this is a bad thing).



Not that I know. Best have an item in the template.


----------



## James Marshall

I'm finding that 'on/off' CC's (I'm use sustain pedal: CC64), seem to be a little inaccurate when being run through CCEnv. It seems that it can be a bit erratic with the 0 (off) and 127 (on) values. Sometimes CC64 get's stuck on 127 keeping the sustain on, despite letting go of the pedal. Screenshot of ReaControl MIDI attached.

The easiest way to recreate the issue is to turn sustain on and off rapidly. I know it's not normal to do this but it can occasionally "stick" on (127) when playing normally too. With CCEnv off I can mash the sustain pedal as much as I like and always finishes on 0.

Apart from that, the regular CC's that aren't on/off work beautifully 

Any ideas?


----------



## pmcrockett

James Marshall said:


> I'm finding that 'on/off' CC's (I'm use sustain pedal: CC64), seem to be a little inaccurate when being run through CCEnv. It seems that it can be a bit erratic with the 0 (off) and 127 (on) values. Sometimes CC64 get's stuck on 127 keeping the sustain on, despite letting go of the pedal. Screenshot of ReaControl MIDI attached.
> 
> The easiest way to recreate the issue is to turn sustain on and off rapidly. I know it's not normal to do this but it can occasionally "stick" on (127) when playing normally too. With CCEnv off I can mash the sustain pedal as much as I like and always finishes on 0.
> 
> Apart from that, the regular CC's that aren't on/off work beautifully
> 
> Any ideas?


Haven't had time to actually get into the code to fix it, but I have at least recreated the bug. It seems to be happening only with input/recording and not with playback, so I have a general sense of where in the code things are going wrong.


----------



## jadedsean

How can i add this script to Reaper?


----------



## robgb

jadedsean said:


> How can i add this script to Reaper?


Download and copy the text into your clipboard. Open your FX browser, right click on JS, choose create a new effect, name it, and paste the text. Save.


----------



## jadedsean

robgb said:


> Download and copy the text into your clipboard. Open your FX browser, right click on JS, choose create a new effect, name it, and paste the text. Save.


Cheers Rob much appreciated.


----------



## pmcrockett

jadedsean said:


> How can i add this script to Reaper?





robgb said:


> Download and copy the text into your clipboard. Open your FX browser, right click on JS, choose create a new effect, name it, and paste the text. Save.


Alternately, the .jsfx files can be placed directly in the Effects folder in the Reaper resource location (Options > Show REAPER resource path in explorer/finder), which is where _create new JS FX_ puts things by default. You may have to scan for new plugins to get it to appear if you do it this way.


----------



## Fujosej

Hey guys ,there is a bug or something like that with CC_env scripts.


Spoiler: Video







As you can see in the video , i cant adjust each track individually.

The routing for midi track 1-16 is like that , First track All>1 , secod All>2 etc.


Spoiler: routing













*Could someone please fix this issue?*


----------



## pmcrockett

Fujosej said:


> Hey guys ,there is a bug or something like that with CC_env scripts.
> 
> 
> Spoiler: Video
> 
> 
> 
> 
> 
> 
> 
> As you can see in the video , i cant adjust each track individually.
> 
> The routing for midi track 1-16 is like that , First track All>1 , secod All>2 etc.
> 
> 
> Spoiler: routing
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *Could someone please fix this issue?*



So, the issue is that the input plugin isn't distinguishing among the possible output plugins it can send data to, and it doesn't naturally know which instances of the output plugins are in its own signal chain because plugins don't know what tracks they exist on. And the data can't be passed down the chain as normal MIDI data because the whole point is to avoid doing that. It's a problem leftover from the original code that I didn't catch in my modifications.

There are a few possible approaches to fixing it. The most straightforward is either to have the user manually set ID numbers on each plugin instance so the input plugins know which output plugins to route their data to, or to have a sync button on each plugin where you would press sync on the input plugin and it would match to the next output plugins that you pressed sync on. Or possibly instruct the user to briefly turn on record monitoring during plugin setup, which would let the input plugin send a MIDI signal down the chain to see which output plugins were in the chain with it.

Another possibility would be to add a Lua component that runs in the background independently of the plugins and tells each plugin what track it's on (ReaScript can gather this sort of data, whereas JSFX can't). It would be a little cumbersome to have a separate script that needs to run in addition to the plugins, though, so I'd like to avoid this if I can.

The best solution, which I haven't thought through in detail yet because I've never done audio processing in JSFX before, is that I may be able to use the audio output routing from the plugins to send the MIDI data as a dummy audio signal that won't actually be output as sound but will properly travel down the signal chain to be read by the appropriate output plugin.

I'll explore these options and make the fix when I'm able, but unfortunately my current job situation has left me without much free time to work on these sorts of projects, so I can't guarantee any kind of timetable on this.

EDIT: Just realized that Reaper lets you set the record mode to record the MIDI output rather than input. Haven't played around with it yet, but this might let me restructure the entire plugin so it all sits in the output FX section, which would make everything a lot simpler.


----------



## EvilDragon

Do note that recording the output of MIDI track probably adds a buffer of latency compared to recording the input.


----------



## Fujosej

pmcrockett said:


> So, the issue is that the input plugin isn't distinguishing among the possible output plugins it can send data to, and it doesn't naturally know which instances of the output plugins are in its own signal chain because plugins don't know what tracks they exist on. And the data can't be passed down the chain as normal MIDI data because the whole point is to avoid doing that. It's a problem leftover from the original code that I didn't catch in my modifications.
> 
> There are a few possible approaches to fixing it. The most straightforward is either to have the user manually set ID numbers on each plugin instance so the input plugins know which output plugins to route their data to, or to have a sync button on each plugin where you would press sync on the input plugin and it would match to the next output plugins that you pressed sync on. Or possibly instruct the user to briefly turn on record monitoring during plugin setup, which would let the input plugin send a MIDI signal down the chain to see which output plugins were in the chain with it.
> 
> Another possibility would be to add a Lua component that runs in the background independently of the plugins and tells each plugin what track it's on (ReaScript can gather this sort of data, whereas JSFX can't). It would be a little cumbersome to have a separate script that needs to run in addition to the plugins, though, so I'd like to avoid this if I can.
> 
> The best solution, which I haven't thought through in detail yet because I've never done audio processing in JSFX before, is that I may be able to use the audio output routing from the plugins to send the MIDI data as a dummy audio signal that won't actually be output as sound but will properly travel down the signal chain to be read by the appropriate output plugin.
> 
> I'll explore these options and make the fix when I'm able, but unfortunately my current job situation has left me without much free time to work on these sorts of projects, so I can't guarantee any kind of timetable on this.
> 
> EDIT: Just realized that Reaper lets you set the record mode to record the MIDI output rather than input. Haven't played around with it yet, but this might let me restructure the entire plugin so it all sits in the output FX section, which would make everything a lot simpler.



Ok Thanks for the answer, that sounds really kinda complicated for me to handle.

The setup i am using right now 
I use MidiNotch in INPUTfx , and set it to filter all CC inputs. (like that)


Spoiler: Input FX











And then for Regular FX slot ,i use your two JS plugins.


Spoiler: Regular FX












And after that i just choose what cc's i need in envelope lane and learn them with my midi device


Spoiler: CC Envelope












That requires some extra work because of learning process.

The only problem i have with this setup, is if i try to record in midi output mode (records all cc's in midi items).


----------



## impakt

Thanks to pmcrockett and his CCenv, I am now able to record automation with my outboard gears such as a Nord Lead 2. It's working really great!

Below are the parameter definitions for anyone who may find it useful.

Here is a question about possible optimisation:

For Nord Lead 2, only seven parameters are needed from the cc64-cc127 JS, and cc47-cc63 are unused. The first CCenv would have plenty of room to account for cc70-80.

Can the code be altered in a simple way so that, for example, cc50-cc63 becomes cc70-83? I'm guessing a simple math formula will do?

This would help immensely because then Synth settings can be stored, recalled, and transmitted with a single JS preset. I hope it can work out this way.



Code:


desc:CCEnv (Nord Lead 2) A

slider1:0<0,127,1>-slider1 CC0
slider2:0<0,127,1>-Modwheel CC1
slider3:0<0,127,1>-Breath Ctrl CC2
slider4:0<0,127,1>-slider4 CC3
slider5:0<0,127,1>-slider5 CC4
slider6:0<0,127,1>Portamento CC5
slider7:0<0,127,1>-slider7 CC6
slider8:100<0,127,1>Gain CC7
slider9:0<0,127,1>Oscillator Mix CC8
slider10:0<0,127,1>-slider10 CC9
slider11:0<0,127,1>-slider11 CC10
slider12:0<0,127,1>-slider12 CC11
slider13:0<0,127,1>-slider13 CC12
slider14:0<0,127,1>-slider14 CC13
slider15:0<0,127,1>-slider15 CC14
slider16:0<0,2,1{Mono,Legato,Poly}>-Oscillator Mode CC15
slider17:0<0,1,1{off,ON}>-Unison CC16
slider18:0<0,127,1>-slider18 CC17
slider19:0<0,4,1{Filter,FM,OSC2,LFO1,Morph}>-ModWh Destination CC18
slider20:80<0,127,1>LFO1 Rate CC19
slider21:0<0,4,1{S&H,Saw,Tri,Sqr,soft Rnd>LFO1 Waveform CC20
slider22:0<0,4,1{PW,Filter,Osc2,Osc1+2,FM>LFO1 Destination CC21
slider23:0<0,127,1>LFO1 Amount CC22
slider24:80<0,127,1>LFO2 Rate CC23
slider25:0<0,8,1{hold-DN,hold-UP,UP,hold-UD,AMP,Osc1+2,hold-RND,hold-Echo,Filter,Arp Off (filter)}>LFO2 hold / dest CC24
slider26:0<0,127,1>LFO2 Amt / Arp Range CC25
slider27:0<0,127,1>Mod Attack CC26
slider28:127<0,127,1>Mod Decay CC27
slider29:0<0,3,1{Osc2,FM,PW,off}>Mod Destination CC28
slider30:64<0,127,1>Mod Amount CC29
slider31:1<0,3,1{Pulse,Sawtooh,Triangle,Sine}>Osc 1 Waveform CC30
slider32:1<0,3,1{Pulse,Sawtooh,Triangle,Noise}>Osc 2 Waveform CC31
slider33:0<0,127,1>-slider33 CC32
slider34:64<0,127,1>Osc 2 fine tune CC33
slider35:0<0,1,1{off,ON}>Osc 2 keytrack CC34
slider36:0<0,3,1{off,Sync,Ring,SyncRng}>Osc Ring / Sync CC35
slider37:64<0,127,1>Amp Decay CC36
slider38:127<0,127,1>Amp Sustain CC37
slider39:0<0,127,1>FLT Attack CC38
slider40:64<0,127,1>FLT Decay CC39
slider41:127<0,127,1>FLT Sustain CC40
slider42:0<0,127,1>FLT Release CC41
slider43:0<0,127,1>Resonance CC42
slider44:64<0,127,1>Env Amt CC43
slider45:0<0,4,1{LP 12 db,LP 24 db,HP 24 db,BP,Notch + LP}>Filter Type CC44
slider46:0<0,1,1{off,ON}>Velocity CC45
slider47:0<0,3,1{off,1/3,2/3,full}>Kbd Track CC46
slider48:0<0,127,1>-slider48 CC47
slider49:0<0,127,1>-slider49 CC48
slider50:0<0,127,1>-slider50 CC49
slider51:0<0,127,1>-slider51 CC50
slider52:0<0,127,1>-slider52 CC51
slider53:0<0,127,1>-slider53 CC52
slider54:0<0,127,1>-slider54 CC53
slider55:0<0,127,1>-slider55 CC54
slider56:0<0,127,1>-slider56 CC55
slider57:0<0,127,1>-slider57 CC56
slider58:0<0,127,1>-slider58 CC57
slider59:0<0,127,1>-slider59 CC58
slider60:0<0,127,1>-slider60 CC59
slider61:0<0,127,1>-slider61 CC60
slider62:0<0,127,1>-slider62 CC61
slider63:0<0,127,1>-slider63 CC62
slider64:0<0,127,1>-slider64 CC63

desc:CCEnv (Nord Lead 2) B

slider1:0<0,127,1>-slider1 CC64
slider2:0<0,1,1{off,ON}>Auto Portamento CC65
slider3:0<0,127,1>-slider3 CC66
slider4:0<0,127,1>-slider4 CC67
slider5:0<0,127,1>-slider5 CC68
slider6:0<0,127,1>-slider6 CC69
slider7:0<0,127,1>FM Amt / Tune CC70
slider8:0<0,127,1>-slider8 CC71
slider9:0<0,127,1>Amp Release CC72
slider10:0<0,127,1>Amp Attack CC73
slider11:127<0,127,1>Cutoff Frequency CC74
slider12:0<0,127,1>-slider12 CC75
slider13:0<0,127,1>-slider13 CC76
slider14:0<0,127,1>-slider14 CC77
slider15:60<0,120,1>Semi/ NoisClr/ Sync wfm sel CC78
slider16:0<0,127,1>Osc1 PW CC79
slider17:0<0,1,1{off,ON}>Distortion on/off CC80
slider18:0<0,127,1>-slider18 CC81
slider19:0<0,127,1>-slider19 CC82
slider20:0<0,127,1>-slider20 CC83
slider21:0<0,127,1>-slider21 CC84
slider22:0<0,127,1>-slider22 CC85
slider23:0<0,127,1>-slider23 CC86
slider24:0<0,127,1>-slider24 CC87
slider25:0<0,127,1>-slider25 CC88
slider26:0<0,127,1>-slider26 CC89
slider27:0<0,127,1>-slider27 CC90
slider28:0<0,127,1>-slider28 CC91
slider29:0<0,127,1>-slider29 CC92
slider30:0<0,127,1>-slider30 CC93
slider31:0<0,127,1>-slider31 CC94
slider32:0<0,127,1>-slider32 CC95
slider33:0<0,127,1>-slider33 CC96
slider34:0<0,127,1>-slider34 CC97
slider35:0<0,127,1>-slider35 CC98
slider36:0<0,127,1>-slider36 CC99
slider37:0<0,127,1>-slider37 CC100
slider38:0<0,127,1>-slider38 CC101
slider39:0<0,127,1>-slider39 CC102
slider40:0<0,127,1>-slider40 CC103
slider41:0<0,127,1>-slider41 CC104
slider42:0<0,127,1>-slider42 CC105
slider43:0<0,127,1>-slider43 CC106
slider44:0<0,127,1>-slider44 CC107
slider45:0<0,127,1>-slider45 CC108
slider46:0<0,127,1>-slider46 CC109
slider47:0<0,127,1>-slider47 CC110
slider48:0<0,127,1>-slider48 CC111
slider49:0<0,127,1>-slider49 CC112
slider50:0<0,127,1>-slider50 CC113
slider51:0<0,127,1>-slider51 CC114
slider52:0<0,127,1>-slider52 CC115
slider53:0<0,127,1>-slider53 CC116
slider54:0<0,127,1>-slider54 CC117
slider55:0<0,127,1>-slider55 CC118
slider56:0<0,127,1>-slider56 CC119
slider57:0<0,127,1>-slider57 CC120
slider58:0<0,127,1>-slider58 CC121
slider59:0<0,127,1>-slider59 CC122
slider60:0<0,127,1>-slider60 CC123
slider61:0<0,127,1>-slider61 CC124
slider62:0<0,127,1>-slider62 CC125
slider63:0<0,127,1>-slider63 CC126
slider64:0<0,127,1>-slider64 CC127



In the end, these would be nice minor tweaks to something that is already working perfectly. Thanks for making this possible!

Pat


----------



## gabriel101x

pmcrockett said:


> So, the issue is that the input plugin isn't distinguishing among the possible output plugins it can send data to, and it doesn't naturally know which instances of the output plugins are in its own signal chain because plugins don't know what tracks they exist on. And the data can't be passed down the chain as normal MIDI data because the whole point is to avoid doing that. It's a problem leftover from the original code that I didn't catch in my modifications.
> 
> There are a few possible approaches to fixing it. The most straightforward is either to have the user manually set ID numbers on each plugin instance so the input plugins know which output plugins to route their data to, or to have a sync button on each plugin where you would press sync on the input plugin and it would match to the next output plugins that you pressed sync on. Or possibly instruct the user to briefly turn on record monitoring during plugin setup, which would let the input plugin send a MIDI signal down the chain to see which output plugins were in the chain with it.
> 
> Another possibility would be to add a Lua component that runs in the background independently of the plugins and tells each plugin what track it's on (ReaScript can gather this sort of data, whereas JSFX can't). It would be a little cumbersome to have a separate script that needs to run in addition to the plugins, though, so I'd like to avoid this if I can.
> 
> The best solution, which I haven't thought through in detail yet because I've never done audio processing in JSFX before, is that I may be able to use the audio output routing from the plugins to send the MIDI data as a dummy audio signal that won't actually be output as sound but will properly travel down the signal chain to be read by the appropriate output plugin.
> 
> I'll explore these options and make the fix when I'm able, but unfortunately my current job situation has left me without much free time to work on these sorts of projects, so I can't guarantee any kind of timetable on this.
> 
> EDIT: Just realized that Reaper lets you set the record mode to record the MIDI output rather than input. Haven't played around with it yet, but this might let me restructure the entire plugin so it all sits in the output FX section, which would make everything a lot simpler.



Is there any update on a possible fix for this?
At the moment I'm using a workaround which is not using the input plugin and only the main FX chain part. Then I just midi learn the sliders in the plugin. This works perfectly except that it actually writes cc date to midi items on the track as well as sending it. So I have to either record with the track not armed or just delete the CC data from the item after I finish recording and then it still keeps working fine.

Edit:

I actually found this JS script by DarkStar over on the forums that eats the midi cc data preventing it from being written to the items. I'm just trying to work out how to modify it so I can still record sustain pedal CC



Code:


desc:midi CC eater

@init
  CC_MSG =11;
@slider

@block
while (
  midirecv(ts, msg1, msg23) ? (
    msg = (msg1 / 16) | 0;
    msg_num = msg23 & 127;
    !(msg == CC_MSG && msg_num < 120) ? midisend(ts, msg1, msg23);
    temp=1;
 );
);


----------



## Fujosej

gabriel101x said:


> This works perfectly except that it actually writes cc date to midi items on the track as well as sending it. So I have to either record with the track not armed or just delete the CC data from the item after I finish recording and then it still keeps working fine.



You could try a pizmidi's MidiNotchfilter from the zip folder , and filter all cc data on each track and just midi learn the required ones. Thats a legit workaround i guess. The only downside is you have to manually add necessary CC's and learn them as well. But other than that it works ok i guess. 

But it still not a perfect solution , would be nice to have a fix for pmcrockett - CCenv_input.jsfx script.


----------



## pmcrockett

I'll try to find some time in the coming week to take another look at this.


----------



## gabriel101x

Fujosej said:


> You could try a pizmidi's MidiNotchfilter from the zip folder , and filter all cc data on each track and just midi learn the required ones. Thats a legit workaround i guess. The only downside is you have to manually add necessary CC's and learn them as well. But other than that it works ok i guess.
> 
> But it still not a perfect solution , would be nice to have a fix for pmcrockett - CCenv_input.jsfx script.



Omg thank you so much, I've been trying to find this script everywhere but the website no longer exists for it.


----------



## Fujosej

pmcrockett said:


> I'll try to find some time in the coming week to take another look at this.


awesome , thank you!


gabriel101x said:


> Omg thank you so much, I've been trying to find this script everywhere but the website no longer exists for it.


No problem, hope it works.


----------



## gabriel101x

Fujosej said:


> awesome , thank you!
> 
> No problem, hope it works.



Didn't the first time I loaded and set it up but then it magically started working later..


----------



## pmcrockett

impakt said:


> Thanks to pmcrockett and his CCenv, I am now able to record automation with my outboard gears such as a Nord Lead 2. It's working really great!
> 
> Below are the parameter definitions for anyone who may find it useful.
> 
> Here is a question about possible optimisation:
> 
> For Nord Lead 2, only seven parameters are needed from the cc64-cc127 JS, and cc47-cc63 are unused. The first CCenv would have plenty of room to account for cc70-80.
> 
> Can the code be altered in a simple way so that, for example, cc50-cc63 becomes cc70-83? I'm guessing a simple math formula will do?
> 
> This would help immensely because then Synth settings can be stored, recalled, and transmitted with a single JS preset. I hope it can work out this way.
> 
> 
> 
> Code:
> 
> 
> desc:CCEnv (Nord Lead 2) A
> 
> slider1:0<0,127,1>-slider1 CC0
> slider2:0<0,127,1>-Modwheel CC1
> slider3:0<0,127,1>-Breath Ctrl CC2
> slider4:0<0,127,1>-slider4 CC3
> slider5:0<0,127,1>-slider5 CC4
> slider6:0<0,127,1>Portamento CC5
> slider7:0<0,127,1>-slider7 CC6
> slider8:100<0,127,1>Gain CC7
> slider9:0<0,127,1>Oscillator Mix CC8
> slider10:0<0,127,1>-slider10 CC9
> slider11:0<0,127,1>-slider11 CC10
> slider12:0<0,127,1>-slider12 CC11
> slider13:0<0,127,1>-slider13 CC12
> slider14:0<0,127,1>-slider14 CC13
> slider15:0<0,127,1>-slider15 CC14
> slider16:0<0,2,1{Mono,Legato,Poly}>-Oscillator Mode CC15
> slider17:0<0,1,1{off,ON}>-Unison CC16
> slider18:0<0,127,1>-slider18 CC17
> slider19:0<0,4,1{Filter,FM,OSC2,LFO1,Morph}>-ModWh Destination CC18
> slider20:80<0,127,1>LFO1 Rate CC19
> slider21:0<0,4,1{S&H,Saw,Tri,Sqr,soft Rnd>LFO1 Waveform CC20
> slider22:0<0,4,1{PW,Filter,Osc2,Osc1+2,FM>LFO1 Destination CC21
> slider23:0<0,127,1>LFO1 Amount CC22
> slider24:80<0,127,1>LFO2 Rate CC23
> slider25:0<0,8,1{hold-DN,hold-UP,UP,hold-UD,AMP,Osc1+2,hold-RND,hold-Echo,Filter,Arp Off (filter)}>LFO2 hold / dest CC24
> slider26:0<0,127,1>LFO2 Amt / Arp Range CC25
> slider27:0<0,127,1>Mod Attack CC26
> slider28:127<0,127,1>Mod Decay CC27
> slider29:0<0,3,1{Osc2,FM,PW,off}>Mod Destination CC28
> slider30:64<0,127,1>Mod Amount CC29
> slider31:1<0,3,1{Pulse,Sawtooh,Triangle,Sine}>Osc 1 Waveform CC30
> slider32:1<0,3,1{Pulse,Sawtooh,Triangle,Noise}>Osc 2 Waveform CC31
> slider33:0<0,127,1>-slider33 CC32
> slider34:64<0,127,1>Osc 2 fine tune CC33
> slider35:0<0,1,1{off,ON}>Osc 2 keytrack CC34
> slider36:0<0,3,1{off,Sync,Ring,SyncRng}>Osc Ring / Sync CC35
> slider37:64<0,127,1>Amp Decay CC36
> slider38:127<0,127,1>Amp Sustain CC37
> slider39:0<0,127,1>FLT Attack CC38
> slider40:64<0,127,1>FLT Decay CC39
> slider41:127<0,127,1>FLT Sustain CC40
> slider42:0<0,127,1>FLT Release CC41
> slider43:0<0,127,1>Resonance CC42
> slider44:64<0,127,1>Env Amt CC43
> slider45:0<0,4,1{LP 12 db,LP 24 db,HP 24 db,BP,Notch + LP}>Filter Type CC44
> slider46:0<0,1,1{off,ON}>Velocity CC45
> slider47:0<0,3,1{off,1/3,2/3,full}>Kbd Track CC46
> slider48:0<0,127,1>-slider48 CC47
> slider49:0<0,127,1>-slider49 CC48
> slider50:0<0,127,1>-slider50 CC49
> slider51:0<0,127,1>-slider51 CC50
> slider52:0<0,127,1>-slider52 CC51
> slider53:0<0,127,1>-slider53 CC52
> slider54:0<0,127,1>-slider54 CC53
> slider55:0<0,127,1>-slider55 CC54
> slider56:0<0,127,1>-slider56 CC55
> slider57:0<0,127,1>-slider57 CC56
> slider58:0<0,127,1>-slider58 CC57
> slider59:0<0,127,1>-slider59 CC58
> slider60:0<0,127,1>-slider60 CC59
> slider61:0<0,127,1>-slider61 CC60
> slider62:0<0,127,1>-slider62 CC61
> slider63:0<0,127,1>-slider63 CC62
> slider64:0<0,127,1>-slider64 CC63
> 
> desc:CCEnv (Nord Lead 2) B
> 
> slider1:0<0,127,1>-slider1 CC64
> slider2:0<0,1,1{off,ON}>Auto Portamento CC65
> slider3:0<0,127,1>-slider3 CC66
> slider4:0<0,127,1>-slider4 CC67
> slider5:0<0,127,1>-slider5 CC68
> slider6:0<0,127,1>-slider6 CC69
> slider7:0<0,127,1>FM Amt / Tune CC70
> slider8:0<0,127,1>-slider8 CC71
> slider9:0<0,127,1>Amp Release CC72
> slider10:0<0,127,1>Amp Attack CC73
> slider11:127<0,127,1>Cutoff Frequency CC74
> slider12:0<0,127,1>-slider12 CC75
> slider13:0<0,127,1>-slider13 CC76
> slider14:0<0,127,1>-slider14 CC77
> slider15:60<0,120,1>Semi/ NoisClr/ Sync wfm sel CC78
> slider16:0<0,127,1>Osc1 PW CC79
> slider17:0<0,1,1{off,ON}>Distortion on/off CC80
> slider18:0<0,127,1>-slider18 CC81
> slider19:0<0,127,1>-slider19 CC82
> slider20:0<0,127,1>-slider20 CC83
> slider21:0<0,127,1>-slider21 CC84
> slider22:0<0,127,1>-slider22 CC85
> slider23:0<0,127,1>-slider23 CC86
> slider24:0<0,127,1>-slider24 CC87
> slider25:0<0,127,1>-slider25 CC88
> slider26:0<0,127,1>-slider26 CC89
> slider27:0<0,127,1>-slider27 CC90
> slider28:0<0,127,1>-slider28 CC91
> slider29:0<0,127,1>-slider29 CC92
> slider30:0<0,127,1>-slider30 CC93
> slider31:0<0,127,1>-slider31 CC94
> slider32:0<0,127,1>-slider32 CC95
> slider33:0<0,127,1>-slider33 CC96
> slider34:0<0,127,1>-slider34 CC97
> slider35:0<0,127,1>-slider35 CC98
> slider36:0<0,127,1>-slider36 CC99
> slider37:0<0,127,1>-slider37 CC100
> slider38:0<0,127,1>-slider38 CC101
> slider39:0<0,127,1>-slider39 CC102
> slider40:0<0,127,1>-slider40 CC103
> slider41:0<0,127,1>-slider41 CC104
> slider42:0<0,127,1>-slider42 CC105
> slider43:0<0,127,1>-slider43 CC106
> slider44:0<0,127,1>-slider44 CC107
> slider45:0<0,127,1>-slider45 CC108
> slider46:0<0,127,1>-slider46 CC109
> slider47:0<0,127,1>-slider47 CC110
> slider48:0<0,127,1>-slider48 CC111
> slider49:0<0,127,1>-slider49 CC112
> slider50:0<0,127,1>-slider50 CC113
> slider51:0<0,127,1>-slider51 CC114
> slider52:0<0,127,1>-slider52 CC115
> slider53:0<0,127,1>-slider53 CC116
> slider54:0<0,127,1>-slider54 CC117
> slider55:0<0,127,1>-slider55 CC118
> slider56:0<0,127,1>-slider56 CC119
> slider57:0<0,127,1>-slider57 CC120
> slider58:0<0,127,1>-slider58 CC121
> slider59:0<0,127,1>-slider59 CC122
> slider60:0<0,127,1>-slider60 CC123
> slider61:0<0,127,1>-slider61 CC124
> slider62:0<0,127,1>-slider62 CC125
> slider63:0<0,127,1>-slider63 CC126
> slider64:0<0,127,1>-slider64 CC127
> 
> 
> 
> In the end, these would be nice minor tweaks to something that is already working perfectly. Thanks for making this possible!
> 
> Pat


Sorry for not getting to this back when you first posted it.

It's definitely possible to do a simple code rewrite to accomplish this. I'll post that rewrite along with the general update once I've completed the routing bugfix that I'm working on.

I've considered implementing customizable CC sliders so the user could redefine what sliders control what CCs, but as far as I know the sliders can't be renamed later in the code once they've been defined, so that would mean I wouldn't be able to have the actual CC names show up in the automation view, which would be really inconvenient.





As far as the routing issue goes, I've worked out a system that automatically routes the plugin instances properly. I still need to finish testing it and integrate it with the rest of the code, but I think the underlying issues causing the routing bug are basically resolved, and the update should have minimal impact on the user experience (which is to say, you won't need to manually set instance ID numbers -- things should just work). I'll try to get it finished tomorrow, but it may get pushed back to next weekend if I encounter unexpected problems.


----------



## pmcrockett

This update fixes the routing bug, makes the plugin window size correct by default, and includes a version of the output plugin that can be easily edited to customize slider/CC pairings.

Routing from the input plugin to the output plugins happens automatically when you add the plugins. In order to make sure the plugins route correctly, you should think of the three plugins as being effectively a single plugin. If you add one, immediately add the other two. If you delete one, delete all three. If you copy/paste them, copy/paste all three from the same source track. Basically, a new plugin will route to the next two plugins that are added, so as long as you aren't splitting those groups of three up when adding/deleting, you shouldn't run into any problems.

You must add both CCEnv (CC0-CC63) and CCEnv (CC64-CC127) even if you're using the CCs on only one of them. If you want to get rid of one of them, use the customizable plugin instead. The customizable plugin replaces both CCEnv (CC0-CC63) and CCEnv (CC64-CC127), so you'll be dealing with only two total plugins instead of three if you choose to use it.


----------



## DynamicK

Thanks for the update. If I am using this with Kontakt in Multi Timbral Mode, would I need to have this on the Midi Tracks feeding Kontakt?


----------



## pmcrockett

DynamicK said:


> Thanks for the update. If I am using this with Kontakt in Multi Timbral Mode, would I need to have this on the Midi Tracks feeding Kontakt?


Yes, you would need separate instances on each track feeding Kontakt. And you would need a separate track for each Kontakt instrument you're controlling rather than using different MIDI channels on the same track, because the track envelope automation in Reaper doesn't distinguish among MIDI channels. CCEnv outputs to MIDI channel 1, but if you need to change that in order to route to the correct Kontakt instrument, you can add the factory JSFX plugin named MIDI Router/Transpose immediately after CCEnv (CC0-CC63) and CCEnv (CC64-CC127) to move the MIDI data to a different channel.


----------



## Jaybee

pmcrockett said:


> This update fixes the routing bug, makes the plugin window size correct by default, and includes a version of the output plugin that can be easily edited to customize slider/CC pairings.
> 
> Routing from the input plugin to the output plugins happens automatically when you add the plugins. In order to make sure the plugins route correctly, you should think of the three plugins as being effectively a single plugin. If you add one, immediately add the other two. If you delete one, delete all three. If you copy/paste them, copy/paste all three from the same source track. Basically, a new plugin will route to the next two plugins that are added, so as long as you aren't splitting those groups of three up when adding/deleting, you shouldn't run into any problems.
> 
> You must add both CCEnv (CC0-CC63) and CCEnv (CC64-CC127) even if you're using the CCs on only one of them. If you want to get rid of one of them, use the customizable plugin instead. The customizable plugin replaces both CCEnv (CC0-CC63) and CCEnv (CC64-CC127), so you'll be dealing with only two total plugins instead of three if you choose to use it.



Thanks! I've hit a bug here though:

I'm using CCEnv_input and the two main CCEnv (CC0-CC63) and CCEnv (CC64-CC127) in my main template tracks. Replacing the April 2018 CCEnv versions with these new ones has now stopped the template envelope recording working completely i.e. I can have CC1 & 11 checked in CCEnv_input, the track set to latch and armed but my cc sliders have no effect at all, no envelopes appear or record.

However, on a new project, a _pre-existing track template_ with exactly the same setup including CCEnv_input and the two main CCEnv (CC0-CC63) and CCEnv (CC64-CC127) sliders is working fine. Envelopes trigger and record. CC64 behaves!

Returning to the older April versions the CCEnv instances in my template return to normal operation.

I'm baffled..

Other tests: Adding new CCEnv_input and CCEnv (CC0-CC63) and CCEnv (CC64-CC127) to an existing template track (that previously had no CCEnv control): not working.

Adding the same track template with CCEnv etc that works fine as a single track in a brand new project into the template: not working

So it seems to baulk at my template which is essentially nothing more than a couple of hundred tracks from the track templates that work on their own...

**Update**

OK narrowing this down a bit, it seems that the template project is still seeing the *old* CCEnv_Input. If I right click it and choose "replace FX" and then select CCEnv_Input (same name exactly) from the JS folder it starts working.

Why doesn't Reaper automatically update the JS folder? I tried a re-scan (clear cache) but that only seems to work on the VST folders. How can Reaper see an old plugin that no longer exists...??!! If I can't get Reaper to 'see' the new jsfx I'll have to do this manually on hundreds of tracks.... aaargh!


----------



## Jaybee

OK, falling on the mercy of @pmcrockett as I am officially all out of ideas. I've tried just about everything over the last 12 hours but here's the bottom line. 

The new version just refuses to work with _any_ track in my existing template. I've tried to overwrite (replace fx), remove the plugs, save, then re-add as if it were a new track. I thought doing this track by track in *batches of three* as per the instructions would cure it but no. On a fully armed and latched "ready to go" track with the new plugs I can see the new GUI this way (all 127 checkboxes) and sometimes I'll get envelopes appear for those checked (1 & 11 to test) but absolutely no movement just one line at a fixed amount. They are unresponsive to my CC1 & 11 controller. Most of the time though the envelopes fail to appear at all. 

I thought this might be the sheer number of tracks so I've cut my template down to just one solitary random track and even that track on it's lonesome refuses to work. I've attached the .RPP so you can see how I'm wired in. Set this track to latch or write and nothing happens.... 

On a brand new project however, a brand new track with any VI (Kontakt or a synth) adding the three new CCEnv plugs works first time. 

I was hoping the workaround would be to just "replace FX" on all my existing tracks but that's not happening either. As an early adopter of 'CCEnv' (I found the original basic script and posted it here in August 2016) it's really embedded into my entire workflow. Really really don't want to have to spend X weeks rebuilding and rewiring this damn template again. I'd rather live with the CC64 bug but it would be a shame if this was a real showstopper. 

Appealing to anyone else out there using CCenv. Has the update worked for you *in an old existing project*??


----------



## pmcrockett

Best I can tell at this point, the problem is caused by the fact that the new version of CCEnv assigns the ID numbers that tell it which plugins match each other upon initial instantiation and not on project/template load. The templates saved with previous versions aren't loading properly because the plugins need data -- the IDs -- that didn't exist when the templates were saved, and the failed load may also be affecting the plugin's subsequent attempts to assign IDs to newly created plugins because it's not seeing what it expects to see in memory.

I'll look into whether I can make the plugins create IDs on project load. This should be possible as long as Reaper loads project plugins in a consistent and predictable order when the project/template loads. I'll run tests and see what I can figure out, so don't manually update your templates just yet. At worst, I may be able to whip up a ReaScript that will at least batch delete and re-add the plugins on any tracks in the project so you don't have to manually reinsert everything.

Thanks for bearing with me on this; planning for backwards compatibility is something that I don't yet have a lot of experience with, so I'm learning this as I go.


----------



## Jaybee

Thanks so much. It's good to have an idea what's causing the old project to stall. I thought I had found it so many times only to be thwarted upon testing.... ha!  Have rolled back to the April version so no rush whatsoever, so appreciate your hard work in getting this workable envelope solution for Reaper. Cheers


----------



## InLight-Tone

What a mess, and the very reason why I can't get on with Reaper despite numerous attempts and long periods of trying. These things should be natively coded, and there's way too much of this going on for critical functionality...


----------



## robgb

Latest version works great for me so far. Thanks!


----------



## gregh

excuse the probably dumb question - but what is the advantage of using midi CC rather than the native Reaper automation to automate instruments and fx?

(outside of the usual performance CCs like velocity)


----------



## robgb

gregh said:


> excuse the probably dumb question - but what is the advantage of using midi CC rather than the native Reaper automation to automate instruments and fx?


I'm not sure there is an advantage, frankly, except that it's SLIGHTLY easier to deal with points than it is the bars in the native automation. At least I thought that until I realized that a great way of making the bars easier to deal with is to simply turn off the "select single CC" function. Now drawing those bars is a breeze without a single glitch. So after dealing with envelopes and points for some time, I switched back to the native way of doing things.


----------



## gabriel101x

robgb said:


> I'm not sure there is an advantage, frankly, except that it's SLIGHTLY easier to deal with points than it is the bars in the native automation. At least I thought that until I realized that a great way of making the bars easier to deal with is to simply turn off the "select single CC" function. Now drawing those bars is a breeze without a single glitch. So after dealing with envelopes and points for some time, I switched back to the native way of doing things.



The advantage is being able to record over it. If you try to record over the bars to overwrite automation it things get very messy.


----------



## robgb

gabriel101x said:


> The advantage is being able to record over it. If you try to record over the bars to overwrite automation it things get very messy.


Interesting. I've never found a need to overdub CC data. Seems like a counter-intuitive way to do it. I simply draw in the new CC curves. That said, the question may be moot. It looks as if Reaper will soon be switching to CC envelopes instead of the bars. There are a couple pre-release versions that utilize the CC envelope method and although it's been taken out, they've promised it will return in later versions. I'm playing around with one as we speak.


----------



## gabriel101x

robgb said:


> Interesting. I've never found a need to overdub CC data. Seems like a counter-intuitive way to do it. I simply draw in the new CC curves. That said, the question may be moot. It looks as if Reaper will soon be switching to CC envelopes instead of the bars. There are a couple pre-release versions that utilize the CC envelope method and although it's been taken out, they've promised it will return in later versions. I'm playing around with one as we speak.



Among composers it's common practice to record midi data like CC exclusively with physical faders.


----------



## robgb

gabriel101x said:


> Among composers it's common practice to record midi data like CC exclusively with physical faders.


Among some composers, apparently. I always record it initially as I play, then draw in the corrections.

By the way, if you really need to do it, just create a child track and record the CC info there.


----------



## Dementum

So I implemented the CCEnv Script onto many tracks but for some reasons it sometimes just set all CC Values to 0 on a "random" track (no idea if its actually random or something is happening). I put ReaControlMIDI for loggin it and it was only channel 0-63 (so one of the plugins) which got caught. Most of those tracks are not even enabled in the Input Plugin. Here is the readout of the MIDI log:



Spoiler: MIDILogText



0: B0 00 00 [CC0 Bank Select MSB] chan 1 val 0
1: B0 20 00 [CC32 Bank Select LSB] chan 1 val 0
2: B0 01 00 [CC1 Mod Wheel MSB] chan 1 val 0
3: B0 02 00 [CC2 Breath MSB] chan 1 val 0
4: B0 03 00 [CC3 MSB] chan 1 val 0
5: B0 04 00 [CC4 Foot Pedal MSB] chan 1 val 0
6: B0 05 00 [CC5 Portamento MSB] chan 1 val 0
7: B0 06 00 [CC6 Data Entry MSB] chan 1 val 0
8: B0 07 00 [CC7 Volume MSB] chan 1 val 0
9: B0 08 00 [CC8 Balance MSB] chan 1 val 0
10: B0 09 00 [CC9 MSB] chan 1 val 0
11: B0 0A 00 [CC10 Pan MSB] chan 1 val 0
12: B0 0B 00 [CC11 Expression MSB] chan 1 val 0
13: B0 0C 00 [CC12 Control 1 MSB] chan 1 val 0
14: B0 0D 00 [CC13 Control 2 MSB] chan 1 val 0
15: B0 0E 00 [CC14 MSB] chan 1 val 0
16: B0 0F 00 [CC15 MSB] chan 1 val 0
17: B0 10 00 [CC16 GP Slider 1 MSB] chan 1 val 0
18: B0 11 00 [CC17 GP Slider 2 MSB] chan 1 val 0
19: B0 12 00 [CC18 GP Slider 3 MSB] chan 1 val 0
20: B0 13 00 [CC19 GP Slider 4 MSB] chan 1 val 0
21: B0 14 00 [CC20 MSB] chan 1 val 0
22: B0 15 00 [CC21 MSB] chan 1 val 0
23: B0 16 00 [CC22 MSB] chan 1 val 0
24: B0 17 00 [CC23 MSB] chan 1 val 0
25: B0 18 00 [CC24 MSB] chan 1 val 0
26: B0 19 00 [CC25 MSB] chan 1 val 0
27: B0 1A 00 [CC26 MSB] chan 1 val 0
28: B0 1B 00 [CC27 MSB] chan 1 val 0
29: B0 1C 00 [CC28 MSB] chan 1 val 0
30: B0 1D 00 [CC29 MSB] chan 1 val 0
31: B0 1E 00 [CC30 MSB] chan 1 val 0
32: B0 1F 00 [CC31 MSB] chan 1 val 0
33: B0 21 00 [CC33 Mod Wheel LSB] chan 1 val 0
34: B0 22 00 [CC34 Breath LSB] chan 1 val 0
35: B0 23 00 [CC35 LSB] chan 1 val 0
36: B0 24 00 [CC36 Foot Pedal LSB] chan 1 val 0
37: B0 25 00 [CC37 Portamento LSB] chan 1 val 0
38: B0 26 00 [CC38 Data Entry LSB] chan 1 val 0
39: B0 27 00 [CC39 Volume LSB] chan 1 val 0
40: B0 28 00 [CC40 Balance LSB] chan 1 val 0
41: B0 29 00 [CC41 LSB] chan 1 val 0
42: B0 2A 00 [CC42 Pan LSB] chan 1 val 0
43: B0 2B 00 [CC43 Expression LSB] chan 1 val 0
44: B0 2C 00 [CC44 Control 1 LSB] chan 1 val 0
45: B0 2D 00 [CC45 Control 2 LSB] chan 1 val 0
46: B0 2E 00 [CC46 LSB] chan 1 val 0
47: B0 2F 00 [CC47 LSB] chan 1 val 0
48: B0 30 00 [CC48 GP Slider 1 LSB] chan 1 val 0
49: B0 31 00 [CC49 GP Slider 2 LSB] chan 1 val 0
50: B0 32 00 [CC50 GP Slider 3 LSB] chan 1 val 0
51: B0 33 00 [CC51 GP Slider 4 LSB] chan 1 val 0
52: B0 34 00 [CC52 LSB] chan 1 val 0
53: B0 35 00 [CC53 LSB] chan 1 val 0
54: B0 36 00 [CC54 LSB] chan 1 val 0
55: B0 37 00 [CC55 LSB] chan 1 val 0
56: B0 38 00 [CC56 LSB] chan 1 val 0
57: B0 39 00 [CC57 LSB] chan 1 val 0
58: B0 3A 00 [CC58 LSB] chan 1 val 0
59: B0 3B 00 [CC59 LSB] chan 1 val 0
60: B0 3C 00 [CC60 LSB] chan 1 val 0
61: B0 3D 00 [CC61 LSB] chan 1 val 0
62: B0 3E 00 [CC62 LSB] chan 1 val 0
63: B0 3F 00 [CC63 LSB] chan 1 val 0



The Problem is, that I even had some of those values automated on that track and it was still set to 0 for that one point.


----------



## Artemi

Hello!
When I use CCenv on the fx and load up some kontakt patch it adds up some others envelope lanes like

Fullmix volume, low eq mid eq high eq
Fullmix send, reverb return

so I have to turn off it manually, how to disable it? I only want CC1 and CC64 to show up in the track envelope lane.




EDIT: wow strange, it doesn't happen now, hmm


----------



## pmcrockett

My current recommendation on all things CCEnv is to use Reaper 6's native implementation of CC curves instead. That's the functionality that CCEnv was intended to provide, and now that Reaper has it natively there's not much reason to use CCEnv anymore.


----------



## Artemi

pmcrockett said:


> My current recommendation on all things CCEnv is to use Reaper 6's native implementation of CC curves instead. That's the functionality that CCEnv was intended to provide, and now that Reaper has it natively there's not much reason to use CCEnv anymore.


so there is a possibility to edit midi cc on the main track page? didn't know that


----------



## pmcrockett

Artemi said:


> so there is a possibility to edit midi cc on the main track page? didn't know that


The CC lanes can be edited from the inline MIDI editor in the main view -- right click a MIDI clip, then _Open items in editor > Open in inline editor_.


----------



## undarken

Hi and thanks for this thread. I'm having this issue with reaper 6 and i can't quite follow the resolve explained here... could some one kindly tell me how / where to implement the script or plugin please? I've used reaper 6 years (logic 25 years) and heavily customised it but not entered this part of the program before... always hated this recording of envelopes to the midi file though - logic nearly got me back just for it's elegance in dealing with envelopes. The other 99 percent of usage is firmly won by reaper  Please ... elp!


----------



## Henrik B. Jensen

undarken said:


> Hi and thanks for this thread. I'm having this issue with reaper 6 and i can't quite follow the resolve explained here... could some one kindly tell me how / where to implement the script or plugin please? I've used reaper 6 years (logic 25 years) and heavily customised it but not entered this part of the program before... always hated this recording of envelopes to the midi file though - logic nearly got me back just for it's elegance in dealing with envelopes. The other 99 percent of usage is firmly won by reaper  Please ... elp!


Reaper has smooth MIDI CC automation now. It was part of, I think, the latest update, so make sure you're running the latest version.

Edit:


----------



## undarken

THat - was an incredibly fast reply! Thank you. 
I've tried 6.14 latest (was using 6.13) but i still have the issue of recording cc data into the midi file when i only want notes... I use the envelope lanes to record and edit cc's, as i have midi and hotkeys all dedicatedto the envelope lane editing. Basically don't want anything but notes in the midi file - Is this possible? cheers, Mike


----------



## Henrik B. Jensen

undarken said:


> THat - was an incredibly fast reply! Thank you.
> I've tried 6.14 latest (was using 6.13) but i still have the issue of recording cc data into the midi file when i only want notes... I use the envelope lanes to record and edit cc's, as i have midi and hotkeys all dedicatedto the envelope lane editing. Basically don't want anything but notes in the midi file - Is this possible? cheers, Mike


There’s a menu item somewhere that lets you move CC data into it’s own lane, but I can’t remember where it’s at or what it’s called. 

If you right-click on a MIDI item, that might be it.

As for fast reply, that’s great  I don’t know an awful lot about stuff, so whenever there’s a question I can in fact answer, I rejoice


----------



## robgb

pmcrockett said:


> My current recommendation on all things CCEnv is to use Reaper 6's native implementation of CC curves instead. That's the functionality that CCEnv was intended to provide, and now that Reaper has it natively there's not much reason to use CCEnv anymore.


I'm actually finding that I prefer CCEnv over the native implementation. It's much easier to edit/control the envelope points, and includes all the benefits of envelope automation. CCEnv is what I wish the native implementation WAS.


----------



## pondinthestream

pmcrockett said:


> My current recommendation on all things CCEnv is to use Reaper 6's native implementation of CC curves instead. That's the functionality that CCEnv was intended to provide, and now that Reaper has it natively there's not much reason to use CCEnv anymore.


there was sooo much opposition to CC curves when first suggested many years ago as not being a true representation of discrete data


----------



## axb312

Is there a way/ script to smooth out already written CC data (by way of mod wheel) in reaper?


----------

