• 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?

Status
Not open for further replies.
I didn't express it clearly. I mean, the file of 7 can't be opened by 6.

That is by design and not a drawback in any way. That is simple design logic.

How would v6 have any idea how to address a v7 file if v6 has no knowledge of the newer file versions capabilities?

VP
 
Fair enough.

Not a Mac user as you can tell and that platform can be troublesome at times - for some users.

But stay far away from AU is my first tip. All plugins in S1 on Mac should be VST3.

If there is something else happening - besides AU issues - that could be environmental to your specific situation and not a symptom of a larger "Mac-centric" issue.

Tons of folks in here use S1 on Mac with zero issues.

VP
 
It would be great if this feature could be built-in.

I obviously don't speak for anyone other than myself, and I'm not a programmer. But I assume it's difficult to justify adding a feature to a program that provides a temporary solution needed by a limited number of people, especially if there's a workaround for those who do need a solution.
 
I assume it's difficult to justify adding a feature to a program that provides a temporary solution needed by a limited number of people, especially if there's a workaround for those who do need a solution.

Agreed. DEV does need to address that specific feature if Studio One Toolbox does it already.

Let DEV deal with more global enhancement.

VP
 
I obviously don't speak for anyone other than myself, and I'm not a programmer. But I assume it's difficult to justify adding a feature to a program that provides a temporary solution needed by a limited number of people, especially if there's a workaround for those who do need a solution.
You are right, and I support your point of view. It's just that, you know, in some developing countries, it is difficult to access English websites such as Google. I'm not kidding, this is because of some policies. (눈_눈) Of course there are also language barriers and the like. I will introduce these solutions to my friends who need this function. It's just that what I can do is obviously limited, so I think maybe built-in is a good solution? Of course, I know that this is not a problem of Presonus nor a problem that Presonus can solve. It's very complicated ╮(╯_╰)╭, and I also understand that Presonus, as a company, needs to continue to make profits and make decisions prudently, so for me, I can actually accept not adding this function for the time being. Again, we all hope that Studio One will get better and better. (๑•̀ㅂ•́)و✧
 
That is by design and not a drawback in any way. That is simple design logic.

How would v6 have any idea how to address a v7 file if v6 has no knowledge of the newer file versions capabilities?

VP
It’s an incredible drawback when working with clients who want to use Studio One in the cloud with workspaces. While I have to stay current with my clients who use Studio One 7, I also have to cater to individuals who run older versions. As it is, I have to break sync, resave the session using Lukas’s brilliant workaround, and upload the session in the format that the client is using if they don’t happen to be able to / want to update. I donated to Lukas simply because of this workaround. It has saved me dozens of times.

Pro Tools does this and it works wonderfully. I keep Pro Tools 10 on a 2012 Mac Pro because I do not want to pay avid more money than I have to. I bring projects home from freelance jobs in rooms using the newest versions of PT and they open with zero problems. I get a dialogue box telling me that certain options might not be compatible as it was saved in a newer version. I edit my sessions at night and bring them back to the shop the next day. It even has a compatibility save option for people using versions older than PT5.

That same computer runs logic 10.4, with which I open sessions created at a local jazz club that uses 10.6.

It can be done, but they don’t. I don’t fault them for not doing it though. It’s about money and forced version updates and I get that it’s probably such a small user base that needs it, but the absolutely wonderful convenience of Workspaces and Presonus Cloud really expamded my ability to interact with remote client performances and mix expectations in a way that I could never have imagined. But if the other person isn’t on the newest version, well, I have to jump through way too many hoops to procure that convenience.

We are very lucky to have Lukas helping solve these problems.

Ian
 
That is by design and not a drawback in any way. That is simple design logic.

How would v6 have any idea how to address a v7 file if v6 has no knowledge of the newer file versions capabilities?

VP
There are DAWS that can handle forward compatibility - Pro Tools does, and I think Reaper can too.
In the case of Pro Tools, the "song" file contains details relating to new features in a way that an older version can interpret and work with. Moving a "song" back and forward between versions isn't guaranteed to be seamless, but it does work. It requires design of the session file and the upgrades in a way to accommodate it, which is not an easy task.

Dominic
 
It can be done, but they don’t. I don’t fault them for not doing it though. It’s about money and forced version updates
You could also reframe your PoV : maybe (unlike their competitors) the overall file structure is widely spread across program code and tightly bound to the program core. So it could be possible to change it, but at the cost that some other stuff may get broken over the course of this process (you'll never find all possible bugs yourself, so the entire userbase becomes beta tester - even those, who don't need this feature). This would lead to other complaints.

