开云体育

Never said it would be easy, just that we wouldn't need to be "afraid" to
use C# like S+. Nothing about any of these changes Crestron is going
through is proving easy. Personally, I think it will be nice to finally
use a grown up language.

I had a conversation with someone at CEDIA about the Simpl - C# - runtime
process, and I honestly can't remember what they said. Brain is full of
ABUFs I think.



On Sat, Sep 15, 2012 at 11:13 AM, Anthony Desimone <
anthony_desimone@...> wrote:

**


C# really is interpreted. It uses a JIT compiler. Even if Simpl compiles
to bytecode the same way that C# does, it's not really accurate to say that
it's in any way turning into C# code. And this still doesn't mean the
transition from Simpl to Simpl# will necessarily be an easy one.


--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

Someone else will have to clarify, cause I might have bad info (which if

it

is, it came from Crestron!)

From what I understand, for 3-series, C# is at the core of what runs on
there. You will be able to write an entire program in C# should you
choose. Simpl is "interpreted" to C#, which in itself is an interpreted
language - to be compiled at runtime. For 2-series, historically and
currently, Simpl compiles down into the specific machine code that runs

on

2-series.

IP stuff is usually best as S+. There's a lot parsing that is just
impossible to do in Simpl alone. You can't efficiently parse text of
unknown length in Simpl. It's hard or impossible to build text strings in
Simpl.

I can't really speak to their modules because I really don't use anything
beyond the TSTAT module (which I'm hoping will be replaced soon also.)

For

now, it seems that S+ should be avoided in as many places as possible,
hence this hours-long experiment to replace a couple lines of code...




On Sat, Sep 15, 2012 at 10:06 AM, eagrubbs <eagrubbs@> wrote:

**

Simpl and the modules are based on the C# language? Did not know. I

really

had no idea what language simpl is based on.

This raises a second question that has been asked before in another
thread, why does simpl+ get used so much by crestron IP modules? That
obviously is not best practices. I would figure crestron would put the
kabosh on all the simpl+, but that is not the case. In fact a lot of

the

cresron modules these days have simpl+ in all of them, which makes the
program slower. So ??????. I understand using simpl+ for news feeds and
weather, getting phone directories for vtc, that type stuff, but there

is a

lot of simpl+ used where if the person took a few and thought it out

on how

to do it in simpl the program could run a little faster and better. My

.02

--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

I thought that too, but seeing how it lays out{ On the surface it

looks

like a lot, but when its running it's not very much.

The Simpl+ module has to loop 16 times, asserting 16 outputs (big

deal I

know). I don't really know how this translates into logic waves. I

swear

this is visible under certain conditions.

The Simpl logic hits 16 EQUs on the first logic wave, and those 16

EQUs

initiate 16 ABUFs on the following. On wave 3, the data is where it
belongs. The other 240 ABUFs just quietly waste away the day, never

to be

accessed.

Don't worry too much about C#. It's what all of this is built on, so

it

will be an equal operator moving forward.



On Sat, Sep 15, 2012 at 9:05 AM, eagrubbs <eagrubbs@> wrote:

**

Wow, I never would have thought that. It is amazing that a few

lines of

code runs slower than hundreds of symbols. I guess that is why they

tell us

to do it in simpl first. :)

Then how is all this simpl# going to work out? I guess we have to

stay

tuned to our favorite Bat Channel.

--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

It seems to work better. This is feeding a source list menu on an

MLX3.

With the S+ version, I get a slight delay when the list comes in.

With

this, everything shows quickly. Now I just need to figure out

why the

list

is exactly upside down :-). I think I can tolerate the extra

second

or

two

of compile time.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

The processing time is almost irrelevant with SIMPL+, the big penalty is
the context switch when you go from the SIMPL engine to a SIMPL+ thread and
back. Being able to do something natively in SIMPL is almost always faster
regardless of how convoluted it winds up being, assuming of course it is
actually possible to do. This is how a SIMPL+ module that adds two numbers
together can be 20 times slower than an ASUM symbol.

