Studio One Pro Update Releases?

[Vocalpoint]

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.

If there is a rampant bug - the users will let the company know - loud and clear - well before a thousand tickets are submitted.

Like @stanft - I work for a very large company and we do very large development. Trust me when I say that we really do not want more than one ticket on any bug - regardless of it's severity.

And like @stanft - we run a tight ship and duplicates on any issue - are deleted.

VP

 

[Vocalpoint]

There must be much more pressure from outside on the software companies here.

There is - it's called "Not buying their software".

If you really want to send a message - nothing hits harder than putting away the credit card.

But you cannot have it both ways.

VP

 

[dkaimone]

Can you send me the ticket number via PM?

After four months of no solutions from support or community, I stumbled upon a solution. It's an obscure setting and I'm astounded that no one in the community or in tech support after many months had an inkling of this.

In preferences, under advanced, there is a setting under Automation called "Reduction Setting". It is by default set to 50 (0-100). I looked this up in the manual and it says that it also affects MPE data. So, I switched it off, or to "0". MPE pitch playback is working now. I'm not sure how this may affect my processor load, but it works.

Four months of no accurate MPE pitch playback and absolutely NO ONE at PreSonus support or community had a clue.

 

[Craig Anderton]

The word "fraud" is not being used correctly. Fraud requires intent, and for it to be worth prosecuting, there would need to be provable and significant damages.

 

[Craig Anderton]

In preferences, under advanced, there is a setting under Automation called "Reduction Setting". It is by default set to 50 (0-100). I looked this up in the manual and it says that it also affects MPE data. So, I switched it off, or to "0". MPE pitch playback is working now. I'm not sure how this may affect my processor load, but it works.

And that's why this forum is pure gold!! Lately, I've been having some issues with complex MIDI parts that have human-generated pitch bend changes (i.e., lots of nodes instead of straight lines). Pitch would ignore a node from time to time. The parts rendered okay, but had occasional problems with real-time playback.

After reading your post, I immediately set Reduction Level to 0 and tested out the song by playing it back several times. So far, there have been no pitch problems. I'm not seeing any significant change in CPU consumption, either. Brilliant! Thank you!

 

[John Vere]

As a brand new user I found this thread very informative. Thanks for listing the pitfalls to watch for.
So far it’s the midi editor that is really far from being as powerful as Sonars. It is even lower quality than Cubase. Otherwise I am enjoying the transition.
The 30 day demo was missing a lot of features I wanted to test like tempo extraction.

 

[dkaimone]

And that's why this forum is pure gold!! Lately, I've been having some issues with complex MIDI parts that have human-generated pitch bend changes (i.e., lots of nodes instead of straight lines). Pitch would ignore a node from time to time. The parts rendered okay, but had occasional problems with real-time playback.

After reading your post, I immediately set Reduction Level to 0 and tested out the song by playing it back several times. So far, there have been no pitch problems. I'm not seeing any significant change in CPU consumption, either. Brilliant! Thank you!

You're welcome! I hope they make this setting obvious to anyone connecting and MPE controller or creating an instrument track with and MPE instrument. It would save a lot of angst!

They do now suggest always setting that reduction to zero. I wonder why the default was 50 if this is a problem and there isn't much processor load. Well, maybe there is dependent on the processor and the project.

 

[stanft]

You're welcome! I hope they make this setting obvious to anyone connecting and MPE controller or creating an instrument track with and MPE instrument. It would save a lot of angst!

They do now suggest always setting that reduction to zero. I wonder why the default was 50 if this is a problem and there isn't much processor load. Well, maybe there is dependent on the processor and the project.

Maybe this is also a safety setting for some (older) hardware synths that get into trouble if too many midi messages are sent.

 

[Lukas]

I wonder why the default was 50 if this is a problem and there isn't much processor load. Well, maybe there is dependent on the processor and the project.

