This Obsidian Preset Renders Incorrectly
https://www.dropbox.com/s/vaermbzb48tnr94/Pain in the Arse Preset.zip?dl=0
I've tried six ways to Sunday to try and make this preset render properly. It'll sound one pitch during playback, but render a different pitch during export. I'm using the latest version of Nanostudio 2, iPad Pro 11" (which means 48khz), 12.3.1. To test, try programming some notes in the bass range for a couple bars and render it. Simple. You'll see that it sounds different between playback and rendered.
I've never had this happen before. Is this a bug in Obsidian?
Comments
Have you tried changing your buffer latency? Sometimes that affects the sound during playback.
I gave it a try. High buffer setting was wonky. Others were fine.
i hear there just problem caused by high LFO rate modulating cutoff... this doesn't sound good at lower buffer sizes. I
Short story: you reached boundary of Obsidian's capabilies
)
Long story:
I'm not sure exactly what is happening there, i'll try explain it based on my knowledge so you get in general idea what is this about . But it may contain som not exactly right information or missinterpretations, so take it just as approximate description ;-)
In general - this is not bug in exact sense, it's more result of inevitable compromises because of CPU optimisations in Obsidian.
First thing - internal control rate (rate at which modulation value affects mod destination) is much lower than audio rate (just few ios synths on iOS are using audio rate modulation and the price is high CPU usage - like Zeeon, Model D)
If i good remember mod target values are updated just once per buffer - this causes artifacts if you push LFO to it's limit rate 60hz. I'm not able explain you exactly what is happening there cause i don't understand all implementation details (maybe LFO's fukl cycle at 60hz is longer than buffer size ?) , but high LFO rate in combination with small buffer doesn't sound good.
(during mixdown NS uses buffer size 128 - "low", which is hreat for very short snappy decay on envelopes - this works better with smaller buffer, but it is not that good for super fast LFO)
Only solution, at least to my knowledge, would be increasing control signals rate - for example update modulation values with every sample - which would mean significant amount of work + massive (negative) impact on CPU load ...
Generally - avoid filter or pitch modulated by fast lfo (close to it's maximum 60hz) with high amount (on small amount those issues are less noticeable).
On my iPad Air 1 the large buffer did not export properly but all other settings were fine. Seems kind of backwards.
It was the limit of the LFO looks like. I had a REALLY fast LFO modulating the filter 1 cutoff, and it just wouldn't work. Disconnected the LFO, and voila! It sounds normal when rendered now. Thank you all for helping me find the solution.
in my experience simple (not warped) waveforms (like unwaeped and unshifted saw) with just small amount works ok - check my patch "liquid resonance" - i usdd theee small amount of 60hz lfo > cutoff for obraining a different (more "analog-like") resonance and it works fine
proble is just with high amount of fast lfo - there is real boundary of Obsidian sonic range
It does help by cutting down the CPU, although now I wish there was a way to expand the sonic range just for certain patches. Perhaps a failsafe switch can be implemented in Obsidian.