Note that this really only applies to 2-series processors. 3-series are an
order of magnitude (or two?) faster, and may not have any measurable
penalty for switching to SIMPL+ -- I really haven't checked yet, but I do
know everything runs faster there, so you're less likely to notice if there
is one.

SIMPL+ on 2-series is preprocessed into C and compiled to machine code.
SIMPL+ on 3-series is preprocessed into C# and compiled to bytecode for
the .NET runtime. SIMPL# is a planned extension to allow the full
expressiveness of C#, probably by cleaning up and publishing the existing
APIs that they're already using for SIMPL+. I don't expect to be able to
write the entire program in S# from day one, but rather do the things we're
already doing in SIMPL+ in C# instead, with the benefit of the framework
(albeit likely the micro framework) and existing libraries for C#.

On Sat, Sep 15, 2012 at 11:05 AM, eagrubbs <eagrubbs@...> wrote:

**


Wow, I never would have thought that. It is amazing that a few lines of
code runs slower than hundreds of symbols. I guess that is why they tell

us

to do it in simpl first. :)

Then how is all this simpl# going to work out? I guess we have to stay
tuned to our favorite Bat Channel.

--- In Crestron@..., Heath Volmer <hvolmer@...> wrote:

It seems to work better. This is feeding a source list menu on an MLX3.
With the S+ version, I get a slight delay when the list comes in. With
this, everything shows quickly. Now I just need to figure out why the

list

is exactly upside down :-). I think I can tolerate the extra second or

two

of compile time.

--
Jeremy Weatherford






------------------------------------




Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

It's not as bad as it seems - if you like to drive :-)

--- On Saturday, September 15, 2012 at 12:05 AM, Chip wrote:

Wow - *that's* a long drive!

- Chip

--- In Crestron@..., "Tony Golden" <mrgolden@> wrote:

I drove last year, but I'm not sure if I'll do it again this year or

not...

--- On Friday, September 14, 2012 at 10:21 PM, Chip wrote:

For anyone that's close enough that they *drive* to Rockleigh coming
from the south, I highly recommend taking 287 North to the NY
Throughway if at ALL possible. MUCH nicer drive than taking

95/Turnpike...

- Chip

--- In Crestron@..., "eagrubbs" <eagrubbs@> wrote:

You and me both. The farthest North I have been is DC. So this
should be

an experience in all shape forms and fashions.

--- In Crestron@..., "richard_leek" <leek.richard@>

wrote:

I signed up for dec 5 - 7. Wanted October but have too much
work. I sure do hope it's nice in NJ in December

**


Yes. I have learned as I gain more experience that I must modify I2P
modules or write my own from the protocol. I actually have gotten to the
point where everything I use, except codec modules, I have written my own.
I have found that my programs run faster and seem to be better for it. Not
to mention I have more of clue of what is happening and why.


--- In Crestron@..., Lincoln King-Cliby <lincoln@...> wrote:

Repeat after me: Crestron I2P Modules should be used as an example of

HOW NOT TO PROGRAM, not how TO program.

The vast majority of I2P modules are written with the assumption that

they will be the only module in the program (and I mean only, as in
literally one, not even "multiple copies of the same module")

The "official" line from Crestron is that I2P modules are there solely

to implement every function provided by the manufacturer, and you're
welcome to thin them down however you like.

Also: Remember Crestron is a hardware company. They make no direct

profit from the modules, etc. It is in their interest to push boxes out the
door. The QM-RMC is often cited as a inexpensive "adaptor" to get around
performance issues.

While it's inelegant, the argument makes sense: A QM-RMC is only a

couple hours of programming time, so if you're in the "Hey, we got a crappy
module, but if you put it on its own processor it works, or I can spend 5
hours building and debugging a module that plays nicely with others" from a
purely financial perspective the QM-RMC makes more sense

