Holiday notice: Cycling '74 will be closed Monday, October 9th. Manual authorization, support cases, and manual order processing will be delayed.
itable, abstractions, and saving data
Jul 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
- Jul 25 2011 | 11:52 amAfter perusing these forums for so e time now, I'm wonderig if pattrstorage is the way forward?
- Jul 25 2011 | 4:49 pmi would use coll instead of itable - and dont give it a name.
- Jul 25 2011 | 4:52 pmcoll doesn't give you a graphic view that you can change on the fly and have it remembered
- Jul 25 2011 | 5:12 pmyou 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.
- Jul 25 2011 | 5:13 pmThanks --- this is definitely my next set of experiments. I appreciate the tips.
