KNOWN ISSUES

3.0 ISSUES
Item Reported
Platform(s) 		Sympton(s) Explanation

Work-Around

UNWARN BAR deletes adjacent STOP in hitter

All

   Just a dumb bug - a failure to account for an hour rollover during preroll when CHASE is ON.  This problem does not occur where there is no hour rollover in the preroll. This issue has been resolved and the fix will appear in the next incremental release.  

Cueline 1M1 'FREE' display not refreshed when STOP en- countered in HITTER

All

   Just a dumb bug - a failure to account for an hour rollover during preroll when CHASE is ON.  This problem does not occur where there is no hour rollover in the preroll. This issue has been resolved and the fix will appear in the next incremental release.  

Hour setting for STOP in HITTER not recognized

All

   Just a dumb bug - a failure to account for an hour rollover during preroll when CHASE is ON.  This problem does not occur where there is no hour rollover in the preroll. This issue has been resolved and the fix will appear in the next incremental release.  

Junk Characters in TEXT SAVE (export) file

All

 A string of characters in the form of something like ^@ @W@@UFUUU?{Gzt? X@... appears either at the end of the last line or the end of the 2nd (bar 1) line of a text file (.QOX) created when TEXT SAVE is set to ON.   The software failed to account for the circumstance where either the START STREAMER or the STOP STREAMER was set to OFF screwing up a pointer to what should have been streamer color text (GREEN, RED, etc.).  This has been repaired for the next incremental release. To avoid the problem meantime, leave the START and STOP STREAMERs ON when creating a .QOX export text file.

BETA 2.g3 ISSUES
Struck text indicates items corrected with 3.0
Item Reported
Platform(s) 		Sympton(s) Explanation

Work-Around

Warning & Start Streamer Misfiring

All

 During a CLICK CUE ON SMPTE, if the start (SMPTE address in bar 1) is around 00:00:10:xx, the warning streamer fires but no countoff clicks are heard. However, clix do commence correctly on the downbeat as do all streamers set to occur thereafter. Just a dumb bug - a failure to account for an hour rollover during preroll when CHASE is ON.  This problem does not occur where there is no hour rollover in the preroll. This issue has been resolved and the fix will appear in the next incremental release. For the offending cue either (1) enter CHASE OFF; or (2),  specify bar 1 of the start bar (e.g., CLICK CUE ON SMPTE FROM BAR 1); or (3), using CHANGE SMPTE START TO, set the hour in the  SMPTE start address (e.g., if the start is 00:10:07 in reel 4 then CHANGE SMPTE START TO 04:00:10:07). 
TEMPO RECORDs OmniBook
Only!		 When any of the Auricle's tap tempo functions (viz., TEMPO RECORD [on key] or TEMPO RECORD ON SMPTE] is commenced, the established countoff into the starting bar is inaccurate - each click of the countoff is 64 milliseconds faster than should be, regardless of the stated tempo value. 64 milliseconds doesn't sound like much, but it is quite noticeable the faster the click. This seems to be an OmniBook hardware idiosyncrasy. We are still testing, but this problem persists on the OmniBook even  when loaded with other OS's of differing manufacturers. And this problem is not repeatable on other popular hardware platforms (.e.g., C1, Toshibas, etc.).   None now known This issue has been worked around in software which will appear in the next incremental release.

SLOPE FROM BAR

All

 Data is corrupted or the system crashes or locks after a the execution of a SLOPE FROM BAR where and if and only if one or more bars within the range specified are CIRCLEd. Just a dumb bug yet to be analyzed thoroughly. At the moment it appears that the routine(s) that handle SLOPE FROM BAR are posting to tempi fields in the circled bars when the routine(s) should not. SLOPE FROM BEAT is not affected by this bug. Use SLOPE FROM BEAT instead of SLOPE FROM BAR when you are performing a slope over a range of bars containing CIRCLEd bars until this bug is fixed. SLOPE FROM BAR seems to be working just fine if there are no CIRCLEd bars within the intended range. 

1M1
Bar/Beat
Counter

All

 When/after performing a CLICK CUE, the 1M1 video beat/bar counter does not show the bar/beat of the last click heard when clix were stopped either because (1) a STOP [address] in the HITTER was encountered; or (2,) an ESC key abort was executed.  Just a dumb bug. This issue has been resolved and the fix will appear in the next incremental release. None now known. 
RECOVER COUNTOFF All

The countoff recovered when using RECOVER COUNTOFF is the countoff for the last cue saved and not for the last cue loaded.  

Failure to "load" the  RECOVER COUNTOFF buffer upon a load cue. 

None now known. This issue has been resolved and the fix will appear in the next incremental release.
Click Tracks T3200
Only!

The click heard at  the STOP BAR seems ever so slightly later than it should be heard even though the system reports the tempo to be  unchanging.. 

In the interrupt service routines that manage the clicks a short delay loop was found in the transmit handler for the last note off. This delay inadvertently also stalled the transmission of the last click.  Why this problem can only be repeated in 3200's will forever be a mystery; for,  repair in the next beta was easier and therefore more economical than an academic diagnosis!

If you are not using a 3200, don't worry about this. Otherwise note that the delay  may be noticeable and therefore annoying only in a few circumstances. When you find this troublesome, if you wish you can always just TACET the STOP BAR... ALL numbers (timings) are still perfectly accurate as is the location of the STOP STREAMER!

BETA 2.f3 ISSUES
Struck text indicates items corrected with Beta 2.g3
Item Reported
Platform(s) 		Sympton(s) Explanation

Work-Around
SMPTE capture Omnibooks After time code has been captured during a CLICK CUE ON SMPTE you strike the ESC key a couple or more times to abort the read; then, while the same time code stream is still running you execute another CLICK CUE ON SMPTE and the Time Processor fails to recapture or see the running code.    ESC key breakouts are failing to shut down the read routines at the hardware level so that a re-read operation is not properly initialized while time code is still coming in. There does not appear to be any problem recapturing after time code has been stopped and restarted. Stop then restart the TC source to the Time Processor.  Also a READ SMPTE operation appears to reset the SMPTE reading hardware.
Hooks All  After HOOKing a numeric key (1-0 across the top of the QWERTY keyboard, pressing CTRL and the hooked numeric key does not execute the command hooked "HOOKED NOT RECOGNIZED"). However, a verbal HOOK command for that same numeric key does work.  Adding the NUM lock functions to the present version along with certain variations to better accommodate  notebook keyboards, resulted in this anomaly. None now known. So, avoid HOOKing to numeric keys until this is repaired in the next beta.

SMPTE Generation

 All  An abort/ESC after starting CLICK CUE ON SMPTE (generation) done before the first click of cue does not result in a recycling for recapture or regeneration preventing a "burst" maneuver to pre-locate listening devices.  A design thing. None now known. Rewrite required.
Hit Capture  All Once a CAPTURE SMPTE HIT was terminated, a HITTER sort is not being executed even though AUTO HITTER SORT is ON. A bug.  None now know. Rewrite required.
Hitter Display  All The owner performs a DELETE HIT or STREAMER HIT or like operation with the HITTER window showing and that window does not show any change. This is intermittent. The HITTER window is not "refreshing" after some hit related operations. Those operations are still properly executed, however.  Until this problem is repaired, enter AUTO HITTER SORT ON in to the Auricle. This will force the Auricle to sort the hits in hits' memory after each hit related command and then  refresh the HITTER window automatically.
Save Cue All When performing a SAVE or RESAVE CUE the message plane does not always report the correct name of the cue file being saved. This is a bug that insinuated itself  when the ACTION CHECKING function was added to this version. This is cosmetic only and has no deleterious effects. None. Ignore it.
SMPTE Lock C1
Only 		While a CLICK CUE ON SMPTE is in progress with TRUE LOCK set to ON, the operator calls up a map or other window and the system looses lock. Some operation associated with the display routines in C1 memory of as yet unknown origin is stepping on or corrupting the chase lock data structure. 1) Do not perform any display operations during a CLICK CUE ON SMPTE; or 2) enter SPOT LOCK into the Auricle (but not if you have to do any subsequent inserts in the same cue).
Chase C1
Only 		During a CLICK CUE ON SMPTE operation with CHASE ON, and where the time code coming in is after bar 1, the C1 intermittently has trouble finding and grabbing internal start bars. The chase routines have been rewritten for this version. It has yet to be amended to account for the much slower CPU speed of the C1. Exhibition of this problem may vary depending on your tempo value in the area of the chase. Until this issue is handled, and when and if you run into this problem, use the CLICK CUE ON SMPTE FROM BAR operation for pickups or inserts.

 

Last Edited/Amended 
The End Graphic