Thanks for the update @Thomas_Mahon, I mentioned it in the video comments now.
2 Likes
I’d like to understand more about your solution @Thomas_Mahon and what issue you see regarding value types that causes a dead end. Sometimes the .net runtime can be forced to do things that are not documented…
Hi @Michael_Kirschner2 I’m using dependency injection using an IoC container: There is a compatibility core project comprising of interfaces that act as wrappers around classes / methods requiring backwards compatibility. Then there are two other projects: CompatibilityCurrent and CompatibilityBackwards that reference the core project and implement the interfaces. CompatibilityCurrent targets R2024 / D2.18 whereas CompatibilityBackwards targets R2020 / D2.16.
Theres a BimorphNodes.Services which initializes the IoC container with singleton access. The various implementations are injected at runtime into the container via Autofac Modules which simply query the version of Revit running and then inject the wrapper class from either the CompatibilityCurrent or CompatibilityBackwards. Any call to a depreciated method or class is then replaced by a call to the wrapper class obtained via the container.
Managing the Dynamo Category switch from int to long (or any other breaking change for that matter) is therefore easy from an internal standpoint, the problem arises if a package has to expose Dynamo’s Revit ElementId externally as its a value type. This causes a breaking change which is what I am alluding to when I said there’s nothing that can be done about it - had it been a class, the breaking change would have been managed easily by way of properties, in the same way Revit has handled the problem.
For example, LinkElement.LinkInstanceId returns the ElementId, but since the return type is int and I only deploy one version of BimorphNodes for multiple versions of Revit and Dynamo, there is nothing I can do to change this to long when running in D2.18, not without releasing a separate version of BimorphNodes built specifically for this change - something I’m not prepared to do, not least because of the confusion / incompatibility with the package manager multi-version package deployments cause / have.
I considered boxing the value type but this just turns a blemish in Dynamo’s software architecture into my own, and that’s why I decided to simply remove this node as its the only one in BimorphNodes that returns an element id and not widely used so its not too big an issue.
Perhaps we should move this conversation into a new post as its taking away from @john_pierson OP.
4 Likes
For my part, I am fine with any option that lets me still use Rythm nodes. Having to download from a Github instead of the package manager is not a big deal to me. Also having multiple options on the package manager is fine as well, and would probably be more widely accessible.
@john_pierson Whats the best way to track the progress on the Rythm update for 2024? Thanks in advance.
1 Like
As of right now, the fix for Rhythm is in place in the latest version on the package manager. All of my work is here:
2 Likes
As a frequent user of Dynamo Rhythm, I first want to thank you for all your effort you put in. However I consider all of that a bonus. No one told you to do it and yet you provide for the community anyway.
therefore, depracation is part of the deal. I wouldn’t worry too much about it. You mentioned Viewport placement nodes but a lot of them can be done with built in features from Revit 2024 on and with the pyrevit and eftools plugins.
We’d like to think that Dynamo can fully automate things but BIM is a field for a reason. Otherwise an AI would already run the whole business. So any Dynamo script still is manual labor and testing. If 1% of your package doesn’t work, I’m not bothered by it. I will find other ways.
The Package manager installer is fine. Only when a node stops working I will check for the package updates.
So to summarize, thank you for your concern but it is misplaced, truly.
1 Like
Orchid has more issues than just how to install it. It’s very invasive and will create conflics with OOTB nodes. It also floods the list with nodes when I search for them. Only a select few nodes I prefer using, especially when it comes to moving folders and files around in windows.
Other than that the OOTB nodes from R2022 onward became quite useful and functional and making Orchid more invasive and overkill.
Then also comes the perspective of everyone having to install the package who don’t script but use the developped script. Most people forget that maybe 1 or 2 per office know and utilize Dynamo and they have to make it easy to use for the other people
As counterpoint to Orchid/user skill though, I’d argue it really isn’t a package targeting Dynamo beginners. If you’re at the point of trying to bulk modify families with Dynamo it is a big risk if users are not experienced in this space. In some aspects I agree some of Erik’s choices have been unorthodox, but as a package manager and content creator I can also attest that not everything should be made for a basic user to pick up and run with.
It takes a lot of work and UX to make something complex approachable and safe for beginners, and John’s really shown this (both in time invested, but also in quality of result) with Rhythm and Monocle.
When making family editing tools for my pyrevit toolbar, I actually intentionally implement hostile UX and naming to ensure users only engage in this space if they know what they are doing, e.g. technically orientated tool names, tooltips, default run mode giving an ‘are you sure’ dialogue (and hiding ‘expert mode’ in a shift click mode) and more abstract logos/tool names (my family toolkit is called Griffin, and lives to the furthermost right area of my tools). My Dynamo family scripts are restricted to a user group by username, which in turn triggers a ‘are you sure’ step also.
Cruel to be kind!
1 Like
@john_pierson, you have given a tone to this community over the years and have helped shape what it is today. My personal opinion is to do whatever works best for you. If that is to publish a final version of Reythem then so be it. I can only imagine the guilt that you would feel doing this but it is not your job to keep the dynoverse functioning properly. Personally, all of the major developers should be making well over 100k a year to maintain their packages. Maybe Option 6 is to find someone or a group and pass the torch.
I am sure whatever you decide the community will stand behind. Thank you for everything.
For my personal thoughts on your options.
Option 1: I use Orchid with no problem. Sure it takes an extra 5 minutes for me to figure it out as I very really update any of my packages. An extra 5 minutes for me to use an awesome FREE tool that saves the developer hours of their life sounds great to me.
Option 2: This sounds like a headache for you with the only pro being ease for the end user.
Option3: 100% fine. It’s super easy to download older versions of a package. They can go look at the Primer to figure this out it’s not your job wink wink.
Option 4: I think I said enough here but if you do decide to go this rout rip it off like a bandaid, have no regrets and make sure you have something to fill all the hours of your life that would free up.
3 Likes
It’s growing pains
Wait till Revit becoming fully multi-thread (runs on multiple cores)
Or when Dynamo for Revit runs in the cloud on your projects automatically… Which will happen much sooner than multiple threads. 
Not an option if you live in another part of the world (here it is, but not everywhere)
Starlink has lost some satellites lately
Rhythm for Dynamo Installation Updates
9 Likes
Hi John-
First of all, I want to thank you for the work you have put into Rhythm and the engagement and guidance you have provided to the community. I just watched your video, and I hope you can answer my question, as what is happening to me didn’t seem to be addressed.
I have been working in Revit 2023. (Revit 2023.1.3, Dynamo 2.16.2)( When I go to install the latest Rhythm (2023.8.7) I get the warning: “Package Uses Newer Version of Dynamo!” (see image below).
I just want to confirm this is expected behavior, I should proceed with the install, and your magic will make sure I end up with the correct version for Revit 2023.
Thanks again- Joe
1 Like
That is expected behavior and you should be good to go as Rhythm will install the correct version on the fly.
3 Likes
Here is the latest from the never-ending saga of trying to keep a package updated:
TLDR: Dynamo’s package manager is filtering some kind of file on upload, resulting in an error that I can’t work with.
3 Likes
Apologies if anyone sees my tweet and thinks it is negative. But this is getting ridiculous.
3 Likes
Also happens with monocle now:
I am in contact with the Dynamo team and will let everyone know what I find out.
5 Likes
There’s a good chance (once the package manager thing is fixed) that,
I will push the last update for Rhythm to the package manager ever.
Because… I might change Rhythm to just download the DLLs from Github on the fly instead and every end user just gets the latest.
For more info, check out this branch here:
Also, if anyone has any thoughts let me know. Naturally, if someone is installing a package they:
- have internet access
- have certain permissions already
3 Likes
Rhythm now downloads the DLLs on the fly. This means every Dynamo user (since 2.0.x / Revit 2020) can download the latest version, and it just works.
This also means that I should (almost) never have to push a package manager update for Rhythm again. I just push updates to Git Hub now.
That should do it until the next thing is broken on Dynamo’s side, folks! 
6 Likes