[Eddie]

Bear-Faced Cow wrote:

Just so you don’t think that I’m just here to aggravate you on this. I ran similar bounce tests at 44.1KHz and 48KHz to not only confirm your findings, but also to provide clarity to ToonTrack as what to look for since your images above are way too confusing. If that’s what was provided to them, then I don’t blame them for asking so many questions. However, the images provided here should give clarity as to the issue. The playhead was used as a reference marker.

Damien, Olof or Petter can provide further guidance from here on as to the complexity of this issue.

jord

Thanks for verifying the bug. I appreciate that you’ve taken the time to confirm that it’s happening for you too.

I have provided videos, screenshots, pro tools sessions, audio files, MIDI files, and many explanations. This is also via bouncing internally in Superior, as well as bouncing via the DAW. I have tested this in several DAW’s too FWIW. As mentioned, I have been reporting this bug for 6 years and it has been confirmed by Toontrack.

But also, your screenshots do not show the position of the MIDI, nor do they show that the timing of the resulting audio shuffles in time by random amounts for each MIDI note (rather than a fixed amount). The shuffling in time is an important distinction because it means that the resulting audio can’t just be nudged into place (a relatively easy temporary fix). Ideally the timing would be lined up to the MIDI, and it would remain the same at all sample rates.

• This post was modified 1 month ago by Eddie.

[Eddie]

Mark King wrote:

Yup way off topic. I keep coming back to see if there is anything meaningful added. No such luck so far. Thankfully I don’t use the bounce function. I use multiouts and render in place in Cubase which works bang on. Definitely time for everyone to step back. Well except toontrack as that’s the only reason I keep reading this thread to see if they have anything to add.

Are you sure it’s still perfectly in time at other sample rates than 44.1kHz? My example in the thread is not using the internal bounce from the plugin. Also in my tests the results are the same whether you use the DAW to bounce or the internal plugin bounce.

[Eddie]

Bear-Faced Cow wrote:

How  can we when you consider your side fact and my side speculation ignoring the fact that I have a few decades of experience in this, not to mention every fact I already listed? Even worse is you have done to me the very thing you accused ToonTrack of… gaslighting.

It’s not me that has to get a grip on the reality of it here.

jord

Huh? The fact is that it is broken. There is no sides to that, it’s a fact. Your reasons as to why it is broken, or not fixed yet is speculation. We don’t know for sure.

I have not questioned your experience at any point. Please stay on topic and stop making it personal. Let’s get this fixed and move on. It should not be broken.

2

Thanked by: Mark King and drumjack52

[Eddie]

Bear-Faced Cow wrote:

ChatGPT is not a definitive answer. In fact, it’s nothing more than mashing information in a mediocre lump of misinformation. Next time try answering it using proper old school research.

Again, you are turning this into me not understanding what the problem is or stating there is no solution. You need to get over this and re-read what I have posted throughout.

However, you fail to understand many things about this issue and you have demonstrated this throughout:

• How Superior Drummer bounces and writes kit pieces
• How sample rate conversion is done
• Where the complexity lies within this bug
• Seriousness of a bug in relation to other bugs
• The irrelevance of time when it comes to fixing bugs
• Roles and responsibilities of beta testing

Did I leave out anything?

Stop making this about me or anyone else. My response is and has always been objective and based on experience.

Again re-read what I’ve been saying all along. Further posts are doing nothing but going in circles.

Jord

No, I actually think you understand exactly what the issue is. I don’t think there’s any miscommunication on that, the problem is clear and established.

 

Bear-Faced Cow wrote:

ChatGPT is not a definitive answer. In fact, it’s nothing more than mashing information in a mediocre lump of misinformation. Next time try answering it using proper old school research.

Again, you are turning this into me not understanding what the problem is or stating there is no solution. You need to get over this and re-read what I have posted throughout.

However, you fail to understand many things about this issue and you have demonstrated this throughout:

• How Superior Drummer bounces and writes kit pieces
• How sample rate conversion is done
• Where the complexity lies within this bug
• Seriousness of a bug in relation to other bugs
• The irrelevance of time when it comes to fixing bugs
• Roles and responsibilities of beta testing

Did I leave out anything?

Stop making this about me or anyone else. My response is and has always been objective and based on experience.

Again re-read what I’ve been saying all along. Further posts are doing nothing but going in circles.

Jord

Yes. You are overlooking the fact that supporting multiple sample rates is something that has been built into every version of superior since DFHS v1. It’s not something that has come out of nowhere and blindsided Toontrack. They have a method in place and it is broken. It needs to be fixed. It has been broken for at least 6 years, possibly even since launch. These are just facts, anything else is conjecture and speculation. I’m not particularly interested, all I know is that it is broken, and it should be fixed by now. It is Toontrack’s flagship product, it is not cheap software, and it promises a lot. It’s in everyone’s interest for it to be fixed.

You can speculate all you like as to why it isn’t done yet, or why it might be challenging. It doesn’t excuse the fact that it’s not working as it’s supposed to. It doesn’t really concern us as customers. So rather than going in loops, how about we just stick to the topic and the facts?

[Eddie]

Bear-Faced Cow wrote:

The only reason I have no need to see the email exchanges between the OP and TT is because I can see right from this thread that the OP refuses to understand the fact that the bug could have underlying consequences and has nothing to do with the competency of the company itself.

This is simply not true. Understanding what the issue is, and fixing the issue are 2 different things. The email exchange took a completely unnecessary amount of work to reach a point of understanding the issue. For instance, (among other things) I was told the inconsistent timing was the result of the microphone distances of the samples. This shows a lack of understanding of what the issue was, despite the fact I’d provided a massive amount of information that allows anyone to recreate the issue with ease.

You constantly draw your own conclusions that are not based on any credible facts.

Bear-Faced Cow wrote:

Therefore lining Them all up In a different sample rate is tricky. Therefore, they have to come up with some innovative solution to this bug

This is conflating 2 different things. You are implying that there is not a solution in place for handling different sample rates, rather than assuming that there is already an implementation in place that is causing errors. Without knowing the inner workings of the plugin, it’s not possible to say whether it needs an entirely new approach, or whether there is just a mistake that is causing issues. As I keep mentioning, 5 years is a long time. It should be corrected by now because it makes auditioning samples totally unviable.

And yes, Superior Drummer is a sampler. You may have your own definition on what a sampler is that is based on something else. Here’s ChatGPT to put it in an abundantly clear way for you:
🔸 <strong data-start=”278″ data-end=”306″>Definition of a Sampler:
At its core, a <em data-start=”322″ data-end=”331″>sampler is <strong data-start=”335″ data-end=”517″>any device or software that plays back recorded audio (samples), usually mapped across a MIDI keyboard or pads, often with control over pitch, dynamics, envelope, filtering, etc.

<ul data-start=”520″ data-end=”796″>
<li data-start=”520″ data-end=”616″>
Whether or not you can <em data-start=”545″ data-end=”553″>import your own audio does not define whether something is a sampler.

<li data-start=”617″ data-end=”796″>
The degree of manipulation possible (e.g., granular synthesis, looping, extreme pitch shifting) may be features <em data-start=”731″ data-end=”735″>ofsamplers but isn’t required for something to <em data-start=”781″ data-end=”785″>be a sampler.

🔸 <strong data-start=”805″ data-end=”828″>Superior Drummer 3:
<ul data-start=”829″ data-end=”1135″>
<li data-start=”829″ data-end=”887″>
It <strong data-start=”834″ data-end=”873″>plays back multi-sampled recordings of drum kits.

<li data-start=”888″ data-end=”933″>
Those samples are <strong data-start=”908″ data-end=”932″>mapped to MIDI notes.

<li data-start=”934″ data-end=”1027″>
It provides controls over mic bleed, velocity layers, tuning, ADSR envelopes, filters, etc.

<li data-start=”1028″ data-end=”1135″>
It allows some manipulation of the sounds—tuning, pitch shifting, layering, effects processing, and more.

<strong data-start=”1137″ data-end=”1209″>Therefore, by technical definition, Superior Drummer <em data-start=”1192″ data-end=”1196″>is a sampler.

🔸 <strong data-start=”1218″ data-end=”1241″>Rompler vs Sampler:
<ul data-start=”1242″ data-end=”1785″>
<li data-start=”1242″ data-end=”1407″>
<strong data-start=”1244″ data-end=”1256″>Rompler: Plays back <em data-start=”1268″ data-end=”1276″>preset samples from ROM or preloaded libraries, typically with limited ability to change or import new material. Example: Roland JV-1080.

