Abstraction referencing a table clobbers the table's size
1. Create an abstraction containing [table #1]. Saved in this example as "minimal-table-abstraction.maxpat"
2. In another patch, create a table with predefined size 1000: [table aaa @size 1000].
3. Then add an instance of that abstraction, supplying aaa as the table name.
4. In the parent patch, query the table's size. I get 128 instead of 1000.
It does not help if the abstraction consists of [loadbang] --> "refer #1" --> [table] instead of just [table #1].
Is this a known bug? It's certainly a quite nasty behavior. The abstraction should not override the table's properties.
I ran into this because I created an abstraction to remove some items from the table based on a condition, then found wrong data coming back out of the table at higher indices. While testing that, I found the reason is because the higher indices just didn't exist, despite having been defined. So I guess now I will have to do a [loadbang] --> [delay 5] --> "size 1000" or such.
hjh
why this complications ?
if you have a table and want to edit it, then do it straight.
loading abstraction with table inside defaults to size 128
or any other size set as argument.
when you rename it by typing argument, it edits original table.
Are you sure that for you the loadbang approach doesn't work? It does for me. Which makes sense given it gets executed after objects get initialized, from deepest patcher to topmost one.
> Are you sure that for you the loadbang approach doesn't work? It does for me.
Maybe a Max 9 update, then. It definitely doesn't work here.
> why this complications ? if you have a table and want to edit it, then do it straight.
Defining a resource in one place, and having user-defined library objects (i.e. abstractions) that respect that definition instead of overwriting its properties, is a normal thing to do in programming environments.
Since more recent Max improves the behavior (TFL's message), it would seem that Max devs agree.
hjh