The Pros and Cons of Using Dynamo Versus a Revit Add-In

PRESENTER 1: Anybody knows everything. You know I can figure anything out I believe, but I don't know everything. If we say something you don't think is correct, let us know and we'll discuss it.

This is a slide I put in late. And main reason is because when I presented this to a lot of people at our firm, they really didn't understand the difference between the Revit API and what an add-in is for the most part. They referred to them as the same thing. And they're not. They're really very different animals. Dynamo is a type of tool you can create, and so is an add-in. Revit API is the heart of creating tools in Revit. Without the Revit API, you can't create any custom tools. Period. And we'll go over more what the Revit API is in a minute.

You know what the icon is for Dynamo. That's pretty obvious. Everybody's seen that before. And through this presentation for add-ins we're using this image here. A guy named Juan Osborne created it. And it's being used on a website called Revit add-ons. And basically it's a website that has tools that you-- any new tool that comes on to the Revit app they post on their blog. You can see what's new.

So quick question for the class. Couple of questions. Who here right now writes Dynamo tools? Good number. Who here considers themselves advanced or expert level? Still a number of people.

Who hear creates Revit add-ins? More than I thought. Great. Who here considers themselves advanced or expert? OK. Last, but not least, who here just hasn't created a tool yet in either platform? OK. It's always-- there's always time obviously.

This is one of these-- I had a online survey that I sent out to this class a while back. And I also sent it out to Dynamo BIM community. And I also sent it out to Revit API community. And also my Twitter friends who use both. And this is one of the-- two of the graphs that are in there. And if you download the handout you'll find three or four more.

But anyway, the two main takeaways I take from this graph is that really there's more beginner level in both platforms. In quantum platforms or programming language is probably the better term. We had 150 people. 150 people who actually surveyed and 125 are actually Dynamo users. 89 were working add-ins. So there's also more Dynamo users than there are or Dynamo developers than there are add-in developers. Which is not unexpected really. But again it's all in the hand out and a lot more information.

So a brief history of things, and Revit started really in the year 2000. But it was acquired by Autodesk in 2002. And that's why we're at a Autodesk conference so I thought I'd start 2002. You'll see the sources show up in the top left hand corner and I gleaned this information from various sources.

Revit API, it started around 2005 by one developer that needed to create-- needed to give somebody access to Revit to do structural analysis. And that was actually the beginning of the Revit API. And from 2005 to 2009 is when the Revit API really became more robust where you could actually start using it to create tools. Ever since then, and obviously it's improving and it's changing with new features. I started using Revit printing add-ins in Revit 2009, which happens to be the year that they started what's called centric development. And that means that whenever a new feature is added to Revit, that same developer had to add that feature or abilities for that feature in the Revit API so you could use in a custom tool.

And Dynamo came in in around 2013. And there is a Dynamo API as well. Dynamo is open source. I consider every node that's either delivered with Dynamo or nodes that you can get from the package manager or create yourself, part of a Dynamo API. Each one of these nodes is really one or more algorithms. And it's, as you probably know, every week if you follow the Twitter experts that I follow in Dynamo, new packages and new features are just continually being developed for Dynamo. It's becoming a monster. Any questions about this timeline or the slide?

I kind of wanted to show this mainly because I think a lot of people maybe might not realize that the API is an exposed layer, and it's something that had to be done by-- it had to be done intentionally so that we can create custom tools.

So, and that's a funny image. But, again, Revit API is really the heart of creating custom tools. You can't create a custom tool without the API. And I'm showing the help file here. This is the SDK help file for the Revit API. You can see some of the structure. And it's a pretty vast API. If you ever do programming, this is one of the more biggest APIs out there, and some say convoluted. But there's a lot of-- that's because Revit is very constrained.

One thing you want to do though, is you want to download the software developer kit. If you're going to use Dynamo, if you want to use Python nodes or DesignScript in Dynamo or create add-ins. This help file is invaluable. But also there's lot more information in the SDK, including a lot of example, add-ins. So you can actually access. They're mostly written in C#.

