Tarik

I have a pattr, bound to a multislider with 3 sliders.

I unpack the list that the pattr sends out its left outlet.

I connect the unpack object to three number-objects and to let changes made in these numbers be reflected in the multislider, I connect these to a pak object, which I in turn connect to the initial pattr.

Strange things happen when I change the numbers: they start jumping in strange ways that I don't understand.

I have a pattr, bound to a multislider with 3 sliders.
I unpack the list that the pattr sends out its left outlet.
I connect the unpack object to three number-objects and to let changes made in these numbers be reflected in the multislider, I connect these to a pak object, which I in turn connect to the initial pattr.
Strange things happen when I change the numbers: they start jumping in strange ways that I don't understand.

unpack-pack-pattr-stangeness

If I change the arguments of the pak object from "0. 0. 0." to "f f f" the behaviour changes completely: all numbers just stick to 0, no matter how you try to drag them.

I don't mean to spam you guys but here's another funny example which would be expected to do the same as the previous patch, but works much better! Even though the numbers are still a little shaky (so I still can't really use this principle).

Your patch works fine here, just in the way it should. 4.5.5 WinXP SP2

> Strange things happen when I change the numbers: they start jumping in 

Not that strange as you're doing some kind of feedback.

Insert 3 [prepend set] between your [unpack] and your float boxes.

> Strange things happen when I change the numbers: they start jumping in 
> strange ways that I don't understand.

Not that strange as you're doing some kind of feedback.
Insert 3 [prepend set] between your [unpack] and your float boxes.

But, for your information: pak indeed does not see "f f f" as symbols referring to floating point numbers. Pack and unpack however do!

> But, for your information: pak indeed does not see "f f f" as symbols 

> referring to floating point numbers. Pack and unpack however do!

Hell! You're right. I never used [pack] that way, and I wonder if it 

has always work like this. In Max457's pack's documentation, I read " 

If the argument is a symbol, that item will be stored as a symbol". And 

"f" _is_ a symbol. I'll continue not using what will probably be called 

But why not trying to be consistent and then use "int", "float" 

> But, for your information: pak indeed does not see "f f f" as symbols 
> referring to floating point numbers. Pack and unpack however do!

Hell! You're right. I never used [pack] that way, and I wonder if it 
has always work like this. In Max457's pack's documentation, I read " 
If the argument is a symbol, that item will be stored as a symbol". And 
"f" _is_ a symbol. I'll continue not using what will probably be called 
a feature.

But why not trying to be consistent and then use "int", "float" 
arguments like with [route]?

Yep, it's strange that pak and pack have this inconsistency in their architecture. The reason I like to use "f" instead of "0." is because I create these objects using javascript. If in javascript I want to create a "pak 0. 0. 0.", this seems to be impossible. Either javascript I can make the argument "0." into a string, which makes it work as a symbol argument, or I can make it into a number, which automatically is converted to "0": an integer.

So what I do now is create a "pak 0.000000000000000000000000000001 0.000000000000000000000000000001 0.000000000000000000000000000001" object...!

Funny stuff that Max makes you do sometimes...

jeremy bernstein answered to a similar question not so long ago:

> Yep, it was on purpose. Those shortcuts are non-documented, kept-

> around-for-legacy-reasons, and not-guaranteed-to-work-forever

> aberrations on the otherwise beautiful face of pack.

> Am 24.08.2006 um 21:10 schrieb Yacine Sebti:

> > was it on purpose to "forget" those shortcuts to set the types of

> > I was so used to write pack i f ... that I always forget that it

> > maybe it's to late now to add them ...

> Yep, it was on purpose. Those shortcuts are non-documented, kept-
> around-for-legacy-reasons, and not-guaranteed-to-work-forever
> aberrations on the otherwise beautiful face of pack.
>
> jb
>
> Am 24.08.2006 um 21:10 schrieb Yacine Sebti:
>
> > was it on purpose to "forget" those shortcuts to set the types of
> > pack inlets in pak ?
> > I was so used to write pack i f ... that I always forget that it
> > doesn't work with pak .
> > maybe it's to late now to add them ...
> > hummm ...
> > just to say...
> >
> > //yac
>

Although this javascript instantiation problem is the best argument 

I've heard yet for those two special symbols to be added. Drat.

> jeremy bernstein answered to a similar question not so long ago:

Although this javascript instantiation problem is the best argument  
I've heard yet for those two special symbols to be added. Drat.

> jeremy bernstein answered to a similar question not so long ago:


> Hell! You're right. I never used [pack] that way, and I wonder if it has 

> always work like this. In Max457's pack's documentation, I read " If the 

> argument is a symbol, that item will be stored as a symbol". And "f" 

> _is_ a symbol. I'll continue not using what will probably be called a 

This has been discussed, and the "i" and "f" behaviour has only been 

left for backward compatibility. You should always write [pack 0. 0. 0.] 

even if it interprets "f". Its kind of an unwanted feature which slipped 

But in the example there is no need at all for pak or the extra bangs 

with pack. Even if only the right element is changed, the unpack will 

output all three values... (Elsewise you send 3 (different) lists in a 

Patrick Delges wrote:
> Hell! You're right. I never used [pack] that way, and I wonder if it has 
> always work like this. In Max457's pack's documentation, I read " If the 
> argument is a symbol, that item will be stored as a symbol". And "f" 
> _is_ a symbol. I'll continue not using what will probably be called a 
> feature.

This has been discussed, and the "i" and "f" behaviour has only been 
left for backward compatibility. You should always write [pack 0. 0. 0.] 
even if it interprets "f". Its kind of an unwanted feature which slipped 
in in the past.

But in the example there is no need at all for pak or the extra bangs 
with pack. Even if only the right element is changed, the unpack will 
output all three values... (Elsewise you send 3 (different) lists in a 
fast row...)

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> (Elsewise you send 3 (different) lists in a fast row...)

If you want to use the floatnums as input, this would be the correct 

Stefan Tiedje wrote:
> (Elsewise you send 3 (different) lists in a fast row...)

If you want to use the floatnums as input, this would be the correct 
version:-)

Unpack, pack & pattr stangeness