Tracktion Engine

[dRowAudio]

Can't remember where I read it - possible in the JUCE forum - but I gather the graphics are separate from the engine and not part of the open source information.

I'd expect that, but I would hope that the engine is linked into Waveform as a shared library so that Waveform can be used with a self-compiled engine version. That would allow engine debugging inside Waveform, but it's fiddly to do that and stay cross-platform.

No, we statically link the Engine in to Waveform, it's much easier and more efficient that way.

I'm not going to create a new DAW using the Tracktion Engine, but it would be nice to be able to fix some of the bugs that are in the engine itself via Waveform that have done my head in for ages.

Can you elaborate on which specific bugs you're referring to? We might have fixed them already or they might be in the app code.

[Karbon L. Forms]

When can we write our own devices that show up in the properties area?

Is there a strong demand for this? Would it not be easier to simply write a plugin?

Well yeah, but I was thinking of more access to the TW project internals. So, maybe access to an actual Clip on a Track, as opposed to a buffers worth of timestamped midi if running or clumsy d&d transfer. I've not really thought it through.

[gavindi]

I've taken the liberty to post to r/opensource on Reddit about this: https://www.reddit.com/r/opensource/com ... _now_open/

It's good to let the people know.

I've started sniffing around the code myself to get a sense of the object model and design approach you guys have taken. I must say, it looks very clean and straight forward.

[fromwithin]

Can you elaborate on which specific bugs you're referring to? We might have fixed them already or they might be in the app code.

