Forums > MaxMSP

itable, abstractions, and saving data

July 24, 2011 | 4:29 am

I’ve been building a lot little abstractions that I combine in different ways to make song patches. I wanted to make a velocity mapper that includes an itable that I could just instaniate in different main patches. I found however that if I insert it as an abstraction, then I can’t change the itable values as all other patches will see the change. I wasn’t able to do it as a sub patch since creating an object called ‘p velmapper’ just creates an empty sub patch every time.

How can I create a sub patch or abstraction (or something else) such that I can instantiate it multiple times with each version remembering its own data?

Thanks for any tips

July 25, 2011 | 11:52 am

After perusing these forums for so e time now, I’m wonderig if pattrstorage is the way forward?

July 25, 2011 | 4:49 pm

i would use coll instead of itable – and dont give it a name.

July 25, 2011 | 4:52 pm

coll doesn’t give you a graphic view that you can change on the fly and have it remembered

July 25, 2011 | 5:12 pm

you can use pattrstorage, each abstraction will be listed as a separate entry (you need to use @greedy 1 on the main patch’s pattrstorage). Am assuming that script creating/loading/deleting abstractions will be OK with pattrstorage, should be I imagine, but have not tried it.

Easier, though, is to just use [preset] and save as many as you want (say 8 different table data sets). Then use [loadmess #1] to [preset], and give the abstraction the corresponding argument you want to load as the stored preset number. However, changing presets will NOT be stored, these need to be changed in the abstraction file itself. For changing on the fly you’d need pattrstorage, and you’d need to save the pattrstorage file.

July 25, 2011 | 5:13 pm

Thanks — this is definitely my next set of experiments. I appreciate the tips.

Viewing 6 posts - 1 through 6 (of 6 total)

Forums > MaxMSP