The other option you have is also there are API docs online. I believe this is a little behind this, in as far as the version. But it's still a very useful location to get information on the Revit API.

What the Revit API really is is just a collection of members, methods, and really properties. That's really all it is. It's not creating a tool. It's the ability to create a tool.

PRESENTER 2: OK. And what is Revit Dynamo? Well, it's far less intensive than Revit API. It's a visual programming language that interfaces directly with Revit. As we were talking about before, as Dan was explaining before, works off of those algorithms or functional nodes. You pull them down, you push them together, you plug and play, you see what works and eventually running yourself a script off of that. It's very tactile and very engaging to a visual designer. So.

Now, additionally, like I was saying, it's intuitive to the Revit environment. Connects directly to it. So you just open up Dynamo and automatically you're engaging the project itself with whatever you write and whatever you run. No other bells and whistles. No other additional steps. Nothing else it needs to go through at that point outside of just making sure you don't have it set to automatic unless you really want to.

Additionally, project enhancement. Like I was saying, goes to that project then and there and can actually pull from the project directly too. So you could be looking at it. You could be using it as a way to sort of siphon through specific parameters inside of the project. You could just be connecting different tools and different processes. It's a way to sort of build off of the initial engagement that Revit has. So and again all of this is done through a visual programming language. Similar to Grasshopper with those fun little nodes that you get. So.

PRESENTER 1: Next is what is a Revit add-in? And, again, I was surprised in my own firm they didn't understand in terms of seeing the API and an add-in. But maybe it's just human nature because a lot of people don't create Revit add-ins in our firm. That's just kind of the way it is.

But a Revit add-in in is really a tool that is loaded with a what's called-- whoop. Didn't mean to do that. Which is called a-- didn't mean to do that either. Which is basically it's a tool that's loaded with what's called a manifest file. And this file has dot add-in extension. It's a text file or an XML file. And the idea is that your tool was created with one or more DLLs. Compiled DLLs in either C# or it could be Python or could be VB or any other dot net compliant language-- coding language. But this file is in a location in Revit that can load these DLLs when Revit launches, then really you'd have access to this tool let's say.

That's really what an add-in is. It's a tool that's created by code, and it's loaded by this add-in file, as I mentioned.

There are two types of add-ins. One is called a command. And command is also how Dynamo works. A command basically is a tool that starts and stops. You start it and then it stops. Just like the wall command in Revit. You click the wall command. You place walls. You hit Escape or Modify and it stops.

I'm shooting an example here of another tool. That's the Navisworks Exporter. And these are-- actually just these two files make up this tool. So that loads DLL and the DLL actually gives you access to this tool. And it starts and stops.

The other type of tool, which is more unique, is an application. And this is more-- it's more actually a very powerful ability of creating an add-in. The application starts when you launch Revit. And they can stop when Revit closes. You can stop it before Revit closes, but I typically use it-- I usually from start to finish normally. But it runs behind the scenes. No one no one has to know it's running unless you let them know with a dialog box or with a message or some other coding logic.

But in this case we extract over 60 metrics in our firm every day when somebody opens up a document. And it's only metrics you can extract in milliseconds. And also we display the information in power BI reports. This application is made of two DLLs and is loaded with the [? NAND ?] file. But that's what an application is. And it can be very powerful. And we'll go over more about that in a few minutes.

Any questions about that so far?

PRESENTER 2: So we're going to get a little bit into just what kind of resources we have for both ends of these two programs. Or these two tools. With Dynamo there's the various forms out there. There's a lot of Revit forms that have been converted. But there really is a central resource for Dynamo and that's Dynamo BIM. Very easy to get into. Very helpful for education. Very helpful for problem solving. Very helpful all around. It's a great community. It's a fast growing community. And it's really been pushing the product and it's been enlightening.

But yeah, with Dynamo there really is Dynamo BIM. And that's sort of that. So.

PRESENTER 1: Revit API add-ins are a little different. Because it's been around for a lot longer and the resources are a little more scattered. We're not going to go through all these different things. Don't worry. These are in the handout. But there's a lot of resources out there to learn how to create add-ins and learn how to find support and help on creating add-ins. And again it's in the help file so-- and it's in the handout. So it's all there.

