From the FaceBook TouchDesigner Help Group
In Looking at the design of a simple ue system..I can’t wrap my head around head following to start construction
Theoretically there would one dat table with the preset name description and values
One Table Per Preset or am I looking at setting and recalling the states wrong, and there is an easier way to save and set the state using storage ??
I will build it myself.. looking for the best approach to start working on this.
There are lots of ways you might tackle this. Using a table – you could use a table per preset switching between tables, or one table with all presets where you select the row or column you need.
If you’re using storage you might think about how you store your presets as dictionaries or lists – depending on the complexity of your presets.
IMHO – tables tend to be more straight forward, and for simpler systems are fast to build. Tables are also useful for distributed systems when you need / want to use Touch Out DATs to push information around a network.
Dictionaries are great for complex systems that have lots of moving parts. It takes some additional time to set-up and debug, but is very flexible and extensible once you have the scaffolding in place. For a simple system, however, this might be a little overkill – it’d be easy to loose a lot of time in the building of your data structure, rather than in building your system.
I might start by considering scale first… how many key / value pairs per preset, and how many machines are you running this one. In my experience, the more I’ve spent time thinking through how the larger scope of a project is going to function, the easier it is to make a decision about the appropriate data structure for a project.
I too want to build my own left-mouse->recall, right-mouse->save -table preset system. I started one but got stuck with it unsure.
There’s this on the forums: https://www.derivative.ca/Forum/viewtopic.php?f=22&t=6582 It’s great, but it was also a bit too much to reverse engineer. I’d like to have my own system. Not meaning to hijack this thread but just thinking out loud. If i have say 8 tables with the correct amount of rows, and i use “rmouseclick” to save the CHOP values of my sliders to those tables, and then “lmouseclick”(or whatever it was called) to recall the correct table and overide the slider CHOP value, i can haz presets. Sadly i cant write the python to read/write from table. Probably isn’t too hard
I think I have an example of something like this somewhere Marko – I’ll see if I can dig it out in the next couple of days.
Thanks Matthew… again.
I’ll probably put together an example that does this with tables or with storage – it’s handy to see the guts of how both of these things work in a simple kind of configuration
Thanks, it would be an interesting read into both to see which approach I am going to use
For M and J – first installment. Storing presets in a table data structure.
Move the sliders or type in values from 0 – 1.
Right click on the keys at the top to Record positions.
Left click on the keys to Recall positions.
More thanks than I can ever express to Keith Lostracco – it was one of the example files he posted last year that pushed me to better understand the table COMP, this example pulls a lot of inspiration from the TOX he originally posted.
Next I’ll put together an example of working with dictionaries as a different kind of data structure.
Follow up for M and J here you’ll find a python dictionary approach.
Same as the other TOX:
Right click records, left click recalls.
You’ll notice in dictMethod/table1/recall that a try and except is used for any keys that do not yet exist. Defaults from storage with a dictionary can be tricky, and this is one of many ways around this.
The benefit of a method like this would be scale – dictionaries can hold other dictionaries (just like lists can hold other lists). This means that you could use another set of buttons to specify which dictionary was recalled. You might want to save presets by venue, or media type, or any number of attributes. You could achieve the same result with tables, you would just need to spend some time thinking about how to appropriately structure that approach.
Hope this helps.
Download the examples from GitHub
Comments are closed.