There is already a t_int in Pd, it just isn't used. I made a patch a few years ago for a 'blob' type that's part of Pd-extended. You can look at that to see how to implement it. Basically you add a default handler in Pd for things that don't have a method for  t_int, that does nothing.

Martin

On Sun, Feb 22, 2015 at 9:52 AM, Jonathan Wilkes via Pd-dev <pd-dev@lists.iem.at> wrote:
Hi Benoit,
What do you mean by "64 bits version"?  Do you that mean that you could get your protocol to work on Pd Double, the version of Pd that uses 64-bit floating point numbers?  If so that's probably the way to go-- and keep in mind that Pd Double can run on 32-bit architectures, so that isn't a problem.

On the other hand if you want to code up a patch to a) add an int atom type, b) change Pd's parser to accommodate it, c) write a versioning mechanism so that the parser changes don't end up breaking old patches, and d) write a test suite, then I would certainly look at it.  I highly doubt it would make it into Pd Vanilla-- the increased UI complexity of the implicit typing probably overshadows the benefit of accommodating a new protocol that isn't vital to the normal functioning of the software.

-Jonathan


On Sunday, February 22, 2015 7:03 AM, BEB Digital Audio <beb.digitalaudio@free.fr> wrote:


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

_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev



_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev