<div dir="ltr"><div>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.<br><br></div>Martin<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 22, 2015 at 9:52 AM, Jonathan Wilkes via Pd-dev <span dir="ltr"><<a href="mailto:pd-dev@lists.iem.at" target="_blank">pd-dev@lists.iem.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div>Hi Benoit,</div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div><span class="HOEnZb"><font color="#888888"><div dir="ltr"><br></div><div dir="ltr">-Jonathan<br></div></font></span><div><div class="h5"><div><br><br></div><div style="display:block"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div dir="ltr"> <font face="Arial"> On Sunday, February 22, 2015 7:03 AM, BEB Digital Audio <<a href="mailto:beb.digitalaudio@free.fr" target="_blank">beb.digitalaudio@free.fr</a>> wrote:<br> </font> </div>  <br><br> <div>Hello everybody,<br><br>I have just joined the Pd-dev list and I would like to introduce myself <br>: I am one of the member of the MMA HD development group (amongst other <br>things related to MIDI and RTP-MIDI developments ;-) )<br><br>As you probably heard, the MMA has presented officially this new <br>protocol during the NAMM2015 : <a>http://www.midi.org/aboutus/news/hd.php</a><br>This has been announced also on other places with some further details : <br><a>http://www.synthtopia.com/content/2015/01/16/new-midi-hd-protocol-has-reached-a-milestone/</a><br><br>So now, why am I here?<br>The reason is simple : there is already a Max/MSP implementation of HD <br>(still not public, because of the MMA NDA of HD, still active until HD <br>is officially released in public domain), but no Pd...<br>(By the way, it's not the only existing implementation of HD, believe me <br>;-) . Those who went to NAMM2015 could see a few other ones)<br><br>I have taken a look to the possibility to include HD support in Pd <br>(since I am the creator of the HD Max externals), but there is currently <br>a huge stone in the middle of the road : HD is exclusively based on 32 <br>bits unsigned integer atoms... so it's simply impossile for now to <br>encode HD messages in Pd because of the restricted range of integers <br>(due to the use of float for numbers). It would be eventually possible <br>to use 64 bits version, but this would restrict Pd with HD support to <br>"high end" platforms (and I like the idea of running Pd on small 32 bits <br>platforms)<br><br>Note that HD can be transported over normal MIDI (and MIDI can be <br>transported over HD too :-) ), so it's also possible to use this as a <br>solution... but knowing that shortest HD message is 3 atoms long (12 <br>bytes...), this would quickly lead to messy patches to handle HD in <br>current Pd.<br><br>So, here is my question : what would Pd community think of including 32 <br>bits native support in Pd? I know that it would mean a HUGE change in <br>the code (basically it's implementing a new type!) but I would not like <br>to see Pd being pushed out of HD just because it would be painful to <br>implement 32 bits message<br><br>Benoit<br><br>_______________________________________________<br>Pd-dev mailing list<br><a>Pd-dev@lists.iem.at</a><br><a>http://lists.puredata.info/listinfo/pd-dev</a><br><br><br></div>  </div> </div>  </div> </div></div></div></div><br>_______________________________________________<br>
Pd-dev mailing list<br>
<a href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a><br>
<a href="http://lists.puredata.info/listinfo/pd-dev" target="_blank">http://lists.puredata.info/listinfo/pd-dev</a><br>
<br></blockquote></div><br></div>