I believe that I do not understand all the subtilitées concerning the abstractions particullary in the use of the #
With #0, it me good attribute a random number, but the contents of tables remain identical.
(sorry for bad english)
"table #1something": the #1 part will be replaced by whatever the argument of the abstraction/bpatcher is.
"table #0something": the #0 will be replaced by an unique number (each abstraction/bpatcher instance will have a different number)
Note that in order to work properly the #n needs to be the first thing of a symbol.
use the #1 at the beginning of the table name, and use no spaces. you had "table ifo #1" which won't work for these two reasons. for the #1 to work (in the context of things like send and receive as well) it must be at the beginning of the symbol. If you have a space in the table argument, it won't be part of the name---it would treat it as another argument. So change to "table #1ifo" or whatever you want to call it.
But there's more to it, as I discovered... I made a main patch with "table #1ifo", then made another patch with two bpatchers, so one with argument 1 and one with argument 2. Didn't work because the main table in the master patch was still open. Closed that one, still didn't work... but saved and closed the bpatch-holding patch, re-opened, then voila---the tables were correctly instantiated this time, named "1ifo" and "2ifo", with uniquely-controllable contents.
So... the main thing is to close the patches you're working with before you test with different tables. If they get created while the master one is still open, they'll always reflect that one, regardless of the arguments you give, so it seems...probably the case for coll and other objects too, not sure...
Thank you for all these advices, I can now separate the contents of tables, this forum is really indispensable for me!
My last discovery: tables aren't saved with the patch, in the reopening, the data disappeared (I filled well "save data with patcher" in the inspector)