hey gang,
Has anyone tips how to work an TD Project in a team?
So if there are multiple “programmers” who work on the same project what is the best aproach to avoid conflct between versions etc.?
As i see it: Tools like Git won’t work well, as the projectfiles are binaries (are they?)
cheers
elso
Version control is tricky with multiple programmers. Our approach is to make every feature a unique container, and to name files with descriptors after the file name so we can backtrack and monitor.
Unique containers + communication = everybody is working on an individual section for easy merging
file names w/ descriptors allows easier backlogging and cross-team references
I’ve been happily using bitbucket and github for version control.
Our team’s approach is to lean pretty hard on tox files - just about any given component is a tox that’s loaded by the main project file. This means minimal changes to the main project, with any alterations living in changed or added tox files. It can make of a bit of getting used to as a working method, but also allows you to work together sharing a common base project that doesn’t change - or changes infrequently.
I do it about the same as described by the others above.
When the main program is large we separate everything in a few Base COMPs (or Containers, but only when Base is not possible).
For instance in a simple example: CONFIG, NETWORK, 3D, GUI.
So everything which is osc/midi/tcp goes in the NETWORK Base Comp.
You can fill in the rest.
One developer does all the 3D, another does everything in NETWORK, and one can design the GUI. We treat everything as a black box where we define beforehand all the inputs and outputs, so a developer only has to worry that those I/O’s are correct, and he can do everything he wants inside his black box (as long as it performs well 
Multiple people can work on the same projectfile (their own version), and one project leader merges all the new versions together every x days. If you do it right this merging can be as easy as copying 1 Base comp to the other project.
Also when appropriate we try to separate modules/filters/generators/plugins into separate tox files which you load in the main program. Also with this, we define the inputs and outputs for every kind of toxfile beforehand, so it’s easy for one developer to keep making new filtergreen.tox and filterblue.tox plugins which can always be loaded in when needed without the other developers having to wait.
Also I’m always pushing everyone to make their networks with a clean layout -it really helps a lot if you have go back to your project in a few months and have to change something.
I also use bitbucket and git. Because the files are non-text you can’t see meaningful diffs, so you have to enter useful commit messages, but the versioning still works well for a team, making branches, tag releases, etc.
Not to do with version control but I another often forgot and crucial thing, comment your networks and scripts! You can just leave Text DATs in networks with comments but it really helps going back to in a few months time. Its also useful to name your nodes to something helpful and we often use node coloring to distinguish parts of a network from others.
yes node coloring, good one!
I only found out it was possible after working in TD for a year - press c to bring up the color palette, make all your output nodes red and input nodes green or something fitting.