There are still issues with duplicate notes at the very start of a track, there is no deterministic ordering with Control Changes , Program Changes and notes (i.e. no guarantee that a bank change will be sent before a program change, nor that a program change will be sent before any non-bank-change CC at the same timestamp, and weird ordering when notes are also at the same time), but the worst one is that doing a simple split of an audio file into two clips causes a click at the split point. This is an absolute fundamental issue that has been there since the engine replacement in T4/T5. I submitted a very detailed report last April about this with the following (this forum won't let me attach the file mentioned in the info):

Looking at the rendered clip in a sample editor shows that the start and end of each clip is having the first and last samples set to zero. It causes clicking at split points that really shouldn't be there. The only way to stop it clicking is to overlap the clips and put a fade at the start and end, which is extremely laborious.

I've had a detailed look and it looks to me that in the buffer frame where the split occurs, that frame is also delayed by 2 samples, which are then claimed back when it gets to the next frame.

At the start of the buffer, it repeats the last 2 samples of the previous frame and then skips two samples from the end of the current frame. I've done a comparison between the original and rendered clips by inverting one of them and mixing it on top of the other. You can clearly (Phase cancellation.wav) see where the erroneous buffer starts (sample 91392) and ends (sample 91648). My audio settings are indeed set to have a buffer size of 256 samples, which matches the data in the attached wav.

In summary:
* When a clip is split, the rendering frame in which the split occurs repeats the last 2 samples from the previous frame and continues on with a 2-sample offset.
* It sets the last value of the first clip and the first value of the second clip to zero.
* It then skips 2 samples at the end of the rendering frame.

[Watchful]

There...is no deterministic ordering with Control Changes , Program Changes and notes (i.e. no guarantee that a bank change will be sent before a program change, nor that a program change will be sent before any non-bank-change CC at the same timestamp...

I wouldn't call this a bug but it is an annoyance, especially with hardware synths that depend on MSB and LSB codes. Not sure why this wasn't addressed far earlier in the application's history. MIDI sequencers in the 1980s featured user-ordered control sequences.

[HansP]

( I loved CLAB Notator, it had its own data structure and very intelligent pattern and loop mechanisms. You could tell it to repeat a pattern e.g. 4 times and for the last time extend the pattern into the next pattern, replacing its data for this bar in the song. This means the length, start and end of the pattern could be different for the first and the last repeat. You could reuse patterns in the song, and switch off and on instruments depending on location. You did never lose time with copying midi data and re-doing edits. It was kind of object-oriented on arrangement-, track-, loop-, patch- and instrument levels, including the idea of inheritance.)

[chico.co.uk]

the worst one is that doing a simple split of an audio file into two clips causes a click at the split point. This is an absolute fundamental issue that has been there since the engine replacement in T4/T5. I submitted a very detailed report last April about this with the following (this forum won't let me attach the file mentioned in the info):

Looking at the rendered clip in a sample editor shows that the start and end of each clip is having the first and last samples set to zero. It causes clicking at split points that really shouldn't be there. The only way to stop it clicking is to overlap the clips and put a fade at the start and end, which is extremely laborious.

I've had a detailed look and it looks to me that in the buffer frame where the split occurs, that frame is also delayed by 2 samples, which are then claimed back when it gets to the next frame.

At the start of the buffer, it repeats the last 2 samples of the previous frame and then skips two samples from the end of the current frame. I've done a comparison between the original and rendered clips by inverting one of them and mixing it on top of the other. You can clearly (Phase cancellation.wav) see where the erroneous buffer starts (sample 91392) and ends (sample 91648). My audio settings are indeed set to have a buffer size of 256 samples, which matches the data in the attached wav.

In summary:
* When a clip is split, the rendering frame in which the split occurs repeats the last 2 samples from the previous frame and continues on with a 2-sample offset.
* It sets the last value of the first clip and the first value of the second clip to zero.
* It then skips 2 samples at the end of the rendering frame.

This is interesting, just trying to replicate it on my own windows laptop. I've never noticed a click when I split an audio clip (you mean with the / shortcut key, right?)

Is there more to this than just splitting the clip? Do you need to render it to new audio files as well or something? Because I can't hear any click, after splitting a simple mono audio clip, and if I split it on a peak, there doesn't appear to be a zero either at the end of the first clip or start of the second.

What did you use as a sample editor, to look at this, and I'll have a look on my machine, see if it does it here too. My buffer setting is currently 512 samples (10.7 ms), so i'd think it should be audible, from the way you've described this ...

I'm not doubting you've got this issue, just trying to cause it to happen on my laptop too

[gavindi]

Fwiw, I split samples in W8 now W9 all the time and I have no issues like that. If a bug isn't consistent then it's going to be very difficult to fix.

[dRowAudio]

Are you splitting a compressed audio file? Like an MP3 or similar? If so, they don't have sample accurate sync so probably won't be able to be split like this.

[fromwithin]

About deterministic ordering:

I wouldn't call this a bug but it is an annoyance, especially with hardware synths that depend on MSB and LSB codes. Not sure why this wasn't addressed far earlier in the application's history. MIDI sequencers in the 1980s featured user-ordered control sequences.

I agree that the MIDI specification is effectively at fault here, but the fact is that Tracktion has no event editor, so it's simply not possible to correctly order things manually without it being very laborious indeed.

Are you splitting a compressed audio file? Like an MP3 or similar? If so, they don't have sample accurate sync so probably won't be able to be split like this.

Nope. I never deal with compressed audio. I'll do you a video.

[fromwithin]

Here's a video showing it occurring.

Here are the steps.

• Create a sine wave in Synth1 (or anything else).
• Play it back over a few measures.
• Render out the MIDI clip that plays the sine wave
• Split the rendered clip every beat
• Enjoy the horrendous clicking when you play it
• Render out the track that has the split render
• Listen and look at the data that was just rendered out
• Cry some more at the insane number of hours wasted over the past years from splitting up guitar recordings by bar and having to do manual crossfades every bar when piecing things back together.
  
  It's just so blatant that I can't believe that no-one else has struggled with it. You can see from how I recreate it that it can't be anything to do with my setup. It does the same thing on my laptop and desktop, and always has. If this is not an engine bug, I'll drink a glass of my girlfriend's horrible health drink.
  
  Please fix it. Or let me fix it myself; I've been doing C++ and audio programming for 20 years.

[chico.co.uk]

[EDIT]
I've tested this on my laptop here, and I'm seeing the same problem.

Just for ref, it does the exact same for me too, testing here. I used the Tracktion FM synth, with the Sine Bass patch, to play a high C, with decay turned right up, so it renders like a thick block, rendered it as mono, and stereo, with the soundcard set to 48 or 44.1, and the render set to the same, or different, and the clicks happen here too in all these scenarios. Zoom in and the little bumps you get are also apparent.

I'm now very surprised I haven't noticed this before. Can only think i'm chopping up guitar audio, and not patching it back together in this kind of way. Or something, i dunno.

[fromwithin]

Thanks for confirming the problem.

[dRowAudio]

Thanks, I've also replicated this by cutting a sin wave audio clip, there is a slight discontinuity.
At a guess I would imagine that there is a rounding error (possibly exasperated by a change in sample rate) when converting between Edit time to audio sample time. The other thing this could be is the interpolation algorithm used to resample audio as it is read. I'll see if there's an easy fix.

I think the reason this hasn't come up before is two fold:
1) If you're cutting an audio clip and then not moving it so it should be completely contiguous with the previous clip why have you split it in the first place?
2) More commonly, this split would be moved and then you'd be in the realm of non-zero crossing starts anyway so would apply "edge fades"

If there is a valid use case I'll take a closer look. Cheers.

[fromwithin]

Cross-fading is a pain because you can't have clips split by bar be the size of a bar. It has to underextend/overextend the boundaries of the bar, as does that with which it is fading. Now take a cross-faded clip that has been underextended and copy it somewhere else. With snapping on, it will snap the start of the cross-fade to the start of the bar, so now the timing of the copied version is off and you have to zoom right in to shift it back. That usually means going back to where it was copied from and checking the length of the crossfade.

It's much easier to shift the sample inside the clip so that the crossing point between it and the previous or next one matches. This allows bars to stay exactly one bar in size and is much faster to work with. The clicking bug makes this almost impossible because if the crossing point is not zero, it will click even if the start and end of both clips match.

Another workflow issue is that you might want to copy half of a clip somewhere else. You split the clip and then copy the half that you want. But then you have to go back and merge the clips that you just split because otherwise it will click.