this is a list of current issues with heavy supported objects, that made me loose a couple of hours :-)

some "obvious" ones (the heavy compiler spits errors and warnings out)

-delread~ always needs an initial delaytime set, unlike in vanilla pd. actually, you cannot change delread~ delay time at runtime at all. use vd~in that case.

objects that do not work "properly":

-potentially all midi input. if you use more then one midi port in puredata the additional ports will have midi channel 1-16 remapped to portnumber*midichannel.

i.e. midi channel 1 on the second port will be channel 17 and so on. very useful feature to separate midi streams.
in heavy those additional ports will simply use the same midi channels as the default port. channel 1 stays channel 1. this is of course not desired, since it disallows any further routing of different ports.

-rpole~ does not work at all? at least i could not pass a signal through it in an abstraction, the abstractions simply did not output anything. EDIT: you have to feed a signal to the right inlet of rpole~ and you cannot use sig~ for that for some reason. use a line~ object as a workaround.

for rpole~ I seem to remember you need a signal message going into the right inlet. This (or something similar) may be what is used in the rubber-duckie example.
MIDI channels can be made to behave as you describe by editing the render.cpp file. There are probably a number of other weirdnesses, including not being able to bang number boxes, not being able to set the trigger arguments at runtime, and not being able to start an [until] with a bang.

    hmm, will have to look at rubber duckie then. i tried it with sig~ already and it did not work for me...

    actually it's the envelopeTrigger example. Duckie has [rzero~]

      giuliomoro MIDI channels can be made to behave as you describe by editing the render.cpp file.

      really? how would that work?

        giuliomoro actually it's the envelopeTrigger example. Duckie has [rzero~]

        ok, i found the issue!

        it is not rpole~ that is broken but sig~ feeding rpole~

        if i connect my control signal via a |$1 10( message and a [line~] to the right inlet of rpole~everything works smoothly. but control signal to [sig~] and then to [rpole~] does not do anything...(i.e. rpole~does not let any audio through...)

            lokki and, it seems the delread~ time can not be changed at runtime, or can it?

            EDIT: does indeed not work.

              giuliomoro actually it's the envelopeTrigger example. Duckie has [rzero~]

              @giuliomoro may i ask a further question about heavy/pd? in the envelopeTrigger example, what does the
              [pd @hv_obj __and~f] inside the hv_gte~ abstraction do? i mean, there is an inlet which is not connected to anything...

                  lokki what does the
                  [pd @hv_obj __and~f] inside the hv_gte~ abstraction do?

                  I THINK that it is a Heavy-internal that has "leaked" outside, maybe through heavylib ? Ultimately, when running in libpd, it does nothing , so that is probably broken and [hv_gte~] there should be replaced with the latest [hv.gte] from heavylib?

                  In the source code of hvcc, there are a number of Pd abstractions used by hvcc internally to translate some Pd objects into simpler objects that are already recognized by hvcc. This is the place where I found and fixed all those MIDi-out issues. For instance, the midi objects are just senders or receivers named, e.g.: __hv_ctlout, __hv_notein, etc.

                  Among some of the more interesting abstractions, many use [pd @hv_obj ... ] subpatches that are actually empty. I suspect that the purpose of these is to serve as placeholders for some code that is actually implemented in the Python engine.

                  Note that also rzero~.pd lives in there, so maybe that's where your problem lies, although I suspect it could actually be in the way [sig~] is used.

                      giuliomoro

                      thanks, i am just now looking at those abstractions and getting a feel for the whole thing! i also concluded it is as you wrote, the "empty" abstractions are placeholders for the heavy compiler, so that the corresponding code snippets are filled in there. nice!

                        a year later

                        giuliomoro not being able to bang number boxes

                        Omg this was driving me crazy tonight thank you.

                        Is there a list of other bugs off the top of your head??

                          no, sorry. It's always hit and miss.