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 < [email protected]> 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 < > [email protected]> 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 > [email protected] > http://lists.puredata.info/listinfo/pd-dev > > > > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev > >
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
