ROUNDTABLE DISCUSSION about the proposed "REs with known bugs" list

[orthodox]

All that sounds good, reprodicible, two witnesses and so on. But who will judge whether something is really a bug or it is just the way a device works, which someone does not like?

I guess if it causes an error message and stops Reason from working it’s a bug. Maybe go out from there?

Well, I would call it a bug.

[Enlightenspeed]

All that sounds good, reprodicible, two witnesses and so on. But who will judge whether something is really a bug or it is just the way a device works, which someone does not like?

Good stuff!

So yes, another layer is needed after that to confirm that this is not behavioural to the design.

[Enlightenspeed]

...

[MrFigg]

I guess if it causes an error message and stops Reason from working it’s a bug. Maybe go out from there?

Well, I would call it a bug.

Me too. Propellerheads too. So we’re all agreed. So why don’t they fix them. I mean you, Brian, Robotic Bean, Turn2on and many, many more of the great developers out there (we know who they are) pay attention to the users and work to get their devices functioning as they should. Why does nothing seem to come out from the mothership?

[guitfnky]

Bug reports exist in other forums as a way to report them to the developers, not to call them out.

no. it may be the case in some forums, but strictly speaking, that is a false statement. in most of the other such forums I’ve seen, there is no third party developer presence. it’s literally got nothing whatsoever to do with “reporting bugs to the developers”.

and it’s not about singling out developers. it’s about warning people who use a core product (i.e. Reason) about compatibility issues so they can make informed buying decisions.

since this forum exists purely for Reason users, it is rather obviously the best place to maintain such information.

you’re setting a stupidly high bar to share information that would help people make sound purchases. informing users requires nowhere near the amount of work you describe, in any other forum.

[MrFigg]

Was just reading back some of the comments above. Way I see it is there’s different kind of “bugs”.
There’s the ones, as Orthodox says, which may not be bugs at all. Just the way the device is supposed to behave. I guess the developer themself is the person who should be asked.
Then there’s the bugs which (as we’ve said above) have been tested, reproduced and confirmed by the developer as being actual bugs. Lots of devs are happy to get the reports and strive to fix the problems. Others just don’t bother their holes. So basically you’ve bought a buggy device with no hopes of it ever being fixed.

[challism]

Updating the list doesn't need to be a 24/7 job. That's a really exaggerated claim. How often do updates really hit the shop, anyway? I'm not talking about updates from the regulars like Enlightenspeed, Rob Papen, Turn2on, Blamsoft, Robotic Bean, and on and on and on. These are Devs who support their products and fix their bugs. There is no need to put them on a master list of abandoned (yes, I am calling it that) bugs (because they fix their bugs), and no need to update the list upon their updates (because they fix their bugs). Most of our Devs are great at supporting their products. Bravo to them. No need to warn potential buyers about their products, in my opinion.

The list is intended for Dev who DON'T fix bugs. So updating the list shouldn't be a huge job since they don't fix confirmed bugs. Does anybody really think I'm going to ever have to update the list to remove McDSP? ha ha ha! But if I do.... hurray! That means they fixed it!! They most likely wont ever fix them, and we all know it, because they have abandoned it, even after confirming serious bugs. So has Reason Studios. Yes, I have a bone to pick about abandoned bugs, but that is moot point. That doesn't mean this thread is a bad idea.

I agree, bugs are everywhere.... in all software bla bla bla. I get it. But if an RE stops functioning or is skipping notes or dropping audio because of a bug, that's a big deal and it should be fixed. If it isn't fixed, it should be listed after certain criteria are met.

I don't want to argue about this. I don't want to argue about anything on RT. It's already taken more energy and time than it's worth. Lock the thread if you want, I've pretty much stopped caring about it.

[ab459]

I would say that this thread has concentrated around information about the problems of Propellerhead (Reason Studios) devices. Probably, can keep only this direction, it will already make sense due to increase the likelihood of reaching out to the certain (main) author.
In addition, I agree that the potential buyer should know what he will get as part of the Suite in reality.

Also, when these problems are fixed, and in this topic it will be indicated that no bugs have been detected at present (in native devices), this will be a good advertisement and an motivation to buy program.
I would suggest renaming the topic to "Reason Studios REs with known bugs"

[retreed]

I think such a list is good and helpful.

It must have good documentation of the problem and emotions must be kept outside to be informative for users.

