itable, abstractions, and saving data

Jul 24, 2011 at 4:29am

itable, abstractions, and saving data

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

#58166
Jul 25, 2011 at 11:52am

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

#208892
Jul 25, 2011 at 4:49pm

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

#208893
Jul 25, 2011 at 4:52pm

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

#208894
Jul 25, 2011 at 5:12pm

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.

#208895
Jul 25, 2011 at 5:13pm

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

#208896

You must be logged in to reply to this topic.