Rhythm for Dynamo Availability: Question for the Community

For those interested in what gets deployed from Rhythm’s github to your machine, it is all open-source here:

As frustrating as it is to see the hurdles you’re dealing with despite all the hard work you’ve done to make Rhythm deployment smooth, the github approach actually has a lot of merit… I wonder if there’s some general legs there for others to be encouraged towards in future RE deployment (via Dynamo team or just generally amongst the developer community).

Thanks so much @GavinNicholls. I appreciate it.

So far, the GitHub deploy seems to work on my machines. I already updated Revit nodes, deleted those DLLs locally, restarted Revit, and saw the updates right away!

Very excited about this.

I honestly think there are some great opportunities here where the Package manager could be a “frontend” or sorts to just point at a Github location or something, and it just pulls the latest. But I know security is something they have been concerned with.

Security is something we have to take very seriously, but like with anything there are usually two paths. Realistically we’ll probably have to provide both in time, the “safe and trusted” path which has lots of hoops, hurdles and limitations, but that you can be pretty darn safe, or the “wild west” approach where anything goes.

The latter would have a big pop-up dialog telling you that it’s progress at your own risk and a “I accept” button or somesuch.

I think Dynamo still has a lot of unconverted / unintegrated potential. Such as having a smoother integration of the most downloaded packages’ nodes.

Why not remove all node packages and have them being submitted for integration, then when reviewed, all of them become OOTB when approved…

And about safety, you can also leave the responsibility for downloading add-ons for the end-user right?

A few reasons:

  1. 99% of custom nodes can’t be just converted to out of the box nodes.
  2. Many custom nodes actually don’t scale to fully supported nodes as they fail in testing or require a 3rd party toolset which we (Autodesk) cannot reproduce
  3. Out of the box nodes don’t scale backwards, only forwards. This means that once the OOTB node is implemented the custom nodes would need to be replaced on a version by version instance; my intuition tells me this would be more pain for end users in order to lighten the load on package authors.
  4. It is possible for package authors to perform a pull request to Dynamo or Dynamo for Revit (which is most of what we are talking about, as there are very few specialized packages for other integrations), which enables the workflow which you’re discussing now. Most aren’t doing so as generally speaking we (the community) aren’t technically ready to do so (only 3 of the top 10 packages meet the initial technical requirements for the base framework, and many nodes thereof are missing required features like icons and documentation).
  5. The coding standards for getting into Dynamo Core or Dynamo for Revit aren’t clearly documented anywhere. This includes stuff like: how to add icons; when a method should be public vs private vs hidden in the Dynamo library; help documentation requirements; localization requirements; etc… As such it even those who want to contribute cannot (I’m the problem it’s me) without multiple go-arounds with the Dynamo team.

All of this said, the team does try to pick up common needs and integrate them into core; there are a few instances of this in Rhythm and Archi-Lab over the years. Those efforts include python conversions - the FamilyType.ByGeometry node which was based on the FamilyInstance.ByGeometry node as one such example. Unfortunately a lot of the Dynamo team’s efforts in the last 2 years or so have been on required framework stuff (security things, the .net upgrade, geometry engine updates to keep pace with host applications, the visual refresh, etc.) which has limited their capacity to pick up such items.

As far as safety goes: the general responsibility for safety is on end users; always has been and will continue to be. However as stewards of the community and the software therein, we want to ensure the ecosystem is reasonably safe. Think of this as providing crosswalks to help with safe street crossings, package manager needs to own that framework in a way which doesn’t limit street crossings to once every 50 km, while simultaneously not allowing anything to cross at any point.

Speaking for myself. I never want to have to wait for the Dynamo team to review my nodes or Dynamo extensions. I want to add new features and get them out there ASAP.

I could not imagine only building Rhythm nodes for core, to wait for Dynamo for Revit to adopt the nodes in 2 years.

Can you imagine?

“Hey, everyone, I made some new nodes and submitted them to Dynamo. You will see them in Revit 2027”