PRESENTER 2: Right. Yeah. Quick demo just so we can, again, hammer home just what these two are. Revit. So very quickly we have a Dynamo example right here ready to go. This is one that's just going to look at rooms really fast. Let's unfreeze that node. And you'll see that the chain then becomes alive. If I run it now, it should go ahead and put a little dot showing us where the center of each one of the rooms are within this Revit project on the right hand side.

So I unfreeze family instance on this side and run it again, it's now going to place a toilet at each one of the dots. Because it's looking for the instance by point. So very easy to use. Very functional.

PRESENTER 1: The examples we're going to show you are going to be fairly quick and they're going to be-- yeah, the idea is to get to the pros and cons. We wanted to just show an example of each.

PRESENTER 2: Yeah. And there we've got toilets now in each one. And, again, this builds. So we can actually go back to it. Does a quick Control Z. Did Dynamo just shut down? We can actually freeze the script. And it can look at the rooms themselves. Actually see which ones underneath the parameter for department are actually called restroom. And then go ahead and place that same toilet. Now, just not in every room, but at the ones actually dignified as restroom. And there it goes.

PRESENTER 1: OK. Any questions, guys? Or. Let's go into the next one here. Let me get mouse. Now, Revit add-in is going to be next demo really. So let me just go into- I'll just go into that slide instead of starting our presentation again real quick. So Revit add-in demo. There are many type-- there are many add-ins that I'm sure you guys use every day of your lives here if you use Revit. No, didn't want to do that. I mean, if you look on the add-ins tab right here, there's many add-ins. I'm even creating add-ins to help our BIM 360 effort. Help making things easier.

But you can create add-ins in a lot of different ways. Instead of showing one of these add-ins, I want to show you kind of a unique one that's an application. Because you do an application in Dynamo, and actually you can't even do this with the four JPIs.

I'm going to use the Task Scheduler in Windows to basically launch Revit. Open a model. Detached. Print a sheet set to PDF. And then close Revit. At 2 o'clock in the morning or any time you want. So it's basically automating the use of Revit at anytime you want.

And let me show you that right quick. I'll close Revit here. And if you don't know where the Task Scheduler is, and not everybody does because, you know what? It's a tool that's been around for many years and nobody-- but unless you're an IT person or you have reason to use it, you may not even know about it. This is the Task Scheduler in Windows. And there are tasks that our company uses to probably do different things. But what I'm going to use right now is called auto PDF Print.

So let me run it. Label it first. And right now it's set to run at 2:00 AM every Friday. But I'm going to run it right now explicitly. So I'm going to run it. And, again, it's going to launch Revit. I'm going to have to hit OK because I checked out a license. And I'll show you how it's working. I'll explain what's going on behind the scenes a little bit.

So it's going to launch Revit and it's going to open up the model. But while it's doing that let me show you really quickly what's happening. So if I open up this task, there are triggers here with the Task Scheduler. And you can have it run at anytime you want, no matter-- anytime you want. That's part of this. The actions is where the kind of first part of the magic happens for this particular application. And that is it needs another part to actually run. It needs the EXE to launch Revit. So this task, it launches Revit. And then it passes a config file to Revit so that it knows what model to open. It knows what sheet's set to print. It knows the print set. Also where to put the PDF output file. So it's passing-- this EXE is passing this to an application that's running in Revit to do this print job right now.

So let me cancel this here. Let me cancel this here. And as far as C# goes, and we won't go deeply into this, but this is an application. And it's a very simple application. And there's, again, on startup, which when Revit starts up this is a Revit API event. If I expand this guy, it's doing a lot of config files. And, anyway, when Revit goes away the tool finishes by the way. And I'll show you the PDF output file. But it's By doing a lot of it-- it's doing a lot of config file log file writing. But if the config file is incorrect, I just kill Revit.

If it is correct, I use two different events. I use what's called the idling event, and I use what's called a dialog box showing event. Dialog box showing event lets me close any dialog boxes that might pop up at 2 o'clock in the morning when you;re opening up the Revit model. And it's very simple actually how I'm using it.