None of us know the codebase, so no one can tell potential effort "costs".
 
You could also reframe your PoV : maybe (unlike their competitors) the overall file structure is widely spread across program code and tightly bound to the program core. So it could be possible to change it, but at the cost that some other stuff may get broken over the course of this process (you'll never find all possible bugs yourself, so the entire userbase becomes beta tester - even those, who don't need this feature). This would lead to other complaints.

None of us know the codebase, so no one can tell potential effort "costs".
Absolutely. And I'm not faulting them for not attempting to do it, even if it is just about money (I want Studio One to be super successful after all!), let alone introducing bugs. Just responding that it is indeed a wanted feature (albeit from a VERY small percentage of users) and one that has precedent set both by competitors and by Lukas. Of course the devs are aware of the work done by Lukas on compatibility and their reasons for not implementing it are undoubtedly partly due to what you mention.
 
There are DAWS that can handle forward compatibility - Pro Tools does, and I think Reaper can too.

Totally understood. But they are not Studio One. It is what it is.

That said - I still do not understand any point whatsoever to "forward" compatibility.

For me - personally - once I move from v6 to v7 - any old projects are instantly brought forward and off I go. v6 would be discarded almost instantly.

Granted there are other different use cases - like moving a session between physical studios that are on different versions? But if that's is not you - I still would need someone to walk me through the only one I can think of:

  • I upgrade from v6 to v7
  • I create a hot new session IN 7 (which I am super excited about because I just bought it)
  • Then inexplicably - I would somehow "need" to open that hot new track in v6?
Been using S1 since 2011 - and have to be honest - that last bullet point is non-existent to me.

Let's discuss.

VP
 
Totally understood. But they are not Studio One. It is what it is.

That said - I still do not understand any point whatsoever to "forward" compatibility.

For me - personally - once I move from v6 to v7 - any old projects are instantly brought forward and off I go. v6 would be discarded almost instantly.

And I do understand there could be other different use cases - but I still would need someone to walk me through the only one I can think of:

  • I upgrade from v6 to v7
  • I create a hot new session IN 7 (which I am super excited about because I just bought it)
  • Then inexplicably - I would somehow "need" to open that hot new track in v6?
Been using S1 since 2011 - and have to be honest - that last bullet point is non-existent to me.

Let's discuss.

VP
In some countries where the division of labor in the music industry is not so perfect, you never know what strange things your customers will give you and what strange requests they will make. Sometimes you have to ask them for a project file to see what happened. Sometimes, they will just throw the project file to you and ask you to complete the next step.

When your friends use Studio One 7 and you use Studio One 6, trouble arises.

Unfortunately, the goods are not priced according to the real income level of different countries, so quite a lot of people don't want to upgrade.

I can understand that in some developed places such as Europe or the United States, it is difficult for people to understand this kind of thing, but this "unprofessional" situation is the norm in many places.
 
When your friends use Studio One 7 and you use Studio One 6, trouble arises.

Respectfully - this has nothing to do with Studio One's ability to "forward" navigate song structures and everything to do with you and your upgrade cadences.

I am not going to get into any discussions about your income levels or any other part of your personal situation - except to say - if you are choosing to be in the audio game - in any way - there are unavoidable costs that everyone must make peace with.

If you choose not to keep up your S1 versions to match that of your friends - that is a decision you - and you alone - will need to address.

VP
 
Very strange. It is precisely because it does not have this ability that users have to pay. Users have to upgrade and pay money, which is the intuitive cost caused by this problem.:oops:

Again - no one is forcing you to do anything. If you cannot afford an upgrade - that is fine.

What is very strange (to me anyway) is an expectation that Presonus rewrite the software to not only accommodate (and shield) you having to purchase an upgrade (even on a reasonable cadence) but also to basically guarantee you never need to buy anything again - as you would simply stay on your old version - forever - if this came to pass.

This is a business. Everyone over there working on this wonderful piece of software needs to be paid as well.

Think about this in those terms.

VP
 
Last edited:
  • Like
Reactions: AAV
Again - no one is forcing you to do anything. If you cannot afford an upgrade - that is fine.

What is very strange (to me anyway) is an expectation that Presonus rewrite the software to not only accommodate (and shield) you from an inability to purchase an upgrade (on a reasonable cadence) but to basically guarantee you never need to buy anything again - as you would simply stay on your old version - forever if this came to pass.

