Automation for Newbs (Myself) Christie Series 2 / Doremi+AP20 / GDC+750

[Ryan Gallagher]

If I had a good price on JNIOR-A (NJR-100-001A) units... are they worth playing with (even just to learn), or better to avoid in favor of the more contemporary models?

[Bruce Cloutier]

Okay, I guess I'll break radio silence here.

You can find the original JNIOR and what we call JNIOR2 on the surplus market. These are Dallas/Maxim 80C390 and 80C400 based controllers. Those are 8051 8-bit processor variants with pre-programmed Java Virtual Machine. They were created during the Sun Microsystems embed Java in everything era. To program those you have to write the entire control program. There is no operating system per se. This has to be done in Java and the resulting compiler output run through a TINI converter so as to connect then to the TINI runtime and execute on the hardware. Not easy. The various peripherals in that product are on a Dallas 1-wire network. Again, not straight forward to handle in raw programming. Also slow.

You might not be able to source a Java compiler today that the TINI converter will stomach. The original JNIOR was basically a proprietary thing that we deployed in newspaper systems. The JNIOR2 was an attempt to produce it in volume. It was the first version of JNIOR that Kodak deployed in their pre-show systems.

Kodak demanded a more optimized version of the JNIOR for their widespread use. This is where the JNIOR3 (310 followed by the 312 and 314) came to be. The Series 3, as we call it, remained 80C400 based but I dispensed with the internal 1-Wire network. This allowed us to drive relays to millisecond precision and not only read film cues directly but emulate the projector as well. These JNIOR still require the TINI converter. No fun. Requires huge unruly batch files to compile.

The breakthrough in the Series 3 and the reason it became successful is the JniorOS shell that we developed. This created effectively an RTOS to where application programs like the CINEMA.JNIOR can use inter-process communications to interact with resources without concern for the low-level details. More than one application could then exist as well. The Series 3 are still in use everywhere. They are a real pain to work with. We are not Microsoft and so we still support them and don't ignore you but we are not developing for them.

Then the 80C400 went to End of Life (EOL). That meant the End of JNIOR (EOJ). I came back from another start-up I had going in town to deal with this. Basically the JNIOR Series 4 is a redesign from scratch meant to be a drop-in for the Series 3. So the physical form factor remained the same. We, however, selected a completely new processor (Renesas RX600) which is 32-bit. That obviously has more horsepower. But even better, we developed our own operating system JANOS which now ran in native code. It is written in C and not Java-based. In fact I wrote our own JVM so we could keep the managed language for applications. That runs JAR files directly from your compiler. No converter.

JANOS was developed in a quarantined sense and DOES NOT use ANY third-party code or libraries. None. Every byte I wrote. On a spectrum with Linux at one end and RTOS at the other, JANOS is dramatically close to Linux. Those of you who remember CP/M might notice some throwback in the commands. But with the processor selection and the OS written (in some places using assembly) the Series 4 JNIOR are better than 200X faster. Just watch the difference in the boot. Included is a JVM, full network stack, full-featured web server with PHP-like server side scripting, TLS v1.2 security, and even a built-in network sniffer. Yes, you can deploy your own websites hosted by JNIOR. It is not just for our WebUI. All that code is in the config.zip file if you are interested. JNIOR can, maybe uniquely, serve entire sites directly out of a ZIP file.

Now everything (except JANOS) is basically open source from us. We could obfuscate and/or encrypt applications but do not. Every JNIOR is supported for life. We don't care if you found it in a dumpster. If you call for support we will help you. There are no support contracts or fees. Our approach to support too is to teach. We will help you understand the product so you can better apply it.

Add to that the fact that when you call for support you get to talk directly to the creators. Not a bot. Not someone in India who has studied the American accent. Kevin and I are 100% responsible for the entire existence of the JNIOR from Series 3 on. If you encounter a bug, assuming that we can replicate it in the office, we can rectify it the same day. The buck stops here as they say. We have nobody to which to point fingers. No one else to blame. We just fix it. Some of you can attest to that I am sure.