The idling event is an interesting event because it runs when Revit is totally inactive. There's no transactions running. Revit is totally inactive. That's kind of where this tool is-- that's where the logic really is in this tool. So if I go to the idling event that gets triggered because Revit was inactive completely, I write to log files, which I do a lot it seems. I read the config file information in. And then I open a Revit file detached and another method. If everything goes well, what happens at the very end is I-- where's it at? Right here I print the PDF. If I pass all the information to print the PDF. Revit is still running. And then at the very end of the process, I just kill Revit because it is a detached model. Not going to hurt anything.

That's pretty much it. It's going to finish in a second. Let me just minimize this. And we can close this for now.

PRESENTER 2: Quick question. Did you write that UI?

PRESENTER 1: What's that?

PRESENTER 2: Oh, the UI that you started off and set it all with that you just closed. Did you come up with that one yourself?

PRESENTER 1: The Task Scheduler?

PRESENTER 2: Yeah.

PRESENTER 1: Outcomes Windows.

PRESENTER 2: OK. So I guess--

PRESENTER 1: Again, Columbus LA. So we rehearsed, but you know it comes down to-- yeah. Yeah, it's a very interesting tool to use. Anybody here not know what the Task Scheduler was? OK. It sits-- it can be very useful because you can't run Revit outside-- you can't batch process Revit models outside a Revit.

So it is still running. And I hope it just runs and finishes in a very few seconds. But in the very end-- actually, it might have finished already, but because sometimes on my computer acts weird with Adobe Print Driver. Anyway, let me see if it finished the PDF. So it didn't yet. It'll create a-- there it is. This created the PDF right now. And it closed Revit. So that's all it does. If I look at this PDF, I just have three sheets in here. Our startup sheet with my German shepherd in there. And I thought this was an interesting image. I thought about using it somehow in the presentation, but I don't know how was going to use it. And this is a t-shirt that I bought a couple of months ago. I thought it was kind of funny. But that's the PDF that it created.

You guys have any question about that? See my stupid Adobe Writer still thinks it;s writing but it's not. You guys have any questions about that particular kind of processing? Yes?

AUDIENCE: Are you mostly running that yourself? [INAUDIBLE]

PRESENTER 1: I have a VM that's on all the time. And I have right now ten projects that are printing out maybe 5,000 sheets a couple of days a week. The whole thing about it is Revit has to be running and [? Emfala ?] has to be open for the actual links to print in the PDF. I tried printing it quietly behind the scenes, but the links don't actually print if you do it that way. So yeah, but I have a VM that runs it. I don't necessarily trust my users to have the computers running at 2:00 in the morning. Yeah.

AUDIENCE: [INAUDIBLE]

PRESENTER 1: We have not yet. I haven't created a custom--

PRESENTER 2: No. We haven't. So that's another topic though. Because a lot of-- weirdly enough, the fact that we are so integrated with Dan, with writing commands, coming up with tools in the API and everything else, that sort of leaves a lot of those tasks to actually just be on the API side. That maybe another firm which might be more Dynamo heavy would actually, or Dynamo smarter, would actually be doing that with Dynamo.

We're going to get into some of this stuff later on when we're talking about scenarios. And, yeah, we could probably talk about that a little more in depth too.

PRESENTER 1: Yeah, so my experience is not real-- with my job role, I haven't been into Dynamo enough to get deep into the deep end of it. So I haven't had a chance to play with that part of it. But I would definitely want to in the near future. But have you had a chance to do that yourself or?

AUDIENCE: [INAUDIBLE]

PRESENTER 1: Oh, Yeah.

AUDIENCE: [INAUDIBLE]

PRESENTER 1: OK. If you want to talk more about it after class, I'm kind of curious about where you're going with that. Where you're actually trying to really go with that.

Next slide here is really the pros and cons of Dynamo and Revit add-ins. And, Nick, you take it from here.

PRESENTER 2: All right. So--

PRESENTER 1: Sorry.

