BUG? Reset CC on stop/play

[sqgl]

There is an option in Preferences | Audio | Midi Devices
whereby "On stop/play" you can tick a box to "reset CC" (Continuous Controller).

I unticked this box but still have a reset MIDI controller message generated at the start of every loop. Considering SPP sends a stop & start each loop iteration, this may be the above option not working. I have created a video illustrating the bug and reported it.

http://forum.cockos.com/project.php?issueid=3924

Can someone please reproduce this and tick the box in that thread?

[sqgl]

I've just had the same thing happen with non reset values. See the thread I mentioned.

EDIT - "tracker issue" actually, not "thread". Please limit any discussion there.

[dan_e10]

I am seeing the same or similar behavior (in 4.151). When playing a looped midi track, if I use a controller to send CC's, the CC I sent on the current loop will sometimes be reset to 0 on the start of the next loop. It does not occur every time though.
Dan

[dan_e10]

It looks like this was supposed to be fixed in 4.11 but I'm still seeing it in 4.151:

v4.11 - November 12 2011
+ [4.111 - November 13 2011] OSX64/Win64: stability fix
+ MIDI: fixed sending of excess pitch/note/cc resets on loop

Dan

[sqgl]

This came up in another thread called Does reaper send all notes off when relocating the play cursor in a loop? where I posted the following animated GIF.



A developer, responded, the gist of which is reproduced below. This is the place for discussion rather than me further hijacking that other thread (or adding confusion to the bug tracker post).

Originally Posted by gofer

Confirming that Reaper resets CC when a timeline loop repeats, even if "Reset CC on stop/play" is disabled in the prefs.

To be fair it should be mentioned that a loop repeat is not stop/play. Actually I have a hunch this is planned behavior and not a bug although it's outcome is understandably not good in some situations (similar to the reset messages at stop/play themselves which would need a rethink as well and also the item based search-back for the last sent CC which totally needs to work track-wide across items).

I suppose it would be wise to open this again as a feature request (for an option to disable the loop CC reset altogether and maybe for a way to define our own reset values).

In addition to my bug tracker post? Won't others consider that to be a double posting?

Originally Posted by gofer

I am trying to think of situations where this behavior is annoying to back up the urgency of such a request. It doesn't seem to bother many people (myself I didn't even notice it up to now).

One situation is when you intend to play an instrument live (or record) over a loop of pre-recorded CC values if the pre-recorded item starts later than the left loop edge or has no CC event to fall back to at it's start.
Are there more situations?

"Fall back to"? Sometimes it actually uses the last known value in the loop and inserts it at the start of the loop (ie not an actual reset). This new "initial" value sometimes gets "sticky" ie you cannot delete it and is described in the bug tracker report mentioned earlier.

Originally Posted by gofer

Are there more situations?

Playing an instrument through delay and you change the feedback via a continuous controller. Every loop restart would set feedback to zero.

[gofer]

The only thing I can develop is bad habits . I'm totally no dev, sqgl, just a mere user blessed with some moderation keys here in the forum.

With "fall back to" I meant that if you have a CC event at a point before or at the loop start time Reaper will reset to that value.

Like this situation in the upper pic:


The lower pic shows a situation I personally hate about Reaper's MIDI. It doesn't trace back across items. I reckon it's sort of a shameless plug here, but I just can't resist to mention it wherever it somehow fits

Trying to recreate the sticky reset values, but don't yet succeed.

[chrisharbin]

Ok, this has got me all confused now.

My controller is dropping messages in (117, 118, some others) when I'm recording. Is this what we are talking about? It's not the same as "midi learning/actions" where you set up stop, loop, record, etc. But those cc's are coming through.

So before I bother with anything further, this is what we are talking about? I thought I knew what this thread was about but now I just feel lost.

[sqgl]

Originally Posted by chrisharbin

My controller is dropping messages in (117, 118, some others) when I'm recording. Is this what we are talking about?

This thread is about Reaper adding (not dropping) messages. You may need to start a new thread to sort it out.

[chopstickkk]

Voted able to reproduce.

I've been getting the same behaviour here too. =(

It happens for me even though I've not recorded any CC changes, only tweaked knobs on a controller.

Developers - This is RUINING REAPER ENTIRELY for a small number of people.

Surely that is as important as a small issue that is causing minor grievance to a great number of people.

[chopstickkk]

Okay. Some, I think, new information.

I don't reckon it is tied in with just recorded CC data. I don't use any recorded CC data and I can reproduce what looks like the same bug.

Using a MIDI controller to control a VST parameters via CC (not via Reaper MIDI learn) I can recreate this bug thusly...

-Create a track and add a VST that has parameters that respond to CC
-Create an item with one midi note
-Set up a loop and press play
-Send CC data from MIDI controller to move parameter on VST making sure to move the controller when the playhead passes the note-on and the note-off!
-Jumping value occurs now on every end/beginning of loop
-Restart program to fix

Can anybody else confirm this?

[chopstickkk]

I've made a video of the behaviour here...

http://dl.dropbox.com/u/9600561/CCLoopingBug.swf

Here's a very simple project that adheres to the bug reproduction steps in the previous post. It uses ReaMidiControl if you have a MIDI controller that sends CC7 give it a try.

http://dl.dropbox.com/u/9600561/CCLoopingBugClean.RPP