Both the old and new ARC will require pro subscription. It's still 14 years and 2 million+ lines of code and my blood, sweat, and more tears ha

Oh no! don't kill the old EZ-script. Don't have time to learn a new program, Disappointed at best. I hope it will an easy migration of old to new at least.

@RoboHappy, According to DJ the old EZ Script will be alive and well but only available in the legacy ARC. He says this old version will remain available. As far as migration from ARC to ARCx you'll need to rewrite your EZ Scripts to JavaScript (or Python if preferred?) and manually copy and paste from one version to the other. There is no way to use the "Merge" tool.

It makes sense why Synthiam won't keep EZ-Script.

1. EZ-Robot Inc. and Synthiam Inc. are different companies
2. Synthiam might want to better seperate itself from EZ-Robot more to avoid confusion
3. Python and Javascript are much more common

Also, this might be off-topic, but what happened to the music that you used in some of your earlier videos?

Always did wonder why split from Ez-Robot since he did start that company ( love knowing all the behind the scene secrets  about company's like this)

Well, there are two questions there. Hopefully, I'll answer them satisfactorily.

EZ-Script

I created EZ-Script in a way that was based on a need rather than naturally evolving. This is because there was no scripting ability when I made the first ez-builder. Eventually, I needed to add some level of scripting. Initially, there were no IF/ELSE or loop conditions. There weren't even variables. At the time, no prevalent programming/scripting languages were used by people. There was Java, .Net, LUA, and that's about it. JavaScript was limited to the browser, and Python wasn't accepted yet. As time passed, I started "patch-working" EZ-Script to have variables, conditions, and loops. It was the first time I created a "runtime scripting compiler." Because it was native C# and built on something that wasn't meant to be, it was not very efficient. EZ-Builder, now ARC, had many custom hooks and methods to make EZ-Script work. Eventually, not many will remember, but I implemented a c# compiler in ez-builder. It didn't last long because no one understood it.

Fast forward a few years, as I dropped the built-in c#, and suddenly JavaScript and Python began prevailing as the dominant scripting languages. They took over LUA and many others. I'm pretty glad I didn't implement LUA, although we came close a few times. I didn't feel comfortable with it. So, I implemented a JavaScript runtime and then Python. Those two languages were designed to support fast, efficient calls that merged with the ARC built-in functions. Meaning there was no intermediate call between the function and ARC functions. On the other hand, EZ-Script required a lot of intermediate support for every function. EZ-Script took twice as much code to make a single function available.

Because of the tight integration with Python and JavaScript, they started getting new functions in ARC that were fast and easier to use. This slowly pushed EZ-Script further from the platform's inner workings. It made EZ-Script slow and challenging to update. Although EZ-Script did have a few features that both Python and JavaScript didn't have, they were mostly how strings and variables worked. But, those features weren't enough to make EZ-Script worthwhile to continue supporting.

Now we're at the point of ARCx. Many knew it was coming because I hinted a few times that I had plans for a new ARC. The reason is that ARC was 14 years of code, which totaled almost 2 million lines or more. That's a lot of my hard work, which gave you all the ability to do amazing things. But during that time, I took notes of conversations about things you wish it did. Nink was one of the first who mentioned, "Man, I wish the UI was portable." He wanted the UI not to be bound to Windows and perhaps run in a browser. Given that the world is heading that way, it was inevitable. But, as you'll see when you experience ARCx, I did something unique and different by pushing the limits of how a browser-based operating environment would run.

The original plan by Synthiam developers was to make the entire thing run in the browser.  And I wasn't 100% comfortable with that decision. When you close the browser, what happens to your robot project? It stops working as well! So, eventually, Microsoft pushed hard into .Net Core, an entirely new codebase of .Net with fewer dependencies on the older Win32 libraries. This made .Net Core cross-platform (to an extent).

Recently, Microsoft released .NET 8, which has new Blazor functionality; when I saw that, the stars aligned! Suddenly, it came to me. So, I architected an idea over beers with one of Synthiam's lead developers. I told him what I thought ARCx should be (At the time, we called it ARC24 for 2024). But he didn't know it was possible. The team thought there was no way it could be done.

The same day after coming home from those "few beers, " I had a working prototype that evening. I hit a few roadblocks in the following days, but by diving deep into the inner workings of Blazor, I was able to unite a "service" model with a web UI model. So when you close the browser, the service continues to run. And not just that, I was able to implement a "plugin" model that we're all used to that made ARC so powerful.

I wouldn't say we broke the rules of how .NET 8 and Blazor were designed - but I indeed pushed the limits.

So now we get into ez-script. The ARCx was designed with a ton of functionality that I witnessed many users needing. Not just on the forum but with our enterprise and corporate customers. The ones that are controlling forklifts or other high-priority robots and automation. I needed to balance the David DIY users and the warehouse forklift robots. They are two different customers but with similar outcomes. We hit a wall as the platform was being architected for scalability to integrate new advanced features such as AI and advanced computer vision.

That wall was EZ-Script. The "middleware" that made EZ-Script operate was incompatible with the functionality of ARCx. Not just with the ControlCommand() syntax but with how robot skills interchange data. It was impossible to work with the EZ-Script codebase. I spent some time and sleepless nights trying to figure out how to make it compatible. The decision wasn't easy, but it became evident when we realized EZ-Script would have less functionality than its JavaScript and Python counterparts.

I considered what the user response would be from a less functional EZ-Script. Suddenly, we will have users doing amazing things with JavaScript and Python, with EZ-Script users wondering why they don't get the same experience. That would make many people unhappy to see the potential but not be able to harness it. That's when I had to make the tough decision to rip off the bandaid, so to speak. Because the learning curve to get into Python or JavaScript would be less painful than having a robot that doesn't perform as well as it could.

I talked to a few schools and other larger organizations using ARC to understand their concerns about removing EZ-Script. Their feedback was this: It's okay to remove EZ-Script because it's not an industry language and doesn't teach anyone anything useful. That made me sad, of course, because I was proud of ez-script. But at the same time, I knew many of you would feel the same way. So, I hope everyone understands that we all share the same remorse to see EZ-Script come to an end.

But we can all reflect on the fantastic evolution you experienced from early ARC to what ARCx will be. I am also confident that the similarities of the languages will make the migration painless - I'm sure of it. Even if it means we eventually add an Athena function to help convert EZ-Script to another language.

My Music

You know, music has always been a massive passion of mine. I was always a geek with programming, but I thought I'd end up producing music for video game soundtracks. That was where I always pictured my music being used. I eventually teamed up with a few people who wanted to play live shows at venues, which we had great success at. I enjoyed those days and have a vast library of new and recent music. Almost all of the EZ-Robot and Synthiam videos used my home-produced music from a studio in my basement.

Eventually, with the stress of running a company, music became a source of relaxation. Sitting in the dark with the ambient lighting of my synthesizers and racks of audio equipment, I would escape the world of being a CEO. I would forget about having to put prices on my passion and paying bills, employees, taxes, benefits, servers, and rent. As I continued to create music for this reason, I started to share it less. The music I produced began to be more emotional and personal. As you know, when something becomes that personal to yourself, it gets harder to share because you value the opinions of others. If someone were to say, "I don't like this song," it hits close to home.

I guess what I did was keep it close and stop sharing it. I continue to produce music, but I don't let anyone hear it. Emotional experiences influence some of it, and I may be too vulnerable to listen to opinions. If I had a hard day because I had to let go of a staff member, that song would have a tight connection with my emotions that day. If someone said they didn't like the song, it might make me feel like I relived that day again. It could have been a day I wanted to forget - and the song is a snapshot of what I felt then. The song helped me put that day behind me by locking it away on a hard drive.

As I write this response and reflect on my reasoning, there is a possibility things might change. Nothing is forever, and only time will tell what I'll do with the stash of music. Perhaps one day, I'll create a blog that explains the reasoning behind the song that I link. Perhaps one day, I'll have enough time between then and now to have enough separation not to let it affect me as much. So, that being said, I guess the answer is to stick with me, and we'll see what the future holds!

ARCx

I'm incredibly excited about ARCx, and I hope you do as well because you may not know, as I said earlier, that conversations with all of you have inspired all the features of ARCx . Conversations that happen online or offline. And not just that but observations of our community's challenges and successes. While removing EZ-Script might appear that I took something away that is responsible for your success, I'm confident ARCx will make you forget all about EZ-Script. The enhancements will make your robots easier to sell, easier to build, and easier to use.

Oh, I do need to add this about why ARCx became web-based.

Windows UI

Windows evolved since Win95 to use a set of API calls called Win32, which you may have heard references to elsewhere. Win32 links user interface events (mouse clicks and such) to code snippets. It allows drawing buttons and forms on the screen that the user can interact with. The code is executed based on an event when the user clicks a button. These events are pipped through an event manager, and it all worked well for many years.

I put a lot of faith into Microsoft to create a cross-platform UI when I saw the .Net CORE and Linux subsystem support for Windows. This made me think they would integrate a desktop-friendly cross-platform UI for Linux, MacOS, and Windows. Microsoft also acquired Xamarin, which was a cross-platform .NET compiler and toolset. Microsoft also started working with the Mono team, which allowed .NET applications to run on native operating systems, such as Linux and MacOS.

Because of these reasons, I was sure Microsoft would create a cross-platform UI. They eventually did it in 2023 with something called Maui. I was looking forward to it because it meant taking the ARC codebase and porting it to the Maui UI framework. But, like with Windows 8, Microsoft keeps forgetting their largest market is desktop users, and they developed Maui to make cross-platform mobile apps. There is a Maui for desktop Windows, but it isn't compatible with Linux and has many limitations with MacOS.

When Microsoft created Windows 8, it was around the time of the Windows Phone. They saw the success of Apple and Android in the mobile market and assumed they would be strong contenders. What they overlooked is the fact that "power users" who create stuff need Windows. Windows is necessary to create a mobile app. Windows is required to develop CAD schematics, PCBs, CPUs, and products. Windows is needed to make the "things." Because of the simplicity of creating graphic programs in Windows, all of the best design software is in Windows. Microsoft suddenly threatened the designer's customer base by leaning toward a mobile world.

When the question is asked, "What came first, the chicken or the egg?". In this case, every egg is created by programs created in Microsoft Windows. We wouldn't have the mobile world if it weren't for the Windows apps.

This is relevant because Maui is not an environment where people can create CAD software. No one is making a programming IDE in Maui. No one is creating the next video editing suite in Maui. So, how will ARC make a robot development platform in Maui? The answer is we aren't.

ARCx Web UI

Because I was expecting Microsoft to realize its position as an operating system for "the creator," I kept delaying the development of a new ARC. When .NET 8 was announced with Blazor, I saw the answer.

Would I prefer a native UI? Yup!

Will I get a cross-platform native UI? Nope

So, we end up with a web front end, and that's why ARCx will be web-based. But, being web-based means, there are several advantages to interfacing ARCx with existing tools and the Synthiam website. It also means that any device with a web browser can be the UI for ARCx. And because there's no need to render a GUI on the graphics device of the robot, you can run ARCx on lower-powered SBCs.

There are many benefits to a web front end, even though I had different expectations of where Microsoft was heading.