PRESENTER 2: No worries. So we're going to talk about Dynamo a little bit up front. Oh, this is not helpful. It's vertical. It's not horizontal.

PRESENTER 1: The bottom one.

PRESENTER 2: Yeah. So, yeah, we're going to talk about some of the pros and cons of Dynamo itself. So we'll start off with the pros. First and foremost, no coding background needed. That is wonderful. So, yeah. Makes it a lot easier to get into. And a lot of these guys are going to come off of each other as well. Namely the second one, which is talking about how it's an easy learning curve for novices. Not only is it a no coding background needed, when you're actually using Dynamo it's very plug and play. You get a parameter. You make sure that the end of the parameter finds the front of another parameter that has a similar data type or input for it. Easy to sort of figure out. It's a square peg, square hole type of scenario in terms of trying to write scripts in Dynamo itself. Sometimes you do get odd data types, but that's another story. But, yeah.

Additionally, fast development and use. Easily pop open a project. Just pull down a couple of scripts. You don't have to go through too many other windows, too many other steps. There's not much more to develop it outside of actually being in the Dynamo environment, which isn't good to launch unless Revit's open as well. So it's then and there.

Easy rapid logic changes. You want to play around, you want to look for nodes, you want to build something additionally or faster or think something could work a little bit better? The library on the left hand side is a large Rolodex of everything you could possibly want or need. Drag stuff down. Pull it out. Keep working with it. It's its own sort of catalog of functions in a way in terms of programming languages. So.

Large helpful user community. We already talked about this a little bit. But the Dynamo BIM forums. It's amazing. Nearly anybody can sort of teach themself off of it, or they can be given the resources to teach themselves.

Additionally, like we're saying, continuous iterations, continuously getting built. And people are very helpful on there. It is a very nice place. So.

Now open source content in a lot is available of it. So if you can't find the node you want, Dynamo has an inherent search function that'll let you go through and search for whatever node or whatever package you want. That Dynamo community, they're constantly building new nodes for you to use and sort of like apply inside of here. And that's just for a novice user. Advanced users who actually do understand programming, they can start putting in Python scripts inside of Dynamo itself. To use and create sort of their own functions, their own nodes within there too. So the sky's kind of limit sometimes with Dynamo.

Elemental bindings. Who knows what that means? [? Kiran, ?] you should have raised your hand. So. But, yes. So, when you're placing stuff in Revit, it's remembering what that element is bound to. And when you're working with Dynamo, Dynamo knows how it's binding the elements from point to point. From sort of one end to the other end. How it's going to be placing a beam. How it's going to be placing a column. Where is that toilet going, et cetera, et cetera. If you pull out a curve and you put down 12 toilets on the curve and the curve changes, Dynamo's going to remember where they were. And when that curve changes, so too do the toilets on that curve. So elemental binding.

So as you're sort of writing stuff with the script, the script itself, when you run it again and again, will remember the elements attached to it and will continuously move them where they're supposed to be rather than continuously creating those elements again and again. So. Yeah.

Also, very powerful under the right circumstances. It is a programming tool. It can do a wide range of functions. It can do things to the project that you can only dream of. Just to be a little in the clouds with this. But, yeah, it does provide a new additional series of tools and ones that you can develop for yourself. It's very strong. It can do a lot of things. It can input different parameters. It can do all sorts of automated tasks you would normally hate or take hours. It is a programming language. And it's a fully functional tool for Revit.

Now, lastly, it's fun. So, I don't know how many people here taught themselves Dynamo. I would a lot of people here did. The people who do know Dynamo. Yeah, and for the most part, it actually is very interesting, very tactile way of getting into things. in the survey that Dan had put out.

PRESENTER 1: It was funny because-- well, it's funny. But a lot of people in the survey said that it was fun. They like connecting nodes together and creating tools that makes their lives easier. You know. It's like a game almost to some people.

PRESENTER 2: Yeah, like when we have projects and somebody needs to actually write a Dynamo a script for it specifically, we do have small fights in the office. Of like who gets to do it. So, but yeah. But that is the pros.