This DIY approach to the design allowed us to maintain through the shutdown. It allowed me to deal with the supply chain BS. The JNIOR is generic and in widespread use in other markets. So while cinema was shutdown we still had business and still could produce product. That because we manufacture it ourselves. We do not rely on contract manufacturing. We have machines and out come JNIORs.

Note that, and someone can fact check, we have not increased prices but once since 2005. Those 2005 JNIORs are still running today. We know because they signal us now and then. You can get JNIORs in 2024 and, if I continue to have a say, you will still get JNIORs in 2035. Well, it may be Series 5 which we are toying with in concept these days.

While you can certainly successfully automate anything with an Arduino or any one of a hundred controllers, When you move on from that job, if you did it with JNIOR, there will be a 1,000 other techs that will be able to pick it up and keep it running. And, we will be here to help.

So, is the JNIOR too expensive for you? Because nobody is getting filthy rich from it. I am assuming however that you all don't want to see us close our doors. Or raise prices and start charging for every little thing. No Marketing hype or spin here. We don't even employ marketing people. I am just sharing fact.

I encourage you to continue to automate by any other means. That is educational and a greatly beneficial experience. The hardware is inexpensive and your are investing your time in learning but... I am just saying...

Ahh... A good Sunday morning rant.

[Ryan Gallagher]

Thanks for the insights Bruce. I was not aware how many iterations there have been since those early models. I'm not really interested in running a JAVA based system or dealing with a TINI, so if it meets the needs and I get anyone to bite along these project lines with the expense I'll try to nab Series 4 down the road. Cheers for keeping the product viable, supported, and improved.

I'm keeping an eye on the 2nd hand market for an ECNA-5 too just to play with it.

I need em to purchase a UPS battery, spare lamps for the AV projector, and parts for my DTS processor before I consider asking for anything for my integration dreams. It sounds like smaller room is gonna get ILS this year before the festival, so I'll take what improvements we can get.

[Bruce Cloutier]

In the early 70's when we programmed a microprocessor you used its assembly language. Then the C language came along as a means of portability to where you could compile your program into the assembly language for one processor or another. Groups started to create libraries of C utility routines for reuse and we all took advantage. These, of course, became the "Standard C Library".

Assembly language programmers who moved to C kept (we kept) some bad habits and there was a need to force some better structure on them (us). So they came up with the C++ language. JANOS is written in C but there is a lot of C++ structure in that I often create a context structure and pass it around. This is essentially the 'this' pointer. I guess around that same time Java was created. I am really creating a rough high-level outline of events from memory without checking the dates or anything. There was much more to it of course. But as for structure Java is a managed language that eliminates the pointers (which are what got us all into the security vulnerability crisis we have now) and eliminates the need for the Java programmer to handle memory management (Garbage Collection does that in the background).

Now if you are creating an operating system in which you intend to allow users to program whatever they like, you need to force them to program in a managed language. Otherwise you will never be able to create a stable system and know at all what is going on or going wrong (e.g. Windows). in the 80's the choice was BASIC since most were exposed to that in school. Java however, uses the C syntax and offers structure as does C++. This is more appropriate for professional systems than BASIC.

Given that the Series 3 forced us into Java the decision was made for us. I had attended a conference held by Sun Microsystems in NYC in the 90's. I had acquired the JVM Specifications at that conference and those came in handy many many years later in developing a JVM for JANOS. That let us run the Series 3 programs. So CINEMA.JNIOR (which is really CINEMA.TINI) became CINEMA.JAR as I dispensed with the converter. A JAR file is the same as a ZIP file. Once I had written code to handle compressed libraries you no longer needed the converter.

My point in this is that you absolutely are better off running application programs using JAVA. Obviously, like anything else, we create far too many choices and confuse everything. So... Java yech... what about C#, Visual Basic, Java++, J#, Python, etc., etc.? Not to mention whatever you need for these little hobby controllers or, worse, ladder logic. Most all boil down to the same thing and Java here is the best choice for us. It works and it is more real-time than you would think.

