Hm... thanks for sharing this openly, hiccup. I can't connect to some of the impressions and views you seem to have gotten from my posts, so may I ask further?
- implied that the developer responded to your original post/request without him having a good understanding or having considered the underlying details.
He replied swiftly.
Not to your satisfaction, but unless you think you have a deep and better technical understanding of everything involved, you could accept and appreciate the prompt responses on this forum. Even by the developer himself.
Or you can be unhappy. As you were, and still seem to be.
Where did you get the impression I would think that Steven responded to me without a good understanding?
That was never my thought or intention and would be quite arrogant of me if I would. The only assumption I made based on his response (from my point of view as IT professional, not being specialized in audio software but familiar with software development and IT management processes) is that within 1h he wouldn't have conducted a code inspection in a search for the root cause of the reported behavior. I made this assumption because I wouldn't be able to do that in that timeframe on my own code, especially when it comes to potential memory allocation issues which I find quite tricky to hunt down. However, what I usually can do within 1h is a prioritization of a bug report / request on a number of aspects. Which aspects would have been relevant for Steven to not further investigate for the root cause are not known to me as he didn't elaborate.
Furthermore, why do you think that someone needs to have a better understanding of the technology involved in order to be disappointed with her or his report not being further investigated?
From my point of view users or customers are not expected to have a better understanding of a product. However, if they emotionally connect with a product, of course there will be expectations for their use cases, and naturally there will be disappointments when expectations important to someone are not met. So, as long as things don't get personal, what's the big deal? There always will be expectations not being met. Having said that, I believe that providing a brief rational would help to understand a decision to not further investigate a user report.
- implied (and still do) that since there is a VST addon for MusicBee available, users should expect it to work perfectly with all sorts of VST plugins.
You are aware there are hundreds of them, right? Probably thousands.
And pretty much all of them are designed to be used in DAW studio production software.
(or maybe you know some that claim and advertise they will work perfectly on WinAmp/foobar2000/iTunes/MusicBee/et al. ?)
Posting and sharing with the community (and the developer) which ones work, or which ones don't is of course appreciated and can be useful.
But voicing being unhappy (or disgruntled or whatever) that some won't work, and complaining when that is the case and it can't/won't be addressed or solved for you is something else.
Well, I don't see it in this absolute terms. I don't expect that MusicBee would work smoothly with every and each of available VST plugins out of the box. My expectation is around the situation if someone finds and reports a potentially faulty behaviour with a concrete plugin. Let me elaborate:
Based on my experience there is a variety of different potential root causes for 2 pieces of software to not properly work together, even via standardized interfaces. Some of them can be related to the interface or to the interaction of the pieces of software. And the more parties involved (different developers for different pieces of software, other parties for interface standards etc.) the trickier to resolve. However, other root causes might be around a bug in only one of the software pieces, in this case the VST host or the plugin. (This bug may not surface when combined with another piece of software due to differences in interaction.) Such a potential root cause could be further looked into by a developer on his own within his piece of software. In this context, I personally do have an expectation that a developer of a still supported software is in principle willing to look into such kind of potential bugs. However, I see perfectly reasonable reasons to not look into a specific case - see my next comment below. So my expectation is not that something works flawlessly from the very beginning, or that something gets finally resolved for me, but that a developer is in principle (not in every concrete case) willing to look into a potential bug - with open result.
Can we agree on this or do you have a different view?
Do I get my point across that I make a difference between MusicBee throwing an error in combination with one of my favourite plugins and the response from Steven on my initial bug report? Am I understandable pointing out that I do not complain about the potential bug in the first place, but that I was unhappy with my report not being further looked into and no brief rational for it being provided?
- implied that MusicBee (its developer) is not able to solve this for you since it is not commercial and paid-for software.
Again, by phrasing it like this, you are implying that in principle each and every VST plugin should not only work on professional DAW studio software, but on consumer audio players as well. And if it doesn't, it's likely a lack of programming skills, interest, time, or resources.
Which I believe is a very wrong assumption and standpoint.
Where do you get the impression I would think that the developer is not "able" to solve this for me?
I've neither seen Steven in action nor have I ever had a glance at MusicBee's code. So how should I be in a position to judge Steven's programming skills. Anything in this direction would be nothing short of arrogance and ignorance.
In contrast, I see time and resources as prefectly valid reasons to not look into a specific user report. Genuinely, I'm not sarcastic about this. Time and resources are the main limits for not being able to work on all reports or requests and the reason for the need to prioritize. I myself prioritize every day for me and my teams based on time and resources. And I stated that in one of my early posts to indicate what I would understand as a reason for the decision being made. Furthermore, I see commercial software developers in general to have more resources availabe than the ones developing software in their spare time for free.
Regarding interest, that's where I make another difference between commercial and for free software. Again, no sarcasm, while being a tough argument to defend for commercial software, I personally consider interest as absolute legimite aspect of software shared for free. I could think of a couple of reasons to develop and maintain software in my spare time and offer it for free to others. And one of them is simply my personal interest in a coding challenge or a product I'd like to have for myself. And in such a case, for me interest would be the main aspect when deciding which things to work on.
Again, I pointed this out in my later response to you when mentioning the example of FabFilters response to my report in order to make clear, that I do not have the same level of expectations to a software offered for free than to a commercial software and that I would honestly understand if Steven would say something like "no interest to make MusicBee work with Saturn 2 in my spare time for free".
I am not interested in having discussions with you, nor have any inclination to educate you.
Thanks for clarifying this as it felt that way at times.