can Derivative help us upgrade?

General TouchDesigner Discussion
1

Hi,

even though there are no fantastically impossible changes like path syntax changes or elimination of spare channels, I still see in the release notes that a lot of new commands should “replace” old ones, functionalities have changed for several functions, etc.

What this means is that for complex projects, upgrading is a big task and it should be done often.

My point is that I’d like to keep the old shows up to date, but who’s got the time to run after every little change coming with new version, especially because looking/finding commands and sorting through all the release notes is not easy.

Bottom line - can Derivative add a reliable set of warnings, maybe that can be redirected into a DAT, which warns about obsolete commands or expressions containing commands whose functionality (i.e. fit() ) is now different?

Let’s say I am running a project, I load it up, add a DAT to which in some way I can redirect all these warnings and errors - related to obsolescence and old commands and changed ones.

Let’s say I add the version number of my original show to the operator generating these errors. That way I could be told that “fit()” has been changed since that version, that “play” is now “power”, etc. - WHENEVER the command is encountered (better yet a list of all the appearances of those commands, even though find sometimes hangs forever (I’ve let it run 30 minutes without ever getting the prompt back).

Even more ideally I could check each instance of the command with the new version number (say I have 100 fit() functions, as I move through the occurences I mark some of them as “ok” after examining each and making sure the way it’s used is proper. I could therefore mark each occurrence (I’m thinking DATs if it’s not clear) with the latest version number, and slowly sort through the entire show in weeks, not days or hours.

In short, help us by providing tools that make obsolescence a curse easy and straightforward to avoid - 'cause right now it ain’t.

This would also give you a lot more freedom to make changes that don’t cost thousands of dollars to clients who want to “keep up” with the latest versions.

thanks!
dani

2

No replies from Derivative on this? I’d like to bump it.

For example today I noticed a warning in a null DAT:

“using old export map format. Please include named columns”

I looked through the release notes but couldn’t find anything that addressed this change. I’m sure it’s there, but:
1 - had I not run into this warning I would not have known that functionality has changed.
2 - in the warning, there should be a link to a web page explaining the change so that users are not left to decrypting the meaning of such warnings by themselves.

In addition, if whatever generates this warning upstream could also log it somewhere so that a
“compatibility -issues” kind of command could output the guilty operators with the same warning messages (which would include a link to more explanation) it would save every single one of your users the hit and miss and I-have-no-time-to-research-this-now-since-I-cant-find-documentation kind of process.

It would help keep your users by lessening development and upgrade times (since there’s many, many changes that require retrofitting throughout the year) and by allowing them to keep their applications up to date.

Long live the Touch apps - no more obsolescence!!

thanks!
dani

3

Sorry, not documenting the new format for exporting DATs was an oversight. We’ll add some info to the released notes about them. They are still in flux though so you shouldn’t upgrade your files to use new experimental features until they’ve been around for a bit.
We have a new Error DAT which we are slowing adding more and more information to. I expect this will be a place where these types of messages would live.

4

Hi Dani.
Yah, those messages were to be for internal use until the format was nailed down.
However it appears stable, so the named columns its looking for are:
path parameter value enable
The enable column is optional and defaults to ‘1’ when blank.

An example table might be:

path parameter value enable
/project1/geo1 rx $F 1

Note how the destination parameter is split into two cells: path and parameter.
I’ll update the release notes as well.

-Rob.

5

thanks - this kind of sucks though, it’s the kind of non-backward compatible change (unless you’ll keep the old way around forever, which I’m assuming you won’t) that causes a LOT of changes in any application.

I have hundreds of tables based on the format:

<path/parameter>

it’s the base method I use to specify every component parameters.

which now all have to be changed - mostly by hand - therefore adding a hefty upgrade price tag to every project done to date. Weeks and many thousands of dollars.

This onslaught of incompatible changes is my single biggest worry about developing a large number of apps using Touch and making sure they don’t become obsolete after 6 months.

dani

6

ok here’s an example of what the DAT column naming change means to me, if I try to upgrade all our shows (or even the latest development set of networks).

One fundamental functionality of our widgets (components) is that there’s a set of default values inside the widgets, and an input which is then merged as second input with the default, replacing columns. That way, the user can connect a table to the widget, and override ONLY certain values.

so I had defaults like:

Text/text title
Text/align center

and I could have a table outside the component containing only:

Text/text title2

Unfortunately though, if I reformat the tables, I get

Text text title 1
Text align center

there’s no more unique path/channel that I can replace! This would cause me a lot of extra operations which of course I don’t want to do at this low level (affecting thousands of operators)

argh…

7

This is a feature that is used all over the place so I doubt the old format will stop working anytime soon. Maybe in a year or two…

Are you sending DATs into the COMP to override default values? Maybe the solution to your problem is a type of merge/replace that handles the 2 columns-of-interest case you listed?

8

I think that’s definitely a solution which I can use in a variety of other places. It won’t lessen the time it’ll take to upgrade all the DATs to the named columns, but it would definitely avoid the merging issue.

how about a merge field that says which columns (or rows) should be looked up either by list (0 1 2) or range (1-4)?

that would be cool.

thanks,
dani