Jan 30 2006 | 2:49 pm
    I am trying to distort audio to create snapcracklepop associated with that audio. [bitshift~] does the trick at shifts of 1, 2 or 3 but I have no control over the amplitude [*~] seems to have no effect furthermore it often crashes the audio [bitand~ 2147483647 0] sometimes works but not always
    any one know how I can avoid crashes with this patch or have suggestions for another strategy for snapcracklepop?
    happy tunes, don malone
    it takes all of us

    • Jan 30 2006 | 4:13 pm
      On around Jan 30, 2006, at 15:49, don malone said something like: > I am trying to distort audio to create snapcracklepop associated with > that audio.
      Litter Power is built exactly for this task.
      Take a look at lp.nn~ (Swiss Army knife of signal degradation) and lp.ppp~ for your static. Add lp.gsss~ (dither) or other noise source (lp.pvvv~ or lp.pfff~ or lp.phhh~ for very dark noise) to taste.
      URI below. In your case, Don, all the interesting stuff is in Litter Power Pro.
      Best, Peter
      -------------- -------------- Peter Castine | ^ | Litter Power & Litter Bundle for Jitter | | iCE: Sequencing, Recording, and Interface Building | for Max/MSP | Extremely cool | |
    • Jan 31 2006 | 8:43 pm
      sorry if i got you wrong but ... a bitshift of 3 bits can cause an incredible volume, so try something around 0.00x for the [*~] to be able to control volume!
    • Feb 01 2006 | 7:55 am
      Peter Those are nice but not exactly what I was after. I want the crackle like lp.ppp~ but with the obvious relationship to the sound file like lp.nn~
      Roman Yes I am getting incredible volume that is uncontrolable even at [*~] 0.001 and that incredible volume crashes the audio
      I was hoping to avoid that with the [bitand~] Maybe someone with a better understanding of the bit structure could help with the anding. I am just cutting out the most significant bit. When I cut more (like the most significant byte) I get nothing.
      happy tunes, don malone
      it takes all of us
    • Feb 01 2006 | 10:11 am
      From what I'd read so far, it sounded like ppp~ and nn~ would fill the bill. Let's follow up on this off-list: tell me more about what you want to do and I'll see if I can help you. When you've got a solution, then let's share it with the list.
      The MSP bit-munging objects can be useful, but it's easy to forget that MSP is using floating point signals internally, not integers. Two different worlds.
      PS: I may be slow to respond today and tomorrow because of the realiTV opening in Transmediale, but I will get back to you!
      Best -- Peter
    • Feb 01 2006 | 4:05 pm
      yea that is what i vaguely guessed, and peter was able to find words for: you probably forgot that bitshift~ works on a float signal. the structure should be simple; the first value is the sign, the next seven are the socalled mantissa (used for reaching high dynamic range) and the last 24 are the .. well .. music.
      but it is hardly possible to cut off the mantissa or something, even you convert a signal to 24 bit integer inside MSP, the problem remains that butshoft would work the way you exspected only when the volume input isnt over 0.0 db :)
      -mein manta issa 110 PS!
    • Feb 13 2006 | 6:20 am
      Peter's [lp.ppp~] did work out with [peakamp~] to control the density.
      Also found some settings of [pong~] that work really well but the effect is very hard to maintain.
      Finally, [bitsafe~] helps keep [bitshift~] from becoming a bomb.
      happy tunes don
      it takes all of us