No computer will have any issue with that but (especially older) MIDI hardware devices might have. In the 80s and 90s memory was rare and nobody thought storing/sending that many CC messages (don't forget MIDI bandwidth and multitimbral devices that can receive on 16 MIDI channels as the same time) would ever be a thing.

 

[ianaeillo]

After four months of no solutions from support or community, I stumbled upon a solution. It's an obscure setting and I'm astounded that no one in the community or in tech support after many months had an inkling of this.

In preferences, under advanced, there is a setting under Automation called "Reduction Setting". It is by default set to 50 (0-100). I looked this up in the manual and it says that it also affects MPE data. So, I switched it off, or to "0". MPE pitch playback is working now. I'm not sure how this may affect my processor load, but it works.

Four months of no accurate MPE pitch playback and absolutely NO ONE at PreSonus support or community had a clue.

WHOA. My Chase Bliss CXM now works FLAWLESSLY whereas before it was often choppy and often would fall out of sync with sent data. THANK YOU.

 

[ThomasM]

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.

Will not change in ANY industry any time soon. Look at cars for instance. Or medicals.

In a way it is tied to company

If there is a rampant bug - the users will let the company know - loud and clear - well before a thousand tickets are submitted.

Like @stanft - I work for a very large company and we do very large development. Trust me when I say that we really do not want more than one ticket on any bug - regardless of it's severity.

And like @stanft - we run a tight ship and duplicates on any issue - are deleted.

VP

The question is not if there is 1,14 or 1001 tickets in the developers backlog. That is somewhat irrelevant. There should be only one.

The point I'm trying to make is that the voice of the customers, and the number of those voices are important. Where I work, no external user can create a ticket, everything is handled through customer support and then escalated/prioritized by a product manager according to number of customer interactions as well as new features vs bug fixes.

When/if there actually is a bug that needs fixing then, and only then, a ticket is created.

And trust me as well I've done this for 17 years.

 

[Vocalpoint]

The point I'm trying to make is that the voice of the customers, and the number of those voices are important.

Not disagreeing with the importance of "voices"

However - if there is any type of serious bug in Studio One - the "voice of the customer" will let Presonus know - in literally minutes. On this forum and every other forum. No ticket needed. That's how fast it happens now.

And with respect to the example that started this:

The OP seems to think that if we (The user base) sends in 500 tickets for a single issue - that will somehow magically increase it's priority or automatically "get someone on it".

My opinion on this (based on 20+ years of prioritizing large developments teams and projects) - is that it will not.

That is all I am saying

VP

 

[ThomasM]

Not disagreeing with the importance of "voices"

However - if there is any type of serious bug in Studio One - the "voice of the customer" will let Presonus know - in literally minutes. On this forum and every other forum. No ticket needed. That's how fast it happens now.

And with respect to the example that started this:

View attachment 936

The OP seems to think that if we (The user base) sends in 500 tickets for a single issue - that will somehow magically increase it's priority or automatically "get someone on it".

My opinion on this (based on 20+ years of prioritizing large developments teams and projects) - is that it will not.

That is all I am saying

VP

I think we may have a language discrepancy (my fault). A "ticket" could be a "ticket" raised/created at customer service. I think you mean "ticket" as in a Jira-ticket for development. Yes? In my world the amount of tickets from customer service (we don't have people searching through web forums for user concerns, serious users contact us directly) is the base for prioritizing dev "tickets". I have a hard time understanding how else a customers concern could be raised, the more voices for a single subject/bug, the more serious it might be. Needs to be handled accordingly.

And I have a hard time believing that a ticket raised at any "open website" is created as a Jira-ticket for a dev team? It sure must be a "ticket" for customer service to handle?

With that said, we have neglected several "tickets" that simply doesn't comply with our vision of our product(s), even if the number of voices are "many".

Aaanyheeew, I believe the OP has a point though.

 

[Vocalpoint]

A "ticket" could be a "ticket" raised/created at customer service.

A "ticket" (in my world) can only come in via customer support. It is analyzed - and sent to a queue for the DEV team to review - if the issue warrants it. What they do with it and how they categorize it for priority and so on - is up to them. And ONLY them.

But from that moment on - once a existing ticket for an issue has been cataloged - any further "tickets" for the same issue are quickly scanned for new data (if applicable) and then deleted.

And I have a hard time believing that a ticket raised at any "open website" is created as a Jira-ticket for a dev team? It sure must be a "ticket" for customer service to handle?

When I speak of any "open website" - like say a forum discussion where an S1 issue blows up as soon as it's discovered and then travels like wildfire from one forum site to the next - this of course is not a "ticket" for Presonus DEV.

This would be a known rampant fault - effecting possible hundreds of thousands of users all at the same time. It is an issue that Presonus DEV would be made aware of VERY quickly by either forum employees, colleagues at other companies, emails and countless other vectors.

These are real time discovery that could need immediate work - and if serious enough - a very fast hotfix.

But regardless of severity - these usually still only need a single "ticket". Logged and catalogued like all the others.

To close - it is very important to remember - often what appears to be a major "issue" to a user - is usually far from it for a typical DEV team.

In my case - at my company - even if somehow users were able to submit 178 tickets for a single issue - and those 178 tickets actually reached the DEV team - that still means nothing in the scope of priority or when an issue gets looks at. DEV (where I work anyway) has their own view of the world and how everything fits into it - no amount of "pressure" - via a huge pile of tickets - is going to fundamentally change how they approach an issue. Unless it is a showstopper - where the app/system simply cannot be used for it's intended purpose.

Presonus DEV of course - will have their unique way of working - but I am guessing it is not far from the above.

VP

 

[Craig Anderton]

Some consumers aren't aware issues that may seem easy to solve are actually difficult to address, while issues that might seem complex are solved easily. I know nothing about coding. But I've worked with companies that prefer to fix multiple simpler bugs for a given update instead of one complex bug, unless it's a showstopper. That doesn't mean they ignore the complex bug. They wait until the time opens up to address it.

Or, they might wait until the most efficient opportunity to fix bugs. For example, suppose there are several annoying, but not horrible, automation bugs. If a company is planning to overhaul automation in the next release, they may not bother fixing bugs that won't be relevant in a few months.

Companies are often not transparent about software because it's too easy to think it's possible to do something, only to find out it's much more complex than anticipated. Announcing something and then not being able to do it is more negative to users than not promising something in the first place. Beta testers know that sometimes features are dropped at the last minute because of some unexpected issue. Conversely, sometimes a new, unanticipated feature gets slipped in because someone figured out a way to do something clever.

Again, I can't code, but to me it looks like a hellishly complex task to wrestle with hundreds of thousands (or millions!) of lines of code that all interact with each other. If Apple and Microsoft can't get it right with billions of dollars of resource, I don't expect smaller companies to surpass what giant corporations with unlimited resources can do.

 

[wdkbeats]

Hi

Didn’t Presonus say they were going to roll out 4 major updates per year?

Considering it’s April and we are on version 7.1 that gives Presonus only 8 months to release 3 new major updates….

I'm pretty sure there will be no 4 major updates this year.

 

[Vocalpoint]

I'm pretty sure there will be no 4 major updates this year.

And do not forget - Studio One V7 - came out on Oct 9, 2024.

So it's first real "year" is coming up in less than 5 months now.

VP

 

[ThomasM]

A "ticket" (in my world) can only come in via customer support. It is analyzed - and sent to a queue for the DEV team to review - if the issue warrants it. What they do with it and how they categorize it for priority and so on - is up to them. And ONLY them.

But from that moment on - once a existing ticket for an issue has been cataloged - any further "tickets" for the same issue are quickly scanned for new data (if applicable) and then deleted.



When I speak of any "open website" - like say a forum discussion where an S1 issue blows up as soon as it's discovered and then travels like wildfire from one forum site to the next - this of course is not a "ticket" for Presonus DEV.

This would be a known rampant fault - effecting possible hundreds of thousands of users all at the same time. It is an issue that Presonus DEV would be made aware of VERY quickly by either forum employees, colleagues at other companies, emails and countless other vectors.

These are real time discovery that could need immediate work - and if serious enough - a very fast hotfix.

But regardless of severity - these usually still only need a single "ticket". Logged and catalogued like all the others.

To close - it is very important to remember - often what appears to be a major "issue" to a user - is usually far from it for a typical DEV team.

In my case - at my company - even if somehow users were able to submit 178 tickets for a single issue - and those 178 tickets actually reached the DEV team - that still means nothing in the scope of priority or when an issue gets looks at. DEV (where I work anyway) has their own view of the world and how everything fits into it - no amount of "pressure" - via a huge pile of tickets - is going to fundamentally change how they approach an issue. Unless it is a showstopper - where the app/system simply cannot be used for it's intended purpose.

Presonus DEV of course - will have their unique way of working - but I am guessing it is not far from the above.

VP

Yes. I think our teams work in similiar ways, just the language making a mess really. BUT, in my world a ticket can be created by another team that is in need (or have found a bug) in code that is owned by our team.

And yes, a "ticket" is handled the same way at my place. But the amount of customers contacting customer service is seriously taken in consideration when prioritizing. So in my world, the OP still has a point

I'll stay silent now. Thanks for the discussion.

 

[madFloyd]

I wonder how many developers are still on Presonus' Studio One team. Maybe the new payment scheme resulted in poor revenue and there were layoffs, or perhaps some key developer resignations that impacted key features that were part of the next release.

There's got to be a reason they haven't been able to deliver on promises and are keeping silent.

 

[Lukas]

I wonder how many developers are still on Presonus' Studio One team.

The number of developers is actually growing - and they're hiring.

There's got to be a reason they haven't been able to deliver on promises and are keeping silent.

PreSonus generally doesn't communicate publicly about upcoming updates or features until they’re ready to release something. So it's not unusual or cause for concern. And yes, a new update is coming soon.