That said, I've never needed to resort to a bandaid like that to get

around performance issues. But I also don't use many Crestron modules.

--
Lincoln King-Cliby, CTS
Sr. Systems Architect | Crestron Certified Master Programmer (Silver)
ControlWorks Consulting, LLC
Crestron Authorized Independent Programmer


-----Original Message-----
From: Crestron@... [mailto:Crestron@...] On

Behalf Of eagrubbs

Sent: Saturday, September 15, 2012 12:06 PM
To: Crestron@...
Subject: [Crestron] Re: Challenge

Simpl and the modules are based on the C# language? Did not know. I

really had no idea what language simpl is based on.

This raises a second question that has been asked before in another

thread, why does simpl+ get used so much by crestron IP modules? That
obviously is not best practices. I would figure crestron would put the
kabosh on all the simpl+, but that is not the case. In fact a lot of the
cresron modules these days have simpl+ in all of them, which makes the
program slower. So ??????. I understand using simpl+ for news feeds and
weather, getting phone directories for vtc, that type stuff, but there is a
lot of simpl+ used where if the person took a few and thought it out on how
to do it in simpl the program could run a little faster and better. My .02

--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

I thought that too, but seeing how it lays out{ On the surface it looks
like a lot, but when its running it's not very much.

The Simpl+ module has to loop 16 times, asserting 16 outputs (big deal

I

know). I don't really know how this translates into logic waves. I

swear

this is visible under certain conditions.

The Simpl logic hits 16 EQUs on the first logic wave, and those 16 EQUs
initiate 16 ABUFs on the following. On wave 3, the data is where it
belongs. The other 240 ABUFs just quietly waste away the day, never to

be

accessed.

Don't worry too much about C#. It's what all of this is built on, so it
will be an equal operator moving forward.



On Sat, Sep 15, 2012 at 9:05 AM, eagrubbs <eagrubbs@> wrote:

**


Wow, I never would have thought that. It is amazing that a few lines

of

code runs slower than hundreds of symbols. I guess that is why they

tell us

to do it in simpl first. :)

Then how is all this simpl# going to work out? I guess we have to

stay

tuned to our favorite Bat Channel.

--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

It seems to work better. This is feeding a source list menu on an

MLX3.

With the S+ version, I get a slight delay when the list comes in.

With

this, everything shows quickly. Now I just need to figure out why

the

list

is exactly upside down :-). I think I can tolerate the extra

second or

two

of compile time.

------------------------------------

Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the

Database area.

Yahoo!
Groups Links

Repeat after me: Crestron I2P Modules should be used as an example of HOW NOT TO PROGRAM, not how TO program.

The vast majority of I2P modules are written with the assumption that they will be the only module in the program (and I mean only, as in literally one, not even "multiple copies of the same module")

The "official" line from Crestron is that I2P modules are there solely to implement every function provided by the manufacturer, and you're welcome to thin them down however you like.

Also: Remember Crestron is a hardware company. They make no direct profit from the modules, etc. It is in their interest to push boxes out the door. The QM-RMC is often cited as a inexpensive "adaptor" to get around performance issues.

While it's inelegant, the argument makes sense: A QM-RMC is only a couple hours of programming time, so if you're in the "Hey, we got a crappy module, but if you put it on its own processor it works, or I can spend 5 hours building and debugging a module that plays nicely with others" from a purely financial perspective the QM-RMC makes more sense

That said, I've never needed to resort to a bandaid like that to get around performance issues. But I also don't use many Crestron modules.

--
Lincoln King-Cliby, CTS
Sr. Systems Architect | Crestron Certified Master Programmer (Silver)
ControlWorks Consulting, LLC
Crestron Authorized Independent Programmer