Let's talk about the cons a little bit. So double edged sword. Now with it not needing a coding background, with it sort of being this nice way of sort of connecting the dots literally, it also has this spaghettification that happens. Where your projects can very quickly turn into angel hair. And because of this, it can be difficult to read. Especially if you didn't write the script. So. Yeah, deciphering these things can be trouble. Although that's sort of rule, I guess, in a lot of programming. But here it's an especially strong visual one. So. Yeah.

Additionally, it's not the most efficient computing language. Does wonderful things in terms of hooking things up inside of Revit, but when it comes to running something, it's not exactly the greatest thing on your processor. That's not to say your processor is going to explode. It's just to say that it's going to take it another maybe four times the amount of time of another language depending on what the task is. Because it's, again, not that efficient.

Maintenance between versions. When you add another layer of something that means you add another layer of quality or care I should say. So you've got to sort of maintain that you have the right version of Dynamo running, the right script, the right nodes inside of it, and we'll get to that in a second. But just making sure that all the versioning is up to date in this additional tool.

And with that, when you have a new version going, your scripts can become out of date. Your nodes can no longer be functioning because some of the nodes, especially the custom ones, are very version specific. So when those guys go, you practically have rewrite the script sometimes. So.

Now, difficult feedback error. It will tell you where something went wrong. It won't necessarily tell you why. So that can be a problem. You sort of have to figure that one out on your own. Lots of times it's a data type issue. But, again, you're not going to know until you really begin playing with it. And even then it could not even be this yellow node there itself. It could be something down the road. So you never know.

Reuse can be limited by project. So, because it is so project specific, because it maybe is relying on the parameters or some other sort of typology to the project itself, you try and open up the same script inside of another project of Revit, it may not run right. It may not have the right Family Types elements, looking for the correct parameters. Maybe those parameters were a shared parameter, something specific to the project. All of these things can be an issue. Coupled with the fact too that everybody uses a Revit template, maybe start using a different Revit a template. Maybe this project is coming from a consultant, which sort of has something else and the integration that you had for Dynamo inside that template no longer exists. So again reuse can be limited by project.

And I swear put this slide in before Monday. So. But with great power comes great responsibility. And if you're going to be running a script inside of Dynamo you've got to be ready for the consequences. Lots of times it's good to actually pull out the file, make a copy of the file itself, and test to see how your script performs inside of there. Because if you're running an untested script inside of a live project that other people are using and everything else, and it may not do what you want it to do, or it's doing something completely bizarre, which actually would probably be something you didn't want it to do too. But it can ruin a lot of things.

With it being a very powerful tool under the right circumstance, it is a very powerful tool under the wrong circumstance. So make sure you test your scripts in an isolated project first to make sure everything's going according to plan. So.

Lastly, if somebody gets really going to Dynamo they may seek employment in another field. So this is bizarrely true. So I run into programmers all the time who used to be architects. And that could be an issue depending on a company that really wants to keep sort of this individual who's been their bread and butter within something to continue working for them rather than going off into another company altogether.

PRESENTER 1: We lost many people who were great at Dynamo to either start up firms or other firms. It just it is what it is, you know. It's hard to keep them sometimes when they really know what you're doing.

PRESENTER 2: Yeah. All right, buddy, your turn.

PRESENTER 1: Any questions about these pros and cons? Any comments? Any-- oh, got comments.

PRESENTER 2: Yes, you in the front.

AUDIENCE: [INAUDIBLE] so in that case, I have to [INAUDIBLE]

PRESENTER 1: I can maybe answer this one if you want me to. I've heard from somebody that you can edit a Dynamo script, and basically all the element IDs are kept in the Dynamo script. And there's a way of deleting them out of there. I never did it before, but I heard that that's actually possible to do. That's one way around it. And I think, from what I understand, Dynamo is planning to add the ability so element bindings won't happen unless you check a box or something. I think they're planning to do that in the future. Was there another question?

AUDIENCE: [INAUDIBLE]

PRESENTER 1: Most- you can take this one.

