When the Heavy compiler was with Enzien Audio there was a list of supported PD objects on https://enzienaudio.com/docs/pdobjects.html .
For one that link is dead now, yet still linked on https://hoxtonowl.com/mediawiki/index.php/Creating_Patches_in_PureData
More importantly, where can we find the currently supported list of PD objects and which PD version is the latest supported one? Thanx in advance.
Well that isn’t of much help. Your archive.com link is nothing more than an archived copy of an old page from 2016.
What’s the current state, rebel techs?
Hi, I’ve just recently started using hvcc, so I am in no way an expert, however by looking a little into the documentation (hvcc/12.heavy_lang.md at master · enzienaudio/hvcc · GitHub and hvcc/13.heavy_ir_lang.md at master · enzienaudio/hvcc · GitHub),
it seems to me that the two files in https://github.com/enzienaudio/hvcc/tree/master/core/json:
should contain a list of all supported objects.
Looking a little more in the source code I found in hvcc/utils/hvutils.py which if copied in hvcc/ can be executed:
$ python hvutils.py pdobjects
which returns this list (sorted by me)
[’!=’, ‘%’, ‘&’, ‘&&’, ‘’, '~’, ‘+’, ‘+~’, ‘-’, ‘-~’, ‘/’, ‘/~’, ‘<’, ‘<<’, ‘<=’, ‘==’, ‘>’, ‘>=’, ‘>>’, ‘abs’, ‘abs~’, ‘adc~’, ‘atan’, ‘atan2’, ‘b’, ‘bang’, ‘bendin’, ‘bendout’, ‘biquad~’, ‘bng’, ‘bp~’, ‘catch~’, ‘change’, ‘clip’, ‘clip~’, ‘cnv’, ‘cos’, ‘cos~’, ‘cpole~’, ‘ctlin’, ‘ctlout’, ‘czero_rev~’, ‘czero~’, ‘dac~’, ‘dbtopow’, ‘dbtopow~’, ‘dbtorms’, ‘dbtorms~’, ‘declare’, ‘del’, ‘delay’, ‘delread~’, ‘delwrite~’, ‘div’, ‘env~’, ‘exp’, ‘exp~’, ‘f’, ‘float’, ‘floatatom’, ‘ftom’, ‘ftom~’, ‘hip~’, ‘hradio’, ‘hsl’, ‘i’, ‘inlet’, ‘inlet~’, ‘int’, ‘line’, ‘line~’, ‘loadbang’, ‘log’, ‘lop~’, ‘makenote’, ‘max’, ‘max~’, ‘metro’, ‘min’, ‘min~’, ‘mod’, ‘moses’, ‘mtof’, ‘mtof~’, ‘nbx’, ‘noise~’, ‘notein’, ‘noteout’, ‘osc~’, ‘outlet’, ‘outlet~’, ‘pack’, ‘pgmin’, ‘pgmout’, ‘phasor~’, ‘pipe’, ‘poly’, ‘pow’, ‘powtodb’, ‘powtodb~’, ‘pow~’, ‘print’, ‘q8_rsqrt~’, ‘q8_sqrt~’, ‘r’, ‘random’, ‘receive’, ‘receive~’, ‘rmstodb’, ‘rmstodb~’, ‘route’, ‘rpole~’, ‘rsqrt~’, ‘rzero_rev~’, ‘rzero~’, ‘r~’, ‘s’, ‘samphold~’, ‘samplerate~’, ‘sel’, ‘select’, ‘send’, ‘send~’, ‘sig~’, ‘sin’, ‘snapshot~’, ‘spigot’, ‘sqrt’, ‘sqrt~’, ‘swap’, ‘symbol’, ‘symbolatom’, ‘s~’, ‘t’, ‘table’, ‘tabosc4~’, ‘tabplay~’, ‘tabread’, ‘tabread4~’, ‘tabread~’, ‘tabwrite’, ‘tabwrite~’, ‘tan’, ‘tgl’, ‘throw~’, ‘timer’, ‘touchin’, ‘touchout’, ‘trigger’, ‘unpack’, ‘until’, ‘vcf~’, ‘vd~’, ‘vradio’, ‘vsl’, ‘wrap’, ‘wrap~’, ‘|’, ‘||’]
thanks @ykmm
here it is in Markdown:
<<<<===>>=>>|||--~!=//~**~&&&%++~absabs~adc~atanatan2bbangbendinbendoutbiquad~bngbp~catch~changeclipclip~cnvcoscos~cpole~ctlinctloutczero~czero_rev~dac~dbtopowdbtopow~dbtormsdbtorms~declaredeldelaydelread~delwrite~divenv~expexp~ffloatfloatatomftomftom~hip~hradiohsliinletinlet~intlineline~loadbangloglop~makenotemaxmax~metrominmin~modmosesmtofmtof~nbxnoise~noteinnoteoutosc~outletoutlet~packpgminpgmoutphasor~pipepolypowpow~powtodbpowtodb~printq8_rsqrt~q8_sqrt~rr~randomreceivereceive~rmstodbrmstodb~routerpole~rsqrt~rzero~rzero_rev~ss~samphold~samplerate~selselectsendsend~sig~sinsnapshot~spigotsqrtsqrt~swapsymbolsymbolatomttabletabosc4~tabplay~tabreadtabread~tabread4~tabwritetabwrite~tantglthrow~timertouchintouchouttriggerunpackuntilvcf~vd~vradiovslwrapwrap~List made with:
python utils/hvutils.py pdobjects | sed 's/[\[ ]"/* `/g' | sed 's/",/`\n/g' | sort
You pointed out a dead link, starting with nothing. I posted the last known snapshot of it for the benefit of other readers here. If it was so obvious, why didn’t you post it first?
Based on the latest support list, there were only 13 objects added since 2016:
While using rzero rev~ i see that the compiler doesn’t eat arguments. Is that fixable? rzero_rev~ compared to rzero_rev~ 1 unfortunately gives me 18 db level difference when i use this as one side of a threshhold-detecting algorythm.
I have to admit I have no idea how rzero_rev~ is meant to work, but this is what’s in the hvcc source:
if obj_type in ["rzero~", "rzero_rev~", "czero~", "czero_rev~"]:
g.add_warning(
"[{0}] accepts only signal input. "
"Arguments and control connections are ignored.".format(obj_type))
There’s this file interpreters/pd2hv/libs/pd/rzero_rev~.pd:
where __del1~f is, as far as I can see, a reference to a single sample delay implemented in SignalDel1.py / HvSignalDel1.h.
Do you think it would be easy or even possible to edit the pd file to accept the args as needed?
Is it the initialisation argument you are looking for here or something else?
Thanx for getting into this, Martin: Yes i am looking for a creation argument for the filter coeeficient.
For what the rzero family of objects does i refer you to Miller Puckette: “rzero~, rzerorev~, rpole~: elementary filters with real-valued coefficients operating on real-valued signals.The three implement non-recirculating filters of the first and second types, and the recirculating filter.They all have one inlet, at right, to supply the coefficient that sets the location of the zero or pole.The inlet for the coefficient (aswell as the left inlet for the signal to filter) take audio signals. No stability check is performed.”
That stated it also means that the filter can only be used variably during operation, if it has a second inlet. Without the creation argument it’s pole (zero) would always default to zero.
Additional info: You can check what rzero-rev~ does in H14.all.pass.pd, which you find in 3.audio.examples of PD’s doc files.
Connect the rzero-rev~ object straight to the filter-graph2 (most right inlet) instead of going through the rpole~ object.
Then run the filtergraph with both arguments 1 (which i needed for my patch) and 0 (which the object defaults to, when no argument is given or - like in our case - accepted.
Argument 1 produces a broad with gain 0 at both 0 Hz and samplerate Hz, and gain 1 in the center of the spectrum - whereas no argument or 0 produce a flat filter response with gain 1 on any frequency.
That explains the gain difference i had posted about above. So, can we somehow get arguments into those filter functions (rzero~, rzero-rev~ and rpole~) - and their imaginary partner obects czero~, czero-rev~ and cpole~ aswell?
recirculating filter - does he mean an IIR, as opposed to FIR?
Is it possible to modify your patch to either
a) send in a constant 1-valued audio signal, or
b) use the bp~ filter instead?
I understand both options are probably overkill for what you want to do, but it would be good to know if there’s a possible workaround.
A better solution might be to rewrite the Puredata lib in hvcc to accept a constructor arg, but I’m not sure I understand the problem well enough to do that myself!
Might it be as easy as doing this (compare rzero_rev.pd screenshot above)?
… or does it need an additional multiplier stage, with [*~ $1]?
How do you set a default value for $1? or for an inlet?
Pd is confusing!
Does this image explain it better?
Just for reference: A “default value” is called “argument” of an object in PD.
Just found, that /heavy.ir.json on enzianaudio’s github does not contain an rzero object - Is this affecting or the rebel tech compiler yet?
I’m not sure what the purpose of that file is, but I know that PdParser.py pulls in the definitions in pd2hv/libs/pd/ which is where rzero~.pd is, using the graph_from_file function. So that file substitutes the rzero~ object in your patch.
That’s why I was thinking that if we can modify the implementation there to add the args, with defaults, then the problem is fixed, right? But then I got stuck because I can’t work out how to add construction args with defaults in Pure data.
Perhaps this is why Enzien didn’t already do it? Perhaps it needs custom handling in the parser to make objects with ‘args + defaults’? Or perhaps I’m barking up the wrong tree altogether?
Hi, so what is rebeltechs relationship with the heavy compiler? I’m coming in new, from what i can gather GitHub - enzienaudio/hvcc: The heavy hvcc compiler for Pure Data patches. looks kind of abandoned, but is in use by rebeltechs compiler for pd patches. Who maintains it? Do they want to cover all vanilla pd objects? What does its future look like, both as a compiler, and how its used by rebeltech?
What led me here: an existing pd patch (one from https://puredata.info/downloads/rjlib) that I’d like to use makes use of the [list] object. It seems rather basic, mentioned here /chapter: Lists / PURE DATA but heavy doesn’t have it. I’m new to puredata, so option 1 i could try and find how to replace [list] with something else. Option 2, maybe [list] could be added to heavy, but I dont know who would do this and would this even happen. Option 3, I can’t use rj patches that use [list] and should find a replacement resonant filter patch somewhere.
As an aside, so far puredata has been a bit of a nightmare of absolutely insane default behaviours, odd bugs, convoluted ways of setting up simple things and some really basic modules just dont exist in vanilla, so im pretty close to jumping ship, but i like the concept a lot. I’m a software engineer, but for this type of thing I just want to connect boxes with lines to get fun effects. MAX/MSP is much more expensive than I expected so havent gone that way yet.
Ok, I’m keen in powering through with pd for now, and will document issues that I hit. Uploading and using the hello world patch was easy as, no issues there. Writing my own tremolo patch with limited vanilla pd objects ([osc~]) and it was all fine too. As mentioned above I’m a fan of the rjlib library (https://puredata.info/downloads/rjlib), but some of their patches expose holes in the Heavy compiler.
I was using rjlib’s [u_highpassq.pd], which used [list]. At first when the compilation failed all I saw was this:
mv: cannot stat ‘/tmp/owl/owl-build-lFETEP/c/*’: No such file or directory make[1]: *** [/tmp/owl/owl-build-lFETEP/Source/Heavy_owl.h] Error 1 make: *** [heavy] Error 2 ERROR: Patch build failed.
But click on the Stdout tab to see the errors that caused the error
Building patch untitled-d51252a7ba6a 1) e[91mErrore[0m pd2hv: biquad6 ------- in "_main.pd/mosfez-trem-mono.pd/u_lowpassq.pd/biquad6 -------" @ (x:0, y:0): Don't know how to parse object "list". Is it an object supported by Heavy? Is it an abstraction? Have the search paths been correctly configured?
The solution for me was to replace [list] with something else. The super helpful people at pdpatchrepo.info responded with ideas, all of which worked (Replacement for [list]? | PURE DATA forum~)
Warninge[0m pd2hv: [unpack 0 0 0 0 0] in "_main.pd/mosfez-trem-mono.pd/e_beequad.pd/zeros" @ (x:208, y:103): Heavy only supports arguments 'f' and 's' to unpack.
My patch contained [unpack 0 0 0 0 0], I changed this to [unpack f f f f f]. As my patch doesn’t appear to use the default values, this works fine. I assume that a [loadbang] into a [0 0 0 0 0( could always prime the unpack with a bunch of default values, if I’m understanding it right.
Warninge[0m pd2hv: zeros in "_main.pd/mosfez-trem-mono.pd/e_beequad.pd/zeros" @ (x:386, y:79): [czero~] accepts only signal input. Arguments and control connections are ignored.
This one is odd. At first I had this:
I figured it was complaining about those control connections from [r $0-clear] to [czero~], and as I wasn’t using the clear functionality I removed those lines. But even when the only connections to [czero~] are signal connections, I still get the error saying only signal inputs are allowed.
@jrp and @mars I feel like I’ve hit something similar to what you were talking about earlier in the thread. I’d like to use [czero~] rather than [rzero_rev~] like you jrp, but compilation is erroring out due to that same conditional branch during compilation:
What’s odd is that I’m not wanting to use any arguments and I still get the error. Did either of you make any progress on this or find out anything new?
Hi dxinteractive. Personally i have no idea, how exactly the compiler works. As Enzienaudio went out of business (or service) we sort of rely on Martin to make corrections or further implementations possible.
And there is the speed issue. PD patches converted by the compiler tend to run up to 4 times slower, than the same (edit: very similar) patches from GEN.
Personally i am rarely using the OWL now so i am afraid i won’t be of much help, but of course would appreciate, when the filter objects you mentioned would be properly implemented, as that would enable drastic improvement of built in PD filters.
Do a search for quality of Pure Data filter objects. Many discussions there, since many years - the result of which in brief is: If you understand the math then use rzero etc instead of hip, lop, bp - however we can’t use them as dynamically controllable objects with the OWL as long as control inputs aren’t enabled
Check this thread, too: Tools to support PD patch development
… Martin doesn’t seem to use PD himself, so we might be kind of stuck here. Or take this matter in our own hands. Me, i cannot. I do not understand the process well enough.
Stupid me. Yes, i probably could edit
https://community.rebeltech.org/uploads/default/original/1X/373dfe33c2226cdb1b4887504ebfbb901ec752c2.png
https://raw.githubusercontent.com/enzienaudio/hvcc/master/interpreters/pd2hv/libs/pd/rzero_rev~.pd
Here’s a creation argument added to rzero_rev~.pd.
To import this in pd you can load the following into a .txt editor (no formatting) and resave as .pd
#N canvas 142 100 629 632 10;
#X obj 16 18 inlet~;
#X obj 16 183 outlet~;
#N canvas 0 22 450 300 @hv_obj 0;
#X obj 175 149 outlet~;
#X obj 173 75 inlet~;
#X restore 16 126 pd @hv_obj __del1~f;
#X obj 31 94 *~;
#X obj 16 161 -~;
#X obj 61 18 inlet~;
#X obj 75 47 loadbang;
#X obj 75 68 f \$1;
#X connect 0 0 2 0;
#X connect 0 0 3 0;
#X connect 2 0 4 0;
#X connect 3 0 4 1;
#X connect 4 0 1 0;
#X connect 5 0 3 1;
#X connect 6 0 7 0;
#X connect 7 0 3 1;