-----Original Message-----
From: Crestron@... [mailto:Crestron@...] On Behalf Of eagrubbs
Sent: Saturday, September 15, 2012 12:06 PM
To: Crestron@...
Subject: [Crestron] Re: Challenge

Simpl and the modules are based on the C# language? Did not know. I really had no idea what language simpl is based on.

This raises a second question that has been asked before in another thread, why does simpl+ get used so much by crestron IP modules? That obviously is not best practices. I would figure crestron would put the kabosh on all the simpl+, but that is not the case. In fact a lot of the cresron modules these days have simpl+ in all of them, which makes the program slower. So ??????. I understand using simpl+ for news feeds and weather, getting phone directories for vtc, that type stuff, but there is a lot of simpl+ used where if the person took a few and thought it out on how to do it in simpl the program could run a little faster and better. My .02


--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

I thought that too, but seeing how it lays out{ On the surface it looks
like a lot, but when its running it's not very much.

The Simpl+ module has to loop 16 times, asserting 16 outputs (big deal I
know). I don't really know how this translates into logic waves. I swear
this is visible under certain conditions.

The Simpl logic hits 16 EQUs on the first logic wave, and those 16 EQUs
initiate 16 ABUFs on the following. On wave 3, the data is where it
belongs. The other 240 ABUFs just quietly waste away the day, never to be
accessed.

Don't worry too much about C#. It's what all of this is built on, so it
will be an equal operator moving forward.



On Sat, Sep 15, 2012 at 9:05 AM, eagrubbs <eagrubbs@> wrote:

**


Wow, I never would have thought that. It is amazing that a few lines of
code runs slower than hundreds of symbols. I guess that is why they tell us
to do it in simpl first. :)

Then how is all this simpl# going to work out? I guess we have to stay
tuned to our favorite Bat Channel.

--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

It seems to work better. This is feeding a source list menu on an MLX3.
With the S+ version, I get a slight delay when the list comes in. With
this, everything shows quickly. Now I just need to figure out why the

list

is exactly upside down :-). I think I can tolerate the extra second or

two

of compile time.

[Non-text portions of this message have been removed]

------------------------------------



Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the Database area.
Yahoo! Groups Links

I've only seen the 2 minute video, but based on the recent ease & success of working with new software/products, I can say with confidence that Home Design Studio will work perfectly out of the box and save at least 90% time when programming systems. Crestron always makes sure all the bugs are worked out before releasing new stuff so we don't get stuck wasting time in the field.


--- In Crestron@..., "eagrubbs" <eagrubbs@> wrote:

+1 Too funny

--- In Crestron@..., Tray Schaeffer <trayschaeffer@> wrote:

"... crashes more often then Lindsay Lohan"

LOL, you made my day!

Tray

==


-----Original Message-----
From: Nick Mitchell
Sent: Friday, September 14, 2012 12:32 PM
To: Crestron@...
Subject: Re: [Crestron] Crestron Studio - Home Designer

It doesn't seem beta to me. More like alpha. It crashes more often then
Lindsay Lohan. It is an excellent concept tho. Combining vt pro, simpl, and
toolbox and system builder all into a single application. At CEDIA they
told me they were hoping for a December production release.

Nick

Sent from my iBerry

On Sep 14, 2012, at 9:47 AM, Marlon Culpi <marlonrac@> wrote:



What do you guys think?




[Non-text portions of this message have been removed]



------------------------------------



Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

I thought that too, but seeing how it lays out{ On the surface it looks
like a lot, but when its running it's not very much.

The Simpl+ module has to loop 16 times, asserting 16 outputs (big deal I
know). I don't really know how this translates into logic waves. I swear
this is visible under certain conditions.

The Simpl logic hits 16 EQUs on the first logic wave, and those 16 EQUs
initiate 16 ABUFs on the following. On wave 3, the data is where it
belongs. The other 240 ABUFs just quietly waste away the day, never to be
accessed.

Don't worry too much about C#. It's what all of this is built on, so it
will be an equal operator moving forward.



On Sat, Sep 15, 2012 at 9:05 AM, eagrubbs <eagrubbs@...> wrote:

**


Wow, I never would have thought that. It is amazing that a few lines of
code runs slower than hundreds of symbols. I guess that is why they tell us
to do it in simpl first. :)

