Poly~ and pre-DAC attenuation


    Feb 17 2006 | 12:49 pm
    Hi,
    I wonder whether anyone may be able to offer me some pointers when it comes to ensuring a multivoice poly~ doesn't clip on output? I have a groove~ patch within a 12 voice poly~ and understand that there may be occasions when the combined gain of the output of the poly~ may exceed 1. I've taken a look at the limi~ and tap.elixir~ objects, but it's unclear to me where I should place them (i.e inside or out of the poly~) and how exactly they would work. Can anyone post a working example?
    Thanks a lot,
    Chris.

    • Feb 17 2006 | 1:12 pm
      >I wonder whether anyone may be able to offer me some >pointers when it comes to ensuring a multivoice poly~ >doesn't clip on output? I have a groove~ patch within a 12 >voice poly~ and understand that there may be occasions when >the combined gain of the output of the poly~ may exceed 1. >I've taken a look at the limi~ and tap.elixir~ objects, but >it's unclear to me where I should place them (i.e inside or >out of the poly~) and how exactly they would work. Can >anyone post a working example? . did you check out normalize~?
    • Feb 18 2006 | 11:38 pm
      I've had the exact same issue. I wrote the following to get rid of this:
      make a buffer, pass the name of the buffer to a kpl_normalize instance in your poly~ patch,
      Here's a sample sine polysynth. test_kpl_normalize is needed by poly_normalize_test as the poly~ patcher.
      The first Let me know if you want the source to compile on windows.
      thanks
      _Mark
    • Feb 19 2006 | 9:23 pm
      Thanks for this, but I'm afraid I can't work out where the sample patch is! Is this possibly a mailing list/forum incompatability problem? (I'm looking at the forum post...)
      Chris
      ------------------------
      I've had the exact same issue. I wrote the following to get rid of this:
      make a buffer, pass the name of the buffer to a kpl_normalize instance in your poly~ patch,
      Here's a sample sine polysynth. test_kpl_normalize is needed by poly_normalize_test as the poly~ patcher.
      The first Let me know if you want the source to compile on windows.
      thanks
      _Mark
    • Feb 20 2006 | 7:21 pm
      Sorry, rookie mistake ;)
      I forget that there's no way of attaching files to a forum post. I use the mailing list... so I can receive files with no issues.
      I'll post the source / patch source tonight. I think that there should be some sort of mechanism that replaces my external built into poly~ I'm sure a whole lot of people would like to be able to normalize their poly~ output in a similar fashion. Or perhaps I'm missing something?
      _Mark
    • Feb 20 2006 | 9:10 pm
      Mark Pauley wrote: > I've had the exact same issue. I wrote the following to get rid of this: >
      Could you please repost the patches and include everything into a zip? files with no extensions get completely screwed through the mail, or paste them as text into the mail.
      Stefan
      --
      [][] [][][] [][] [][][] [][][][][][][][][][][][][][][]
      Stefan Tiedje Klanggestalter Electronic Composition & Improvisation
      /~~~~~ \ /|() ()| ))))) )| | |( \ /// _/)/ ))))) ___/ ///
      -------------------------x---- --_____-----------|----------- --(_|_ ----|-----|-----()---- -- _|_)----|-----()----------- ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France Phone at CCMIX +33-1-49 77 51 72
    • Feb 21 2006 | 5:25 pm
      Here's the source to the patchers:
      poly_normalize_test:
      test_kpl_normalize:
      The external is mac only.
      _Mark
    • Feb 21 2006 | 6:24 pm
      Yes, I sent exactly this mail earlier this morning, though I don't see it yet. It seems like it takes a message forever to make it through the mailing list pipe sometimes, often I actually get the mail in reverse order...
      _Mark