Open davidlamhauge opened 4 years ago
The old behavior:
The situation where it might be useful is when you want to overlap sound files but not on the exact same position, either a frame before or after x. The alternative solution would be to lay out your sound files on multiple layers, which has no disadvantage, except taking up more space on the timeline. This logic also relates to how audio editing software like Audacity, Adour and the like handle their tracks.
We would need to write migration code, moving overlapped audio tracks to new layers or remove sound tracks with overlapping keyframes, forcing them to re-add their audio tracks, manually.
Personally I think that we could announce the change as a breaking change, making people adapt to the new logic, instead of us having to maintain such logic... my excuse is that we haven't reached 1.0 and therefore shouldn't be required to guarantee that new versions are compatible with the old. It's software in development, nothing is set in stone.
We would need to write migration code, moving overlapped audio tracks to new layers or remove sound tracks with overlapping keyframes, forcing them to re-add their audio tracks, manually.
We also could choose an easier way: 1) Prevent anyone to have overlapping sounds from next version. 2) Make a function that checks a file after it is opened. If it has overlapping sounds, then inform the user, that it is not supported, and advise them to move overlapping sounds to extra sound layers, if they want all their sounds to be played back.
Over time the problem will disappear.
We/I have started a discussion in a thread that is rather hidden, so I thought I would take it out in the open. The general idea behind keyframes, is used in the Bitmap and the Vector layer, where you add a keyframe every time you want to change your animation. If you animate the bouncing ball with 24 fps, you'll typically have 12 drawings/keys per second, and an empty key at last, when the ball leaves the camera view. In the timeline we'll see a key, an empty space, a key, an empty space, and so forth. One keyframe occupies one frame, and if a frame has no keyframe, then you'll see the content on the previous keyframe. Sound and Camera layers work differently: 1) In the Sound layer, sound files can overlap. A sound that lasts 2 seconds, will be taking up 48 frames at 24 fps. As it is now, sounds can overlap, so you can have a keyframe on frame 1, that covers frame 1-48, and another keyframe on frame 10 that covers frame 10-35, and so forth. It should not be allowed. Sounds should not be allowed to overlap, unless they are on separate layers. Furthermore I think we should at all times advice our users, to keep anything but lip sync sound files, away from Pencil2D. Audio work should be done in a video editor. (Lip sync sounds = dialogue and other sounds you need to know beforehand, to do your animation). But, no matter what, sound frames should not be able to overlap. 2) The Camera layer does not have keyframes for every change. You can have a keyframe on frame 1, and one on frame 100. If you have a camera movement between the two frames, there is an invisible calculation, that makes the camera move, but you can't see it on the timeline. There should be a keyframe for every frame that is affected. In the above example, it'll be frame 2-99, that should have a write-protected keyframe, with position, size etc.
I think it would improve user experience, if we were more consistent with keyframes. Especially the missing keyframes on the camera layer, has annoyed me for a while.