Int vs float in MIDI velocity operations


What is the thinking behind the decision to be able to get a velocity value from a MidiMessage as an int value between 0 and 127 but if you want to set the velocity, you have to scale it yourself from the standard 0 to 127 into to a 0.0 to 1.0 value?



Most of the methods let you pass either a uint8 or a float for velocity, don’t they?


Unless things have changed in the latest Juce (and I am going to buy a professional version today) as we’re ready to release a new product), there is a getVelocity and getFloatVelocity but the setVelocity is ONLY float.


TBH that’s a pretty rarely used and unloved method. Most people will use the MidiMessage class in an immutable style, i.e. creating objects with one of the constructors that does take either an int or float, and then not changing them afterwards.

It’d only be a one-liner to add a method that does what you’re asking, but if I was going to make any changes to that class, I’d prefer to be removing the setter methods in order to simplify the class rather than adding more of them… I think the fact that the class isn’t entirely immutable is a bit of a legacy design mistake in hindsight.


I don’t want to get into discussions about whether objects should be immutable or not (I personally hate immutable strings) and I like the idea of being able to just transpose a note number or constrain a velocity by just changing a value in an object rather than creating a brand new object every time, specially if those objects are being created dynamically. In the system we’re building, that approach becomes important. I can easily add the extra method myself, I get that.

However, that’s not my question. If the MIDIMessage object used floating point ONLY (e.g, note numbers, velocities, pitch bend values) that would be one thing (and probably rather nice). However, the notion that I create a MidiMessage using standard MIDI values (0…127) but changing velocity requires 0.0 to 1.0 is strange and that’s why I was curious as to the underlying thinking.


There probably wasn’t much thinking! That method would have been added at some point and just never got an integer-based counterpart. If I was to design it now, there are nicer things that could be done using intermediate classes that would automaticall convert between 8-bit and floating point midi values, which could be used all over that class and which would simplify a lot of other methods too.


Fair enough.


Please, @jules, don’t remove the setters !! We use them heavily on our app, to constraint the velocities to a certain range for example, or force maximum velocity all the time. Or is it a design flaw ?


No, I won’t remove them, as that’d break people’s code. I just meant that actually I kind of wish I hadn’t added them in the first place.