ROUNDTABLE DISCUSSION about the proposed "REs with known bugs" list
Who is going to moderate the moderators???
Actually this whole thing is a publicity stunt we're doing to boost the activity in the forum.
-
- Moderator
- Posts: 1851
- Joined: 14 Sep 2015
- Location: Paris, France
Wait until we release challism's naked insta vids...
This thread has taken and wasted more energy in discussion that it really should have, and probably more than the actual list will take. It seems like the vast majority are in favor of the list happening and it more than likely will happen. If it takes more time and energy than we think it will has yet to be determined, but we won't find out until we get started. There really isn't any sense in rehashing the same things over and over, is there? Because I feel that is what we are doing. It feels like all the points in favor and against have already been stated. Can we move on yet, or should we keep playing ping pong?
As for the word abandon, lets look it up.
Abandon - verb
1) To withdraw one's support or help from, especially in spite of duty, allegiance, or responsibility; desert.
Seems fitting.
And, yes our publicity stunt scheme has worked perfectly. Look at all this activity! *high fives Joey*
Watch out for the forthcoming scandal vids.
As far as the word abandoned being mentioned, is that word some kind of hot button issue or something? The first post said it, yes, and it's quoated above. I'm talking about the bugs being abandoned. It seems like an appropriate use of the word to me. I'm talking about the word in relation to the bugs. I can see how one could read the word abandoned being meant for the RE itself, but that doesn't make much sense to list REs for being abandoned does it? The list is about bugs.... bugs that aren't intended ti be fixed.... bugs that are abandoned. It can be read both ways, I suppose, and might need to be reworded, but if one would think about it a bit and realize the list is about bugs, it seems to become pretty obvious what is meant by the word abandoned relating to the bugs, not the REs themselves. It would be nice if we could move on, though, and stop scrutinizing every word that is typed.
As for the word abandon, lets look it up.
Abandon - verb
1) To withdraw one's support or help from, especially in spite of duty, allegiance, or responsibility; desert.
Seems fitting.
And, yes our publicity stunt scheme has worked perfectly. Look at all this activity! *high fives Joey*
Watch out for the forthcoming scandal vids.
I support the idea of an area to discuss bugs. I imagine it would require a whole separate section with a separate thread for separate bugs. I don't find joeyluck's comment that all software has bugs to be useful, because it can only be true if it includes bugs that aren't noticeable. In my experience, most Reason devices don't have bugs. Reason's some of the nearest-to-bug-free software I've ever used. It's easy to define what a bug is, and it's not necessary to rank severity. Knowing about bugs helps with decisions about purchasing. Discussing them helps developers see what's happening. I agree they should be described, not just listed, and computer specs and software versions should be listed.
Sorry I didn't realize there was any holdup with efforts while also having the conversation.challism wrote: ↑22 May 2020This thread has taken and wasted more energy in discussion that it really should have, and probably more than the actual list will take. It seems like the vast majority are in favor of the list happening and it more than likely will happen. If it takes more time and energy than we think it will has yet to be determined, but we won't find out until we get started. There really isn't any sense in rehashing the same things over and over, is there? Because I feel that is what we are doing. It feels like all the points in favor and against have already been stated. Can we move on yet, or should we keep playing ping pong?
As far as the word abandoned being mentioned, is that word some kind of hot button issue or something? The first post said it, yes, and it's quoated above. I'm talking about the bugs being abandoned. It seems like an appropriate use of the word to me. I'm talking about the word in relation to the bugs. I can see how one could read the word abandoned being meant for the RE itself, but that doesn't make much sense to list REs for being abandoned does it? The list is about bugs.... bugs that aren't intended ti be fixed.... bugs that are abandoned. It can be read both ways, I suppose, and might need to be reworded, but if one would think about it a bit and realize the list is about bugs, it seems to become pretty obvious what is meant by the word abandoned relating to the bugs, not the REs themselves. It would be nice if we could move on, though, and stop scrutinizing every word that is typed.
As for the word abandon, lets look it up.
Abandon - verb
1) To withdraw one's support or help from, especially in spite of duty, allegiance, or responsibility; desert.
Seems fitting.
And, yes our publicity stunt scheme has worked perfectly. Look at all this activity! *high fives Joey*
Watch out for the forthcoming scandal vids.
And I apologize for my confusion, but to me making a determination whether it's the product or the bug itself to be considered as abandoned sounds pretty similar. So what then is the criteria for declaring this? A particular amount of time passed? Official public word from the developer?
It then sounded like it was going to be about any existing bugs for any RE, making it a more comprehensive, unbiased list. But then it sounds like it's still about what some determine to be abandoned (whether that's the RE or the bug itself).
I'm aware of long-term bugs in devices, often from developers I like and respect. I'd feel a bit bad posting these in the list, but it needs to be done, as consumers come first. I can understand why these bugs can sometimes go unfixed, as for some devs this isn't a significant source of income and I can see there isn't much motivation to spend more time on these devices, when paid work and other things have to take priority.
PH / RS stand out for me as they are actively developing new REs without fixing problems in their previous releases. Maybe there are other third party devs that are doing this also, but I'm not aware of them. For me this is worse than the devs that have abandoned work on REs as they didn't do as well as they thought they might. Both though should be included on the list, so users are able to make an informed choice before they buy a RE.
PH / RS stand out for me as they are actively developing new REs without fixing problems in their previous releases. Maybe there are other third party devs that are doing this also, but I'm not aware of them. For me this is worse than the devs that have abandoned work on REs as they didn't do as well as they thought they might. Both though should be included on the list, so users are able to make an informed choice before they buy a RE.
The thread should include the exact version numbers of the REs that are affected by the bug(s). That way even if it is not kept 100% up to date people can see if a new version of the RE was released and can (ask to) test if it is still affected by the bug, in case the changelog of the RE is not explicit enough to tell from reading it.challism wrote: ↑22 May 2020If this project turns out to be a big mess or a mistake, we have that delete button; it can always be taken down. And if it isn't kept up to date, we can (and should) take it down. You're right, it needs to be kept up to date or it isn't fair to the devs. We need to make sure we are fair to the devs.
Also, I'm all for this thread and the combined community effort of documenting the bugs and creating good instructions on reproducing them (best with test files). In an ideal world, imho, this task would have to be done by the shop owner (aka. The Props/Reasonheads) and the information should be available right on the shop page for each RE. But as they are amongst the worst offenders I don't see this happening any time (soon).
- Boombastix
- Competition Winner
- Posts: 1929
- Joined: 18 May 2018
- Location: Bay Area, CA
If the word abandoned is a hot button, why not just state the date of the last update and date when the bug was first reported. Then I as user can make my own determination.
Personally if a bug hasn't been fixed in 3mo I'll be annoyed, 6mo I'll be frustrated, 9mo I'll consider it trash and probably abandoned.
Personally if a bug hasn't been fixed in 3mo I'll be annoyed, 6mo I'll be frustrated, 9mo I'll consider it trash and probably abandoned.
10% off at Waves with link: https://www.waves.com/r/6gh2b0
Disclaimer - I get 10% as well.
Disclaimer - I get 10% as well.
they do not fix bugs period (or even bothering to notify the relevant 3rd party developer) unless they destabilize the entire program. they've known since shortly after it was released that 4dyne has a critical bug that makes it completely unusable for it's primary/advertised purpose at sample rates above 48k. a bug that should be extremely simple to fix for a single person and makes the RE utterly worthless unless you're working at 48k or redbook. not only were they too lazy to fix it for over two years, they actually had the audacity to include it in one of the 3rd gen bundles, advertising it as one of the cream of the crop REs in a software package they were selling for $300 a pop, knowing full well that it was entirely broken and the people buying it would never be able to use it because they had zero intention of every fixing it. that's called fraud and it's very consistent with their fundamental dishonesty across every facet of their business. RS really are the most despicable software company i've ever encountered. if you get anything but blinding stupidity, laziness, and arrogance in response to reporting a bug you've hit the jackpot. this will probably never change and definitely won't until the fanboy crowd around here stops paying through the nose to get bent over by them over and over again.
Had time today to reproduce both described bugs (for Layers and RDK), well interestingly. (Frankly, i first time saw now how Reason device cause error heh).
About Layers, initially i been guess that the problem lay in certain incoming cv\gate range, what Layers do not like, that can reproduce if supply the sine lfo form (which cover full range). It's rightly via use the Shape default sine condition, or for example Subtractor triangle lfo. In both cases we get error.
But if we load other wave in Shape (more thin for example), we not get error.
But then i tried Arcus user knobs output - for manually scan whole range (again - for gate and cv simultaneously) with CVA7 analyzer, but nope - Layers sounds ok, no error here. Oddly enough.
About RDK (separate overhead and room outputs stop working after enable\disable any of solo button at front panel) reproduce too, thru use in reason rack in Studio One.
Would be interesting to know about any other catches regarding native devices, if anyone found.
About Layers, initially i been guess that the problem lay in certain incoming cv\gate range, what Layers do not like, that can reproduce if supply the sine lfo form (which cover full range). It's rightly via use the Shape default sine condition, or for example Subtractor triangle lfo. In both cases we get error.
But if we load other wave in Shape (more thin for example), we not get error.
But then i tried Arcus user knobs output - for manually scan whole range (again - for gate and cv simultaneously) with CVA7 analyzer, but nope - Layers sounds ok, no error here. Oddly enough.
About RDK (separate overhead and room outputs stop working after enable\disable any of solo button at front panel) reproduce too, thru use in reason rack in Studio One.
Would be interesting to know about any other catches regarding native devices, if anyone found.
There’s another bug in Layers which I found ages ago which has something to do with the timing in the built in sequencer. Can’t really remember what it was but it caused Reason to shut down completely. Apparently something to do with the Gorilla Engine (U-Jam) but due to the fault only occurring under EXTREME conditions Props deemed it low priority. I should have written down what I did so I could remember...but I didn’t because at the time I figured they’d never fix it anyway. Still do.ab459 wrote: ↑31 May 2020Had time today to reproduce both described bugs (for Layers and RDK), well interestingly. (Frankly, i first time saw now how Reason device cause error heh).
About Layers, initially i been guess that the problem lay in certain incoming cv\gate range, what Layers do not like, that can reproduce if supply the sine lfo form (which cover full range). It's rightly via use the Shape default sine condition, or for example Subtractor triangle lfo. In both cases we get error.
But if we load other wave in Shape (more thin for example), we not get error.
But then i tried Arcus user knobs output - for manually scan whole range (again - for gate and cv simultaneously) with CVA7 analyzer, but nope - Layers sounds ok, no error here. Oddly enough.
About RDK (separate overhead and room outputs stop working after enable\disable any of solo button at front panel) reproduce too, thru use in reason rack in Studio One.
Would be interesting to know about any other catches regarding native devices, if anyone found.
🗲 2ॐ ᛉ
-
- Information
-
Who is online
Users browsing this forum: No registered users and 4 guests