It’s been a while since a new experimental update as we have been working on substantial changes that took some time.
First of note, there are a number of important compatibility issues which might require you to adjust your projects. These are always difficult choices to make but we feel they should be done now to improve the software for the long term. Please check the Backwards Compatibility section in the Release Notes.
Secondly, a rather significant update was made to the parameter dialog user interface. Previously some parameters were a long list of parameters when multiple copies of that parameter existed. These now start out with just one parameter and you can Add or Remove duplicate parameters when needed. Please let us know if you discover any bugs when loading your older files into this build.
Lastly a major change for macOS is the minimum requirement has been upped to 10.12 Sierra. Earlier versions of macOS will not be able to run TouchDesigner anymore.
Lots of exciting new additions in this build including… Kinect Azure CHOP received a major SDK update with improved body tracking Shared Memory OPs added to macOS Kantan Mapper reported bugs addressed NDI updated to 4.1 Ouster LIDAR updated to v1.13 firmware support Notch TOP has improved unloading support for and easier time when updating block assets
Geometry Instances can now have up to 12 custom attributes
Line MAT received many additions and improvements
There are over 100 new improvements in this build so check out the Release Notes for the full changelog!
Thanks for the update! I always look forward to the new experimentals.
Here’s my 2 cents regarding the new parameter dialog options so far:
I’m not sure how much of a fan I am of the new parameter dialog plus and minus buttons, at least in the case of the constant CHOP.
While the single parameter (name* and value*) per line is more consistent with the rest of touchdesigner’s operator parameters, it does seem to end up looking more cluttered and difficult to read by the time a bunch of channels are created. I thought it was pretty neat and intuitive to have the channel name next to its corresponding float slider the way it was previously.
Clicking the button is kind of cool for one or two channels but you end up having to chase that button down as the number of channels increase and I’m thiking this might become annoying when you’ve gotta go fast.
I think an integer entry box or alternatively a string entry with pattern matching to automatically fill out the channels with corresponding names might be preferable in a lot of cases although less immediate to newer users and maybe also a bit annoying in some cases.
So far there have not been bugs with older projects in which the channels in the constant CHOP have already been created but I’ve been using a lot of scripts that dynamically name/rename the constant chop’s parameters in order to create or remove them and I’m worried some of these might end up trying to call up parameters that no longer exist and result in an error.
I do like however that there no longer is an upper-limit to the number of channels in the constant CHOP but I’m wondering if the “plus button” can be pulsed via python. In any event, although not insurmountable, it’s going to have an effect on workflow for a couple of applications I’ve been using this operator for.
Thanks for the feedback @owenkirby, we will consider the 2 vs 1 line parameter layout of the Constant CHOP, but we have been on a mission to remove non-standard parameters everywhere we encounter them in TD, and this was an opportunity for cleanup. That doesn’t mean we can’t design a new ‘standard’ parameter that is that.
We will add python but it wasn’t ready for this release. Note however that you do not need to manually add a parameter before using it. The system is smart enough that uf you script the use of a parameter that does not exist yet, it iwll just automatically create that parameter and all the missing ones in between. For example, if you do this op(‘constant1’).par.name8 = ‘chan8’, it iwll not error but rather create that parameter and all the ones missing to get to name8, ie name1-8
Note that these are always sequential in order, par8 can not exist if par0-7 do not exist, this is a requirement of parameters.
We actually got the python interface committed as well:
It’s through the Sequence class:
python >>> n = op(‘/project1/constant1’)
python >>> n.par.name0.sequence.numBlocks += 1 #add a block
python >>> n.par.name0.sequence.numBlocks = 5 #or set total to 5 blocks
Should add: You can find the .sequence from any parameter of that sequence. It needn’t be the first element. ie name1, value0, value1 work equally as well as name0.
However, I am still finding that parameter +/- button really annoying to use. I know it wouldn’t look as good if set at the top of the parameter page but having to chase it around when I just want to slam down some channels is a mood killer.