<li data-start=”1408″ data-end=”1520″>
<strong data-start=”1410″ data-end=”1422″>Sampler: Plays back samples with some degree of control and possibly the ability to load your own samples.

<li data-start=”1521″ data-end=”1785″>
<em data-start=”1523″ data-end=”1541″>Superior Drummer is <strong data-start=”1545″ data-end=”1552″>not a rompler in the traditional sense because it <strong data-start=”1599″ data-end=”1633″>does allow sample manipulation (tuning, mic mixing, layering), and <strong data-start=”1670″ data-end=”1705″>you can import your own samples in certain use cases (e.g., adding user-created libraries or stacking samples).

Calling Superior Drummer a <em data-start=”1814″ data-end=”1823″>rompler is a <strong data-start=”1829″ data-end=”1851″>half-truth at best, used to <em data-start=”1861″ data-end=”1874″>distinguish it from fully open-ended samplers like Kontakt or Logic Sampler. But that’s more about scope <strong data-start=”1968″ data-end=”1992″>than actual category.

🔸 <strong data-start=”2002″ data-end=”2027″>Granularity Argument:
<ul data-start=”2028″ data-end=”2504″>
<li data-start=”2028″ data-end=”2257″>
Saying “I use Kontakt, so I know samplers” is like saying “I use a Ferrari, so I know cars.” Kontakt is a <em data-start=”2136″ data-end=”2151″>very advanced, fully-featured sampler—but that doesn’t mean other simpler or purpose-specific samplers aren’t samplers.

<li data-start=”2258″ data-end=”2504″>
Superior Drummer 3 doesn’t need to do granular synthesis or loop slicing to qualify as a sampler. It’s <strong data-start=”2363″ data-end=”2408″>purpose-built for realistic drum playback, so its sample manipulation tools are geared toward <em data-start=”2461″ data-end=”2470″>realism, not experimental audio mangling.

✅ <strong data-start=”2512″ data-end=”2524″>Summary:
<ul data-start=”2525″ data-end=”2711″>
<li data-start=”2525″ data-end=”2584″>
<strong data-start=”2527″ data-end=”2584″>Superior Drummer 3 = Sampler (specialized for drums).

<li data-start=”2585″ data-end=”2646″>
<strong data-start=”2587″ data-end=”2646″>Kontakt = Sampler (general-purpose, deep manipulation).

<li data-start=”2647″ data-end=”2711″>
<strong data-start=”2649″ data-end=”2711″>Rompler = Fixed-sample playback with minimal manipulation.

The confusion often comes from people conflating <strong data-start=”2762″ data-end=”2773″>sampler with <strong data-start=”2779″ data-end=”2799″>synthesis engine capabilities or <strong data-start=”2816″ data-end=”2845″>sample import flexibility, but the <strong data-start=”2855″ data-end=”2900″>definition is about playing sampled audio with some level of control, which Superior Drummer definitely does.

1

Thanked by: drumjack52

[Eddie]

Bear-Faced Cow wrote:

No, it was trying to make it sound like it was user error

That’s not gaslighting.

No. You are trying to belittle how much of a problem this bug is, for whatever reason.

Wrong again. I said if they couldn’t fix the bug without causing more serious issues.

At least we all now know why you believe that you’re being gaslit.

jord

So without seeing any of the emails or correspondence, you know what was going on.

I really cannot understand your stance here or why you think software remaining broken for so long is acceptable, but you’re more than entitled to have it. Thankfully very few plugins on my computer have bugs that have been present as long as this, usually they get fixed eventually.

My stance is that it fundamentally inhibits how I am able to use the plugin, and makes it unviable for one of the main uses I have for it (to augment real drums). It’s not practical to convert every session to 44.1kHz just to audition samples, and then convert back to whatever sample rate I need to work at. I’d tolerate that for a while, but expecting users to do it for years is simply below the standards I typically expect of Toontrack, who make otherwise industry leading products. I hope this gets resolved, and I hope others are aware that in its current state it may not function as they expect it to be.

1

Thanked by: drumjack52

[Eddie]

Bear-Faced Cow wrote:

That’s not gaslighting. The fact that they were sending emails back and forth is an indication of the willingness to help. Sound like you are taking it more personal than it needed to be.

