Hey there,

i'm a complete noob on pure data and i was just experimenting with some random, tone generators yet. In the following Patch i created, i still get clicks out of my monitor boxes everytime i turn on the toggle even though i putted down the line~ (and also the vline~) object with different ramp-values. Is there anything wrong on how i embedded the line object? Or is it my hardware (I'm using 4.5 PreSounus Monitors and a Focusrite 2i4 with buffer on 2ms, but i already tried higher buffer lengths). I appreciate if anyone could help me with that issue.

Thanks, T.

@pud Hello pud........ It is a mistake that everyone makes only once!
The [$1 50] ......... ([$1 5] would be plenty) is a message that you are sending to [vline~].
The message should be [1 5( and [0 5( depending upon the toggle state....
But you put an "object" [$1 50] and not a "message" [$1 50(.......
It should be.........
without_clicks.pd
David.

Oh man, thank you very much. I better improve my knowledge about box-types or my own debugging skills. No clicks anymore...

Thanks! T.

This is really insidious.

In a toplevel patch

[$1 50]

evaluates to

`[0 50]

When you put that in an object box, Pd sends a message "0 50" to the special class "objectmaker". And what does "objectmaker" do when it receives this list? It creates a new [list] object with the arguments "0 50".

So

[0 50]

is the same as

[list 0 50]

This is probably useful 0% of the time, and probably a subtle bug 100% of the time.

It'd be quite dangerous to change Pd's message evaluation to check for this special case. But it looks like it's possible to check for this when a user tries to instantiate a new object when creating a patch. In cases where an object box has multiple arguments and starts with a float, it'd be better to make a broken object than instantiate it.

@jancsika
A toggle feeding [$1 50] outputs "1 0 50" and "0 0 50" and so [vline~] "switches" after 50 in both directions and so it "clicks"........
The middle atom, the 0 (zero) is the translation of the first argument of the abstraction........ and as this is not an abstraction (so no value has been assigned) it is given the value "zero"........
An object that outputs a series of atoms outputs the series as a list if the first atom is a float....
It is documented and is not a bug.......... http://puredata.info/docs/manuals/pd/x2.htm
chapter 2.3.1 Anatomy of a message (at the end)...........
It makes no sense to create an object containing an un-assigned variable........
If there is a bug, it is that it throws no error... but then the program cannot foresee your future requirements for the object........
David.

@whale-av said:

@jancsika
A toggle feeding [$1 50] outputs "1 0 50" and "0 0 50" and so [vline~] "switches" after 50 in both directions and so it "clicks"........
An object that outputs a series of atoms outputs the series as a list if the first atom is a float....

I'm not saying Pd's default list handler is buggy. I'm saying it's a bad idea to let users create implicit lists inside object boxes.

The language can specify implicit list behavior, and at the same time the implementation can block users from doing something that's nearly guaranteed to cause a runtime bug.

Connecting an object's outlet to its cold inlet is similar. The language defines this behavior, but the GUI does not let you do it.

@jancsika That is true, but so often a huge workload is saved as we can pass variables directly to an object. Getting $0 into an object involves a workaround that not many seem to understand, and we would have to deal with that all the time and for every variable......
The program cannot know whether we are writing the object to the (future) top window........
David.

@whale-av said:

@jancsika That is true, but so often a huge workload is saved as we can pass variables directly to an object. Getting $0 into an object involves a workaround that not many seem to understand, and we would have to deal with that all the time and for every variable......
The program cannot know whether we are writing the object to the (future) top window........
David.

Looking back at the big wad of side-effects that is Pd object instantiation, it may be more trouble than it's worth. But the logic is pretty simple: check if the box text the user wants to instantiate starts with A_FLOAT after the dollars are expanded-- if it does and it's not inside a message box, refuse to create it.

The code path responsible for instantiating a box the user typed into is separate from the parser and pd file i/o, so those areas of the program wouldn't be affected at all.

Edit: well not exactly separate, because box instantiation relies on the parser. What I mean is you can do the check for A_FLOAT without touching the parser code.

@jancsika True...... that would work and be an excellent idea...... you could put it to the bug list for consideration........https://sourceforge.net/p/pure-data/bugs/
David.

Another possibility-- if the user types a list in an object like [0 1], create [list append 0 1].

If a user types a float like [1], create [float 1].

Everybody wins.

@jancsika That is already exactly (well..... nearly....... the float is replaced) what happens......... in extended.....
To me replacing the float seems "logical"......... it is a defined "placeholder" like [f]......
in vanilla I don't know if that is true.....
.......... no [rawprint] ...... boo hoo......

See Pd\doc\manuals\MessageOddness if you want to understand all of the possible pitfalls.....

David.