The OSC spec has an optional tag for double support, but it is optional.
Some OSC applications communicate among instances of themselves with additional, nonstandard argument types beyond those specified above. OSC applications are not required to recognize these types; an OSC application should discard any message whose OSC Type Tag String contains any unrecognized OSC Type Tags. An application that does use any additional argument types must encode them with the OSC Type Tags in this table:
Type of corresponding argument: 64 bit (“double”) IEEE 754 floating point number
That is the OSC protocol itself – at least, 1.0, I’m not certain about 1.1 – before client implementations such as oscP5. So you could check the oscP5 source to see if it handles ‘d’.
In addition to @kfrajer’s blob suggestion:
If oscP5 doesn’t support double, then you could use int32s like in the standard examples.
For example, one workaround would be to copy the 64 bits of a double into two int32s, send them over OSC, then copy the bits from the two ints back into one double.