programming – Page 2 – Kiel the Coder

Start Small

It’s been a while! My workload hasn’t slowed down any, and this blog has had to take a backseat until I get caught up. So this post will be very brief and about a single idea, one that works for many types of problems: start small.

Solid GOLD

I passed the Gold Exam! Once I get the official badge from Crestron, I’ll post it all over my online presence.

In accordance with testing protocols, I can’t share anything particular about this exam, but I thought this would be a good chance to reflect on my experience taking the test.

SIMPL+ and Delegates

I’ve been working on my Gold Exam and a good chunk of it is written in SIMPL#. It’s been a good reminder that getting code in SIMPL# to play nicely with SIMPL logic can sometimes turn into a chore. We have SIMPL+ to thank for most of the hair-pulling. I thought a post about delegates and getting them to work in SIMPL+ would be a good thing to write down.

P201 Projector Exam

You can grab this short example from my GitHub repository at https://github.com/kielthecoder/Full-Crestron-Examples. This was the class project / final exam for the Intermediate Crestron Programming class (that turned into P201).

Crestron Drivers

I just finished watching all the videos for the C# for Crestron – Crestron Drivers online course and feel like I absorbed very little of it. The driver abstraction seems overly complicated, and the overall presentation of their videos is very dull. I like to contrast them with Q-SYS videos which are short and focused enough to hold your attention. Something about Crestron’s videos feels too robotic and I find myself multitasking with them on in the background.

SIMPL Crosspoints Best Practices

When I started Crestron programming in 2010, you had to take two classes. One covered almost the entire Crestron catalog. All I can remember is my eyes glazing over after a couple days of that. We might have built a touchpanel layout, too. The second class actually got into SIMPL programming, but we only covered button presses, feedback, interlocks, and maybe a toggle. It was fairly basic, but it was enough to get started programming Crestron systems.

After passing the exam at the end of class, they told us to go program systems for a year then come back and take the 201 class.

VC4 and SIMPL

I was recently asked if we could get a customer with an old PRO2 upgraded to VC4, probably to support new hardware they wanted to install. Looking at the existing system, there were a couple devices that needed a hardware controller: DSP and lighting control over RS-232, cable TV control over IR, and a Cresnet button panel for basic room functions. I told them we’d need to keep the PRO2 for all the connectivity, but maybe we could get it to talk to a new program running on VC4?

The Future of AV Programming: Part 6

It’s been over a year since my last installment in this series, so I thought it was a good time to reflect on where things are and where they seem to be going. I completely missed the mark on touchless control! But I think the need to diversify our skills as AV programmers is more apparent than ever. Prepare yourself, things look a bit bleak.

Multithreaded Programming

In this post, I’m going to explore the different threading options on 3- and 4-series processors. I find it difficult to keep everything straight when working in different Crestron environments, so hopefully this post will be a good refresher when I need it.

SIMPL Module Best Practices

When I started programming Crestron systems, there were two other programmers on my team. One was a senior programmer who had been doing it for years already; the other was a junior programmer who had been doing it for a year maybe? I feel like I fit into the middle slot between them quite nicely. So, I tried to follow the senior guy’s example and help the junior guy out when I felt that I could.

The workflow I picked up from the senior programmer was:

Copy-and-paste the previous program you worked on and only change the bits needed for the new system. 90% of the code is probably going to be the same anyway.
Don’t jam ANY signals together, always buffer them or use an OR.
Never hide program logic inside of a module.

I can already tell this is going to be a divisive post because of how different people treat user modules. I want to present 3 modules in this post, talking about why they were written, how they evolved, and why they were the best approach.