[PD] [*] vs [*~]

[Mathieu Bouchard]

On Wed, 27 Dec 2006, carmen wrote:
> Matju wrote:
>> why is it that [*] is only for floats, whereas if you want to multiply 
>> two signals one has to use [*~] ? And then why is it that [*~] can 
>> multiply a signal by a float, but [*] can't do that?
> because according to Pd rules its not OK to confuse the user with 
> seperate objects/operators for floats vs ints or symbols vs strings, but 
> ok for signals vs floats?

Well, signals have also that special mojo that makes their execution order 
fly high above the mortal mofos like floats and stuff... that would be a 
reason to keep them different.

> why is it that [*] can't multiply a list by an integer?

[*], like many arithmetic classes, interpret a 2-element list as if it 
were:

[unpack]
  |    |
[*     ]

there's a lot of implicit [unpack] all over pd. If lists are to be 
supported in [*], we need to have them implemented differently... have 
another kind of list, a list-atom (A_LIST), but then, because it means 
a new way of interacting with atoms (unlike strings that can be 
handled just like symbols), it has to be given a new selector. This 
can't be 'list' because it's a conflict with an existing name that has 
different expectations (the existing 'list' is closer to 'anything'; 
the new selector goes with a single A_LIST element instead of having 
the message be the collection).

> or is that what you mean by signal, a list of floats?

It could be, but there are three major distinctions:

  1. that list is float-only, stored as t_float[] instead of t_atom[].
  2. that list would be A_LIST so that it doesn't get caught in [unpack].
  3. that list has the mojo.

>> And then why is it that [*~] can't multiply a float by a signal, the 
>> signal has to be on the left?
> the main reason i can think of is it's a lossy operation if the return 
> value is a float.

The assumption that you are making is interesting: you assume that in this 
case the output would/could be a float, according to some unspecified rule 
which appears to be that the output type follows the type of the left 
input.

In MAX (and jMax), float vs int is decided by the right input, not the 
left one.

In GridFlow's [#], output size is determined by left input, which is sort 
of suggesting that output type should also be determined by left input 
(although this feature has not been implemented there).

In Pd, the mode of [*~] (and such) is determined by right input. Actually, 
I should stress that this is determined by right argument, which then 
forces a specific right inlet type. I don't remember whether MAX/jMax's 
float-vs-int input type can be changed at runtime, but for atom-vs-signal 
I think I recall that they do it like Pd.

> what value for the signal are you operating on - the value of the first 
> sample in the DSP block?

In the logic of [#], it would be the first sample, because [#] causes an 
implicit [#redim] on its right input.

> the average of all the samples in the block?

That wouldn't be so often useful for sound, would it? In any case, it's 
the same difference as between those two:

   [#downscale_by 64]
   [#downscale_by 64 smoothly]

> the * vs *~ distinction might be useful to specify a desired return 
> type..

... but that's only one way to specify a rule. doing it by the type of the 
right input (inlet and/or argument) is another way.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada