Jump to content
Light-O-Rama Forums

New Command Feature


Dinosang

Recommended Posts

Steven wrote:

It still amazes me that passing a 57kHz signal through a circuit designed for an 0-19kHz audio signal actually works. But apparently it does.

That amazes me, too, Steven! I would expect the front end of many transmitters (or, any transmitter with tone controls) to act as a low pass filter, severely attenuating the 57kHz signal to the point it would be useless. I certainly can't explain how they're getting away with it. But, like you said, apparently they are.
Link to comment
Share on other sites

So, it will work with most transmitters.

You let me know when you find one it doesn't work with....

It still amazes me that passing a 57kHz signal through a circuit designed for an 0-19kHz audio signal actually works. But apparently it does.

Yea, imagine that....
Link to comment
Share on other sites

Tex

You let me know when you find one it doesn't work with....

Doing a little Google search found this transmitter, although it's a moot point because it can be ordered with an optional RDS encoder already installed!
Link to comment
Share on other sites

Does anyone know the difference between the Pira MiniRDS and the Pira32? Would the MiniRDS allow one to just put the current song title/artist out on the radio? I don't know enough about RDS to gather this info from their website...

-Tim

Link to comment
Share on other sites

Tim Fischer wrote:

Does anyone know the difference between the Pira MiniRDS and the Pira32? Would the MiniRDS allow one to just put the current song title/artist out on the radio?

There are other differences, but the main reason I bought the Pira32 was its ability to lock onto the 19kHz stereo pilot signal. The RDS documentation says that if the 57kHz RDS carrier is not locked to the 3rd harmonic of the 19kHz stereo pilot signal that it could cause distortion in some radios.

If you are transmitting in mono, then this is not an issue.
Link to comment
Share on other sites

I was thinking about this, and thought of a potential problem that could possibly affect somebody next year when a new song is added.

Instead of using "New Musical Sequence" and "Import Channel Configuration", some LOR users will create a new sequence by opening an old sequence, deleting the events and timings, setting a new media file, and then doing a "Save As". (Ok, maybe no one does it this way, I'm just guessing.)

If you do this, and your old sequence has a Windows Command, then changing the Windows Command in the new sequence will also change it in the old sequence - the only way to make them different is to delete the Windows Command in one and recreate it in both.

Ok, maybe no one does this, so it won't be a problem. But to demonstrate, try this:

  1. Create a New sequence.
  2. Edit the "Windows Command" for this sequence, to something like "RDS 1".
  3. Save this sequence as "seq1".
  4. Now save it as "seq2".
  5. Close both files, and reopen "seq2".
  6. Change the Windows Command to something like "RDS 2".
  7. Close "seq2" and reopen "seq1".
  8. Look at the Windows Command.

Link to comment
Share on other sites

Instead of using "New Musical Sequence" and "Import Channel Configuration", some LOR users will create a new sequence by opening an old sequence, deleting the events and timings, setting a new media file, and then doing a "Save As".

Good catch. Thanks.

I'll change it (for a future release) so that "save as" causes a new key to be generated for the new sequence file.

There will still be the same problem if a user creates the new file by copying the old one in Windows Explorer, or something like that, but I'm not sure how much can be done to prevent that (without giving up the security that the key-scheme provides).
Link to comment
Share on other sites

bob wrote:

Instead of using "New Musical Sequence" and "Import Channel Configuration", some LOR users will create a new sequence by opening an old sequence, deleting the events and timings, setting a new media file, and then doing a "Save As".

Good catch. Thanks.

I'll change it (for a future release) so that "save as" causes a new key to be generated for the new sequence file.

There will still be the same problem if a user creates the new file by copying the old one in Windows Explorer, or something like that, but I'm not sure how much can be done to prevent that (without giving up the security that the key-scheme provides).



Would it not be better to store the info within the Sequence itself?? This would eliminate this issue would it not?
Link to comment
Share on other sites

Would it not be better to store the info within the Sequence itself?? This would eliminate this issue would it not?

That's what I meant by "giving up the security that the key-scheme provides".

By putting the Windows command directly in the sequence itself, we would be opening up an easy security hole. For example, someone could set up one of their sequences to include some sort of spyware. If the command were stored directly in the sequence file, and they shared their sequence with you, and you played that sequence, then you would be infected with that spyware.

So, instead of doing it that way, we put a level of indirection in: the sequence does not contain a Windows command; it contains a key to an entry in another file on your computer - a "command map file", called cmdmap.lcm. This file is unique to your computer, and the keys in one person's file won't match the keys in another person's file. So - as long as you don't copy someone else's command map file - sharing sequences is safe.

This has a side effect, though: If you have two (or more) computers, let's say one for sequencing and one for playing the show, you'll have to keep your cmdmap.lcm files in sync with each other if you want the commands to work on both machines.

Please see the following page in the help file for details:

"Light-O-Rama Concepts" / "Sequences" / "Windows Shell Commands"

On that page, look for the section entitled "Sharing Sequences between Computers, and Security".
Link to comment
Share on other sites

bob wrote:

Would it not be better to store the info within the Sequence itself?? This would eliminate this issue would it not?

That's what I meant by "giving up the security that the key-scheme provides".

By putting the Windows command directly in the sequence itself, we would be opening up an easy security hole. For example, someone could set up one of their sequences to include some sort of spyware. If the command were stored directly in the sequence file, and they shared their sequence with you, and you played that sequence, then you would be infected with that spyware.

So, instead of doing it that way, we put a level of indirection in: the sequence does not contain a Windows command; it contains a key to an entry in another file on your computer - a "command map file", called cmdmap.lcm. This file is unique to your computer, and the keys in one person's file won't match the keys in another person's file. So - as long as you don't copy someone else's command map file - sharing sequences is safe.

This has a side effect, though: If you have two (or more) computers, let's say one for sequencing and one for playing the show, you'll have to keep your cmdmap.lcm files in sync with each other if you want the commands to work on both machines.

Please see the following page in the help file for details:

"Light-O-Rama Concepts" / "Sequences" / "Windows Shell Commands"

On that page, look for the section entitled "Sharing Sequences between Computers, and Security".


Bob ... Anyway to specify where LOR saves this file at (IE: Network File Server)?

Harrison
Link to comment
Share on other sites

Bob ... Anyway to specify where LOR saves this file at (IE: Network File Server)?

It's saved to the same directory that your sequences are saved in, and you can specify that directory (when you install, or by running LORPost.exe). Besides that, no.
Link to comment
Share on other sites

bob wrote:

Would it not be better to store the info within the Sequence itself?? This would eliminate this issue would it not?

That's what I meant by "giving up the security that the key-scheme provides".

By putting the Windows command directly in the sequence itself, we would be opening up an easy security hole. For example, someone could set up one of their sequences to include some sort of spyware. If the command were stored directly in the sequence file, and they shared their sequence with you, and you played that sequence, then you would be infected with that spyware.

So, instead of doing it that way, we put a level of indirection in: the sequence does not contain a Windows command; it contains a key to an entry in another file on your computer - a "command map file", called cmdmap.lcm. This file is unique to your computer, and the keys in one person's file won't match the keys in another person's file. So - as long as you don't copy someone else's command map file - sharing sequences is safe.

This has a side effect, though: If you have two (or more) computers, let's say one for sequencing and one for playing the show, you'll have to keep your cmdmap.lcm files in sync with each other if you want the commands to work on both machines.

Please see the following page in the help file for details:

"Light-O-Rama Concepts" / "Sequences" / "Windows Shell Commands"

On that page, look for the section entitled "Sharing Sequences between Computers, and Security".




Hi! Bob
Yes I noticed that and since I do most of my sequencing on one machine I copy the cmdmap.lcm over to the computer that I use for the show. I realise there is always a risk in sharing files of any sort but I was wondering if you can incorporate a checksum into the file so it can be checked and have to pass before it can be used?? If it is to much to incorporate it maybe we can get into the habit of using MD5 to generate a checksum so if we share it and then you can decide if you should rely on the source.

One other option might be to be able to save a file with all the data in the sequence and have a different file extension so you can tell the difference .That way you can have a file if you were to use for your personal use and have a save as option to save the file without command option like the existing files and you would have to add a new command if you choose to use the feature.

Just a few thoughts.
Link to comment
Share on other sites

Just another thought I forgot to mention I actually thought you were going to incorporate the RDS function using the show editor to hold the RDS info and have the player relay it to a file because this is a file nobody shares. That way you would be able to have different text for different shows if you wanted to and the sequence file would be safe to share.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...