PRESENTER 2: It can be. So, I mean, this is-- at that point we're sort of getting into the theater of the mind a little bit. Like thinking up the perfect scenario, the perfect storm for it to both either work or not work in that situation. It comes back to something the gentlemen in the back was talking about before in terms of Dynamo Player, which is a wonderful tool that lets you look at all the scripts in the company and be able to run them in the project depending on what you need.

Now, the thing about that though is normally within the Dynamo Player you're using scripts that are designed to be somewhat oblivious to the project. Like they're probably keyed into the template, they're probably doing very automated tasks. Maybe looking to see what schedules aren't on a sheet. Maybe looking to see-- make sure that all doors have been properly placed. Or maybe making to see maybe rooms are properly enclosed or something else like that. But nothing so specific as in like putting this specific guy in the specific place, placing a lighting fixture across, like, sort of a ceiling featurette or something else like that. They tend to be very generalized for that reason. So they will have some reuse functionality.

But those bigger scripts oftentimes are very project specific. They're trying to accomplish one thing about reading out say some sort of, like, thermal component to the building itself to get the right numbers back for LEED accreditation or something else of that nature. That we would not put into a Dynamo Player. And that might run into some errors itself, if not creating errors inside of the project.

PRESENTER 1: Another comment quickly is that with that particular comment on the screen, it depends on the tool you're making, you know if you make a tool that;s generic enough you can use on any project. But in our firm at least most Dynamo scripts are created for project-- are kind of project specific. But it isn't always the case.

AUDIENCE: [INAUDIBLE]

PRESENTER 1: Like Nick was saying, if the user doesn't know what the script is doing, they should probably create a backup file or create detach file before they actually use it because it can be scary. If they don't know what it's doing.

PRESENTER 2: Sorry. If it's so specific a script, I would pull out a copy of the project first and run it on there to make sure everything's running right. If you're really trying to get it to do a specific task of creating a very unique ceiling of some variety, oh, yeah, pull it out, let it run. If it's in the Dynamo Player and your firm has set up rules about when to use X,Y, and Z, and you're expecting a particular result and it's really only pointing towards one piece of it, say doors or something like that, you might be safe in that scenario. You might be safe to actually open it up, run it, and if it doesn't run right, Control Z it back. Because whatever Dynamo does is about a Control Z away. I think with the exception of maybe some view ports or something. There are some.

PRESENTER 1: Yeah. We have time for one more question if you guys have one more question. We have to keep moving.

PRESENTER 2: In the front. Yeah.

AUDIENCE: [INAUDIBLE]

PRESENTER 2: Yeah, the data type juggling is one of the bigger lessons and one of the defining moments that when you become a beginner user to an actual novice to expert so. But, yeah.

PRESENTER 1: OK, so let's look at the pros and cons of creating an add-in. So first one is you can create a command. Which is, again, similar to how Dynamo runs. Or you can create an application, which is kind of what I showed you earlier. One example of an application, actually two, the one with the metrics as well. They're both applications. Very powerful ability in the creating an add-in.

Ability to use Revit API events are very powerful. There's over 50 API events. And it lets you hook into actions that happen while Revit is running. So I can show you-- tell you one example, which would be a great tool to create if you wanted to create it. File importing. File importing event arguments. If you use this particular event in an application and somebody tries to import a DWG, they import a DWG, with that event you can actually stop it from happening. And show a user friendly message saying, why are you doing this, dummy? Or whatever you want to call it, you know. Whatever you want to say. But there are so many events and they are so powerful. If you get into something-- if you need to do that kind of thing. And, again, I'm showing you a small portion, but there's over 50.

The other advantage is the power of a IDE or integrated development environment. A code editor, a smart code editor really. And these are two of the most popular ones out there.

The ability to debug every line of code to see exactly what's happening in the application is very powerful. The ability to create any kind of interface for your tool is very powerful. Also with these kinds of tools you could also handle-- look at the memory management and do a lot of different bells and whistles that these tools have that can make your tool run as efficient as possible.

