AVS Forum banner
Status
Not open for further replies.
1 - 5 of 5 Posts

·
Registered
Joined
·
19,586 Posts
Discussion Starter · #1 ·
* Posted with permission from AVS *


I'm finally on the up slope of the journey to the next generation of CQC -The Charmed Quark Controller , and I just wanted to get a little feedback on some of the new functionality that it will include, hopefully so that if anyone sees any shortcomings I can deal with them earlier rather than later. This next release is going to be 0.9.0, which will be the first candidate for a 'blessed release'. As soon as the bugs are worked out of it and any serious user issues dealt with, it will, after seemingly centuries, be available for sale as a commercial product.


* Note that the web site current describes the released version, not the upcoming version being discussed here!


I had hoped to get the 1.0 release out about a month ago. However, after discussion with beta uses, who confirmed some concerns I had, I decided to step back and take a bigger bite out in preperation for the next release. There were two primary reasons. One was ability for users to customize the product and ability for users to create their own interfaces to devices without any C++ programming.


Customization is done in a number of ways, some of them graphical via drawing tools and configuration, but also via macro programs, which are just text files of commands that cause sequences of things to happen. The CQC version currently out there has a macro language, but it's rather simple and difficult to extend. The current version also has a means for users to integrate their own devices into CQC, a protocol description language in which you describe the protocol in a text file. It worked out ok, but wasn't nearly powerful enough to handle more complex devices.


So, in order to basically kill two birds with one bush, I decided to ditch both the macro language and protocol language, and instead create a very powerful macro language which could be used both for customization and for creating device interfaces. The outcome of this, the result of a few months of insane work, is a very powerful, object oriented, macro language with it's own graphical development environment (integrated debugger and editor), a nice runtime library, and a device driver (in the CQC sense, not in the Windows sense) development and macro development framework based on that IDE and macro engine.


This means that the next version of CQC will be able to support almost any sort of device completely without any C++ code at all, and that your CQC macros will be fully debuggable in a visual debugger that provides you most of the conveniences you'd expect from a language IDE (break points, single stepping, display of parameters, members, and locals, redirection of console output, integrated editor/debugger, click on compile error to go to error, call stack window, etc...)


There will still be C++ drivers that I'll do, for some types of devices which are still a little complex to do in the macro language, mostly because they are core parts of CQC system, such as the X-10 driver, which supports different module types and soon different controller types and has lots of configuration and such, or the IR device drivers, for similar reasons plus it needs training interfaces and whatnot. But in terms of A/V or home automation devices, the ones that you'd want to be able to interface to CQC, you should be able to pretty much handle any of them with minimal to no compromise.


I've just completed the first macro based driver, which is for a simple Kramer video switcher that I often use as a guinea pig for binary type protocols (as apposed to ASCII text protocols), and I've posted the code for it here , if you would like to look at it. The protocol is simple and is documented in the file comments. The language isn't documented yet, so you'll kind of have to pick it up as you read, but if you are familiar with Java or C++ or C#, you'll probably have no problem with it. It's a combination of Java, C++, and Modula3 concepts mostly. It is very strictly OO, and leans towards safety over convenience and speed, as is appropriate for a language used for what it will be used for, i.e. automation.

Here is a screen cap of the IDE showing most of it's windows open, to give you a feeling for what it is like. This same IDE is used when you write a macro or create a device driver. The editor handles multiple files at once, and the compiler uses your local changes so you don't have to save to test. CQC, if you aren't familiar with it, is a fully distributed system. Macros are saved on a 'master server' and are easily editable or runnable from any machine on the network running CQC. It is also fully secure and account based, so only admins can run the IDE and manage macros (and other important system configuration.) You can create common macros and use them from other macros just by importing them, with a syntax like the Java classpath.


Anyway, this is a major step forward towards making CQC not just a product but a complete platform for distributed control and processing. I'll soon add a 'scheduled events' server as an optional component and you'll be able to create very powerful macros that automate your home and home theater by either running periodically or based on events occuring in the system. And, since CQC is all about two way control, your macros can look around at any device states in the network and decide what it should do, allowed for slick coordination of disparate subsystems that would otherwise not understand how to work together.


I hope that you'll take a moment and check out this new functionality and give me some feedback. Please feel free to ask any questions you might have or let me know about any concerns. You can do it here, or you can do so on the Charmed Quark discussion forum (link is at the top of the main page), if you don't want to bog down AVS with CQC specific discussion. There are already threads over there about the new macro language and the macro based driver system.


