|
Subject:wierd paste bug - good luck isolating this one!
Posted by: Snappy
Date:7/11/2003 5:04:22 PM
let's see... what's a good word to start a bug report with? how about..... 'sometimes'? :P sometimes... when i copy a few bars of a track and paste it elsewhere, i will come back later to find that there are 'gaps' in the pasted section. this is a hard problem to track down, because i don't notice it until much later - in fact, i don't think i've *ever* caught this bug 'red-handed'. usually i notice it when i'm having a relaxed 'assessment listen' and notice there is a drum (or other) hit missing at a certain location. then upon closer inspection, i notice that the grid point where the hit should be is empty! but... the next grid point will still contain the tail of the decay of the missing hit. then, upon CLOSER inspection, i notice that it did this everywhere i pasted it! and SOMETIMES, when i zoom in on these troubled areas to touch them up, i might delete the orphaned tail, or delete a hit that overlaps another hit, and suddenly the MISSING hit (or a portion thereof) will re-appear. (IMPORTANT NOTE: this is NOT a video issue - when they are not showing, they are not playing!) ------------------------- to shed a bit of light, here are some details about my method: i often create drum patterns out of one-shots with separate tracks for kick, snare, cyms, etc. i usually start out working with 2 or 4 bars, then once i have a good 'seed', i copy and paste it out to 32 bars or so, to give me a little to work with and develop the rest of the song. when i create these patterns, 99% of the time, i use CTRL+paintbrush to drop drum hits on the grid with their full decay. the only time i don't use CTRL is when i'm trying to go for a 'special effect' of an intentionally short decay. while writing in this way, i'll most commonly be looking at grid divisions = 1/16th note. the vast majority of drum samples i am placing will be LONGER than 1/16th note (at the tempos i most commonly work at)), so there are many instances of a tail overlapping into the next hit. (i instinctively feel this paragraph is very relevant, because part of the 'evidence' left behind by this bug is the orphaned tails) also, sometimes while writing the initial bars, i will use the right-click of the paintbrush to trim out certain portions of certain hits. a general example off the top of my head - erasing the end of an 'open hh' which is followed by a 'closed hh', to simulate the pedal closing. (not sure if this right-click erasing is part of the cause of the problem, but included here FYI) also, i am pretty careful about placing my hits - i don't put in double hits on the same beat, or leave orphaned tails lying around when i am crafting the initial beat. ------------------------------------- to summarize: when i paste tracks containing overlapping one-shots, sometimes the paste contains gaps where a hit should have been pasted. hope the info i provided makes sense. (ask questions if not!) hope somebody else has run into this. (in the meantime, i am going to try to figure out how to reliably reproduce it) hope it can be fixed! (uh........... hope it can be fixed!) TIA! =) PS - not gonna send this one to support just yet... gonna try to reproduce it, + wait and see if anyone else has had this experience. AND, as always, if this bug has been resolved in a newer version, disregard this message (although i sure haven't seen it mentioned in the release notes!) ----------------------- Acid 4.0b 317 - WinXP Pro SP1 |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: groovewerx
Date:7/11/2003 5:11:50 PM
Parts are pasted to the end of segments. If the tail end of a loop you are copying does not stop at or extend to the next line on the grid, you will paste it to the end of the segment. Resulting in what you call a bug. |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: Iacobus
Date:7/12/2003 12:00:52 PM
I occasionally come across something similar, but only with chopped Loops, not One-shots. They simply just don't copy and paste as they should. It's very rare though. Iacobus |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: Snappy
Date:4/24/2004 1:53:15 AM
iacobus - i've seen it on loops too. it's not so rare when you do this kind of stuff often... ;-) groovewerks - u'r not even playing the same sport as me, let alone being in the ballpark. (resulting in what I call "a newbie") |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: Algorithm9
Date:4/25/2004 6:55:24 AM
Snappy - I also sequence primarily using one shots and I ran into the EXACT SAME problem as you. Large gaps for a certain number of measures and after that, sound where I didn't intend it, or the pattern I had drawn had been double and was off. I was using the common feature "select all on track" and copy, when I was just trying to copy one or two measures of work. I would paste at the appropriate time but later in the song i'd hear colliding beats. Slowly as I scoot over patterns that won't work or ones I want to use later in the track they'd get mixed in WITH the patterns I wanted to use and I'd never notice until I zoomed out and played a few times. This had only recently started happening when i got 4.0 because 3.0 didn't have the "select all on track" feature yet. Also you said you'd erase part of a one shot and a piece of another one was underneath it. That would happen also but it's important you get rid of the second layers because sometimes the sounds will be mute when you render it to another format. If thats not the problem try using "render to new track" instead of pasting one shots. It's alot quicker and if you duplicate the track and offset one of them on purpous you can get some pretty interesting results. |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: ATP
Date:4/25/2004 1:47:31 PM
i've noticed this too, here's usually how it happens for me. take a one shot sample, and paste it onto the grid. now, duplicate it and move it so that it partly overlaps the first event. everything will play as normal. now, set your cursor at the beginning of the second event (which overlaps the first partly), making sure the FIRST event is selected. Press S to cut the first event at that point. now the second event will dissappear entirely, to be replaced with the tail end of the first event. now here it comes ... when you delete the tail end of the first event, the second event miraculously reappears again! no idea what causes this, or even if it isn't unintended, but it could account for the "orphaned" files you speak of. |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: Snappy
Date:4/26/2004 10:35:07 PM
SWEET! When it comes to BUGS, corroboration is where it's AT, cats! Algorithm9 & ATP - nice detective work, both! Tech support are you listening? (I'll mail them the link to this thread.) I will have to try that offset trick.... ;-) |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: Sony_fshotwell
Date:4/27/2004 2:48:40 PM
I can explain the strange behavior that you're seeing in ATP's paste-select-split repro case (and I will in a minute), but I'm afraid it's going to be really really boring. Sorry! What ATP described is something that you'll only see happening with one-shots. One-shot events behave differently than all the other event types when it comes to overlapping. This goes all the way back to ACID 1, and the basic rules are as follows: - When two events overlap, the one which starts later is always on top. - When two events overlap, the one which starts earlier will be 'cut off' by the event on top of it. - The 'cutting off' of earlier events by later events is not a destructive thing -- if you slide the later event to the right, you'll see that the earlier event exposes more and more of itself, until it has exposed the entirety of its original length. You've noticed that one-shot events change length when the project tempo changes, but no other events do. This is because one-shot events store their length in 'absolute time' rather than 'music time' -- you want to hear the same amount of decay for your drum hits, regardless of project tempo. So if you increase the project tempo, it means you're moving along the timeline more quickly than before. One-shot have the same 'absolute time' duration, but this translates to a longer 'music time' length, and the events on the timeline are all drawn in 'music time'. Anyhow, the overlap rules for one-shots guarantee that whatever you do with the project tempo, the initial attack portions of one-shots are preserved, even if a project tempo increase makes earlier one-shots long enough to attempt to overlap and interfere with later one-shots. The rules are also designed so that in general, you can get 'retrigger' style playback when you over-lap events, but if you move events around, you don't have to go back and re-create the tails of events that you expose by removing the overlappers. So here's what's happening in the weird 'split at the overlap point' bug. (Pardon the ASCII graphics) under the hood we have: aaaaaaaaaaaaaaa bbbbbbbbbbbbbbbb on screen we see: aaaaaabbbbbbbbbbbbbbbb Then we split event a, creating a new event c: aaaaaa ccccccccc bbbbbbbbbbbbbbbb c and b have exactly the same start point, but event c gets 'grandfathered' ahead of b in the list, since it was previously attached to a which was previously first in line. And since c is first in the list, it completely overlaps & obscures event b. So we end up only showing c, and onscreen we get: aaaaaaccccccccc Not exactly intuitive, but then what would you expect to happen? Nothing? Event c splits off from a, and is immediately hidden behind event b? That probably makes more sense (but is not really useful in any way I can see). I'll look into whether this can be done without ugly repercussions. But the more important bug is whatever is going on when you're doing large copy/pastes of multiple events and aren't getting the results you expect. If you're pasting one-shot events over areas that already have events, then it's possible that the one-shot overlap rules are truncating event decays. But if you're working with loop events, then there has got to be something else going on. I've been hammering away and haven't seen anything suspicious yet, so any more clues would be great. Thanks, Frank Shotwell Software Design Engineer Sony Pictures Digital |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: ATP
Date:4/28/2004 9:48:08 AM
thanks for your detailed explanation, Frank. please note that i do not find this behaviour of one-shots annoying per say, but i know what to look for so that helps. :) after reading your explanation i can see why the behaviour is like this, it does seem to make the most sense. can't help with the loop problem as it has never occured to me yet. |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: Iacobus
Date:4/28/2004 12:21:08 PM
Hi Frank, Actually, I haven't seen the Loop event bug since I posted about it last July. Could it be video-related? (I've updated video drivers a couple times since then, as well as updated to the latest version of ACID Pro 4.0.) I'm having a hard time trying to repro, but if I see anything, I'll definitely let you know. Iacobus ------- RodelWorks - Original Music for the Unafraid mD's ACIDplanet Page Guitars 4 Kids |
|
Subject:RE: wierd paste bug - good luck isolating this one!
Reply by: Snappy
Date:5/20/2004 7:36:35 PM
Alright, I know how to reproduce this 'bug' now. I am sending a sample project + instructions to Product Support. ---------------------------- Frank said: Not exactly intuitive, but then what would you expect to happen? Nothing? Event c splits off from a, and is immediately hidden behind event b? That probably makes more sense (but is not really useful in any way I can see). I'll look into whether this can be done without ugly repercussions. ---------------------------- When I first read this, it made sense, but now that I have zeroed in on this situation and realize that cccccccccc is preventing bbbbbbb from being played, I think that 'Event c splits off from a, and is immediately hidden behind event b?' *IS* what should happen! But -- a factor to consider is that the original location will play as expected. The precedence re-ordering appears to happen only on a paste (or Duplicate Track). For this reason, also, I lean towards 'bug'. As for a fix: At least, a 'proper' sample should get layering precedence over the orphaned tails* -- the orphaned tails may still exist, but they should be given lower priority so the intended sound is heard. At best, the orphaned tails should automatically be deleted and never heard from again! *Although the tail may actually be a desired event in rare cases, I think it's far more likely that the event that actually *begins* at that tick is the sound the artist desires to be heard. The layering/overlap precendence logic should reflect this. Also, I wonder ... can saving a file with tracks in this state, with multiple one-shots layered over each other, could lead to the corrupted save files I occasionally see in Acid, which I think *might* be related to undo-ing and re-doing multiple steps (then saving) in situations like this. If so, all the more reason to fix this! If not, then that's a bug for another day! ;-) |