View3d.SetSectionBox and View.SetCropBox have been removed. These nodes were becoming too difficult to support due to persistent dynamo issues with bounding boxes.
A collection of custom nodes for Dynamo.
If you appreciate the work put into this free package, please vote in support of it on Dynamo's package manager.
This tool is not affiliated with Autodesk and was written and provided in a personal capacity by the author. This tool is provided "as is" without warranty of any kind, express or implied. Use at your own risk. By using this open-source tool, you acknowledge that the developers and contributors are not liable for any damages, losses, or issues that may arise from its use. You are responsible for ensuring compliance with all applicable laws and regulations. Remember, open-source software relies on community contributions, so functionality and security might vary. Always review, understand, and, if necessary, modify the code to suit your specific needs.
Supported Revit versions are 2020 and up. And supported Dynamo versions are Dynamo 2.0.x and up. Rhythm is deployed from github, and auto-downloads the correct node libraries on the fly.
For Revit 2027, Rhythm no longer ships the legacy *.customization.dll icon assemblies because .NET 10 disables the legacy bitmap resource loading path they relied on. The package still downloads the main node libraries and customization XML files for 2027.
Rhythm consists of several sub-libraries. These are describe a bit more in detail below.
- Rhythm Core, General methods and helpers with no reliance on Revit.
- Rhythm Revit, All the Revit nodes, built for Revit 2020-2027.
- Rhythm UI, Revit UI Nodes.
- Rhythm View Extension, this view extension allows for the auto-annotating of Rhythm nodes and control of the run mode when the user places
Background Documentnodes. - Rhythm Python, Python code for many of the popular Rhythm nodes. if you want to hurt my feelings and not use the Rhythm package 🥺
- Nodes that interact with background opened documents take some more consideration. This includes running Dynamo graphs that use them in manual run mode and often times closing and opening dynamo after the process is complete. The reason this happens is Dynamo has limited document switching capability and we are exploiting this with those nodes. (Included Nodes: Applications.OpenDocumentFile, Applications.CloseDocument)
This package is primarily managed by the author of http://designtechunraveled.com with additional contributions from People Like You™.
Since there is not currently an update notification process on Dynamo's package manager, I post notifications for updates on twitter.
Examples will be available on the wiki soon,
You need Visual Studio 2022 or newer (for MSBuild — dotnet build cannot compile the .resx files that hold the node icons), and the .NET SDKs for 8.0 and 10.0. You do not need Revit installed: the Revit and Dynamo APIs all come from NuGet.
One codebase covers Revit 2020–2027, so every project has sixteen configurations — Debug R20…Debug R27 and Release R20…Release R27. The configuration picks the target framework, the Revit and Dynamo package versions, and the R2x / R2x_OR_GREATER compiler constants used for version-specific code:
| Configuration | Revit | Target framework |
|---|---|---|
| R20 – R24 | 2020 – 2024 | net48 |
| R25 – R26 | 2025 – 2026 | net8.0-windows |
| R27 | 2027 | net10.0-windows |
Building one Revit year looks like this:
msbuild src/RhythmCore/RhythmCore.sln /p:Configuration="Release R24" /p:Platform="Any CPU" /t:Restore,Build
msbuild src/RhythmRevit/RhythmRevit.sln /p:Configuration="Release R24" /p:Platform="Any CPU" /t:Restore,Build
msbuild src/RhythmUI/RhythmUI.sln /p:Configuration="Release R24" /p:Platform="Any CPU" /t:Restore,BuildOrder matters. RhythmUI references deploy/<year>/RhythmRevit.dll, so build RhythmRevit for the same year first or you will link against a stale one. Each project's post-build step copies its output into deploy/<year>/.
Every configuration up to Revit 2025 restores from nuget.org alone. Revit 2026 and 2027 need DynamoVisualProgramming.Revit 3.6+ and 27.0+, which are published only to a private GitHub Packages feed.
That feed is deliberately not in the committed NuGet.Config. GitHub Packages answers 401 rather than 404 to unauthenticated callers, and NuGet treats a 401 from any configured source as fatal — so listing it would make every configuration unrestorable for anyone without a token, including the 2020–2025 builds that never needed it. Add it yourself if you are building 2026/2027, using a token with the read:packages scope:
dotnet nuget add source https://nuget.pkg.github.com/johnpierson/index.json --name johnpierson-github --username YOUR_GITHUB_NAME --password YOUR_TOKEN --store-password-in-clear-textdotnet test tests/Rhythm.Tests/Rhythm.Tests.csprojThese cover the Revit-independent nodes, and run against the built RhythmCore.dll rather than recompiling the sources — so what they assert is what ships. Build RhythmCore for Release R24 first. The project is intentionally outside the shipping solutions, to keep a test framework out of the node libraries' dependency graph.
deploy/ is not just build output — it is the distribution channel. The package manager installs only a small bootstrap, and the view extension downloads the version-matched node libraries from deploy/ on this repository at first run. CI rebuilds all sixteen configurations on every push to master, verifies the folder structure, and commits the result back with [skip ci].
So a change is not shipped when it is merged; it is shipped when CI has rebuilt deploy/ from it. Local builds also write into deploy/, so discard those changes rather than committing them (git checkout -- deploy/) and let CI produce the binaries — hand-built assemblies drifting from source is a mistake this project has made before.
Every node ships with a help page that Dynamo shows in the panel beside the graph — right-click a node and choose Help.
Those pages are generated from the assemblies and from the <summary>, <param> and <returns> comments above each node in src/, so they cannot drift from the nodes they describe. To improve a page, improve the comment and regenerate:
./scripts/generate-docs.ps1 # writes docs/nodes
./scripts/pack-docs.ps1 # copies it to deploy/Rhythm/doc, where Dynamo reads itThe build fails on a pull request whose generated help has drifted from the source, so run both before pushing. docs/nodes/README.md explains the layout and records how much of the help is actually written — including which nodes still have no description at all, if you are looking for somewhere to start.
If you're interested in contributing to Rhythm, just submit a pull request.
Rhythm is available through Dynamo's built-in package manager. This provides the simplest installation for most users. If you are interested in manual install, there are some fabulous resources out there describing how to build your own Dynamo package.
With Dynamo 2.0 comes a fundamental file format change that makes anything that is a DYF or DYN (the filetypes that Dynamo uses) not backward compatible. This forced me to choose between two options. Option 1: Have 2 versions of Rhythm for each major version of Dynamo, eg. “Rhythm for Dynamo 1.x” and “Rhythm for Dynamo 2.x”. Option2: Continue my long term goals of migrating Rhythm to be fully “Zero Touch” c# code. I went with option 2 as it provides a more stable product and further compatibility.
