Calculating cc change speed in Max (for Boppad, but not exclusively)

Tech
#1

I just got a KMI Boppad in the mail and while it’s nice and responsive for doing what other pad controllers do, I’d like to use its robust midi specs for sharpening my Max skillz, and I’ve gotten great help from this board before, so I thought I’d start here.

What I want to do:
Similar to getting a sound by scraping or scratching a surface, I’d like to touch the surface of the boppad to trigger a sound which would then keep playing and would vary in pitch based on how fast I moved along the radius axis of the boppad.

Midi output available from the boppad:

“• Initial Radius - where you initially strike the surface will be used.
• Radius - the position of where you are pressing onto the surface.
• Relative Radius - the difference between where you are currently pressing the surface and where you initially struck the surface.”

What I’ve figured out so far:
Starting and stopping the sound is the easy part: those are note on/off messages, routed in Max like you’d route any other note on/off message.
It’s capturing the speed of the scrape that has me puzzled. I’m assuming that the process will look something like:
*note on message begins the process
*process counts tiny chunks of time
*process divides timespan by difference in midi values
*difference converted by [computer magic] into a new cc that can be routed to pitch

Where do I start?
Recommendations for relevant max object, tutorials, or example patches are all welcome. Thanks in advance!

1 Like
#2

It’s been a while since I was in MAX/MSP but what you are after should be pretty simple:

A basic meta recipe would look like this:

You need an object to store the last CC value. Not sure what this would be called. Just some sort of constant/number object that holds a value.

You need a timer & counter that counts at some constant rate and can be reset at will.

Incoming CC event does the following:

  1. Read from stored value and send it to a subtract object for step 2.
  2. Subtract that stored value from incoming value (this gives you the magnitude of change)
  3. Divide by the timer value (this gives you the rate of change in whatever units your timer is clicking at)
  4. Reset timer
  5. Store the incoming CC value in place of the old one.

In applications like this I would then pass that ‘rate’ value through a smoother/filter/slew to avoid obvious jumping with each CC input.

Hope thats helpful! It’s been a while since I was in MAX/MSP/Puredata land but I do stuff like this all the time in code.

#3

I think MAX has some sort of timing object that you can poll for the elapsed time since the last bang? I that would make the timing portion less complex.

#4

What you’re doing is taking the derivative of the CC signal. There may even be an object that does this directly.

#5

Perhaps mnm.delta?
http://ftm.ircam.fr/index.php/MnM_Modules

A fairly advanced example of usage:
http://ftm.ircam.fr/index.php/Gesture_Follower

Oh, oops, I guess they have a newer version that is independent of FTM?
http://imtr.ircam.fr/imtr/Gesture_Follower

#6

I keep this in snippets for calculating rate of change. From somewhere on the forum… can’t take credit I’m afraid:

30 PM
Screen Shot 2017-10-25 at 6.55.30 PM.png698×1192 35.7 KB

3 Likes
#7

This is better than what I suggested because it will go to zero without having new CC values coming in. Just pull out the ‘abs’ if you want negative values.

#8

Man, everything has been helpful, thanks y’all.
I never took calculus, so I had to go google ‘derivative’, but this is all seeping in slowly.
Later tonight I’ll try that bit of code that you posted, _mark, and see if I can get something to do something.

2 Likes
#9

Do let us know how it goes. Seems like there’s plenty of potential in the data it supplies.

1 Like
#10

I was able to get your code working. Thanks!

Not sure what the next step will be, i’ll have to brainstorm ways to implement this.

Short video of speed modulating pitch of an oscillator to approach something like scratching:

2 Likes