[PD-dev] HD support in Pd

[Martin Peach]

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 at 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 at 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 at lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150222/95d43762/attachment.html>