Longstanding MIDI Timing Bug still not fixed

Superior Drummer 3 Help
Viewing 15 replies - 1 through 15 (of 27 total)
  • drumjack52
    Participant

    Does your daw allow you to work in samples and/or ticks? If so (and if it’s changeable) have you tried changing that setting? How do things work out if you try a multiple of 44.1 like 88.2?

    Jack
    aka musicman691 on other forums
    Superior Drummer 3.4.0
    Area 33 1.0.0
    Death and Darkness 1.0.1
    PT 2021.6
    OSX 10.13.6
    3.46 GHz hex core 2012 MacPro 48 gig ram

    Eddie
    Participant

    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.


    Superior Drummer 3 version: 3.4.0
    Operating system: macOS Sequoia (15)
    Bear-Faced Cow
    Participant

    It has nothing to do with  whether they care or not. It’s more about whether they can fix one bug without introducing 5 more potentially serious bugs.

    Upsampling is a rather tricky programming process, especially when you are not going between multiples of the recorded sample rate, as you’ve experienced.

    jord


    Jordan L. Chilcott

    Web Site: https://jordanchilcottmusic.com/

    Eddie
    Participant

    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.

    Bear-Faced Cow
    Participant

    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


    Jordan L. Chilcott

    Web Site: https://jordanchilcottmusic.com/

    Eddie
    Participant

    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 2 days, 12 hours ago by Bear-Faced Cow"> 2 times, last modified 2 days, 12 hours 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
    Bear-Faced Cow
    Participant

    This is not about making plug-ins. This is about DSP math and its concepts. And yes, I am fully aware of what it takes both mathematically and programmatically to change a sample rate between a non-multiple of the original sample rate. I’m also familiar in which the process in which Superior Drummer bounces. The process is indeed far more complex, bordering on complicated, when dealing with each file individually as opposed to summing it and then doing to upsample.

    I asked you a very simple question which had nothing to do with how far back you go in time. It’s plain and simple that if you did report the bug five years ago and it was acknowledged then there is obviously a reason why it hasn’t been fixed and your beliefs on it have little to do with the reason why it is not been fixed. You seem to have difficulty believing that fixing one bug can create a series of other bugs. And it has nothing to do with making plug-ins. This is any type of software programming in general.

    However, if this is the first time they are hearing of this bug, ToonTrack is listening on the forum. Damien, Petter and Olof are rather active participants on this forum, so they can tell you better if they know about it. And even more so, they can expound on it. Saying they should have known, or it should’ve been caught in beta-testing, is an absurd statement. All software has bugs and many are made known after release quite often by users as yourself. Further to that, bugs are weighed objectively as to their severity. Considering that this is considered functional with a workaround, it’s not as serious.

    jord


    Jordan L. Chilcott

    Web Site: https://jordanchilcottmusic.com/

    1

    Thanked by: Scott Eshleman
    Eddie
    Participant

    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
    Participant

    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.

    Bear-Faced Cow
    Participant

    There’s way too much noise in your post. Let’s grab the key points.

    If the answer to fixing bugs was “well it might introduce more issues”, then nothing would ever get fixed.

    Absolutely false. There are bugs that carry functional consequences if resolved and there are bugs that can easily be handled. Otherwise, we wouldn’t have point releases. Refusal to believe this is more a demonstration of your inexperience of software development in general.

    What is a fair time frame if 5 years is asking too much?

    The amount of time to fix a bug is irrelevant. Some bugs take longer to find an adequate solution. The VST bug was one example that took years to fix because an immediate fix would have broken a large number of project files. They finally found a solution that worked despite all of the time.

    I am sure Toontrack are aware of the bug, because I was borderline gaslit…

    I’ll stop that one right there. I don’t think you know the difference between gaslighting and fact finding. If someone is questioning your findings, they are not telling you that you’re making it up. So let’s put that into proper perspective.

    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.

    Keyword: A sample. Superior Drummer acts more more like a DAW in which is handles and processes many (sometimes 40 at a time) audio samples in various ways. It’s not a simple sampler. It’s not really a sampler at all.

    There are several approaches to oversampling that are well understood and documented, and circumventing their shortcomings is also well understood.

    We’re talking upsampling and not oversampling. And can you name one such methodology?

    Why is there not even an official recommended guideline for a workaround or acknowledgement of the bug?

    That’s standard practice in the SDLC. Which again sounds like you’re unfamiliar with.

    The purpose of beta testers is to iron out bugs.

    No it is not. The purpose is to test the software. Unless it is totally glaring, which this really isn’t, it’s not necessarily going to show on anyone’s radar.

    This bug occurs at 48kHz which is an extremely common sample rate

    Only for video. Audio standards deal specifically with multiples of 44.

    And I can’t say I’ve been particularly thrilled with the process involved in getting it resolved

    Your feelings are not relevant to the amount of time it takes to fix a bug. If they can fix it without breaking anything else, they will. Fixing bugs takes time. I’m current dealing with this with a company far bigger than ToonTrack. They fixed one process and broke 16 other processes. And it has nothing to do with audio.

    Jord


    Jordan L. Chilcott

    Web Site: https://jordanchilcottmusic.com/

    Bear-Faced Cow
    Participant

    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.

    Again, they could have hit a snag. It’s not as clear cut as you think.

    jord


    Jordan L. Chilcott

    Web Site: https://jordanchilcottmusic.com/

    Eddie
    Participant

    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.

    Bear-Faced Cow
    Participant

    Almost every one I have worked with have worked in multiples of 44 for audio and 48 for video over the past 3o years. Many of the big name engineers that I have had the pleasure of knowing work with multiples of 44.

    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.

    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.

    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 it’s 5+ years, how can anyone have faith it will get fixed at all?

    You are totally missing the point.

    jord


    Jordan L. Chilcott

    Web Site: https://jordanchilcottmusic.com/

    Eddie
    Participant

    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.

    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.

    Bear-Faced Cow
    Participant

    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


    Jordan L. Chilcott

    Web Site: https://jordanchilcottmusic.com/

Viewing 15 replies - 1 through 15 (of 27 total)

No products in the cart.

×