Hello Editsuite.com friends,

Due to tons of abuse, we now require that you request user access by sending us your Login, Name, Email Address, Phone Number, and Profession by submitting that info HERE.  I'll review your request and try to get back to you within the week.  You can't imagine how many folk want to trash forums with bogas advertising. 

Also, please help us gain enough Facebook "Likes" to have a custom Facebook URL!  

--Gary Lieberman

Recall or Run causes transition stutter

1 reply [Last post]
Sat, 04/07/2007 - 11:52
mtiffee
User offline. Last seen 14 years 48 weeks ago. Offline
Joined: 19 Aug 2005

In the past, I've noticed that sometimes a dissolve will stutter during the show. I finally sat down and recreated this. Surely others have seen this before but I don't remember any discussion on it here. Here's what I found:
On the Kalypso, when performing an EMEM recall on any ME or when hitting the "RUN" button while performing a transition using a fader bar on any ME, the transition seems to pause for a few frames at the instance of the recall or run then jump to the current fader bar position. You can really see this when manually performing a wipe but it happens with either a wipe or mix. It does not occur when performing an auto-trans.
Any ideas why? I can only think that hitting the run button or recalling an emem sends traffic down the network that interrupts the digipot data being sent to the frame but that seems odd. Aren't EMEMS stored on the frame?

Top
Sat, 04/07/2007 - 21:56
#1
Bob Ennis
User offline. Last seen 5 years 16 weeks ago. Offline
Joined: 24 Aug 2005
I remember seeing this, too. While it is certainly possible that network traffic could clog up the command stream - I've been to a number of places where this has happened - it may also have something to do with the duty cycle of the frame. The following would be my take on what might be happening, based on my testing days at GV: As I recall having things explained to me by various software engineers, source switching and transition commands are at the upper portion of the priority list of the frame...we all know that the frame is constantly splitting its attention trying to process a myriad of commands and manage a lot of data, lots more than just the commands that we as users initiate. What seems to happen right around each new software release (and I'm not singling out the Kalypso - I've seen other products with this problem) is what I call the "bucket syndrome". Software is written to fulfill the requirements of the currently implemented tasks. However, what often happens is that the software is written in such a way as to use up close to the maximum amount of available memory (filling the bucket). When new features are added, the new software often exceeds the amount of available memory (overflowing the bucket). This would cause things like transitions to "bog down" the frame (depending on what else it is doing at the time). So to fix things like this, the entire code base must be compressed or re-complied in a way to make room for the new commands that were not factored in in previous versions and thus keeping the "bucket" from getting so full that the system locks up. This "compression" can create "hiccups" in performing such things as transitions or show up as a delayed source switch long after you've pressed the crosspoint button. Now, I could be "full of prunes" on this explanation (if so, I'm sure that someone from GV will have no hesitation about pointing out how wrong I am), but it's what I remember being told by the software mavens. I'd suggest submitting this to GV customer service. Something like a transition causing the system to stutter would be a pretty big deal & I'm sure that they would get working on it right away once they knew about it.

Bob Ennis

Top