|
|
I second that, but can elaborate a bit on the 'fixing'. It appears that a muted clip can be unmuted by changing/moving the crossfades a bit. I am not convinced that it has something to do with the length of the crossfade, but rather some mess-up in the order of the clips/crossfades. Note, that the moving of the crossfade often results in the other clip (the clip crossfading in to/out of) being muted instead, thus propagating until a silent zone is encountered in the playlist. The said fix of saving and reopening of the project has not worked for me. Also I can report older projects (projects made with Ardour 2.5) suddenly spawned a lot of these crossfade mutes. |
|
|
this bug still happens in 2.8 it seems to happen sometimes when a region (1) overlaps a following region (2) and region (1) is on a higher layer. I also experienced the bug at region overlaps without a crossfade in between. |
|
|
I can't reproduce this with current SVN. Is it still a problem? If so, can you note which option in the "Options>Layering" mode is active when you are setting the bug up? |
|
|
carl, its still a bug. someone on IRC got sort of close to a recipe, but never posted it here. |
|
|
fixed in 2.0-ongoing (rev 7114) and will be in a soon-to-come 3.0 commit as well. feedback would be appreciated. |
|
|
I tried to load one of my old sessions, that didn't have these mutes when I originally created them (with version 2.1 I think). And I'm afraid the bug is still there. I tried to change the layering method, without any luck. I tried to move the muted region to the top layer, and that seemed to work. But regardless of layers... I still think that two regions cross-faded together should be played, both of them. I'll be happy to supply the session file, but it is rather large, so I will only do so upon request. |
|
|
the mutes are not "in" the session. they are caused by a bug in deciding which regions need to be read during playback. the bug is semi-random (or will appear that way to the user) since it depends on where on timeline disk i/o takes place, which in turn depends on where you start playback from. i have to say that i am pretty skeptical that the bug still exists, but i've been wrong about such things before. i know the code in 2.5 that started causing it, was able to replicate the bug fairly reliably, understood what was wrong, and fixed that. i may have missed another related case. could you attach a screenshot of a relevant section of your session in which the unintended mute sometimes (or always) happens? thanks. |
|
2010-05-27 18:48
|
mutebug.png (40,001 bytes) |
|
|
Here you go. The muted regions are the ones I have selected. |
|
|
please confirm the information in the "About" box. your screenshot is specifically the case that i was testing and fixed. |
|
|
I am deeply sorry. I have discovered and old 2.8.2 version on my system, and that one was the one in my path. I have now tested it with the correct svn version, and it works like a charm. |
|
|
see notes. |
|
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
- Anonymous
