Freedrum midi commands

Freedrum midi commands. V6

Some of you techies out there will be happy to hear that Freedrum can be controlled via standard MIDI messages. There are a few, per-sensor, global settings that are set via MIDI CC messages along with per-zone (zone==pad or drum) settings.

Don’t forget that, depending on how you send these values you might need to add the standard 2-byte MIDI header to the data. Usually 0x8080 works fine for that.

Also note that none of these values are guaranteed to be stay the same forever. They are valid for v3 of the firmware but we don’t promise more than that.

Status codes

When writing the below CC values, you get return values in the form of CC 21. It carries the following possible value byes:

  • 0 ok
  • 1 badChannel
  • 2 gyroWarning. Gyro maxed out, play softer dude!
  • 3 unknown CC. Strange command sent to sensor.
  • 4 general error

“Global” settings (affecting all zones of a sensor)

CC 16
Sent when the sensor moves to another zone, value is the zone number

CC 20
With CC 20 you can send a few commands to Freedrum. The commands are sent in the “value” byte of the midi message.

  • value=0 : Save settings. Without this command, any settings you’ve set with the other CC’s are lost when the sensor is turned off.
  • value=1 : Factory reset. Resets sensor zones to the default 6-zone setup.

CC 24

CC 25
Emitted when sensor changes reference drum.

CC 105
Sensor sensitivity.
Sets the sensitivity of the sensor. This value is sort of an amplification factor: If you need to strike too hard to get a loud sound/velocity with a sensor, this is the value to tweak. Defaults to 10. For a foot pedal it’s often better to set it higher, at 30 or so.

CC 104
Sensor threshold.
This is the lowest hit strength at which the sensor will generate midi on notes at all. Set it higher if you get a lot of false hits (notes when you were not intending to hit anything.)

CC 111
default value: 12
This one affects how quickly the reference drum adjusts the drumkit. The reference drum is the currently most played drum/zone and it’s used to eliminate drift. Each hit on the reference drum slightly orients the kit towards an angle where the reference drum is in a good position in its zone. This is to prevent gyro drifting. As long as you hit the reference drum now and then, the kit will remain stable and not turn.

CC 110
default: 40
This value determines how many pad hits we look at for determining what is a good reference drum. The higher this value, the less often we switch between reference drums.

CC 113
How accurately do we need to hit the ref drum in y-axis to get prediction of hit time? 0 means turn off this kind of prediction.

Per-zone settings

There are also settings for the different pads/zones of the sensor. As of v3 of the firmware there are 6 different zones. The MIDI channel represents the zone (ranging from 0-15). By default zone 0 is the hihat, 1 is the snare etc.

CC 106
Sets the midi note to send for this zone/pad.

CC 23
With this one you can set the angle of a specific zone. Keep in mind that midi values range from 0-126, we scale this so that 126=360deg. By default, the drums on the lower layer (hihat, snare, floor tom) are at y=0deg and the upper layer (cymbals etc) are at y=50deg

CC 103
The z-axis is the one point up from earth. By default, the snare is at z=0deg.

CC 107
When you set this > 0 the sensor begins to stream x axis values as CC 107 messages. Values come at a rate of about 10/second.

CC 108

CC 109

CC 112

Reading values

CC 22
read value
To read one of the values from above, send CC 22 with value set to the corresponding CC. The sensor will answer with the currently set value for that parameter. Use the channel as zone number where applicable.

We also have a few MIDI Sysex messages. Sysex are sent as
0xf0 0xf7

Sysex commands:

0xf0 0x04 0xf7 - enter bootloader (for firmware update)
0xf0 0x05 0xf7 - turn off


If you for example want to change the snare to a cymbal (midi note 57) you would send this in one midi message:

0x8080 //midi header, omitted depending on transport protocol
0xB1 // MIDI CC + channel 1 because the snare is in zone 1
0x6A // CC 106, midiNoteForPad above
0x39 // note 57

As a response we get
0x15 // CC 21, “status”
0x0 // ok


Hi August,

Thanks for this documentation, excited to play around with these settings.
Just one question, is there a reliable way to reset a sensor to a factory settings in case something gets screwed up with writing these values? :smiley:

Not yet, just forgotten about that :slight_smile: What you can do is rolling back to an old version, and then revert back to the new version, then the settings will have the default values. There’ll be a command for “factory reset” in the next firmware update.
Meanwhile, if you only set the midiNote for zones, the app will reset those when you change between foot/hand setup

