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
That is strange. I’m curious, does it behave the same way if you use an AUv3 synth in NS2 instead of Obsidian?
Just to make sure, record quantization and edit grid quantization are separate settings, you can find record quantization settings here:
Yes. Real time quantize is set to off. The cc data does not look quantized. Just fewer events than I would expect.
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
Ok, this isn’t the first time this has come up, I’ll make sure this is seen.
@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
Well, personally I sometimes notice it on very quick knob movements but wind controllers are a whole different ballgame, so I do empathize. I hope this is not too difficult to accommodate. 🙂
Good example - I can understand how this would make a huge difference.
Thanks @Stiksi
If it turns out to be difficult to implement, it would be good to know that as well.
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.
I just noticed the zipper noise is directly related to the buffer latency setting. The lower the latency the worse the cc response. This is true even if there is nothing else running on the iPad, there is only one track in ns2, and audio cpu usage is < 7%. It’s even true if the ns2 is stopped and you just monitoring in real time. To reproduce just assign cc1 to maximimum control filter cutoff and amp level. hold note on your controller and move the mod wheel quickly. Adjust the buffer latency and repeat. If I record at lower latency and playback at high the zipper noise lessens but never completely goes away. The reverse is also true which tells me midi data resolution my not be the issue. Could be the audio rendering rules. The bad news is that mixdown produces zipper noise you get at the lowest latency settings no matter what it’s actually set to. So it might sound acceptable in playback but the mixdown sounds bad. I have tried mixdown at higher bits and sample rates but nothing helps. Looking for a workaround and getting frustrated. Any ideas?
Mixdown always uses very low latency, that’s not a user selectable setting. You could record the sound output with high buffer to another app using audiobus.
Eeek! Are there any plans to fix this or provide some kind of high quality but slower mixdown option? I would have expected what-you-hear-is-what-you-get on mixdowns. I will use audiobus going forward.
The understanding so far has been that lowest buffer = least problems and best quality. For example, quick attack and decay times work more reliably the shorter the buffer is. This has been the first report of it going the other way around, but it’s certainly something to take seriously. I’ll let Matt know about this additional info and I hope it goes on from there.
That is probably true of pure audio but this is about rendering from midi. Why would buffer latency impact midi response? This is not the crackling you get from audio latency too low when the processor gets overloaded. This is straight ahead midi zipper noise that is unrelated to how busy the processor is. It’s also unrelated to the number of midi events which I originally thought. Here is an archive that demonstrates. It requires just 1 note and 3 cc events spread over about 1 second. There are 2 scenarios that alternate in a loop so you can hear the impact of changing the latency as it runs. One is a slope and the other immediate 0 to 127 change. Only the sloped one is impacted. Let me know if the attachment does not come through and i will email it to you. Thanks for listening and sorry for being a pain about this.