vcf~ requires signal into second inlet in order to work

[giuliomoro]

If you have a message into it it won't error, won't warn, won't work. This is probably because vcf~ is implemented as an external with a [inlet~].

Desired behaviour: turn it into a signal automatically.

[dromer]

From what I can tell [vcf~] in pd should always receive an audio signal to set the center frequency (according to the docs).

Do you have an example where [vcf~] turns a message into a signal automatically? Because afaict this is not how it's intended to be used.

[giuliomoro]

#N canvas 769 255 450 300 12;
#X obj 194 44 hsl 128 15 100 10000 1 0 empty empty empty -2 -8 0 10
#fcfcfc #000000 #000000 0 1;
#X floatatom 193 94 5 0 0 0 - - - 0;
#X obj 122 131 noise~;
#X obj 148 258 dac~;
#X obj 152 197 vcf~ 1;
#X connect 0 0 1 0;
#X connect 1 0 4 1;
#X connect 2 0 4 0;
#X connect 4 0 3 0;
#X connect 4 0 3 1;

also the [vcf~] help file says

Vcf~ is a resonant band-pass and low-pass filter that takes either a control or an audio signal to set center frequency

So it is an expected behaviour. What hvcc needs is probably a new type of inlet that can take (and deal with) control vs signal (uh! complicated), or at least its [vcf~] should have something like

[inlet~] // second inlet
|
[sig~]
|
// rest of the patch

[dromer]

Huh, the docs in my pd say this:

vcf~ is a resonant band-pass and low-pass filter that takes an audio signal to set center frequency, which may thus change continuously in time.

So this has been changed in later Pd versions. It's unlikely that Heavy will be fully compatible with the absolute latest Pd API. Dealing with inlets that allow both signal and control rate is very tricky and I'm not sure this will ever be possible with heavy (especially since it uses abstractions for many implementations).

I don't think your proposed solution would work considering sig~ expects a control message as its input (I mean you literally can't patch this).

[giuliomoro]

two recent versions of Pd

[dromer]

Yeah odd:

[dromer]

So I honestly think the chances of someone coming up with a way to handle both signal and control messages on the same inlets in Heavy are extremely slim. This likely needs a complete redesign which is obviously not going to happen.

However I wonder how we can do the initialization without any input. Any suggestion to detect this is welcome.

[dromer]

I'm now thinking .. if there is no input then normally [inlet~] initialized with a default, which would be equivalent to [sig~ 0] no? Isn't that what you are seeing here? it would not give an error because it simply initializes with a 0 value/signal.

[edit: hmm, ok I see that then it behaves as if the vcf~ isn't there. Must be some way to detect this .. I'm afraid this won't get any attention until we can run signal tests and properly observe this.]

[dromer]

Heh. On the topic of inlets that can handle both signal and control messages I went on a little excursion down the rabbit hole and found at least some hints on how this is achieved.

Some references:

https://wasted-audio.github.io/hvcc/docs/07.heavy_lang.html#connections
https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/interpreters/pd2hv/PdGraph.py#L80

So, it might be done by implanting a special subpatch that "splits" the connection and handles things.
Now I don't know if this is also how we could then define a "default" so the vcf~ gets initialized properly without any incoming sig~ ...

It seems that they've done this by "forcing" such a connection to take place in the pd-patch manually (see for instance https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/interpreters/pd2hv/libs/pd/snapshot%7E.pd ). Something you can't do in the pd patcher directly.