[PD-dev] HD support in Pd

[BEB Digital Audio]

Hello everybody,

I have just joined the Pd-dev list and I would like to introduce myself 
: I am one of the member of the MMA HD development group (amongst other 
things related to MIDI and RTP-MIDI developments ;-) )

As you probably heard, the MMA has presented officially this new 
protocol during the NAMM2015 : http://www.midi.org/aboutus/news/hd.php
This has been announced also on other places with some further details : 
http://www.synthtopia.com/content/2015/01/16/new-midi-hd-protocol-has-reached-a-milestone/

So now, why am I here?
The reason is simple : there is already a Max/MSP implementation of HD 
(still not public, because of the MMA NDA of HD, still active until HD 
is officially released in public domain), but no Pd...
(By the way, it's not the only existing implementation of HD, believe me 
;-) . Those who went to NAMM2015 could see a few other ones)

I have taken a look to the possibility to include HD support in Pd 
(since I am the creator of the HD Max externals), but there is currently 
a huge stone in the middle of the road : HD is exclusively based on 32 
bits unsigned integer atoms... so it's simply impossile for now to 
encode HD messages in Pd because of the restricted range of integers 
(due to the use of float for numbers). It would be eventually possible 
to use 64 bits version, but this would restrict Pd with HD support to 
"high end" platforms (and I like the idea of running Pd on small 32 bits 
platforms)

Note that HD can be transported over normal MIDI (and MIDI can be 
transported over HD too :-) ), so it's also possible to use this as a 
solution... but knowing that shortest HD message is 3 atoms long (12 
bytes...), this would quickly lead to messy patches to handle HD in 
current Pd.

So, here is my question : what would Pd community think of including 32 
bits native support in Pd? I know that it would mean a HUGE change in 
the code (basically it's implementing a new type!) but I would not like 
to see Pd being pushed out of HD just because it would be painful to 
implement 32 bits message

Benoit