USITT ASCII Text & Strand Showport

[Paul_R]

According the USITT standard all delimiter characters should be treated equally and there is no significance to which delimiter is used where...

...however it would appear that at least as far as Showport is concerned the delimiter does have some significance as sometimes a space is used, sometimes '/' and sometimes '>' otherwise it would be consistent?

Examples below.

 

Anybody able to provide any assistance on this, it would be gratefully appreciated.

 

Thanks,

Paul

 

Cues:

$$Attr 9.02 H0 10.02 H0 31.02/H74 32.02/H74 33.02/H74 34.02/H74

$$Attr 35.02/H74 36.02/H74 37.02/H74 38.02/H74 39.02/H74 40.02>H74

$$Attr 41.02>H74 42.02/H74 61.02 HAD 61.15 H0 62.02 HB6 63.02 HAD

 

Groups:

Group 21

Text ALL BACK LIGHTS

Chan 81/100 82/100 83/100 84/100

 

Group 21.1

Chan 83 100

 

Group 21.2

Chan 82 100

 

Group 21.3

Chan 81 100 84 100

[gareth]

Have you tried importing the data into another application, and found that the difference in delimiters affects the way in which the data is handled? It's odd that the file you've generated seems to contain different delimiting characters in different places, but I wouldn't have thought it should make a difference when you actually try to use that file to import into something else.

[peter]

In the Wiki, it says

Some systems may use the characters >, =, and < instead of @, to indicate whether the level that follows is increasing, decreasing, or tracking. The same editing caveat above applies to edits of the level numbers.

.

 

Does that help?

[obsoperator]

According the USITT standard all delimiter characters should be treated equally and there is no significance to which delimiter is used where...

...however it would appear that at least as far as Showport is concerned the delimiter does have some significance as sometimes a space is used, sometimes '/' and sometimes '>' otherwise it would be consistent?

 

Note Paul that this is not an error or an inconsistency ... It's a concession to the fact that humans may be reading ASCII output. That is, the clues to whether a value is increasing or decreasing or blocked at the same value makes it easier to interpret the Cue being looked at. The "receiving" system, i.e. the console or computer that reads the ASCII file will indeed regard all of the delimiters as equivalent, since it "cares" only whether the Channel has a Level in the Cue being read.

 

This is a little troublesome in regard to Tracking/Non-Tracking consoles. That is, a Channel that has no Level in a Cue would simply not appear in the ASCII file. And when the cue is played back on the console, the Channel involved would not come up. But on many consoles, the value Zero (as in CHAN 55=0) has the added meaning of a blocking value. Of course the "hardware" result is the same - all the dimmers patched to that Channel don't come up in the Cue.

 

You should also note that $$Attr is properly regarded as an "extension" or user-defined keyword that isn't necessarily recognized by any system other than the system that generated it. For example, if you use Obsession II (I know, it's not so popular in the U.K.), their offline editor has a bunch of extensions, even more sophisticated than Strand, for the purpose of allowing easier upgrades to their next line of consoles, like EOS. But Strand won't be able to interpret most of those extensions, and vice versa.