This is a business. Everyone over there working on this wonderful piece of software needs to be paid as well.

Think about this in those terms.

VP
我累了,我决定停止使用翻译软件。

没人说有谁强迫我,也没人说我付不起一款软件的钱,更没人说开发软件的人不应该得到报酬。是你在问“什么场景下会用到这个功能”,我回答了你的问题,给出了会用到这个功能的场景。你就非说这是用户不愿升级导致的,你这不纯逆天。多给不爱升级的一个机会和选择怎么了,这是非常反人类的事情吗?

再退一步,我作为一个用户,我是购买的产品,不是来向公司乞讨来的产品,我还不能提意见了?我作为用户凭什么要处处为公司着想?公司应该为了他的利益和市场份额处处为它的用户着想!
 
Again - no one is forcing you to do anything. If you cannot afford an upgrade - that is fine.

What is very strange (to me anyway) is an expectation that Presonus rewrite the software to not only accommodate (and shield) you having to purchase an upgrade (even on a reasonable cadence) but also to basically guarantee you never need to buy anything again - as you would simply stay on your old version - forever - if this came to pass.

This is a business. Everyone over there working on this wonderful piece of software needs to be paid as well.

Think about this in those terms.

VP
I think when they introduced workspaces and allowed for easy sharing across platforms and continents through the integrated Workspaces, it became an issue. I have clients who use various versions of Studio One. When I am editing their project and returning them for further overdubbing, you have to break sync in Workspaces to allow them to open up a project. I dunno if you somehow missed my very detailed explanation of the problem.
 
I understand the problem well. I was working with an artist who had Studio One 5 and I was using Studio One 6 at the time. Fortunately she was generating the tracks, not me. I downloaded Studio One 4 and worked on tracks her in that. Once I had done all the necessary editing and she was ready to have me do the final mix, I loaded the project in Studio One 6 to complete it. I made it clear to her that once I started mixing, it would not be possible for her to load the song in her computer and make any changes, but there were other solutions. For example, if she wanted to add an overdub, I could send her a premixed WAV file. She could then load that, add the overdub, and send me the overdub file to add to the project on my computer.

Sending premixes works very well. I did that on a remix of a song by Chuck D from Public Enemy. I was collaborating with Brian Hardgroove, who uses Cubase. We sent premixes back and forth, and overdubbed or rendered parts on our machines. Eventually we ended up with the same collection of rendered WAV files, he had them with Cubase and I had them with Studio One. I wish we'd had .dawproject back, it would have helped when we were first starting the project.
 
I dunno if you somehow missed my very detailed explanation of the problem.

Ian,

Respectfully - I was not responding to you - specifically. Nor did I read your use case - my apologies.

I agree - exchanging projects with actual clients is a great use case but it is one that Presonus - who decided the entire concept of Workspaces was a good idea - should be responsible to address.

That said - since Presonus (if anyone) should be keenly aware of challenges posed with Workspaces due to project compatibility - I do find it telling that they seem to only ever allow only "backward" compatibility.

I suspect this concept of opening a v7 project - byte for byte - in v5 - borders on a technical impossibility rather than a "non-willingness" to accommodate users such as yourself.

Making "forward compatibility" a reality would likely stunt any future enhancement to the .song format and put the majority of the user base (like me) in a position where we would need to bear the brunt of a static locked file format - in favor of a minority who needs "forward compatibility".

VP
 
I suspect this concept of opening a v7 project - byte for byte - in v5 - borders on a technical impossibility
While there's definitely some truth here, there are programs that offer features to export a song file for previous versions of the program. So it's basically a feature request.
 
While there's definitely some truth here, there are programs that offer features to export a song file for previous versions of the program. So it's basically a feature request.

Agreed - but the way I read this discussion - there seems to be some expectation of a "non-export". As in - simply fire up v5 or v6, select a v7 file and away you go.

No one mentioned building out an "forward compatible" export - which would surely complicate the online concept of Workspaces - but would solve the general concern.

VP
 
Agreed - but the way I read this discussion - there seems to be some expectation of a "non-export". As in - simply fire up v5 or v6, select a v7 file and away you go.
Yes, this expectation doesn't make any sense, as it would be highly unusual for software in general. It would require the file format to never change - or to be designed for this kind of capability from the start, which is extremely complex and ultimately unjustifiable.
 
Status
Not open for further replies.
Back
Top