Are there any CPU-efficient methods to reduce aliasing? Specifically in FM?

    Oct 13 2016 | 2:14 am
    So I made this multi-operator FM patch earlier this week, and it serves its base purpose, but it's also very prone to turning itself into an NES gunshot sound effect if it's given more than a little modulation. I'm really new to the whole DSP thing (About a month or two of studying during my breaks at work,) so correct me if I'm wrong, but I'm fairly certain it's an issue with aliasing. So I've tried upsampling a few times in poly~, and that does solve the problem, but it's at the cost of about 15-30% CPU. I also still seem to encounter lots of volume issues (clipping, clicks and pops regardless of phase being reset, extremely quiet output) regardless of the upsampling, which may be related, or just some obvious flaw in how I programmed it. Anyhow, as the title says, I was curious if anyone knows any ways to get better results besides just upsampling? It'd be appreciated. For reference, here's the patch in its current state. Sorry if it's a bit messy, it's not exactly a finished product...

    • Oct 13 2016 | 2:51 am
      NES gunshot or not, if oyu do FM or phase distortion using only sinewaves you should be fine.
      for smoothign stuff more that over nyquist apply a keytracked low pass filter....
    • Oct 13 2016 | 10:36 am
      Hello Noah,
      Multiplying a signal by events to control an amplitude is never a good idea because you'll obviously get cracks or at least zipping noise any time you turn the dials. Insert a "$1 50." message box and a line~ object between each dial and *~ object. Also, replacing send~ / receive~ objects by wired connections might help to reduce the charge on the CPU.
    • Oct 13 2016 | 10:55 am
      Oh I forgot this: if you replace your send~ to receive~ connections with wires, you'll have to insert a one-vector delay (which exists in the send~/receive~ connection already anyway). Insert a tapin~ 0. /tapout~ 0. couple of objects and that's it.
    • Oct 14 2016 | 2:00 am
      Thank you for pointing out the the line~ thing. I probably should have remembered to do that, but I've been so caught up on fixing the sound quality that I kind of put it to the way side.
      I'm not quite sure what replacing send~/receive~ would help though, unless their CPU usage increases significantly with upsampling (which I can sort of vaguely understand being a possibility). Either way I tried it with the tapin/tapout addition, and now I get no sound, and a "no tapin~ connected" error with each tapout~. Any idea how I implemented that wrong? (I put them in the receiver subpatches, FYI)
    • Oct 14 2016 | 6:06 am
      It does not function because the tapin~ 0/tapout~ 0 thing should be inserted on every "p routing" output, not just one in four.
      Like this:
    • Oct 14 2016 | 5:01 pm
      Oooh okay that makes sense. I'd been reading other threads about FM feedback where you mentioned the same thing, and I figured that meant I'd only really need it on the signals feeding directly into themselves. Sorry like I said I'm still new... been trying to balance my time with the trial between learning new stuff and making stuff with knowledge I already have (It seems I thought I had more knowledge about FM than I actually do...)