Complete control of code logic. When using Dynamo, you are relying typically on either a code nodes that came from delivered with Revit or nodes they came from the package manager or from some other location. So they may or may not be as efficient as writing code yourself. If you know what I mean. If you're writing the code yourself you know exactly what it's doing, and it can be as efficient as you are a coder. If you're relying on somebody's package who created something for a particular reason and you're using that package, it may not be as efficient.

Error handling and clear messages. I've created add-ins that never crash. Never crash Revit. Never crash anything. And that's-- I'm not saying anything about Dynamo, but yes, it doesn't crash anything. And I always show clear messages.

Error handling is great. And not even just error handling. If somebody tries to use one of my tools in an incorrect way, I can show them a clear message why they're using it incorrectly and how to use it correctly. So back to complete control. That's complete control.

Firm wide deployment. We do not firm wide deploy right now Dynamo tools. Because of many factors that Nick went over on his pros and cons. We have our own toolbar, and I deploy tools firm wide all the time and project wide as well. I can give one of my tools to somebody in our Shanghai office and I'm confident it's not going to crash Revit and it's going to do what it has to do. So at this point in time, we don't deploy Dynamo tools firm wide. I'm not saying you guys shouldn't and I'm not saying that it's not possible. But I wouldn't do it unless I knew exactly what was in those nodes code wise. I wouldn't-- I'd make sure that it was very foolproof. Bulletproof.

Back to computing time. This chart here kind of shows a lot of the reason why. When you create a Revit add-in you;re working directly with the Revit API. You;re working in Dynamo, using a Dynamo API, like I said, running on top of a Dynamo application that uses the Revit API that you run on top of Revit. And also with the packages that you get from package manager again, with possible, you know, a possible efficiency issues. So faster computing time.

Total-- printing tools that look exactly like they came from Revit are a pretty big feature. I mean you can create tools, like I said before, under the add-ins tab. You create tools right here as well with your own image, which I do a lot. And you can also create your own customs firm tab with your own images. And every year we have an ad hoc group, we go through all the tools that we have-- I'm not showing all our tools here, but we go through all the tools we have on our tab. And we see which ones aren't being used. We create new ones. And we go from there. But that ability is pretty powerful.

Now the cons. Learning a coding and programming language can be daunting. It can be very time consuming. And it's not for everybody. I'm sure a lot of you would agree with that. The only positive about this con is that if you did learn a coding, programming language like one of these three, you can also code for other applications. Not just Revit. That's the only pro I can put on that con.

Learning Revit API at a more in-depth level. You have to learn-- you have to know how the API works. If you start coding and you start just putting stuff in there and not knowing what you're doing, you're screwed. So you really have to learn the Revit API much deeper level.

More time consuming to code. I code with three or four fingers. I never learned to type correctly. I code pretty quickly with three or four fingers, but I do code. And you can copy paste code, of course, and all other ways as well. But placing nodes in a canvas and wiring them together for simple tools or more complex tools just can be faster.

Restarting Revit to debug. My language of choice is C#. So I do have this issue where I hate having to restart Revit every time I have a logic change. There are ways around that. There are hacks around that. You could use what's called the Add-in Manager, get around that in some ways. You can use Python scripting also in some ways. Even the macro editor that comes built in Revit, there is a way of kind of getting around this. But I use C#. It's my language of choice and I have to restart Revit every time. And that's kind of how it is.

Rapid logic changes are challenging, which is why Dynamo is a really great tool to use. You make changes all the time. You rewire nodes. You change your logic. It's very quick and simple. When you do it in a add-in well, you're changing code, you're recompiling, you're making sure no errors are found. You're redeploying the tool. It's just, you know, rapid logic changes are just harder in the add-in world. And that's just the nature of the tool.

Having to digitally sign. Yeah, this is more of a nuisance. And I just hate this, and I kind of wish Revit never-- Autodesk never implemented this. But in Revit 2017, I'm sure many you've seen this dialog box when you downloaded a tool from some site. But, yeah, if you don't digitally sign your tool, then you see this dialog box. And that always load doesn't-- sorry. That always load doesn't always work. At least not for me. Anyway, we have digital signature in our firm that I just use for our tools. But it's a big nuisance.