In response to your example below, the result of the addition will be 5~ given that messages [2( and [3( were sent while DSP was off. This is a surprise to me!

[sig~] can be helpful when you require a constant value at audio-rate, any example I can conjure seems contrived (as in writing a constant value to a tabwrite~).

On Wed, Nov 3, 2010 at 11:21 AM, Mathieu Bouchard matju@artengine.cawrote:

Why not have implicit control -> signal conversion everywhere it is

...

possible? For example why not allow this? |2( |3( | | [+~ ]

This is allowed (though I haven't checked the details of what happens if you send that while dsp is off).

---

| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 3 Nov 2010, at 16:14, Andy Farnell wrote:

There are some uses of [sig~] which are not immediately obvious but turn out to be desirable. By definition it is useful any place you want a message domain value converted to a signal, without any further ado. Without it, relying only on implicit conversion you might never have access to a signal except by a degenerate idiom like

[$1( | [line~]

Crucially, [sig~] can be given a creation parameter, as in [sig~ 1], and will not need any messy initialisation like using a [loadbang] in order to obtain a signal constant immediately.

Why might you want a signal constant? Perhaps for a relation like (1 - x), useful in panning, crossfading, or (1 / x) common in waveshaping.

Matju raises a question over DSP on/off. I have encountered problems relying on implicit right inlet conversion with deep abstractions, so from practical experience it seems safer to use [sig~] in these circumsatnces.

It also make code more readable to make important message/signal distinctions explicit.

Thanks Andy. So:

[sig~ 1] | [tabosc4~ foo]

avoids:

[loadbang] | |1( | [tabosc4~ foo]

This is reason enough for me.

best,

Jamie

On Wed, 3 Nov 2010 14:46:51 +0000 Jamie Bullock jamie@postlude.co.uk wrote:

...

Hi all,

This is more of philosophical question than anything else. I'm curious to know why [sig~] hasn't been designed out of Pd. Why not have implicit control -> signal conversion everywhere it is possible?

For example why not allow this?

|2( |3( | | [+~ ]

Jamie

-- http://www.jamiebullock.com

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-- Andy Farnell padawan12@obiwannabe.co.uk

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

--- On Wed, 11/3/10, Andy Farnell padawan12@obiwannabe.co.uk wrote:

From: Andy Farnell padawan12@obiwannabe.co.uk Subject: Re: [PD] Purpose of sig~ To: pd-list@iem.at Date: Wednesday, November 3, 2010, 5:14 PM There are some uses of [sig~] which are not immediately obvious but turn out to be desirable. By definition it is useful any place you want a message domain value converted to a signal, without any further ado. Without it, relying only on implicit conversion you might never have access to a signal except by a degenerate idiom like

[$1( | [line~]

Crucially, [sig~] can be given a creation parameter, as in [sig~ 1], and will not need any messy initialisation like using a [loadbang] in order to obtain a signal constant immediately.

Why might you want a signal constant? Perhaps for a relation like (1 - x), useful in panning, crossfading, or (1 / x) common in waveshaping.

Matju raises a question over DSP on/off. I have encountered problems relying on implicit right inlet conversion with deep abstractions, so from practical experience it seems safer to use [sig~] in these circumsatnces.

Is this because signal inlets of signal objects (except for the leftmost) don't accept one-element lists? If so I think it'd be a cheaper workaround putting a [t f] before those inlets.

It also make code more readable to make important message/signal distinctions explicit.

They are already explicit-- at least in pd-extended, where the signal inlets are visually distinct from the control inlets.

-Jonathan

On 2010-11-03 23:42, Jonathan Wilkes wrote:

Is this because signal inlets of signal objects (except for the leftmost) don't accept one-element lists? If so I think it'd be a cheaper workaround putting a [t f] before those inlets.

or upgrade to Pd-0.43, where there is an implicit conversion between 1-element-lists and floats/symbols, as well as zero-element-lists and bangs.

fgmasdr IOhannes

On 4 Nov 2010, at 09:50, IOhannes m zmoelnig wrote:

On 2010-11-03 15:46, Jamie Bullock wrote:

...

Hi all,

This is more of philosophical question than anything else. I'm curious to know why [sig~] hasn't been designed out of Pd. Why not have implicit control -> signal conversion everywhere it is possible?

For example why not allow this?

|2( |3( | | [+~ ]

i don't think i understand your question.

Well retrospectively, the question doesn't make any sense at all because it's based on a test I did with a (subsequently discovered) broken bang~.

See bug https://sourceforge.net/tracker/?func=detail&aid=3102828&group_id=55...

So I thought that implicit conversions weren't working, when in fact bang~ wasn't triggering my snapshot~.

Jamie

the above is totally legal on the versions of Pd i have installed on this machine.

otoh, [sig~] has been there for ages and longer. some old patches might still use it, because _then_ you had to explicitely convert to signals. should [sig~] be removed and break these patches?

and while i do use implicit float/signal conversion in my patches, i think explicit conversion is not that bad either: it may prevent people from hooking a slider into a [*~] and then complain why they get glitches.

fgmasdr IOhannes

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list