Allow receiving messages on signal inlets, helpfile fix

[timothyschoen]

By implementing the "fwd" message, we can make sure that signal inlets can still receive messages. Pretty essential for signal objects, since you'll probably still want to be able to use methods on the first inlet. I checked the purr-data source code, and it looks like this should also work there.

Also fixed a bit of outdated API I found in the helpfile

This should really be everything, I would hope

[agraef]

Can you please have a look at #44 and fix that along the way? Thanks.

[agraef]

I don't quite get it. :( The only way I can actually pass a control message on the signal inlet seems to be explicitly as fwd data ... and then I need to dispatch on the fwd selector in the Lua code. Is that how it's intended to work?

[timothyschoen]

If I do this:

local lua_sig = pd.Class:new():register("lua_sig")

function lua_sig:initialize(sel, atoms)
    self.inlets = {SIGNAL, DATA, DATA}
    self.outlets = {SIGNAL}
    self.phase = 0
    return true
end

function lua_sig:dsp(samplerate, blocksize)
    self.samplerate = samplerate
end

function lua_sig:in_1_abc(atoms)
    pd.post("message")
end

function lua_sig:perform(in1)
    local frequency = 220       -- Frequency of the sine wave in Hz
    local amplitude = 0.5       -- Amplitude of the sine wave (0 to 1)

    -- Calculate the angular frequency (in radians per sample)
    local angular_freq = 2 * math.pi * frequency / self.samplerate

    -- Loop through each sample index
    for i = 1, #in1 do
        in1[i] = amplitude * math.sin(self.phase)
        self.phase = self.phase + angular_freq
        if self.phase >= 2 * math.pi then
            self.phase = self.phase - 2 * math.pi
        end
    end
    return in1
end

I can now still send the "abc" message to the first signal inlet. Does that not work for you?

I'll look into the segfault as well!

[agraef]

Yes, abc works, as does any other meta message, and I also see the arguments if present.

But, at least for me, with this PR float values don't work any more. In fact, they neither work on the signal nor on the data inlets. Float inputs not working at all is kind of a big deal for me. ;-)

[agraef]

Scratch that, the data inlets are still alright. But for me the signal inlet doesn't accept any float values, it just ignores them. Is that by design? But the osc~ object does that just fine.

[timothyschoen]

Scratch that, the data inlets are still alright. But for me the signal inlet doesn't accept any float values, it just ignores them. Is that by design? But the osc~ object does that just fine.

I noticed this too, looking at the pure-data source code, it looks like the "fwd" message is implemented for everything except floats and pointers. Maybe we also need to add a float method and also hook that up to dispatch?

[agraef]

Hmm yes, looking at the C code for vanilla's osc~, I see that there's some special magic going on there, via CLASS_MAINSIGNALIN(), which expands to class_domainsignalin().

The way it's done here, using dsp_addv(), I don't think that we can emulate that kind of behavior.

[timothyschoen]

Hmm yes, looking at the C code for vanilla's osc~, I see that there's some special magic going on there, via CLASS_MAINSIGNALIN(), which expands to class_domainsignalin().

The way it's done here, using dsp_addv(), I don't think that we can emulate that kind of behavior.

Trying this some more: it just automatically converts floats to signals. I think that's a fine way to have it, since this is what you'll want to have most of the time anyway.

[agraef]

Anyway, this is still a big improvement, as you can now at least have the first signal inlet deal with meta messages, e.g., to set internal control values. Like so:

function lua_sig:in_1_freq(atoms)
    self.freq = atoms[1]
end

function lua_sig:in_1_amp(atoms)
    self.amp = atoms[1]
end

I like it. :)

[agraef]

Trying this some more: it just automatically converts floats to signals. I think that's a fine way to have it, since this is what you'll want to have most of the time anyway.

Agreed. That makes perfect sense.

[agraef]

Merged, thanks!

[agraef]

Drats, this one has issues in Purr Data, too. There I'm only getting the symbol float via the proxy, and nothing else. Might be that we simply haven't implemented the fwd message, I will have to investigate.

[agraef]

Yes, it looks like we missed pure-data/pure-data@2fa003d0 when backporting the "fwd" feature. I'll need to fix that on the Purr Data side.

[timothyschoen]

Yes, it looks like we missed pure-data/pure-data@2fa003d0 when backporting the "fwd" feature. I'll need to fix that on the Purr Data side.

I saw this, looks like it's implemented? https://github.com/agraef/purr-data/blob/50241ace9d55df48574279f0216b51bb914796ad/pd/src/m_obj.c#L84

[agraef]

Not quite. Guillem used mess3() instead of typedmess() in inlet_fwd() which doesn't do the right thing there. This should be easy to fix, though, stay tuned.