Then how is all this simpl# going to work out? I guess we have to stay
tuned to our favorite Bat Channel.

--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

It seems to work better. This is feeding a source list menu on an MLX3.
With the S+ version, I get a slight delay when the list comes in. With
this, everything shows quickly. Now I just need to figure out why the

list

is exactly upside down :-). I think I can tolerate the extra second or

two

of compile time.

[Non-text portions of this message have been removed]

Someone else will have to clarify, cause I might have bad info (which if it
is, it came from Crestron!)

From what I understand, for 3-series, C# is at the core of what runs on
there. You will be able to write an entire program in C# should you
choose. Simpl is "interpreted" to C#, which in itself is an interpreted
language - to be compiled at runtime. For 2-series, historically and
currently, Simpl compiles down into the specific machine code that runs on
2-series.

IP stuff is usually best as S+. There's a lot parsing that is just
impossible to do in Simpl alone. You can't efficiently parse text of
unknown length in Simpl. It's hard or impossible to build text strings in
Simpl.

I can't really speak to their modules because I really don't use anything
beyond the TSTAT module (which I'm hoping will be replaced soon also.) For
now, it seems that S+ should be avoided in as many places as possible,
hence this hours-long experiment to replace a couple lines of code...




On Sat, Sep 15, 2012 at 10:06 AM, eagrubbs <eagrubbs@...> wrote:

**


Simpl and the modules are based on the C# language? Did not know. I really
had no idea what language simpl is based on.

This raises a second question that has been asked before in another
thread, why does simpl+ get used so much by crestron IP modules? That
obviously is not best practices. I would figure crestron would put the
kabosh on all the simpl+, but that is not the case. In fact a lot of the
cresron modules these days have simpl+ in all of them, which makes the
program slower. So ??????. I understand using simpl+ for news feeds and
weather, getting phone directories for vtc, that type stuff, but there is a
lot of simpl+ used where if the person took a few and thought it out on how
to do it in simpl the program could run a little faster and better. My .02

--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

I thought that too, but seeing how it lays out{ On the surface it looks
like a lot, but when its running it's not very much.

The Simpl+ module has to loop 16 times, asserting 16 outputs (big deal I
know). I don't really know how this translates into logic waves. I swear
this is visible under certain conditions.

The Simpl logic hits 16 EQUs on the first logic wave, and those 16 EQUs
initiate 16 ABUFs on the following. On wave 3, the data is where it
belongs. The other 240 ABUFs just quietly waste away the day, never to be
accessed.

Don't worry too much about C#. It's what all of this is built on, so it
will be an equal operator moving forward.



On Sat, Sep 15, 2012 at 9:05 AM, eagrubbs <eagrubbs@> wrote:

**

Wow, I never would have thought that. It is amazing that a few lines of
code runs slower than hundreds of symbols. I guess that is why they

tell us

to do it in simpl first. :)

Then how is all this simpl# going to work out? I guess we have to stay
tuned to our favorite Bat Channel.

--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

It seems to work better. This is feeding a source list menu on an

MLX3.

With the S+ version, I get a slight delay when the list comes in.

With

this, everything shows quickly. Now I just need to figure out why the

list

is exactly upside down :-). I think I can tolerate the extra second

or

two

of compile time.

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

I think you've not yet learned a mantra of this field: there's no such
thing as a "quick and easy" job.
On Sep 14, 2012 11:08 PM, "Jeremy Weatherford" <jweather@...> wrote:

Stick to Viewport on older firmware, Toolbox seems to have forgotten that
v3 firmware still exists.