No, it was trying to make it sound like it was user error when it was abundantly clear through demonstration that it was a bug. Not sure how you can offer such an opinion without having seen any of the communication. And yes, I spent a lot of time and effort explaining that, all in good faith and politely and nothing has happened since. So now I am discussing the issue and communication publicly. I think that is fair. I don’t see it as anything personal, but I do think it is below par and not particularly encouraging, That’s just my opinion though and I wouldn’t say its reflective of most of my other dealings with Toontrack. Its a rare blip, but a disappointing one.

Bear-Faced Cow wrote:

You are totally missing the point.

No. You are trying to belittle how much of a problem this bug is, for whatever reason. Why not try and help get it fixed so we can all move on? You’ve made several incorrect assertions that the bug doesn’t matter, which is entirely unhelpful.

[Eddie]

We’re talking about 5 years here, not 5 weeks or 5 months.

5 years is an absolute age in software. I’d expect we see SD4 within 5 years time.

There’s a hell of a lot to unpack in your post, but suggesting 44.1kHz is the preferred format suggests you aren’t aware of the guidelines Universal Music’s delivery spec is 96kHz /24 bit as a minimum and has been for a number of years. I know of many other audio professionals working at 48kHz or 96kHz, as well as 44.1kHz. Suggesting that it’s only for video, is both wrong, and also dismisses the need for composers for video to need drums to line up properly. I work predominantly in mixing audio and receive files in all kinds of formats. 88.2kHz is probably the least common, and I’d actually say 44.1kHz aside, they tend to be in multiples of 48kHz.

Regarding the gaslighting, (among other explanations) I was being told that the timing issues were caused due to time delay of the signal into different mics. There was a clear inability to even understand the problem, despite sending audio, sessions, videos etc. This took several weeks of back and forth to communicate a straightforward bug. You’re more than welcome to assume what you like without having read the emails or gone through the work in helping to try and get the bug resolved.

Regardless of whatever stance you are trying to take, the facts are that the software has a longstanding bug that nerfs the ability to use the plugin as it is intended, and that needs fixing. Whether that means another 5 years or 5 weeks is at Toontracks discretion and customers are more than entitled to hold their feelings on that. If a developer fixes it in a day, a customer might be thrilled. If it takes a year, it might be somewhat frustrating. If its 5+ years, how can anyone have faith it will get fixed at all?

I’d say that if customers are unable to use the software in their preferred manner, it’s a very understandable source of frustration.

[Eddie]

Just checking through my emails, I believe I first reported the issue in 2019, but there was a LOT of back and forth to even acknowledge the bug. Eventually we got to this point:

IMO, waiting a year shows tremendous patience for a broken product. 5 years and counting is another level.

[Eddie]

I’m not entirely sure what you’re trying to defend here. It’s clear that the sampler in its current state does not behave as intended.

I can’t name a single other sampler that i’ve ever come across that cannot reproduce a sample at the location it’s supposed to. A sampler at is most basic level needs to be able to play back a sample when it is supposed to. There are several approaches to oversampling that are well understood and documented, and circumventing their shortcomings is also well understood. Toontrack are not novices, and triggering samples in time forms the basis of most of their product line. Samples not triggering in time is a fundamental problem. Furthermore; the workaround is not something suggested by toontrack, it’s been left to users to figure out. Why is there not even an official recommended guideline for a workaround or acknowledgement of the bug?

SD3 was released in 2017, and this is not a new bug. Was this an issue in Superior 1 or 2? Is 5 (maybe more) years not long enough to fix one bug that is fundamental to the operation of the plugin? What is a fair time frame if 5 years is asking too much?

Fixing any bug can introduce more bugs, that is not unique to this problem. The goal of maintaining and supporting a product is dealing with them. If it was a brand new plugin, or a newly introduced version, I can understand. But this is the same issue that has been left unresolved for longer than the length of most product lifecycles for a plugin. If the answer to fixing bugs was “well it might introduce more issues”, then nothing would ever get fixed. I’d say that as far as bugs go, this one is far too important to leave broken.

I am sure Toontrack are aware of the bug, because I was borderline gaslit in recreating it and describing it over the It involved sending several sessions, audio files, videos, MIDI, explanations – all for something that anyone can recreate for themselves quite easily.

