Awesome

I also encountered another issue with merge
When I unpack an Array get into 16 floats ( converting to symbols ) into a merge 16 , the object prints twice
9_05.pd

If you click on one of messages (-,x) in the first inlet of merge 16 it will output a list as expected becauseit's hot , but so does the 13 th input ..which is weird

@ porres , If you don't mind I will post this on the discord/else forum since it's out of the scope of this topic .
Thanks everybody for the suggestions .

Either way , else merge -unmerge is great , good job !
I don't see any benefit in using pack anymore when combining floats - symbols .
Thanks !

Unjoing a symbol
Join 3 where third inlet is symbol
Then unjoin 3 , third outlet is a decimal : 1.91027e-20
Unmerge otoh is working correctly

@porres
Wow , amazed that Cyclone has join .
Sadly unjoin it not behaving as it should when unjoining characters-symbols

True to that , some of pd modules are more flexible
List store appart from storing lists can also be used as a lookup ( get $1 ) , in max you need zl lookup etc..
Will try , thanks guys for the answers

@seb-harmonik.ar
That's exactly what thought
Is there any way how to actually see how pack works internally , or any other object for that matter . ?

@ oid , interesting
How did you find out that pack works like that ,( not that I doubt your expertise at all ) ?

Max has this wonderfull object in the pack family called join ( not zl - join ) it accepts everything no matter the selector .
You just give it the nr of input arguments and the hot inlet port ( all if needed )
Really wish pd has someting like that

Thanks , but dont you mean "many NON vanilla objects go against vanillas standard behaviour ? "

But what if the first inlet is not a list it unpacks, like in my examples ?

Firstof all , I 'd like to say that is the second forum I am posting this on because it is doing my head in .
If I have a pak object (PAK ) with s s s as arguments , it accepts and outputs a list , but I can not conclude if these are considered symbols or not ( see next )
Like this
If I use a pack ( PACK ) with s s s , the messages 'x ' and '-' in the second and third inlet , need to be converted to symbols in order for the pack object to work , the first inlet does not need it
Like this

Now have a look at pack without the symbol boxes ,

When pressing the second and third toggle , the console says : expected symbol but got "x" or "-" ( there is no symbol box involved ) .
When pressing the first toggle , the "- "or "x" is send and received , does the pack see this as a symbol ? ( if so how can we examine this )
Furthermore , why doesn't it see the second and third as a symbol ?
This is were it's so cumbersome to actually see what's going on under the hood ..

Now I change the first argument of pack to integer , so pack = i s s , then the console says : Pack_symbol wrong type
From this I can conclude that the first message is indeed interpreted as a symbol (and rejected because it expected an integer ) , so why do the next and third inlet need an explicit symbol box , and why doesn't PAK need any at all ?

Just when I got the hang of lists and it's selectors , I bump into new issues

Thanks