Richmond Sound Design Ltd. Theatre Sound Design, Show Control & Virtual Sound System Software SoundMan-Server Release Notes ****************************************************************************** Version 1.0.28 1) SMS will now show a tray icon rather than a normal program taskbar icon when it is minimized. You can use the tray icon to display the window, show the About Box, or exit the program. 2) If we fail to connect to an interface, and the driver name starts with the string "MOTU", we will not do a messagebox about the driver failure, since the MOTU drivers already do this themselves. We don't need two annoying message boxes when one will do. 3) In earlier versions if we failed to connect to the driver we could insome cases crash shortly after. This has been fixed. 4) If the driver fails to open, a balloon tooltip will show over the icon in the lower right corner of the desktop. This will give the operator a hint as to why sound might not be coming out even though SMD seems to be running cues. 5) Fixed a small memory leak that could sometimes occur under very unusual conditions. 6) The positive gain limit for a submaster was 20dB,consistent with all other gain controls. However SMA can send positive submaster gains up to 47.25 db. Changed the limit for positive submaster gain to 50db. The range is now -160 to +50. In AB mode or CC mode the overall gain of the control point will still be limited to +0db maximum. ******************************************************************************* Version 1.0.27 This is a major new version of SoundMan-Server which reads and generates SMPTE time code and has a large number of timecode manipulation, chase and lock capabilities. Here is the summary of this release, provided by Loren: This version of SM-S can both generate and read SMPTE timecode, and can lock any number of playback channels to the input timecode. You can also lock the timecode generators to incoming timecode from a reader, so you can either regenerate timecode or you can generate timecode of a different form locked to the input timcode (for instance, generate 24 fps timecode from 30 fps timecode. Note that in this version the reader and generator deal with SMPTE, *** NOT *** WITH MTC! SMPTE readers are "fake output channels". There are two of them, on channels O1000 and O1001. You can route any input channel or for that matter playback channel to either of the readers. You should never route more than ONE source to a given reader if you want it to decode correctly SMPTE generators are "fake playback channels". This lets you start and stop them in sychronism to other playback channels, and to set speed and pitch and starting time using "track" parameters, just as you might do if you were playing back a timecode track recording. There are two SMPTE generators, on channels P1000 and P1001. Playing back multiple tracks in sync to timecode requires the use of a GROUP. There are a number of group channels with names starting from GROUP 0 or G0. The group is the ringmaster that receives incoming timecode from a timecode reader and makes sure that all of the playback channels in the group stay in sync. To make this work you first have to declare a group that has a number of playback channels in the group, and which also has a SMPTE reader. You also specify the timecode lock mode and starting timecode value for the tracks. All tracks in a group need to start at the same timcode value, and tracks locked to timecode position cannot be set to loop. If the track looped there would be multiple possible timecodes for each position in the track. This is not currently allowed. There are two ways you can lock tracks to timecode. You can lock them by pitch/speed, or you can lock them by time. Sometimes all you need is to make sure that your playback channels will play at the same speed as some external device, like a video projector, but you can start and stop the sound manually. If this is what you want, you want to lock to timecode speed. This lets you start and stop tracks manually, and the tracks can loop. However, they will faithfully follow the incoming SMPTE playback rate. More commonly you want to lock the playback tracks to a constant time position. When you do this you can set all of the tracks to be locked (in the group declaration) and start the tracks. If timecode is not present, or it is before the track starting time, the tracks will not play. Once the timecode appears and is stable and within the track range the tracks will play to timecode. You can manually stop the tracks even if timecode is still playing, and they will stop. When you start them again there will be a short delay while they seek to the current position for the current timecode value. Audio will only follow timecode that is running forward. If the timecode stops, or starts running backward, or runs at a constant frame number, the audio will not play. Once the timecode is running forward and is within the track time range the tracks will play IF they have previously received a PLAY command. When playing tracks to timecode, you do not send the Play command to the individual tracks as you would normally do. Instead, you tell the group to play, for instance, PLAY G0. The commands necessary to play to timecode and all specific new commands are described below. 1) There are now two signal generators. Previously there was a single generator. Both signal generators are identical, and can be used to generate two different tones or other wave shapes routed to different outputs. The SET GENERATOR and GET GENERATOR commands have been enhanced to allow you to specify the generator of interest. The syntax now is: SET {GEN | GENERATOR} [channel number] SHAPE SINE|SQUARE|TRIANGLE|WHITE|PINK FREQ|FREQUENCY fpt 5..24000 SWEEP PAUSE|STOP|RESUME|min max time GET {GEN | GENERATOR} [channel] SHAPE FREQ|FREQUENCY SWEEP [MIN|MAX|TIME] This is identical to the previous syntax, with the addition of the optional generator channel number following GEN or GENERATOR. If the channel number is not given it will default to 1000, which is the first generator. If the channel number is given, it must be either I1000 or I1001, as those are the two signal generator channels. 2) There are now two timecode generators on channels P1000 and P1001. The timecode generators can be used independently to generate two different timecode streams. The timecode streams can have different time bases, or can have different timecode types. For instance, you could generate SMPTE at 30 frames/second from one generator and 24 frames/second from the second generator if you needed to lock a projector and a lighting console to the same time, but they required different frame rates. The timecode generators appear to be playback channels. Since they are playback channels they can be started and stopped with PLAY and STOP commands, just like real playback channels. This lets you generate timecode in synchronism with audio playback. The timecode generators can start, stop, pause, loop, and change speed just like playback channels, so can track all movement actions identically to playback channels. The timecode generators can generate many different forms of timecode. They can also generate pure sine waves, so can be used as an additional two signal generators if this is desired. By default the generators generate full output level. The command syntax for the timecode generators is similar to the setup for normal signal generators: SET {TCGEN | TCGENERATOR} [channel number] FREQ|FREQUENCY fpt 5..24000 CODE SINE SMPTE30 SMPTE30D | SMPTE30DROP SMPTE25 SMPTE24 IRIG A [INV|INVERTED] IRIG AMOD [INV|INVERTED] IRIG B [INV|INVERTED] IRIG BMOD [INV|INVERTED] START [TIME|TC] [AT [TIME|TC] ] DATE yy/mm/dd DAY nnn USERBITS nnnnnnnn SPEED fpt number RUNNING YES | NO | ON | OFF GET {TCGEN | TCGENERATOR} [channel] FREQ|FREQUENCY START {TIME | TC} CODE TIME DATE DAY USERBITS SPEED RUNNING The frequency should only be set if you are generating a sine wave. When you set any other code type the frequency is set automatically to the correct rate for that timecode type. It is possible though to manually set the frequency after setting the timecode type. This will probably cause the timecode to run off of the correct frequency, but there may be times when that is useful. The timecode type generated are: SINE A plain sine wave SMPTE30 30fps non-drop SMPTE SMPTE30D 29.97fps drop frame timecode SMPTE30DROP 29.97fps drop frame timecode SMPTE25 25fps SMPTE timecode SMPTE24 24fps SMPTE timecode IRIG A 1000Hz IRIG-A pulsed timecode IRIG AMOD 10KHz IRIG-A sinewave modulated timecode IRIG B 100Hz IRIG-B pulsed timecode IRIG BMOD 1000Hz IRIG-B sinewave modulated timecode SMPTE timecodes are most commonly used for synchronization between show equipment of various forms. IRIG is an older timecode form that is very good for long-range synchronization, between hundreds of feet and for some codes, tens of thousands of miles. It tends to be more resistant to noise and distortion than SMPTE timecode. However, it is polarity sensitive to decode correctly. Since the output polarity of an audio channel is not necessarily predictable, you can generate the IRIG codes either positive or inverted. The TIME field is used to set or get the starting (or current)generation time. The time will start from zero by default. If the playback channel for the generator has a TRACK START TIME specified, the TIME field will be the timecode value corresponding to that relative position. If no track start time is given, the TIME timecode is the time generated at the front of the track. The DATE field is used to set or get a date field. This will be placed into the USERBITS field for SMPTE. The field will be validated to insure that it is a valid date. If the DATE and USERBITS parameter are both used and DATE occurs second, it will override the USERBITS value. The date value is initialized to zero by default, and is not automatically rolled over. The DAY field takes a Julian day number between 1 and 366. This will be inserted into the Julian day field for IRIG timecode. This value is automatically incremented when the time rolls over from 23:59:59 to 00:00:00. It will also automatically roll over from 366 to 1, but not from 365 to 1. The USERBITS field will place an arbitrary hexadecimal value into the SMPTE timecode user bits field. This will override any value set with the DATE parameter if it occurs after the DATE parameter. For IRIG timecode, the low 27 bits of the userbits value will be placed in the "control bits" field in the timecode value. The SPEED value can be used to tune timecode generation to match some external source that is running at the wrong speed. Normally pitch = 1.0, which is exact speed. A smaller value will slow down timecode generation and a larger value will speed it up. It is generally more practical to use the TRACK SPEED parameter on the generator channel than to use the SPEED parameter on the generator command. The RUNNING value will start or stop the generator. The generator is stopped initially, and can be started from the generator command or from a PLAY or RESUME command, possibly along with other playback channels that it will then track. 3) The annoying flutter of the VU meters with a constant signal level has been corrected. 4) The PLAY command will now start all tracks at the defined start point for each track. Previously it always erroneously started from the first sample of the wave file, regardless of the defined starting position. 5) Fixed a very rare crash that could happen if you were positioning into a wave file and closed the file at the same time. 6) There are now two timecode readers on channels OUT 1000 and OUT 1001. You can route signal from any input (or playback) channel to either of the timecode readers. Typically you would have an incoming SMPTE (or IRIG) timecode on an input channel, for instance from an external SMPTE generator or other source. However, you might have a click track or other canned show where the SMPTE source was a recorded track, so you can also route from a playback channel to the timecode readers. You should never route more than one source channel to any single reader. It is not illegal to route multiple channels, but doing so will degrade the timecode decoding if there is noise on the other channels. Obviously if more than one timecode source is fed to a single timecode reader at the same time, chaos will result, and in all probability the correct timecode values will not be read. The current timecode read by the first reader (channel O1000) is displayed on the debug monitor display for SoundMan-Server. The timecode from the second reader is not displayed. There are currently no options to set in the timecode readers. They decode the incoming timecode data, determine the general format, and then produce an output that can be used to synchronize playback channels and the timecode generators. NEVER lock a playback channel or timecode generator to a timecode reader if that channel is supplying the timecode to the reader! This will result in positive feedback, and the timecode will very quickly run off the tracks. 7) You can now lock a group of playback channels to a timecode reader. Note that the timecode generators are also considered to be playback channels, so you can lock the timecode generators to the timecode readers. You might do this to regenerate timecode, or to generate timecode of a different format slaved to incoming timecode. For instance, if you have 30 fps SMPTE coming in and you need to slave a projector to the timecode, you could generate 24fps SMPTE in one of the generators and lock that generator to the reader following the 30fps timecode. You lock the playback channels to a reader indirectly through one of the group channels. The group channel insures that all of the playback channels in the group will remain in sample-accurate sync while following timecode. If you locked individual channels to the timecode reader, the channels would follow the timecode within a fraction of one frame, but sample accuracy between the channels could not be guaranteed. The SET GROUP syntax has been extended to deal with timecode locking. The syntax now is: SET { G | GROUP } < nn > nn = group number 0 to 127 or group name NAME < alphanumeric group name > { CHANS | CHANNELS } < channel_list > CLEAR remove all channels { TC | TIMECODE } READER { channel number } LOCK SPEED { TIME | TC } < timecode > [ AT { TIME | TC } value ] UNLOCK Setting a group sets group properties. Group properties include the list of channels in the group, an arbitrary name for the group, and various timecode-following parameters. By grouping channels you can send many commands to the group that you would normally send to a list of channels. In that sense they are somewhat like a VCA on an analog mixer. You can also group playback channels that will play simultaneously to timecode. Here the group is more important, since it insures that all of the channels will remain exactly in sync as they follow the timecode variations. Examples SET GROUP G0 NAME BACKING_TRACKS CHANS P0-P7 SET G BACKING_TRACKS TC READER 1000 LOCK TC 01:00:00:00 PLAY GROUP BACKING_TRACKS SET GROUP G0 CHANS P0-P7 SET G0 TC READER 1000 LOCK TC 01:00:00:00 PLAY G0 Either of the two above sets do exactly the same thing. Another typical example might be: SET GROUP G0 CHANS P0-3 TC READER O1000 LOCK TC 1:0:0:0 AT 0 There are two ways you can lock to timecode: you can just follow the speed or rate at which the timecode is running, or you can lock to the actual timecode position. Sometimes it is sufficient to insure that a playback started at some random time will remain in sync with some other device, for instance a video playback. If the audio runs at the same speed as the video source the lock will be maintained over extended periods of time. If this is all that is required, you can do TC LOCK SPEED to insure that the playback and the timecode will run at the same rate. Note that the audio will NOT follow the timecode if the timecode value jumps, since only the speed of the timecode is being followed. If the timecode slows down the audio will slow down to match. More commonly it is necessary to lock the audio playback to a particular time relationship in the incoming timecode stream. If you do this and the audio channel is in playback mode, the audio will start and stop if the incoming timecode stops. If the timecode jumps, the audio will also jump to follow the timecode. If the timecode is arriving continuously but is showing the same frame value over and over, the audio will be frozen at the current time position. It will begin playing the instant the timecode begins moving. Audio will not follow timecode that is running backwards. For that matter the timecode reader will not follow backwards timecode. The timecode must be running in the forward direction to be recognized. (Stationary timecode must be presented with the bits in tor forward direction to be recognized.) Audio will speed up or slow down as necessary to remain as close to the current timecode value as possible. However, timecode, especially when generated by a mechanical source like a projector, can have a lot of wow and flutter. The timecode reader aggressively filters the timecode values to eliminate flutter and to reduce wow to the lowest possible levels consistent with remaining in sync with the timecode. Note that the audio pitch will change as the timecode speed changes. Thus if the timecode is shuttled forward, you would expect the audio playback to increase in frequency during the shuttle movement. (The audio will not currently follow a backwards shuttle.) If the timecode jumps, the audio will jump to follow it. Depending on the number of tracks being played and various other conditions, there may be a short silence while the audio files seek to the new position and re-lock to the timecode. Timecode jumps either forward or backward will be followed, as long as the timecode bits continue to run forward. When locking to timecode, you need to specify a timecode value for some position in the audio track. Typically you would specify the timecode value for the front of the track. However, it might be that the important timecode position is 12.71 seconds into the track. So that you don't have to convert 12.71 to frames at the current timecode rate and subtract that from the desired starting timecode, the group syntax lets you specify both the locking timecode value and where it appears in the track. In the example given above, the first sample of the track file occurs at one hour of timecode. However you could have specified LOCK TC 1:0:0:0 AT TIME 12.71; This would have made the one hour mark occur exactly 12.71 seconds into the track file. 8) The various bar graph displays would freeze when the interface was closed. This is now fixed and they update continuously. 9) The IO usage bar graph no longer hangs non-zero when nothing is playing. 10) There are now two timecode display lines, one for each timecode reader. 11) Commands have been implemented to get the current speed multiplier and pitch multiplier from a playback channel. These commands have the format GET {CHAN|CHANNEL} TRACK SPEED GET {CHAN|CHANNEL} TRACK PITCH The full implemented syntax for GET TRACK is GET {CHAN|CHANNEL} TRACK FILE # TRACK FILE "name" START|STOP|REPEAT # TRACK WORD ON|OFF NOTIFY ON|OFF TIME|TC # TRACK WORD TIME fpt | TC tc LOOP # TRACK WORD LOOP ON|OFF NOTIFY ON|OFF START|STOP|REPEAT TIME|TC # TRACK START|STOP TIME fpt | TC tc SPEED # current speed multiplier PITCH # current pitch multiplier POSITION # current position in samples TIME # current position in seconds LENGTH # track length in seconds STATUS # PLAY or STOP ******************************************************************************* Version 1.0.26 1) Changed the code that reads temporary dongle files to be more reliable. ******************************************************************************* Version 1.0.25 1) You can now copy/paste from the Response line in the control panel. 2) The window position is now saved in the registry rather than an ini file. 3) Added the dongle serial number to the About Box contents. 4) Changed copyright date to include 2008. 5) You can now copy and paste from the info panel in the About Box. 6) The operating mode indicator on the control panel is now reliable. 7) Changed the warning message when we can't set the desired sample rate from a popup to a log message. This keeps from screwing up programs that open SMS remotely. 8) All single-line responses except OK or ERROR should now be terminated by a semicolon to make parsing easier. The caller receiving a response can tell if it is single-line or multi-line by making some simple checks: a) If the first word is OK or ERROR it is a single-line response. b) If the response line ends with a semicolon it is a single-line response. c) In all other cases it is the first line of a multi-line response and the complete response will end with a line containing a single ".\r\n" in the first character position. Asynchronous responses (ones that are not the direct result of a preceding command being issued) are not yet implemented. However when they are, the first character of the first line of an async response will be an "@" character to flag the line as async. If it is a multi-line response only the first line will be flagged with an @ sign. It is expected that all async responses will be single line responses, but the program receiving one should check the rules given above to determine if the response is a single-line async response or the first line of a multi-line async response. All multi-line responses are guaranteed to be transmitted as a group. No other single or multi-line response will ever be mixed with another multi- line response. 9) If you try to open an audio file and request a track number that exceeds the number of tracks in the file, you now get an error message that clearly states the problem. Previously you got a generic "could not open file" error message, which was confusing since the file was in fact opened. 10) When closing the ASIO interface, we now lower the priority on thecallback thread first. This should prevent broken drivers locking up the entire system if they loop during the close attempt. However, SMS itself will probably still get locked up in this case and have to be killed and restarted. Better SMS than the entire system. 11) Added an extra half second delay in the process of closing an ASIO driver. The Maya driver takes a very long time to shut down the callback thread (which should have been complete when ASIOStop returned) and the callback thread would then die after the buffers had been freed. The extra delay gives the callback thread time to stop, and then close completes cleanly. 12) You can now give start, stop, loop, and repeat positions in samples as well as time. This can be handy for controlling programs that have accurate sample position info in the files being played. The sample positions are in terms of file sample rate, which may be different than the interface sample rate. The syntax for SET TRACK has been changed to add this new feature. The changed areas are: SET CHAN TRACK START SAMPLES TIME