The purpose of beta testers is to iron out bugs, and testing plugins at various sample rates is one of the first requirements. This bug occurs at 48kHz which is an extremely common sample rate, and should have been easily flagged and dealt with by now. They absolutely should be aware of it, and I’m sure they are.

 

I say all this as a massive fan of Toontrack as a company, and of their products. To be unable to resolve this over so many years is simply a failure. And I can’t say I’ve been particularly thrilled with the process involved in getting it resolved, which is partly why I’ve resorted to making this thread and putting things as bluntly as I have. I’ve more than held my end of the bargain as a customer, with the faith that this will get fixed. I’ve wasted far too much time demonstrating and explaining it. All I am saying is it needs to be acknowledged and fixed.

[Eddie]

Bear-Faced Cow wrote:

Yes, it is a rather complicated process to upsample. It’s not as simple as telling CoreAudio “play at 48KHz”. It’s further complicated by the way they create their bounce.

The other stuff is moot and has nothing to do with the fact that this bug could be hidden in ball of tightly knitted code where fixing this could unravel the entire engine.

Considering that you are only a couple of posts in and have stated that this bug is five years old, did you report it to ToonTrack back then?

jord

• The post has been modified 1 month, 1 week ago by Bear-Faced Cow"> 2 times, last modified 1 month, 1 week ago by Bear-Faced Cow.

For someone who does not make plugins for a living, yes, maybe it’s not as straightforward as “play at 48kHz”. For a company like Toontrack, given all the complex plugins and features they’ve made over the years, getting a sample engine to play back the correct sample at the correct time is probably the most basic thing it needs to do. A sampler that cannot do that at supported sample rates is broken. I’m not demanding a fix instantly, but if 5 years can pass without it being resolved, it’s hard to say that it’s a priority or something they care about.

I’m not sure why you think my post count here is relevant. I’ve been a Toontrack user ever since DFHS v1 and am a very heavily invested customer of theirs. And yes, as with all bugs I encounter, I report them to support. I managed to track some of my earlier emails to them which is how I am sure that I reported them 5 years ago. I wanted to give Toontrack the benefit of doubt to fix it, but seeing as nothing has happened I decided to post publicly. I’m actually quite surprised there’s so little mention of it online, aside from a few others. IMO its not something that should have slipped through beta testing.

1

Thanked by: drumjack52

[Eddie]

Let’s not forget that this isn’t a V1 piece of software from a new company. These are the market leaders in the field, with their flagship product, YEARS of experience. How many years has SD3 been out? Should a bug like this take more than 5 years to fix for a company and product like this?

I’m not saying it’s necessarily a straightforward fix, but it’s nothing different to what any other sampler plugin has to deal with. Slate, Addictive Drums, Kontakt, BFD etc all have it locked in. It’s pretty fundamental stuff, and SD3 is performing way more complex tasks than simply playing samples back in time. Adapting for different sample rates is really not that complicated either – its par for the course for every plugin ever made, they are all expected to be able to do it without botching its behaviour.

[Eddie]

At 88.2kHz the timing starts to shift early, but by a consistent amount each hit.

The first audio file is bounced at 44.1kHz and lines up with the MIDI for every hit. The 2 files below are bounced at 88.2kHz (one is ticks based, the other is sample based). It makes no difference what DAW you use, or whether its ticks/samples or the internal Superior MIDI editor. This is also tested on several computers, different operating systems etc, and its related to Superior’s behaviour at different sample rates.

I believe Toontrack are well aware of the bug, I sent a LOT of examples over the years highlighting exactly when it occurs and when it doesn’t. The issue for me is mostly whether Toontrack care enough to fix it, because 5 years is a long time now.

Reply To: Longstanding MIDI Timing Bug still not fixed version: 3.4.0
Operating system: macOS Sequoia (15)

[Eddie]

Rock songs and basic rock are your best bet for midi. Check out the zildjian artist series by platinum samples, all sorts of weird quirky stuff there.

Evil drums is perfect for the kind of bands you mentioned, it’s still available from some stores if you look hard enough. You may also want to try the CLA and terry date expansions for Steven slate drums, they’ll work very well.

Pretty sure david bendeth has been working on a sample library, I wonder who for?

[Author]

Replies