This can help to evaluate to still use/buy a product, e.g. if they consider the bugged RE is worth something for a person or helpful nonetheless (like challism's example of Drum Sequencer).

There is always a chance to stop it and archive the thread, if people start with great drama. It's a great community project if executed properly and worth a try, so let's prove it.

[MrFigg]

I don't want to argue about this. I don't want to argue about anything on RT. It's already taken more energy and time than it's worth. Lock the thread if you want, I've pretty much stopped caring about it.

I don’t think you need to argue about it any more either man. Just read through the thread. The vast majority of comments are positive towards this idea. I personally appreciate you taking the time and I know that there are many more here on RT who feel the same way. Drink some tea and put your feet up.

[Boombastix]

I was on the verge to buy the McDSP stuff but got similar devices from another company, however the thing regarding their bugs was unknown to me. Had I known I would never had considered buying them, so close to dropping $60 bucks or whatever into a bad purchase.

So, I fully agree a list would be useful, but we need to make sure it doesn't become a discussion forum about REs behavior and or some bug confirmation thread, those discussion should be in the usual RE thread, so a bug thread is just listing DEVICE NAME, TYPE OF BUG, HOW TO REPLICATE IT (or the circumstances when it happens), DATE. Something like that.

[dioxide]

I think this is a good idea, and I have also noticed that PH / RS rarely fix known bugs in their REs. The GUIs often look better than some other third party RE devs, but I find third party devs are usually more interested in fixing stuff. So I think this thread helps keep the RE ecosystem healthy and is more in line with the general idea that Reason is a very stable platform compared to other DAWs+VSTs. Native PH devices tended to have fewer bugs but PH / RS are just coasting on their past reputation at the moment, and it is the third party devs that are doing a better job of creating new devices. Reason competes in a crowded market, and it is well known for it's stability and lack of bugs. In my opinion RS are throwing their well earned reputation down the drain by ignoring all the user reported bugs in their devices.

[Arjanders]

More info on the drum sequencer problem: https://www.reddit.com/r/reasoners/comm ... r_pattern/

[MrFigg]

I actually have a suspicion that this thread is not going to happen due to Challism’s initial enthusiasm being wrung out of him by negativity before it even got anywhere. I think it’s a shame but I totally understand how it feels when you think you’ve come with a good idea which would be beneficial and you’re met with someone repeatedly telling you it’s a bad idea. Looking at the thread, as I said previously, there a lot of people commenting, I’d go as far as to say the majority, who think this would be a good thing to have albeit with the right structuring. More often than not positive energy gets dampened by constant negativity to the point that people just want to go to sleep and forget it. Especially when if they go ahead and it doesn’t work there’s a good chance of a “told you so”. So with that said, I think it’s a great idea for people to be made aware of bugs which are being ignored by the developer despite them receiving reports but I would also understand if Challism is worn out and just wants to lock the thread.

[DaveyG]

The list needs to be on its own in a locked thread. Otherwise it just descends into bickering.

[MrFigg]

The list needs to be on its own in a locked thread. Otherwise it just descends into bickering.

Yep.
Look at it as a pre-thread.
Read back though. How much bickering do you see there? Nearly everyone thinks it’s a good idea.

[challism]

The idea of having a list of REs with bugs that need fixed has been floating around our forum for a few weeks (months?) or so. I've seen it pop up in a few threads. It was last being discussed in a thread about a bug in RS Layers. So I decided to go ahead and create the tread and get it started. A number of users had already expressed that they supported the idea, and I support the idea, too. I'm not convinced a thread like this is a bad idea. I really don't understand that argument. It seems like the vast majority think it's a good idea, if done correctly. I don't see how it needs to be a full time job or a huge burden or responsibility, either. If an RE bug gets fixed, and it's on our list, it will be removed at the earliest convenience. If it takes a dev 5 years to fix a bug, I think it's perfectly fine for the list to be updated in 2 days or even 2 weeks. It doesn't have to be the 24/7 job, as described earlier in this thread. Besides, the REs that make it to the list are going to be the REs that have been neglected to be fixed, intentionally, by their developers, so they will most likely never need to be removed from the list (let's hope they are fixed and need to be removed, though). I'm just not seeing how this is a problem or a big burden. Seems like an argument for the sake of arguing, to me.

Since this idea is supported by a number of regular users, I think we should go forward with it. I see this forum as belonging to the users, not the moderators. You guys want it, we should do it. Let's use this thread to hammer out the process of what we think should happen. Then, when we are happy with it, we can lock this thread and begin the new, official thread. I will now unpin this as we discuss how to implement this bug list.

[DaveyG]

I think it's a great idea.

It works on other forums but not as one big thread. You need a bug sub-forum. At the top of that forum is a sticky thread detailing the state of play - all the known bugs and the info to reproduce them. That thread is locked. Only the owner/mod can edit it.

The rest of the forum can have a thousand threads of bug reports, queries, arguments, discussions, decisions. If I think I've found a bug I start a new thread in that forum. People agree, disagree, test, discuss, whatever. If we reach a consensus that it is a bug it goes on the list, if not the thread just stays there and gradually moves down the forum. Inevitably people will report the same bug again but we have enough regulars to spot that.

[MrFigg]

Excellent!!!

[JiggeryPokery]

Something to add, if I may. Bugs need to be reproducible and verifiable by at least two users, other than the original reporter, and OS/System Spec needs to be reported.

After this verification stage is really the point when you want to be contacting the developer.

Users should never assume a bug has been reported if they think they've found one, unless there is some kind of public(ish) bug tracker where you can clearly see the exact same thing has been reported, otherwise it's the software equivalent of the Bystander Effect ("Oh well, I'm sure someone else will save this poor Rack Extension's life!").

Equally, a report needs to be taken just seriously enough by the dev at first and at least minimally investigated even if only one person reports it, and provided the report is detailed enough (after a follow-up with the reporter for more specific information if required), there is no reason whatsoever for a bug to need to be reported by two different people for it to become valid. A bug is not somehow "not a bug" just because only one person reports it. The only other person needed to verify it is the coder. (This is particularly relevant for direct-to-dev reports; via a forum such as this follow-up posters to an OP "is this a bug?" type posts invariably result in at least one person confirming, but again, even if no-one does, it doesn't automatically invalidate the OP, just something else might be in play.)

Most times the developer should be able to subsequently recreate the bug given the same triggering circumstances. And even these "one reporter" bugs can be surprisingly obvious, if no-one has twiddled that knob in that way during testing while playing the device in a fairly standard manner **.

In a general sense and this isn't aimed at you, Brian, in the more complicated devices a bug can be a serious outlier, e.g. bugs that only trigger in one OS can be a real shit if you as a dev use the other OS. And if the one original reporter refuses to follow up then absolutely that can be a fucking pain in the arse: we had a bug in Ammo where there was a single report, but I couldn't help as I'm on Windows, the reporter on OSX but refused to help further. Took Pitchblende a while to even trigger the supposed error, but trigger it eventually did, and after some proper hassle tracked that error down, and fixed it. We could have taken the view that because it was so rare it wasn't worth fixing. But that's a really count view to take imho: if one is still reasonably active or able to be active as a dev, especially for a product maybe six months old at the time, then it's a matter of pride in one's work that such things should be fixed.

It's absolutely the case that ultimately I agree we all do need to apply some kind of case-by-case "cut-off" date to ongoing bug fixes if the device has reached a point where bug reports are unlikely, and that any real report is so obscure because it's only triggered on a Tuesday afternoon around tea time while there's a supernova in Saggitarius, because we do need to get on with our lives; but a $20m business, allegedly successful and growing, can damn well afford to fix product bugs a good year and more after release, yet they choose to cut support weeks after release, arguably even before release, given the number of known bugs they often ship with. (It's important to distinguish here between "bugs" and "feature requests", as one issue is that a few beta testers do seem to find these two terms synonymous, and such "bug reports" can make bug trackers look longer than they really should be. )

I can honestly say I've never submitted a device for publication with a known bug. Now, all devs probably have had a situation where at least one of the little bastards was discovered right after submission and before acceptance, and so inevitably most of us have that embarrassingly obvious day one update, but that's the nature of continuing to test thoroughly after submission, and not treat submission as completion. Sometimes I think Props, in the RE era, don't really use the products they release outside of basic marketing tracks put together before products even really hit wider testing, because in my experience that's how you end up with functions that remain not working as expected after launch. "Well, we didn't personally find a need for that bit to work as it should, therefore you don't, so it's not an issue that needs fixing. Won't fix".


**One example from my own history. Frankly embarrassing to admit, cos everyone missed this one for nearly two years, but then no-one reported it either, so presumably no-one was using that function, perhaps because those knobs were on the back panel at the time, but the envelope curves, one of the them returned a bad value if pushed beyond 80% or something, cutting the envelope completely. I discovered it myself while testing v2, but it had been there there since v1 launch.

[Enlightenspeed]

Something to add, if I may. Bugs need to be reproducible and verifiable by at least two users, other than the original reporter, and OS/System Spec needs to be reported.

After this verification stage is really the point when you want to be contacting the developer.

Users should never assume a bug has been reported if they think they've found one, unless there is some kind of public(ish) bug tracker where you can clearly see the exact same thing has been reported, otherwise it's the software equivalent of the Bystander Effect ("Oh well, I'm sure someone else will save this poor Rack Extension's life!").

Equally, a report needs to be taken just seriously enough by the dev at first and at least minimally investigated even if only one person reports it, and provided the report is detailed enough (after a follow-up with the reporter for more specific information if required), there is no reason whatsoever for a bug to need to be reported by two different people for it to become valid. A bug is not somehow "not a bug" just because only one person reports it. The only other person needed to verify it is the coder. (This is particularly relevant for direct-to-dev reports; via a forum such as this follow-up posters to an OP "is this a bug?" type posts invariably result in at least one person confirming, but again, even if no-one does, it doesn't automatically invalidate the OP, just something else might be in play.)

Most times the developer should be able to subsequently recreate the bug given the same triggering circumstances. And even these "one reporter" bugs can be surprisingly obvious, if no-one has twiddled that knob in that way during testing while playing the device in a fairly standard manner **.

In a general sense and this isn't aimed at you, Brian, in the more complicated devices a bug can be a serious outlier, e.g. bugs that only trigger in one OS can be a real shit if you as a dev use the other OS. And if the one original reporter refuses to follow up then absolutely that can be a fucking pain in the arse: we had a bug in Ammo where there was a single report, but I couldn't help as I'm on Windows, the reporter on OSX but refused to help further. Took Pitchblende a while to even trigger the supposed error, but trigger it eventually did, and after some proper hassle tracked that error down, and fixed it. We could have taken the view that because it was so rare it wasn't worth fixing. But that's a really count view to take imho: if one is still reasonably active or able to be active as a dev, especially for a product maybe six months old at the time, then it's a matter of pride in one's work that such things should be fixed.

It's absolutely the case that ultimately I agree we all do need to apply some kind of case-by-case "cut-off" date to ongoing bug fixes if the device has reached a point where bug reports are unlikely, and that any real report is so obscure because it's only triggered on a Tuesday afternoon around tea time while there's a supernova in Saggitarius, because we do need to get on with our lives; but a $20m business, allegedly successful and growing, can damn well afford to fix product bugs a good year and more after release, yet they choose to cut support weeks after release, arguably even before release, given the number of known bugs they often ship with. (It's important to distinguish here between "bugs" and "feature requests", as one issue is that a few beta testers do seem to find these two terms synonymous, and such "bug reports" can make bug trackers look longer than they really should be. )

I can honestly say I've never submitted a device for publication with a known bug. Now, all devs probably have had a situation where at least one of the little bastards was discovered right after submission and before acceptance, and so inevitably most of us have that embarrassingly obvious day one update, but that's the nature of continuing to test thoroughly after submission, and not treat submission as completion. Sometimes I think Props, in the RE era, don't really use the products they release outside of basic marketing tracks put together before products even really hit wider testing, because in my experience that's how you end up with functions that remain not working as expected after launch. "Well, we didn't personally find a need for that bit to work as it should, therefore you don't, so it's not an issue that needs fixing. Won't fix".


**One example from my own history. Frankly embarrassing to admit, cos everyone missed this one for nearly two years, but then no-one reported it either, so presumably no-one was using that function, perhaps because those knobs were on the back panel at the time, but the envelope curves, one of the them returned a bad value if pushed beyond 80% or something, cutting the envelope completely. I discovered it myself while testing v2, but it had been there there since v1 launch.

I totally agree.

I think that we really just need some safety nets as well, so that one dev doesn 't get hit by all sorts of nefarious turdery.
I'm fairly sure that one of the big name early RE Dev's quit because one user in particular was giving them all sorts of nefarious turdery. Or at least part of the decision was made as a result of the incessant nefarious turdery.

Anyway, just while the topic is hot I thought I'd add this to the discussion. I'm very much in favour of the idea, but I think checks and balances are needed.

Cheers,
Brian

P.S. I'm loving the term "nefarious turdery", so if everyone can dop me a favour and spread this around (the term not the turd!), I'd be grateful.

[demt]

I'm still confused.

Every piece of software has bugs.

I think your intentions for the list are coming from the wrong place. It's expressed in the other thread that you are upset with particular devs and you want to call out those devs. And now this list seems it would serve that purpose. Bug reports exist in other forums as a way to report them to the developers, not to call them out.

And now the list is defining it as those that are "abandoned"? Which is a term people around here throw around and use incorrectly.

I still disagree. This thread would need much more attention than you think. This can't be like the free RE thread where it doesn't get updated for a week or weeks. Someone needs to be on top of it daily.

You'll end up singling out devs who have bugs reported and not those who have bugs that aren't reported. You might as well start with listing every piece of software (or in this case, every RE) and then start adding the bugs next to them. If you can't find them—keep looking.

i write code and it doesnt have bugs it does have an attitude problem then it may have bugs yet it works perf then having proved bugs essential to the new workflow has known and unknown bugs witch either breed or die out as the work progresses you need to get your hands on sum software that comes from a crack team doing there best youll never say bugs again.............youll say gremlins demons church

[challism]

P.S. I'm loving the term "nefarious turdery", so if everyone can dop me a favour and spread this around (the term not the turd!), I'd be grateful.

I'm loving it too. Let's try to work it into the official guidelines at least twice.

And I agree, we should not have nefarious turdery which could drive developers away. Nobody wants that.

I think it's important to give a developer a chance to fix a bug instead of announcing it to the world first. Before this Drum Sequencer bug, I had always sent developers a private email or message whenever I had found a potential bug instead of posting about it publicly. RS has proven themselves completely unresponsive when it comes to fixing bugs, so RS are now an exception, and I don't bother contacting them about bugs anymore. It's a waste of time and that is a very sad state of affairs. Anyway, I digress. The reason I always email a developer about it first is out of respect. It seems like announcing a bug to the word is akin to dragging their name through the mud, in a way. So I have always given them the information first and a chance to fix the bug before the world knows about it. Most developers have appreciate the discrete method and have been very fast at squashing the bugs, with a few exceptions.

I say all this because you (Brian) mentioned something like there should be confirmation by a few people of a possible bug before the dev is even contacted. It seems a bit contrary to my way of thinking. So what do developers prefer, publicly announced bugs or discrete emails?

[bxbrkrz]

EDIT:

This thread has been changed from the original intent. Let's use this thread to hammer out the process of how we think the process should work. When we are happy with our process, we can lock this thread and begin the new, official thread.

Thank you

~~~~~~~~~~~~~~~~~~~~~~~

ORIGINAL THREAD INTENT BELOW




ROUGH DRAFT.......... This list is going to take some time to put together.... and if you read the comments, we still have a few things to iron out....... so........... this list is coming soon

This first post will act as the master list for all the REs with known bugs that have been abandoned by their developers. Please feel free to discuss and report any buggy REs in comments below. I sort of see this first post ast he master list and the following posts as the backup evidence to support the bug claims that are made. So try to include the following information, if you can: Also PLEASE MAKE SURE YOU HAVE THE LATEST VERSION OF THE RE INSTALLED!! It very well could have already been fixed in an update you may have missed.

* RE name and developer
* describing the problem and how to reproduce it
* name your version of Reason and your operating system
* attach a song file (or pictures) which show an example (so we can reproduce it)
* did you contact the developer, if so, how did they reply?

Please remember to keep comments civil and respectful to the developers. This isn't meant to be a thread for attacks, rather, it's a thread to be used as a helpful resource for potential RE buyers.

REs with Bugs:
will go here

Basic idea:

1 - Bug targeted in a [maser] thread
2 - Talks about the bug - and confirmation it is one from multiple sources
3 - Give the bug a random number case - add that case to a (read only/locked) google doc, or anything similar, with all the bug details
4 - All discussions about that confirmation phase are then deleted by the original bug tracking participants from the [master] thread

The [master] thread should never go beyond a x number of pages. The online doc could grow or shrink (after the fixes), but not the thread.
The thread should be as small as possible, maintained by the bug tracking participants themselves.
The admin would deal with updating the read only online doc, mostly

[joeyluck]

I'm sorry if any of my comments are taken the wrong way. I'm only trying to help by pointing out concerns of having a pinned post with a list, which would be presented in what could be perceived as official. I'm only offering suggestions.

And after all, this thread was born out of another thread, in which it was said, "developers need to be publicly shamed." I appreciate you all and what this thread could be. And I'm a big fan of challism and I know we all can be passionate or upset about different things, so I'm only trying to help guide some of that.

Beyond having solid verification of bugs, I simply noted that I feel the list needs to be well kept and comprehensive. But then there's another layer where folks apparently want the list to only involve products that they interpret and determine to be abandoned...so then there's posts referencing personal email messages and all the different interpretations of that...

I feel like having a list claiming that these REs have bugs or are abandoned can easily be a misrepresentation, because the viewer is very likely not going to see most of the REs that could be on the list (because the people participating simply don't own them or know about them). If it's not constantly kept going and becomes stale and then sits there with only a handful of devs and bugs singled out, that is a misrepresentation and unfair. So I'm not just talking about closing reports when I talk about upkeep.

I don't think it's impossible to manage. I only wanted to point out the attention to detail I feel would be necessary. I also think that if you open it up to all bugs and steer the thread's attention towards helping developers as well as users, that the energy will be in a better spot, and can move away from the initial motivation of "public shaming."