I can't say for sure how much longer till 0.9.0, but the far and away biggest chunk of work is basically done and mostly debugged now. I'll provide more information as I become more sure of things. I'll probably be getting a little hacked up toolkit available to people who've done drivers in the current system, to let them get a chance to start working on converting their drivers to the new system as soon as possible. I'll be more than happy to give a free copy of each new release to anyone who completes a quality driver and keeps it tested and up to date for that release (and of course who provides the macro source code for integration into CQC releases, by releasing the code to Charmed Quark for future distribution.)
 

·
Registered
Joined
·
19,586 Posts
Discussion Starter · #2 ·
Hey guys, I'm starting to work on the new web site content for the next drop of CQC. I'd like some feedback on the look and feel and so forth. If you have a moment, take a peek at it and let me know what you think. A lot of the technical documents are just stubbed out right now, for the installation and configuration of the product, since those things are going to change in the new release, and the supported devices list only has a couple of place holder documents since I've not finished updating all of those pages. But, a lot of new stuff is in there, in particular related to the new powerful macro language (as discussed above, one of the big new features in this upcoming release.)

Here is a link to the preview content. Keep in mind that everything there is subject to change, since it's just preview content. The main web site ( www.charmedquark.com ) is still the official word until the new release comes out.


Also not mentioned there, since I've not got around to adding it, but anyone who does a quality CQC driver for a non-trivial device will get CQC for free. In subsequent releases, if you insure that the driver continues to work and keep it going, you'll continue to get it for free. You just have to assign copyright to the driver classes (written in the new macro language) to yourself and Charmed Quark Software so that it can be distributed with the product without restrictions.


I'm going to be providing a preview drop of the driver development kit in the next day or so, which allows you to develop your driver in a simpler, offline environment. If it works there, it'll work under CQC proper. I have a few folks who have done drivers in the old serial protocol language scheme that existing CQC versions support, who will be upgrading their drivers for the new scheme. But if any of you are interested in using CQC and getting your devices under control, let me know and I'll give you a copy of this development kit preview drop. The development kit is based on the new macro language IDE that will also be part of the upcoming release, so it's a nice, video development tool that really makes it far easier to develop a driver, using a simple but powerful object oriented language.
 

·
Registered
Joined
·
19,586 Posts
Discussion Starter · #3 ·
I've posted the preview drop of the test harness. So, if anyone is interested, just drop me a line and I'll get you going.
 

·
Registered
Joined
·
19,586 Posts
Discussion Starter · #4 ·
BTW, here is a CQC device driver for the HAI Omni family of panels, written in the new CQC macro language. This pretty much shows that the language is powerful enough to handle a quite complex device and protocol. So technically minded users should be able to get pretty much any device under control without any C++ code and using the driver development tools provided by CQC in th upcoming 0.9.0 release.


There are five files involved in this driver so far:
  • DriverImpl.mengc . The main driver implementation class.
  • OmniHelpers.mengc . Gets some grunt work, bulky code out of the main class to keep it more readable.
  • OmniInfo.mengc . Just contains types and literals used by other classes.
  • OmniItem.mengc . The Omni has a lot of things that are dynamically discovered, because they are optional on any particular panel. So we need to track them and be able to convert between the name, the Omni item number, and any field ids that we associate with an item of a particular type. So we keep some lists of these items, one list for each type of item (button, unit, area, etc...)
  • OmniMsg.mengc . Hides the complexities of dealing with the Omni message format.


The driver test harness part of the upcoming release has been in the hands of some long term testers for a bit now, and I'm about to do the 4th drop of it. It's getting pretty well worked out now. So, if anyone else is interested in getting access to it so that you can do a CQC device driver, let me know. You will get a free copy of CQC for as long as you maintain one or more drivers, and share the copyright with Charmed Quark Software so that it can be freely distributed with the product, so it's a good way to get a free copy of a very powerful tool while simultaneously making that tool useful for your own purposes.
 

·
Registered
Joined
·
19,586 Posts
Discussion Starter · #5 ·
And here is a first whack at the Digital Leeza driver. I still have to add support for some more fields, but this is a good example of what a CQC driver for a purely ASCII based driver would be like. It's fairly straightforward for a device like the Leeza which only speaks when spoken to.
 
1 - 5 of 5 Posts
Status
Not open for further replies.
Top