The TINI was awful at handling memory management. That is an issue that still plagues us with those Series 3 JNIORs. In fact we had to go out of our way to keep from challenging the TINI memory manager requiring some confusing and non-standard approaches to variable handling in our early Java programs. I employ much more sophisticated techniques in JANOS and memory issues have virtually been eliminated.

But if I had a small shop on a limited budget I would make things work however I could. It would be quite a different thing if I were looking to deploy something across an entire cinema chain.

If we can help, let me know.

[Ryan Gallagher]

Sorry Bruce, I should have said "I'm not interested in PROGRAMMING a Java system". My understanding of the series 4 is that the UI allows you to do most things without dealing with whatever java internals you are still powering them with. ;-)

[Ryan Gallagher]

Here is a hiccup I was not expecting with my recent AP20 automation commands:

Big premiere tonight, was asked to cut audio at a specific timecode in crawl. Great, I have commands for that now, and they have all been behaving fine the whole festival.

For whatever reason, probably because of muscle memory, I decided to put a "AP20 Fader 0.0" macro in instead of my "AP20 Mute". Lesson learned!

Macro Fader 0.0 executed like clockwork and AP20 display read 0.0 as expected. But to my shock, my co-workers on coms reported that the 2nd song after the command started playing in the house.

I couldn't roll it off cause I was already at 0.0, so I had to just slam the mute button.

Is there a nuance in the way the AP20 "processes" fader changes that could cause this? Maybe a built in fade time that gets longer the larger of a distance you tell it to move? That is the only freakin thing I can think of. Had two cinema techs from the studio in the booth with me and they were just as preplexed as I was. 0.0 visible on the fader should mean exactly that?

Or perhaps some configuration change made by one of the several studio techs poking at the AP20 this week could cause this?

???

edit: my initial thought was that maybe my co-workers heard my booth monitor feed (which does not follow fader levels) over my open mic on coms. But confirmed that was not the case, minders from the film next to them were asking for it to be muted after that intentional mute point had passed.

[Ryan Gallagher]

So managed to test the issue in the last post. Definitely an AP20 issue with TCP fader commands for us, sometimes it will adjust outputs immediately, sometimes not at all, despite the display reflecting the update.

I've sent my config and diag off to Datasat, they are going to try to reproduce it on a unit.

[Ryan Gallagher]

Here is a hiccup I was not expecting with my recent AP20 automation commands:

Big premiere tonight, was asked to cut audio at a specific timecode in crawl. Great, I have commands for that now, and they have all been behaving fine the whole festival.

For whatever reason, probably because of muscle memory, I decided to put a "AP20 Fader 0.0" macro in instead of my "AP20 Mute". Lesson learned!

Macro Fader 0.0 executed like clockwork and AP20 display read 0.0 as expected. But to my shock, my co-workers on coms reported that the 2nd song after the command started playing in the house.

I couldn't roll it off cause I was already at 0.0, so I had to just slam the mute button.

Is there a nuance in the way the AP20 "processes" fader changes that could cause this? Maybe a built in fade time that gets longer the larger of a distance you tell it to move? That is the only freakin thing I can think of. Had two cinema techs from the studio in the booth with me and they were just as preplexed as I was. 0.0 visible on the fader should mean exactly that?

Or perhaps some configuration change made by one of the several studio techs poking at the AP20 this week could cause this?

???

edit: my initial thought was that maybe my co-workers heard my booth monitor feed (which does not follow fader levels) over my open mic on coms. But confirmed that was not the case, minders from the film next to them were asking for it to be muted after that intentional mute point had passed.

Happy to update that after a reboot of the AP20, all systems were normal and no longer having the auditorium output struggling to follow the fader/display after automation commands.
That was a WEIRD one, gonna have to keep an eye/ear out to see how long it takes for that to recur (if at all). Unfortunately hard to monitor from the booth, may just have to make a habit of a reboot before major film engagements.

[Carsten Kurz]

Do you leave this AP20 on over night?

[Ryan Gallagher]

Do you leave this AP20 on over night?

It stays on 24/7 with the rest of the equipment in that rack. Not my choice but past practice.