I am seeing some anomalies in Vixen 3.9

[ChiefWarrant]

I have been toying with Vixen 3.9 (both the 32bit & 64Bit builds) and have noted a couple of potential issues. I am not certain if it is just my system or if others are seeing these also.

• When I start playing a sequence from the beginning, an audible noise spike of about than 0.1 seconds long can be heard. When I roll back to Vixen 3.8 (Build #1045), this noise is not heard. This spike does not appear in the wave bar at the top of the sequence.

• While going through some sequences I created in Vixen 3.8, it appeared to me that the timing was slightly off in the display preview, by about 0.1 seconds. If i shift everything in the sequence 0.1 seconds to the left, everything looks good. This is in both the default and the OpenGL previews.

• All the effects are still lined up to the beat mark collection, however all the elements appear to fire about 0.1 seconds too late. I tried re-associating the audio and regenerating the marks, but did not get a change in the status.

• When I rolled back to Vixen 3.8, I initially encountered problems opening “.tim” files that had been opened in 3.9. I suspect this had something to do with profile changes I made while test-driving Vixen 3.9. When I restored my backup data, containing the old profile data, opening the 3.9 file was no longer an issue. I guess that is a testament to backing up your data before upgrading.

Has anyone else seen/heard this in 3.9?

Note: I also have "Vixen-BetaBuild-VIX-2310-1" loaded in a different directory. Could this be causing the “issues” I am seeing?

-Tony

[RichieNorthcott]

Good spot. I have both version like you (3.9 and am testing the Beta release, but I think the Beta version is treated as a completely separate installation) - I see / hear the same. Definitely a little audio glitch at the beginning of existing sequences. Also, making a new sequence in 3.9 with audio only (no effects), I get the same audio glitch issue.

I don't have my display hooked up (hey, it is September), but agree the on-screen preview looks a little out of sync. I played one of my sequences with super-tight timing marks back at very slow speed, I agree the audio seems slightly ahead of the preview graphic. I assume the preview graphic represents what's being output data-wise at that point in time, but don't have anything connected to confirm.

I'm not using OpenGL in my case.

I'm also finding the 'back to start' button unreliable

I also bumped into the audio->speed/tempo option which I've not come across before, which seems to switch how the audio plays back if not at 100% speed - i.e. whether it pitch shifts or not. Nice Personally I prefer the 'off' mode which is equivalent to speeding up / slowing down a tape/vinyl playback.

[ChiefWarrant]

I'm also finding the 'back to start' button unreliable

I thought that was me just missing the button when I clicked it.

For the developers, I would like to also note that I am using wired headphones, because I know that wireless headphones can sometime cause and audio delay.

-Tony

[jchuchla]

We changed the underlying audio engine this year. The old engine was very out of date and no longer supported. I'm not too surprised to see an audio bug or two pop up. Though i am surprised it's hitting both of you this quickly. There were some initial timing issues observed in the dev build cycle, but we thought we got it cleaned up before release. (sample rounding errors) Evidentially there's still more to fix.

Since both of you are testing the moving head build, it's worth mentioning a few other version related details. There was a note in my email about using a copy of your profile for testing the new build. This copy should only be used in the new build. That includes the sequences too. If you use the release (or older version) to open the profile or sequences that has been used in the mover build, you'll lose all work related to the movers. The effects and other data structures related to the movers don't exist in the release code, so when vixen opens the files, it doesn't know what to do with that data and just discards it. When it saves the profile, or sequences, only the data that that particular version knows about will be saved. In other words, don't use the same profile and sequences in different versions, especially backwards. You will lose data. Consider the 3.9 release or anything in the main dev build branch to be "older" than the mover build until the mover branch is merged into the mainline.

Question about the back to start. Is it unreliable while the sequence is playing, or while it's stopped, or both?

[jchuchla]

I also bumped into the audio->speed/tempo option which I've not come across before, which seems to switch how the audio plays back if not at 100% speed - i.e. whether it pitch shifts or not. Nice Personally I prefer the 'off' mode which is equivalent to speeding up / slowing down a tape/vinyl playback.

This is a feature that the new audio engine gives us. We wanted to include it to give you more options. The speed option mimics the old behavior with chipmunk/monster sounding voices as you speed/slow the sound. The tempo option attempts to speed/slow the playback without affecting the pitch of the sound. If you go to slow, it'll get glitchy, but we found that even when it's glitchy at really slow speeds, it can still be useful for sequencing, so we left it.

[RichieNorthcott]

I think the play from start button issue might be a red herring - if you hit play then pause (F5-F5) the button doesn't work (maybe the button should be disabled while in this state?). But after pressing stop (F8) it seems okay. Stop actually can return to the start anyway, depending on if you have set a playback region on the timeline.

I made a new profile under 3.9, then added an audio file on a blank sequence. The playback glitch isn't there on first playback, but it's there on every subsequent playback, using F5 and F8 to control. It's maybe a previous playback buffer not being cleared? Starting the timeline part way through (by defining a 'start' position) the audio will glitch sometimes, sometimes not. it seems to depend on where you are at time-wise - a bit like a video file has GOPs - some areas seem sensitive to the glitch, others not.

Zooming in on the audio vs some of the marks on my existing timelines (3.8 sequences in 3.9) I agree the timing is out by IRO 150ms in 3.9. If the audio file playback was delayed by this amount everything would be in about the right place.

Also - one of my 3.8 sequences references a WAV file rather than MP3, which used to work fine. Opening in 3.9 causes a Vixen crash. Not a showstopper, but just a FYI. If adding a new file, you can select WAV type, but likewise this causes Vixen to quit.

Re the movers testing, i haven't been trying to add to old sequences/display setups. All my testing has been on new profiles made under 3.9. I haven't got onto trying to re-engineer my old sequences with movers to use the new functionality.

[RichieNorthcott]

More info....

The audio glitch is definitely the data from 'previous' playback. I have an audio file with a few seconds of silence at the beginning. F5-F8 in this region, no issues. Once there is sound, on 'next' playback you here a glitched version of the previous data when starting. I'm not sure this is related to the timing issue (150ms), that's possibly something else.

[dirknerkle]

I'm not sure whether this might be an issue, but Windows sometimes keeps data in a cache and if you're going back and forth, starting/stopping, etc. I can see how Windows might get in its own way. You might explore turning off the Windows cache to see whether that makes a difference.

[RichieNorthcott]

Example of timing issue.... I took this from my 3.8 'Sleigh Ride' sequence - the mark was aligned tightly on the 'whip' sound at the end of the track.
timing.png

[Popo-B-Trippin]

I also noticed the timing was off when playing at full speed. As I sequence my singing facing the old school way, I usually run it at 50% speed to sequence it. While at that speed everything was dead on, however, when I went to full speed, the mouth movements were off a touch. I found I needed to move all the mouth movements over to the left 3 clicks and then it was good.

I didn't mention it during testing as I just recently started sequencing the singing face parts for this year. I didn't really notice an issue with the other elements.