Need help cleaning up a Gen patch


    Feb 15 2018 | 4:19 am
    So I got an Owl Pedal awhile ago, which restricts the programming to Gen, and I finally got to work trying to make an effect. I made an arpeggiator/pitch shifter that does ramp up, ramp down, up/down, and random in major, minor, and octaves. My problem? When I was half done with it, the pedal's CPU usage was around 48%. Now that I finished it, it's at 149%, so I can't use it until I optimize it and get that usage down. That being said, I know, I know, I know it's really messy. But I'm new and just started teaching myself this last week. So any suggestions are very very appreciated!

    • Feb 15 2018 | 6:24 pm
      I made some changes. Down to 80%! It's playable! If there's any more efficiencies, let me know!
    • Feb 15 2018 | 9:20 pm
      I'm not sure what the resctrictions of the Owl pedal i would get rid of all the scale and fold objects, only use them when you really need them.
    • Feb 15 2018 | 9:51 pm
      Great suggestions! That definitely seems simpler, but that would make the range 0-4. How do you make the range 1-4.99 and not 0-4 or 1-5 by adding 1?
    • Feb 15 2018 | 11:28 pm
      " by adding 1?"
      Yeah, pretty much that but see the patch for comments.
    • Feb 16 2018 | 8:48 am
      The usual solution is use 'floor' after multiplying a float, before performing any other maths on it, although it sounds like you would prefer 'round' in your case.
    • Feb 16 2018 | 8:32 pm
      I've been working on this all day and the only way I've been able to change 0-1 into equal parts to be usable by the selector for the arpeggiator sequence is: + 1 / 0.25 / 1.0025 - 2.99 floor
      but I'd need a completely different setup if I wanted 1-3.99 or 1-5.99 etc. At this stage, is it really less processing than using a scale object?
    • Feb 16 2018 | 11:22 pm
      It's unnecessary to use floor when you control the input of selector, (afaik) everything in Gen is treated as a float. I'd make a back up just in case :) but i think you can get rid of floor entirely. Unfortunately i can't come up with a good way to eliminate scale while keeping the same functionality and reduce load.
      Best thing i could think of was to create a buffer in max, fill it and access the values inside Gen but i'm afraid that doesn't work due to the limitations of the Owl?
    • Feb 16 2018 | 11:38 pm
      Interesting about the selector input. Right. The Owl pedal program must be entirely contained within a gen~ object.
    • Feb 17 2018 | 1:01 am
      of course you are right about selector~ my bad. With regard to 'scale' the exact equation for it is in maxhelp for the MAX scale object. Usually you can get rid of a few factors because, for example, you are starting at 0 or something. It's not that difficult to do in gen~. I made a number of versions of it for Godel on Max 6 which I could dig up if it's helpful.
    • Feb 17 2018 | 2:17 am
      This is about as efficient as i can make it without using scale and is most likely what scale is doing itself internally (the max6 helpfiles didn't show anything though). It should be cheaper than scale because like Ernest suggests you dont have to check for a lowerlimit.
      And please do share Ernest, i'd love to see your solution(s).
      <Edit> " most likely what scale is doing itself internally " -uhhm no, i mixed up constrain with scale...
    • Feb 17 2018 | 2:58 am
      from docs:
      This optional fifth argument specifies the nature of the scaling curve. This argument must be a floating-point number greater than 1., with larger values leading to steeper exponential curves. In classic mode a typical value for this argument is 1.06 and the number is converted according to the following expression: (out_high-out_low >= 0) ? (out_low + (out_high-out_low) * ( (out_high - out_low) * exp(-1*(in_high-in_low)*log(power)) * exp(x*log(power)) )) : (-1) * ( out_low + (out_high-out_low) * ( (out_high - out_low) * exp(-1*(in_high-in_low)*log(power)) * exp(x*log(power)) ) )
      In non- classic (modern) mode the value for the scaling curve must be higher than 0. and is converted according to the following expression:
      ((x-in_low)/(in_high-in_low) == 0) ? out_low : (((x-in_low)/(in_high-in_low)) > 0) ? (out_low + (out_high-out_low) * ((x-in_low)/(in_high-in_low))^exp) : ( out_low + (out_high-out_low) * -((((-x+in_low)/(in_high-in_low)))^(exp)))
      Note that prior to Max 6.0.4 the exponent was inverted. Thus, if you gave it an exponent of 2 the object behaved like it had an exponent of 0.5, and if you gave it an exponent of 0.5 it behaved like it had an exponent of 2. Patches from versions prior to 6.0.4 may require updating to work properly.
    • Feb 17 2018 | 3:13 am
      Oops my bad, i thought that only applied to the scaling curve and i kinda read over it :)
    • Feb 17 2018 | 2:55 pm
      That works for some purposes, but its not accurate. It's fine for using a knob or whatever (since it's just me turning a knob and I won't notice), and changes the max of 5 to a 4, but that still leaves the range of 4 at 101% of the interval between the other numbers, which adds up quick with an arpeggiator. This is tricky!
    • Feb 17 2018 | 5:42 pm
      Fixed.
      Luvulongtime!
    • Feb 17 2018 | 8:53 pm
      That works! I had to make some changes for each division, but I spent the morning on it and everything's functioning the way it should. I added more features, and even with the added functionality, it's taking up only 74% CPU . Thanks so much! Try it out if you get time! The last problem I have is that I have Knob B working in a pseudo-arc but I'm not sure how I'm properly supposed to do this. In other words: to change the scale of the knob from 0-0 but with an arc going up to a number in between. Is this possible?
    • Feb 17 2018 | 9:22 pm
      Cool, but just remember that division is always computationally more expensive than multiplication.
      Yeah, i think you're looking for a window function. Just search the forum
    • Feb 18 2018 | 12:33 am
      Oh man, you were absolutely right about the division. And I don't know why it wasn't so obvious to me that my issue was that I was adding the 1 before multiplying, not after. So now it's working incredibly smooth at 64% CPU. Thanks guys! You taught me so much!