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-reache...
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
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-reache...
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
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-reache...
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-02-22 17:10, Martin Peach wrote:
There is already a t_int in Pd, it just isn't used.
the "t_int" type *is* used quite a lot: it is the type to be passed and returned tp/from the DSP perform callback.
i'm not sure whether using it as a 32bnit integer is actually "abuse".
fgmdsr IOhannes
(i totally agree that "t_int" is a horrid name for that type; it really should is a (void*) type and should have a proper name; but there you go).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-02-22 15:52, Jonathan Wilkes via Pd-dev 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.
in practice it might well be: if your CPU only has instructions for single precision math, then using double precision (while technically possible) might have dysmal performance, making a double-precision Pd unusable on these platforms. (we had a similar problem with 1st generation handheld devices, such as PDAs, that would only have fixed point arithmetics. in order to actually run Pd on those devices we needed PDa, a fixed-point fork of Pd)
fgnsd IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
hi,
On 2015-02-22 13:03, BEB Digital Audio wrote:
Hello everybody,
[...]
I have taken a look to the possibility to include HD support in Pd
great!
(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)
i think the way to go is to (with the least preferred suggestion at the bottom)
- - internally use whatever representation fits your needs (uint32_t)
- - for in-patch communication, create a semantic layer that does not require uint32_t. (use a symbolic "noteon" message instead of it's encoded uint32_t equivalent¹)
- - use Pd native types where this is not possible but still feasible (e.g. if your "channel number" is encoded as 32bit uint, you will get away with a 23bit integer - as is provided by Pd's t_float type) in virtually all cases)
- - where it's absolutely necessary to be able to feed your objects with a 32uint_t from within a Pd-patch, you could always use list of two numbers (just read them as two shorts and recreate the uint32_t from that). just make sure that you don't end up with multiple pairs in a single (user-exposed) message)
fgmasdr IOhannes
PS: congratulations to the MMA committee for chossing a clever, unique and unambiguous name like "HD".
¹ please note that i have absolutely no clue about the internals of MIDI-HD; so the "noteon" example might not be the best one; but i hope you get my point.
-
BEB Digital Audio -
IOhannes m zmoelnig -
Jonathan Wilkes -
Martin Peach