On Fri, Sep 14, 2012 at 10:58 PM, rocketshipav <mpninc@...> wrote:

**


Hey Crestron group,

I wanted to know if this has even happened to you. Customer has a CP2E 2
STX1550C and 2 STX gateway. The system is very old but it works. Customer
called and he had swapped out is old Hughes DTV for a Directv box so I

told

him no problem... I checked the compile from the procesor and he matched
our current file so I make the change (5 minutes). Then I upload, this is
wear hell break lose....Once I finished the upload the remote is very

slow

to response and the IR control of the AM/FM radio stop working...Opened
debugger and found the IR for the AM/FM radio numeric has shifted that

was

easy. Made the change and still the STX1550c is very slow to response.

Load

the old file everything works...Tried updating the firmware for the CP2E
from 3.137 to current. Half way thru the puf update Toolbox stop
responding. Now i have to flash the CP2E to reload the firmware (Alt + K
method using Viewpoint). After all that I was able to get the CP2E

working

again and I load the old file back in and now it is getting late and the
customer said to come back another day, customer said "I thought this was
an easy process didnt know that you were going to be here for 3 hours".
What do I tell the customer "Oh, you have old firmware and Crestron
software suck! and I didnt know it was not compatible and for me to

change

your IR file I need to update the whole system and pray to the Crestron

god

that the system will work again.

Come On Crestron can't make anything simple but you call your software
"Simpl".

--
Jeremy Weatherford


[Non-text portions of this message have been removed]



------------------------------------




Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

[Non-text portions of this message have been removed]

Don't worry too much about C#. It's what all of this is built on, so it
will be an equal operator moving forward.

--- On Saturday, September 15, 2012 at 12:05 AM, Chip wrote:

Wow - *that's* a long drive!

- Chip

--- In Crestron@..., "Tony Golden" <mrgolden@...> wrote:

I drove last year, but I'm not sure if I'll do it again this year or

not...

--- On Friday, September 14, 2012 at 10:21 PM, Chip wrote:

For anyone that's close enough that they *drive* to Rockleigh coming
from the south, I highly recommend taking 287 North to the NY
Throughway if at ALL possible. MUCH nicer drive than taking

95/Turnpike...

- Chip

--- In Crestron@..., "eagrubbs" <eagrubbs@> wrote:

You and me both. The farthest North I have been is DC. So this
should be

an experience in all shape forms and fashions.

--- In Crestron@..., "richard_leek" <leek.richard@>

wrote:

I signed up for dec 5 - 7. Wanted October but have too much
work. I sure do hope it's nice in NJ in December

I thought that too, but seeing how it lays out{ On the surface it looks
like a lot, but when its running it's not very much.

The Simpl+ module has to loop 16 times, asserting 16 outputs (big deal I
know). I don't really know how this translates into logic waves. I swear
this is visible under certain conditions.

The Simpl logic hits 16 EQUs on the first logic wave, and those 16 EQUs
initiate 16 ABUFs on the following. On wave 3, the data is where it
belongs. The other 240 ABUFs just quietly waste away the day, never to be
accessed.

Don't worry too much about C#. It's what all of this is built on, so it
will be an equal operator moving forward.



On Sat, Sep 15, 2012 at 9:05 AM, eagrubbs <eagrubbs@...> wrote:

**


Wow, I never would have thought that. It is amazing that a few lines of
code runs slower than hundreds of symbols. I guess that is why they tell us
to do it in simpl first. :)

Then how is all this simpl# going to work out? I guess we have to stay
tuned to our favorite Bat Channel.

--- In Crestron@..., Heath Volmer <hvolmer@> wrote:

It seems to work better. This is feeding a source list menu on an MLX3.
With the S+ version, I get a slight delay when the list comes in. With
this, everything shows quickly. Now I just need to figure out why the

list

is exactly upside down :-). I think I can tolerate the extra second or

two

of compile time.

[Non-text portions of this message have been removed]