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 conversio
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 th
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
--- On Wed, 11/3/10, Andy Farnell wrote:
> From: Andy Farnell
> 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 defi
Ah yes! A joy us vanilla freaks have yet to fully cherish.
:)
a.
On Wed, 3 Nov 2010 15:42:07 -0700 (PDT)
Jonathan Wilkes wrote:
> They are already explicit-- at least in pd-extended, where the
> signal inlets are visually distinct from the control inlets.
--
Andy Farnell
_
Though on the downside... a [sig~] is
more expensive.
The good part about implicit conversion is
you have to do it once and the object can
retain that state.
cheers
a.
On Wed, 3 Nov 2010 16:20:57 +
Jamie Bullock wrote:
>
> On 3 Nov 2010, at 16:14, Andy Farnell wrote:
>
> > There are
On 3 Nov 2010, at 15:21, Mathieu Bouchard wrote:
> On Wed, 3 Nov 2010, Jamie Bullock wrote:
>
>> This is more of philosophical question than anything else.
>
> I think of it as rather pragmatic. What does make a question philosophical
> according to you ?
I mean that I'm interested in the rea
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 imp
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
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 constan
Le mercredi 03 novembre 2010 à 14:46 +, Jamie Bullock a écrit :
> 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 e
On Wed, 3 Nov 2010, Jamie Bullock wrote:
This is more of philosophical question than anything else.
I think of it as rather pragmatic. What does make a question philosophical
according to you ?
I'm curious to know why [sig~] hasn't been designed out of Pd.
But it *has* been designed out.
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.jam
13 matches
Mail list logo