1 Like

Here’s the UUID’s of the characteristics and services.

+(CBUUID*)UUIDFreedrumCharOrientation   { return  [CBUUID UUIDWithString:@"0E5A1525-EDE8-4B33-A751-6CE34EC47C00"]; }
+(CBUUID*)UUIDFreedrumDrumConf          { return  [CBUUID UUIDWithString:@"0E5A1526-EDE8-4B33-A751-6CE34EC47C00"]; }
+(CBUUID*)UUIDFreedrumVersion           { return  [CBUUID UUIDWithString:@"0E5A1527-EDE8-4B33-A751-6CE34EC47C00"]; }
+(CBUUID*)UUIDFreedrumStatus            { return  [CBUUID UUIDWithString:@"0E5A1528-EDE8-4B33-A751-6CE34EC47C00"]; }

+(CBUUID*)UUIDBattery               { return  [CBUUID UUIDWithString:@"2A19"]; }
+(CBUUID*)UUIDAppleMidiIO          { return  [CBUUID UUIDWithString:@"7772E5DB-3868-4112-A1A9-F2669D106BF3"]; }

+(CBUUID*)UUIDDFUTargetSignedService    { return  [CBUUID UUIDWithString:@"0xFE59"]; }
+(CBUUID*)UUIDDFUTargetUnSignedService  { return  [CBUUID UUIDWithString:@"0xFE58"]; }
+(CBUUID*)UUIDBatteryService            { return  [CBUUID UUIDWithString:@"180F"]; }
+(CBUUID*)UUIDFreedrumService           { return  [CBUUID UUIDWithString:@"0E5A1523-EDE8-4B33-A751-6CE34EC47C00"]; }
+(CBUUID*)UUIDAppleMidiService          { return  [CBUUID UUIDWithString:@"03B80E5A-EDE8-4B33-A751-6CE34EC4C700"]; }
1 Like

I used Midi OX and send CC20 Value 111 to see the refDrumStrength but it did not give back the Value. Instead it keeps sending CC21 bye 3 which as far as I know means unknown CC.

I tried to override using the update v5 which is by the way already installed but it did not do anything, it just keeps on sending CC 21

How do I make it stop sending CC 21 and why didn’t I get the value using CC20?

Any suggestions?

Thanks in advance

If you read a little closer you’ll see that CC20 is “command”. What you want is CC22, “read_value”

I’ve tried to build a work around / my own hi hat pedal solution as I’m stuck with ios10 which isn’t compatible with your freedrum app.

Unfortunately there’s no reliable way to detect if the foot got raised.
If I raise it abruptly note off events are sent. In most of the cases I do it too softly and nothing happens.
I’ve already tried to adjust the sensor’s sensitivity but this didn’thelp.

Is there any way to trigger midi events when the foot pedal sensor is raised? Maybe some midi switch that’s not documented?

1 Like

There’s are CC messages generated continually when the pedal is moved up and down, and I think there are a few IOS apps available that remaps CC values to other midi messages if that’s what you need. You need to turn on CC output for pedal up/down first though, that should be documented in the Freedrum Midi Commands docs.

The foot pedal movement CC is 4.

Hi Fredrik,
I’m not sure what you mean.

The Foot sensor doesn’t send any CC4 Messages. I only see channel 10 note on/off and channel 01 CC24 Messages.

…or was it meant as a hint to map the z-axis events to CC 4, as CC4 will be evaluated by drum synth?

It seems the docs haven’t been updated for this, sorry. Use CC114 to set what CC# the foot pedal should produce. That is, send “CC114 4” to setup the sensor to emit CC4 when foot pedal is raised.

Thanks for the reference guide!
Is there any way to set the auto-off interval of the sensors? I’d like it to be substantially longer.

No, not yet, but good idea!

Would be great if this information could make it into some official docs, or maybe could be updated to include this + the bluetooth uuids, and not hidden in the FAQ. In lieu of official docs page, perhaps a wiki somewhere? I just spent a bunch of time reverse-engineering a subset of this information only to discover afterward that it was available here all along. i.e. a forum is not where one normally goes looking for dev documentation.

It’s on the todo list to update the docs. The UUID is unique for each sensor. If you have any specific question, feel free to contact me and i will try to answer :slight_smile: