Rhythm for Dynamo Availability: Question for the Community

Developers
1

First, I apologize for the mega post, but this is something that is occupying quite a bit of my time and energy as of late.

TLDR

Rhythm is becoming quite difficult to update to offer support for several versions of Revit. This post is meant to gather information from the community in terms of usability.

Background

As you may have seen recently, custom packages have become increasingly more difficult to maintain. This goes for both C# (ZeroTouch) and Python packages (Python is definitely not off the hook as the IronPython deprecation, screwed a lot up too).

A few posts specific to Rhythm can be viewed here:

Rhythm Viewport.Create Revit 2023 Issue
Rhythm Package Missing Nodes
Viewport.Create doesn't see the sheets node

The issues that are demonstrated in those posts vary between Dynamo changes and Revit API changes. Both of these are very hard to tackle when working across several versions of Revit/Dynamo.

At this time, Rhythm tries to support Revit 2021 through Revit 2024, but there are many hurdles when working on that many versions (outlined in the next sections below).

The Problem

As a package author, when you build a Dynamo package you typically target the latest API, (Revit 2024/Dynamo 2.18). This works great when the package is used in that version as your user is “in the environment that you built for”. This works less than great when the user is in an older version that you simply didn’t test for. To contrast this, as Revit plugin authors, we multi-target our plugins for each version of Revit directly.

Example

“Why is this node saying it wants an ElementId that is 64-bit?!”

For reference, 64-bit element id is a big API change in Revit 2024, from 32-bit Element Ids, that are just marked as “to be removed in the next version”. The Dynamo for Revit team decided that 64-bit is all they want to support, so there is no chance of making it work across multiple versions if you are using certain methods. One of these methods that break in older versions if you target Revit 2024 Dynamo is the infamous, ToDsType(true) for casting elements back to their Dynamo variants.

The Ask (aka, what is John looking for from the community)

The reason I am creating this post is that I have gone back and forth dozens of times on how to handle this.

Note: Please don’t reply, “My package works great, and it is easy to do” if you don’t have open-source examples proving it. I don’t have the time or patience to deal with “1-uppers” and people who act like their stuff is perfect.

Also, this is a Dynamo question. So please don’t reply “use pyRevit” or “use RhinoInside” because that is not the same thing, and a reply like that is frankly, extremely unhelpful.

While I am sure that some strategies can work well unless there is an open-source repo that I can follow along, I am going to entertain the other options I have on my mind.

Options

Here are the options I am considering, with their pros and cons.

Option 1| Ditch the Package Manager

The package manager is the simplest way to install a package. Which is the primary reason Rhythm has always been available this way. However, there is no control at all over which version a user will download, because 99.9% of users will just click the big install button. Historically, we can see that this has been an issue for archi-lab as well.

Revit 2022 - Dynamo 2.10 - Package not showing up and icons missing - #7 by Konrad_K_Sobon

Additionally, the package manager lacking certain support across Revit versions is the main reason Lunchbox has left as well.

This is also the reason that Orchid is available on GitHub as its own installer.

Pros Cons
Version Controlled Installer Not easy to install for a lot of users
Managed like a Revit plugin Security Concerns with Exe
Package manager is the primary installation for most users

Option 2| Different Package Versions

This one I like from a usability (package installation) standpoint, but I dislike it from a package author standpoint.

The idea here would be to have a version of Rhythm for each Revit version. So you would have the following:

  • Rhythm for Revit 2020
  • Rhythm for Revit 2021
  • Rhythm for Revit 2022
  • Rhythm for Revit 2023
    and the default package “Rhythm” would always be for the latest version, (at this time that is Revit 2024).

The downside here is I am not 100% certain that Dynamo would resolve the nodes on its own. Frankly, I don’t want to trust Dynamo’s resolution of almost anything anymore.

Pros Cons
Easy to understand from installation POV Node resolving is questionable
Default “Rhythm” package might still get installed on old versions
Several packages for me to maintain

Option 3| Rhythm Only supports the latest.

This option is less than ideal because this leaves users on older versions of Revit confused as to what to install. This is similar to the archi-lab deployment method, where users have to manually go to the versions and install the one that corresponds to their version of Revit.

This one I also dislike as I (unlike the Dynamo team) know that users are on older versions of Revit. The reason I say that is for any new Dynamo feature, you typically get a response to “update to the latest version of Revit”. :roll_eyes:

Option 4| Rhythm Deprecation

This is the option I like the least (of course), because Rhythm is something I have maintained and worked on for a long time.

But, the idea here is that the last version it would support would be Revit 2024.

Option 5| Reflection Invoke All commands (added 2023.08.08-4pm)

This option is incredibly difficult, clunky, and unsupported. But essentially Rhythm would not depend on any DLLs. It would simply find it in memory and invoke it (reflection). This one is not going to happen, but I wanted to mention it because this has been suggested to me on several occasions by the Dynamo team directly. Dynamo Graph Migration Assistant actually uses a ton of reflection because Dynamo’s API changed so much between 2.13 and 2.16.

Closing

I might add a poll to this post, but for now, I am just wanting to get my thoughts out there and see what you all might have to say.

I think it is important to mention that package authors generally do this work for free (because we care about Dynamo), and we (unfortunately) receive very little support from the Dynamo team directly. I have had quite a few meetings with the team to discuss the package manager and other topics, but those will only come to fruition in future versions of Dynamo and Revit. Which does not help most users. As you can see in the posts at the beginning of this, most of these users are in Revit 2021 or older.

Thanks for reading, and I look forward to your responses.
-JohnP

Updates

20230809: 4:45pm
So I am making progress on this via view extension and extension (combo of the two). However, this does mean Rhythm will lose the UI nodes. They are significantly more difficult to maintain across versions, so they are gone. Small price to pay for the package to work on 4 versions of Revit (2020-2024)
Video of this in action: https://twitter.com/johntpierson/status/1689409289301966848?s=20

14 Likes
3

Call it Rhytm2024

1 Like
4

I’m sure that i am biased (in a number of ways), but here is how it shakes out for me (as a Dynamo user):

Option 1| Ditch the Package Manager

This wouldnt bother me (as a user) at all. Its the PACKAGE that matters, and the Package Manager is a hassle regardless. (As you know) we basically mirror and manage our packages on our own anyway, so i only use the PM to get the newest version, if i have to. Running an installer from a developer we trust (you) wouldn’t slow be down in the least.

Option 2| Different Package Versions

This wouldnt bother me (as a user) at all, either. We would just download all of the versions of Rhythm, and mirror them to their respective Dynamo versions. But if the only upside to this is still using the Package Manager, i dont think its worth it for you to have to do the extra work.

Option 3| Rhythm Only supports the latest.

Again, i am biased, but: This would be the second hardest option for me as a user. But, in that case i would go get the latest stable version of Rhythm for each version of Revit, and then pray nothing changes/breaks as time goes on. But since i dont ever use the Package Manager to “update” them, hopefully this wouldn’t be much of a problem.

BUT, currently the version i use Dynamo the most in, is 2022. Whether the Revit or Dynamo development teams understand (or agree with it) or not: That Revit isnt backwards compatible (which doesnt bother me at all) means a lot of office wide implementation stuff happens in older versions, and has to. I spend more time in 21/22 than i do in 23/24, even though we have some active projects in 23/24. And i LOVE Revit 2024. But i am yet to run a single Dynamo graph in it.

Option 4| Rhythm Deprecation

Given how much Rhythm is used in our graphs, this would be soul-crushing (for me). But i wouldnt blame you, as a developer. I mean, its thankless (for you). If anything, i think it would make us wave the green flag on converting a ton of our graphs to apps, because we have a lot of nodes from Rhythm that dont exist in any other packages. So those graphs would just… die. lol.

And then id have to bug you to code your ass off, til we replaced them all. LOL

8 Likes
5

I think the package versioning issues have slowly been compounding into what’s going to be a major problem for Dynamo. I can’t speak from the developer side too much (though even maintaining an internal package with just a few nodes has become a never-ending hassle at this point) but it’s also becoming a huge problem for graph authors and managers.

In a perfect world, different packages for different Revit versions seems the most intuitive (if not redundant) however that causes plenty of trouble based on how Dynamo currently handles packages. Even now, different versions of the same package cause warnings between graphs yet are necessary for different Revit versions and sometimes even Dynamo versions. Separate packages would require completely separate graphs.

I also hate having to move away from the package manager but that seems to give the best results for version control.

All of that is to say… I think this requires a change on the Dynamo development side. There either needs to be a way to maintain version specific “subpackages” under a parent package (in terms of graph control and package manager integration) or the package manager needs to interact with GitHub and allow external installs.

I was hoping that part of this would be solved with cloud integration for Dynamo but I think that would only be on the author/manager side (if anything).

6 Likes
6

Another thought I just had - that would of course require changes on the Dynamo side - would be to have subfolders in the package directory for different Revit versions (similar to Revit addins folder). This would allow you to maintain separate nodes or DLLs in a single package. Unfortunately this still ends up being some extra work for the developer, but it allows for streamlined versioning that’s actually based on patch/point builds and not versioning. The latest version would always be the “correct” version.

3 Likes
7

I like the subfolder option as well. The other downside is, it will only make a real difference in a few years since new stuff only comes out in new versions.

8

Very true. I think that’s going to have to be the case for a long term solution though. I just don’t see how this can be fixed with the means we have now. Something needs to fundamentally change with how we (as developers and authors) interact with Dynamo packages.

That being said, I also realize there is a need for a more immediate solution with 2024.

2 Likes
9

Another thought I just had - that would of course require changes on the Dynamo side - would be to have subfolders in the package directory for different Revit versions (similar to Revit addins folder). This would allow you to maintain separate nodes or DLLs in a single package. Unfortunately this still ends up being some extra work for the developer, but it allows for streamlined versioning that’s actually based on patch/point builds and not versioning. The latest version would always be the “correct” version.

Replying one more time, just because of what Nick brought up, up above:

I think the Revit developers AND the Dynamo Developers need to be clearer, about the intent of both of these ecosystems, again because of the no-backwards-compatibility issue.

The first Content Manager i used (in 2011) the app developer hadnt (yet) realized that the libraries would need to be different in different versions of Revit, hence different apps (or at least different configs).

Fast forward over a decade, and now SOME apps are multi version, SOME apps are one year only (and you install it 4 times). Same with Dynamo versions and Package versions (made worse by the point release dynamo version getting updated at point releases of revit, and users not knowing which version is which, or which they are in).

When you go in the Package Manager, it should ONE HUNDRED percent know: What version of Dynamo you are running, and what versions/packages are viable for that version. If it doesnt know that, its somewhat worthless. “Compatibility checks” have been a thing in computer software since i was in diapers. There isnt a (good) reason this is still a problem.

5 Likes
10

Something on PM to direct and help deploy is kind of a must for your work to scale to customers who aren’t in direct contact; if that is done then users will manage. Most (nearly all) companies don’t manage shared parameters or families across the org (never mind Dynamo packages and graphs), and VERY few do so as well as @Aaron_Maller does (sarcasm: going forward all graphs I send to him will have a node in custom package that isn’t on package manager but is absolutely integral for functionality of the graph /sarcasm).

Hate this from a management perspective, but if it makes it easier, do it.

I could live with this; Personally I see old support from the perspective of my employer though, and I realize that isn’t ideal for many, so feel free or ignore me here (and anywhere really).

The changes in 2025 (the scope of which is still unknown) might sadly make this the best path forward, with an entirely different flavor of Rhythm coming in it’s place.

11

My least favorite options is letting Rhythm die…BUT…that is up to you and only you.
Package authors are the life-blood of Dynamo and you have our appreciation…but continuing shouldn’t be a hassle or drain on your life.

Minimize how far back you support - at some point, the last version of your packages for certain versions should be end of life and that’s that. While I’m just now moving my teams from 21 to 23 (I’m slow), I’m also NOT updating dynamo packages…well, ever… We’ll live!

Keep bug fixes to 2-3 versions back (if important) and new features to 2 (where possible). And only if it’s easy to maintain / share. Move packages off PM and do it your way…seems like you’d probably do it better than the Dynamo team anyway, with your eyes closed.

2 Likes
12

I agree in theory. The only problem is that developers would have to define all of this within their package. I don’t think that’s a huge ask, but it’s not part of the current process. This also makes things weird when a new version of Revit or Dynamo releases before developers have had a chance to update their packages. It seems reasonable to have this built into the package manager and the package information though.

13

once Lunchbox was removed from the package manager we used it a lot less, in theory that shouldn’t be the case but unfortunately that was the case. Even though it seems like that is one of the better options.

Or just support the latest. Which is unfortunate but sort of what Autodesk/Dynamo sets you up for with how the versions work. I agree with @Aaron_Maller though, we work primarily in 21-22 at the moment. We have some work in 23-24 but not much.

14

@john_pierson I think you’ve got a major uphill struggle since you depend heavily on Dynamo and Revit APIs and with the myriad of changes occurring not to mention the coverage your package has over many aspects of the various APIs your options are limited.

In all honestly, I would let go of the idea of having one package to serve them all and do what say Clockwork did when 2021 changed the unit types, and release a Version 2024 of your package. The reason why I think this is the best option in your case is because of a major clanger (IMO) from the Dynamo team (which also affects BimorphNodes - I’ll explain more next) which means, even the solution I suggested on Twitter wont work. It does work for Revit however. The next problem is the fact your time isn’t free yet a lot of time goes into package development so maintaining two versions is going to be a nightmare.

The clanger BTW is the fact that Dynamo uses longs - a value type - to represent represent ElementId’s - a reference type - in the Revit API for 2024. In previous versions its an int and therein lies the problem. This isn’t a problem so much if its internal in your code as there are workarounds, it is an unsolvable problem however if you have any nodes which return ElementIds from Dynamo types since its a type change rather than a change to a property in the type (i.e. Revits ElementId using a long instead of int in 2024). Therefore, there is no way to handle this problem, unlike Revit API where dependency injection can be used - its what BimorphNodes does.

I suppose you could box the value meaning all outputs returning ids would need to change to the object type but that brings with it a type change that will break all graphs using your previous version and create new problems in the future as the type is ambiguous. If Dynamo API had created its own wrapper around ElementId this wouldn’t be a problem. Nobody’s perfect. In BimorphNodes, this problem affects 1 node and my plan is to depreciate the node in the current version and hide it in future versions since other nodes can provide the same result - washing my hands of the problem essentially - and this is why packages with lots of dependencies on the Dynamo APIs cant do this and why releasing a new version is most likely the only option.

I’m still going to publish a article explaining in detail with full implementation details and code snippets to expand on my twitter post, I just don’t know when this will be as I’m snowed under with project work at the moment. I’ll aim for first week of September. You could solve a lot of problems with bar the issues with the Dynamo APIs - the alternative is to remove any node returning element Ids or anything else which is a reference type in Revit but a value type in Dynamo and weather the storm of breaking changes it will create. At least you can stick to maintaining and publishing 1 version which is best IMO irrespective of the shortcomings of the package manager.

6 Likes
15

Thanks for the reply @Thomas_Mahon . Definitely looking forward to the sample, but no rush at all!

2 Likes
16

As a company Dynamo Admin (and not an active package developer), I like the Orchid way (Option 1) without the package manager. If you have an admin who deploys the packages&scripts by robocopy scripts in the autostart folder to all users machines, this is the best way, because users cannot download other package versions in the package manager and you know that the company scripts are working most of the time.

I would upload just a node to the package manager that provides information of how to install the package with the Zip files and where to download the ZIP file with the different versions.
Btw, I think you don’t have to use the Orchid exe file, you can just copy the files from GitHub to the right folders.

In my experience, many users don’t understand how Option 2 works. Students and Single users most often use the latest Revit Version and luckily it just works. If the UI of the package manager would support a system with multiple Revit Versions, it could work much better. But atm this is just a mess, because if you have the latest package version 2024 at the top, you can be sure, that at most companies the users will be downloading the wrong package version for Revit, because they use Revit2021-2023.

My hope is, that one day the Dynamo Scripts and packages will be integrated with Unifi and can be deployed by admins for the whole company by version selection and with one click :slight_smile:

PS: We still use Revit 2021 but preparing for the switch to Revit 2023.

5 Likes
17

Hi John,

I feel this pain too. Actually I’m working developing packages for my clients.

The solution that gives me few concerns about version maintaince was Option 2 for specific Dynamo versions, not all.

Revit 2020 → Dynamo 2.3
Revit 2021.1 → Dynamo 2.6
Revit 2022.1 → Dynamo 2.12
Revit 2023.1 → Dynamo 2.16

I provide an installer that deploys tha package :package: to this versions.

1 Like
18

As a user, all beit more in the Sandbox than in Revit these days, I agree with @Aaron_Maller he pretty much hit the nail on the head. I have a little different outlook on option #3, but other than that hit that nail right on the nail right on the head :hammer:

I also use the archi-lab package, and the way I deal with that is to just create a “2021” or whatever year I’m using folder and put the packaging in there. Then I only add that folder path in that version of Revit (so Revit 2021 only sees the “2021” folder, and Revit 2022 only sees the “2022” folder.

For option 3, only supporting current version, as long as you don’t remove the past versions I don’t see a big issue with this. Yes some people will hit download and get the “wrong” version if they are still on Revit 2021. But in reality if they are still on Revit 2021, they likely don’t want the latest and greatest anyway because they are on an old version of Revit and an old version of Dynamo. They have a graph that works and the less changes the better. Running the latest version is great for testing and new features, but not great for product, that ship doesn’t turn on a dime as we all know.

In the end @john_pierson I vote for what’s the least work for you! You have done so much for this community and given so much of your time and yourself it is just not fair to ask for any more from you! :pray:

This is why it’s so great that you’ve made this package open source so others can learn from it and take up the charge to improve it and move it forward.

4 Likes
19

Hi,

I don’t know if it’s doable, but is it possible to download & install the right versions of the dll and xml at the end of the package installation via an event (installation package finished)?

Which would amount to making a version by version of Revit “Option 2” (maintaining only the latest version) but with a single Dynamo Package which acts as installation management according to the version of Revit

respect and courage

1 Like
20

It is actually fairly possible if I do that within the view extension.

However, Dynamo gets kind of silly with any DLLs hanging out in the extra folder and will latch on to those as well. So I would need to do some gymnastics to download it on the fly.

It also doesn’t help a Dynamo Player user who might’ve downloaded the zip from dynamopackages.com

However, this might be the option I entertain first.

2 Likes
21

Option 4, deprecation actually means ceases to exist at all. That’s why its my least favorite

1 Like