Simulating first note bug

[mr]

Can the program introduce a -60 ms artificial gap to avoid the problem?

[bk]

Unfortunately, a 60 mS delay would make it almost impossible to play guitar through an amp sim, or play a soft synth in time.

edit: Oh, I think maybe you mean a single 60mS at start and not a 60mS delay throughout. Seems reasonable to me, but I really have no idea what all has to happen when you start a sequence.

[jules]

Thanks folks! Much appreciated.

@bk: I tried your archive, but it played fine regardless of what audio buffer sizes I tried (!)

However, I do have a theory:

Ok.. the midi clips in your archive were set to quantise to 1/4 beat.. If I drag the offset of the entire midi clip backwards slightly, (i.e. to slide all the notes to the left), then the first note's "real" position can be moved so that the note is entirely off beyond the left of the clip.. but because it's getting quantised, the note is still shown on-screen being snapped into place and looks like it's still at 0:00. When I do that, then it does fail to play it, presumably because the note is getting clipped before it gets quantised.. I'm not sure if that's the same thing you're seeing, but it's the only actual bug I could manage to make happen here!

[skipkent]

I've never gotten this bug in normal usage, but I just took a few minutes to try to recreate it, and had no problems doing so.

If the first note is short, it causes this problem. Increasing the tempo allowed longer notes to cause the problem. Using T3 and it's built-in sampler, first notes of less than about 54 ticks (at tempo=60) would cause the problem. Longer than 54 ticks played ok. Doubling the tempo allowed notes twice as long to cause the issue.
Also, it would appear that Loop must be turned on for this to occur.
edit:I used 256 sample buffers for these tests.

Here's a simple T3 archive that exhibits the issue pretty clearly:

https://dl.dropbox.com/u/1725539/first% ... 01.trkarch

Simple "C" scale using a short sine wave sample and T's own sampler.
Track 1 exhibits the problem. Track 2 does not.

edit: I should have mentioned that the first note must occur on the very first beat as well. (edit: this is incorrect, see my post below.)
Also, I'm using T3 3048 on WinXP SP3. Just imported the archive to my other T3 machine and it performed exactly like the one the file was created on.

That is an outstandingly thorough bug report. Kudos.

[bk]

@bk: I tried your archive, but it played fine regardless of what audio buffer sizes I tried (!)

That's weird. No wonder it's been such a tough bug.

About your quantize idea: I just turned off quantize (which actually left the notes in the same place because I had dragged them into position by hand), and varied the offset. On my machines, as soon as the note gets short enough, it ceases to play. At 256 sample buffer, I only had to offset track 2 by 7 ticks to make the note stop playing.

I have no idea if this is relevant, just throwing it out there!

As I said in the beginning: I never run into this bug in normal usage. ModuLR would be the guy with the most info on this bug. Hell, he wrote a plugin to alleviate it!

[bk]

That is an outstandingly thorough bug report. Kudos.

Thanks! Unfortunately, Jules still can't duplicate it!

[skipkent]

I seem to recall running into this issue frequently when rewiring Reason into Tracktion as the host (sequencing in Reason, playback through T, as well as sometimes sequencing Reason from Tracktion).

If I'm not mistaken, and I almost always am, I often had to start the Reason portion a bar or two forward of the timeline start in order to pick up the first notes. No time to repro now, but I do recall having issues with the first note occurring on the first beat of the first measure. My workaround was usually to move everything forward a bit to give T a chance to 'ramp up'.

[skipkent]

Thanks! Unfortunately, Jules still can't duplicate it!

Just the fact that he's trying is a total head-spinner!



Feels like I'm a spry, young...38...again.

[bk]

I seem to recall running into this issue frequently when rewiring Reason into Tracktion as the host..

Yeah. Mod commented earlier that there was a separate rewire bug that had the same symptom.

[bk]

I'd be interested to know who tried my archive, and how it performed for them. I know at least one other person had essentially the same results, yet Jules couldn't duplicate it.

[jules]

I'd be interested to know who tried my archive, and how it performed for them. I know at least one other person had essentially the same results, yet Jules couldn't duplicate it.

It's very odd, because apart from the audio buffer size, there's nothing else in your edit that should change on different machines. (...of course, the version that I'm running here is probably <ahem> somewhat different from yours, so in fact it could have been fixed indirectly already..)

[skipkent]

Different?

Version?

Wha???



How many sleeps 'til NAMM again?

[bk]

I'd be interested to know who tried my archive, and how it performed for them. I know at least one other person had essentially the same results, yet Jules couldn't duplicate it.

It's very odd, because apart from the audio buffer size, there's nothing else in your edit that should change on different machines. (...of course, the version that I'm running here is probably <ahem> somewhat different from yours, so in fact it could have been fixed indirectly already..)

I could, uhmm, test that theory for you on my machine!

[mcnelson]

I'd be interested to know who tried my archive, and how it performed for them. I know at least one other person had essentially the same results, yet Jules couldn't duplicate it.

It's very odd, because apart from the audio buffer size, there's nothing else in your edit that should change on different machines. (...of course, the version that I'm running here is probably <ahem> somewhat different from yours, so in fact it could have been fixed indirectly already..)

jules, you are such a tease.

[ModuLR]

sneaky!