CC data not being recorded or played back as entered.

I originally posted this as a bug but I am thinking maybe I am doing something wrong. I play a midi wind controller which sends CC data in response to breath pressure to control volume and other parameters. When playing live or monitoring during recording, Obsidian responds smoothly and perfectly. But when I play back the recorded track it does not sound like it did when recording. Its full of pronounced zipper noise - I.e. you can hear discreet steps in the volume and it sounds bad. Grid is off so I am not quantizing anything. I am using CC2 mapped to Y axis controlling amp env level. Is there another controller - e.g. AT or CC7 - that would playback what was recorded? Or a different knob? Is there a setting somewhere that will smooth this out? I love the NS workflow and efficiency and Obsidian is one of the best responding wind controller synths out there. But I can’t produce a usable midi track with it from my wind controller. Please help. Thanks.

Comments

@boomer said:
I originally posted this as a bug but I am thinking maybe I am doing something wrong. I play a midi wind controller which sends CC data in response to breath pressure to control volume and other parameters. When playing live or monitoring during recording, Obsidian responds smoothly and perfectly. But when I play back the recorded track it does not sound like it did when recording. Its full of pronounced zipper noise - I.e. you can hear discreet steps in the volume and it sounds bad. Grid is off so I am not quantizing anything. I am using CC2 mapped to Y axis controlling amp env level. Is there another controller - e.g. AT or CC7 - that would playback what was recorded? Or a different knob? Is there a setting somewhere that will smooth this out? I love the NS workflow and efficiency and Obsidian is one of the best responding wind controller synths out there. But I can’t produce a usable midi track with it from my wind controller. Please help. Thanks.

Just to make sure, record quantization and edit grid quantization are separate settings, you can find record quantization settings here:

I agree. In particular it seems to affect quick sweeps across a largish CC range. It's as if there's some code to simplify the number of points. This generally works well enough with knob movements, which tend to move in the same direction over time anyway, but I suspect that and quick CC changes catch it out.

In a CC sweep from low to high using a MPD218 I count 15 recorded points (+1 for the start point) when there would have been 127 (or very close to that) CC messages received.

It's likely that in most cases this won't affect the performance, but controllers are becoming more expressive and I really hope this trend continues, and so this is likely to affect the quality of recording more frequently. For example controllers with aftertouch are now common and Mozaic lets me translate aftertouch into a CC (I use https://patchstorage.com/aftertouch-to-cc/ in Apematrix to do this) which then brings lots more life to leads and basslines. Generally I don't have enough control with aftertouch for any CC simplification to make a difference to me, but I'll bet other controllers and touch surfaces (Roli Seabord perhaps?) are more affected.

If there is a strong functional argument for simplifying the number of CCs recorded (and I suspect there is) then perhaps this could be made an option in the app settings? (Ie. by default the CCs are recorded as simplfied, but if you turn on the option then all CC messages are recorded. It would presumably live under midi settings, but it could be a general option or an option by controller. One of these will work best with the NS2 architecture.)

@boomer, it may not be ideal, but have you tried correcting the really bad zippering by re-drawing the CCs for that short section by hand? Just make sure you turn grid off (bottom left of the screen when you are editing the CC recording). This may be enough to make it usable.

Sorry for the essay... I doubt most people will read this far, but that's OK Summary:
1. it looks like boomer is correct
2. there's probably a good reason for it being this way for most people
3. that may not always be the case, so maybe there could be an option to record all CCs

If you managed to get this far, I have a chocolate fish waiting here for you on the kitchen table.... And yes almost all of you will have to google what that is, but it is safe for work https://en.wikipedia.org/wiki/Chocolate_fish

@Trigger_the_Monkey “it may not be ideal, but have you tried correcting the really bad zippering by re-drawing the CCs for that short section by hand? Just make sure you turn grid off (bottom left of the screen when you are editing the CC recording). This may be enough to make it usable.”

Problem is that it’s not a short section, it’s the entire performance. The wind controller puts out massive amounts of cc data that need to be in sync with the notes for the expressiveness to work. I have noticed that often the cc events the should occur right before a note on are missing which causes attacks to really sound bad.
Thanks much for concurring. It’s hard to get developers to pay attention to the needs of people like me since we are in such a minority. I’ve noticed that the increase in number of expressive keyboards is helping in that regard

Attached are 2 files that I think clearly demonstrate the problem. I recorded midi into NS and simultaneously recorded direct to audio into MultiTrack as an audio effect in the same track. LiveAudio is the direct to audio recording. MidiPlayback is the audio rendering of the midi track. The Obsidian response to midi cc is one of the best out there and I really, really want to use it. Hopefully fixing the midi recording is easy. Thanks much.