I work as a software developer in my daytime job. And therefore I know that bug fixing doesn't work this way. If there's a second ticket about a bug, it's marked as a duplicate and closed. Done. That's why this sort of thing is rather annoying for software developers and distracts from the actual work.
-
Hi and welcome to the Studio One User Forum!
Please note that this is an independent, user-driven forum and is not endorsed by, affiliated with, or maintained by PreSonus. Learn more in the Welcome thread!
Studio One Pro Update Releases?
- Thread starter easyrider
- Start date
- Status
Craig Anderton
Well-known member
I truly appreciate the detailed response. Not having this issue with at least some other DAWs led me to think the issue was Studio One-specific, but it seems that when it worked that was more about luck than anything else.
Jamstik bundles a virtual instrument that behaves as desired for MPE, so that's another workaround. I don't know a thing about coding. Perhaps this is something that should be addressed in the virtual instrument, not the DAW?
I'll bring this up with The MIDI Association and see what they think. It's a very active organization these days.
Craig Anderton
Well-known member
Well, talk about instant gratification...I sent Lukas's reply to Jamstik, and received the follow response:
We are aware of Studio One's note allocation scheme. Ableton uses a similar scheme. We do have a fix in the works that will send the string ID as a separate MIDI CC value prior to a note on, so the Creator [virtual instrument bundled with the Jamstik] can route it to the correct string in these DAWs. For now, a workaround is creating 6 tracks only taking input from 1 MIDI channel, then routing that MIDI to the Creator track on the correct channels.
[However] only the Creator would know to interpret the String ID message as a proxy for "intended MIDI Channel", so unfortunately this would not resolve the issue for 3rd party software that expects notes on certain channels.
Creator is actually pretty cool and has low latency. Since having separate sounds on each string is a feature I use only rarely, their fix works for me. Jamstik is a small company so I don't know when they expect the fix to happen, but this is good news for those who want to take advantage of the Jamstik's MPE capabilities within Studio One.
We are aware of Studio One's note allocation scheme. Ableton uses a similar scheme. We do have a fix in the works that will send the string ID as a separate MIDI CC value prior to a note on, so the Creator [virtual instrument bundled with the Jamstik] can route it to the correct string in these DAWs. For now, a workaround is creating 6 tracks only taking input from 1 MIDI channel, then routing that MIDI to the Creator track on the correct channels.
[However] only the Creator would know to interpret the String ID message as a proxy for "intended MIDI Channel", so unfortunately this would not resolve the issue for 3rd party software that expects notes on certain channels.
Creator is actually pretty cool and has low latency. Since having separate sounds on each string is a feature I use only rarely, their fix works for me. Jamstik is a small company so I don't know when they expect the fix to happen, but this is good news for those who want to take advantage of the Jamstik's MPE capabilities within Studio One.
Then state consumer protection should take a closer look at the respective software companies. Selling incorrect software to customers should be classified more clearly than fraud and punished accordingly.
Software is always incorrect
A software without errors is practically not possible — at least when the software reaches a particular complexity. Therefore, in the software industry the goal is to reach "robustness" not "correctness".
Last edited:
ThomasM
New member
No, not the same, at all. Regarding forum posts, it would then suffice with a single post on a single subject.
No team/developer should wade through anything, that is the job of the product manager/team coach.
If a bug is an issue for 1 person, so be it. If it touches the 100s or thousands you bet its more important to fix.
... or easier to find/reproduce
The number of people who have reported a bug does not necessarily correlate to the severity.
ThomasM
New member
Not always, no. But more often than not.... or easier to find
If you have a quirk in the UI or a function that is often used, a lot of people will possibly report this. But if there is a workaround available, the severity still is rather low. But if there is a hard-to-find error that only occurs in a very specific setup of a few users but eventually corrupts the projects with total loss of all your work? That is high severity — even if there are only one or two users who have reported this issue.
Software is always incorrect
Then the state should prohibit being allowed to charge money for it. This borders on fraud. And beyond that, the buyers should be allowed to decide which software is to be considered robust and not the developers.
ThomasM
New member
Yes. But not likely to get a higher priority. Value of teams effort is not tied to severity per se.
What are you talking about?
I'm talking about the fact that reputable software companies should talk openly and directly about what problems have been identified and when and how they will be fixed, without any secrecy. PreSonus is by no means alone in this madness. This also includes communicating very clearly and publicly which future program innovations are currently being developed and when they will appear on the market. Of course, with the actual users on board. That would be an appropriate professionalism in terms of software programming. It is always said in marketing: by professionals for professionals. The entire software industry is still miles away from this. And I fear that this will not change anytime soon.
I don't think that this is a specific problem of the software industry. And beyond this: I don't think that this will always work out well — for numerous reasons like i.e. competition in the market.
What you describe sounds nice in theory, but it's not how things work at larger software companies
This is exactly why I believe that state consumer protection should immediately put more pressure on all software companies. In the interests of all buyers and users of these programs.
This would require a lot of time and effort both for the companies and the customers. And I'm pretty sure that this will be reflected in prices.
Eventually: If you don't like a software, just don't buy it. Or cancel the subscription. There often are demo versions available to test the product before buying it.
The so-called 'competition' in the market tends to ensure that the customer is always the stupid one in the end. At some point, this market-specific insanity must be corrected in the interests of the users. There must be much more pressure from outside on the software companies here. One example is the powerful automotive industry. Even there, there are sometimes state-mandated recalls when certain components on the cars malfunction. Consumer protection should also be given a higher priority in the software industry. And this will only be achieved through stricter government requirements.
There are a lot of regulations in the software industry already. It just depends on the kind of software you are developing.
Concerning your example: A recall in the automotive industry is enforced if there is a risk of human injury or loss of life. And that is exactly the same for software products (I develop software in the aviation industry, and believe me, there is a lot of "pressure" from legal authorities to get things right). But an error in a DAW simply does not have the same impact.
dkaimone
Member
exactly.
- Status