Studio One 7.2 - Discussion Thread

[ianaeillo]

I just can't get over how good the audio engine upgrades are on this release. Simply perfect. Fantastic release.

 

[js1]

It's not even genre-dependent though, my only real use for stem-sep. as a producer currently is making vocal rehearsal/karaoke tracks, it's just not something that's high on my list of concerns personally.

Essentially if you're super concerned about stem separation you just buy an app that specializes in it, and if you're more concerned about producing music with a proper powerhouse DAW a la Studio One you probably won't need to use it very often.

Though I'm a rock/americana type, I've found stem separation to be surprisingly useful.

I'm a reasonably active gigging bassist that does sub work. Stem separation makes it way easier to hear the subtleties in the parts that I have to quckly learn.

I've used it to rebalance the audio on live gig videos taken with an IPhone.

And I've used it for mix references. In Metric AB (great plugin), I'll not only load in the full reference track, but the stems as well. Even though the stems have artifacts, having isolated references for the drums, vocals and bass can really help.

 

[Musicmountain]

● Audio engine dropouts occur on real-time export in specific cases

Unfortunately not solved in my case.

Edit:
On my PC it works. After reinstall on my Mac it worked there too.

 

[danam]

It's just such a niche task, particularly for users of such a powerhouse DAW as S1; Ableton users might seem like a more ideal target market, for instance, or some DAW that sees the lion's share of EDM/LOOPmaking dudes who want to yoink some samples out of someone else's full MIX.

It's not even genre-dependent though, my only real use for stem-sep. as a producer currently is making vocal rehearsal/karaoke tracks, it's just not something that's high on my list of concerns personally.

Essentially if you're super concerned about stem separation you just buy an app that specializes in it, and if you're more concerned about producing music with a proper powerhouse DAW a la Studio One you probably won't need to use it very often.

Also it's very tough to have to compete against Steinberg in this arena, as Spectralayers is essentially at the very head of the pack for this kind of thing and it's super simple to de-mix in another app and simply drag the resulting stem into S1.

The Post/Pre roll counts are OK, I guess?

Practically speaking you would simply set the loop range to include the necessary time to breathe/rest in between takes when loop recording during tracking, so the only real savings here are slightly more compact/efficient takes, but not really even since when you were done with the take you would simply trim the event start/end handles to clean it up in the arrangement.

Only thing that's really turning me on thus far is continuous-scroll, that will be a headache-saver in large projects potentially I think.

Ok, so you are underwhelmed with 7.2, but I respectfully disagree with your assumption how useful stem seperation and loopable pre/post roll are to users (other than you obviously):
1. stem separation: I did not have a tool for it yet and it is very nice to not have to install/buy/learn another tool/service for it. Having it integrated in my DAW of choice is just a time (and money) saver.
2. loopable pre/post roll: Nobody said that looped take/punch recording was not possible before. But the way you described it (and I guess we all are familiar with it) was from my point of view just a hassle compared to how it should have been from the start. Especially if you prefer to record a couple of tracks with multiple takes in one go and then edit/comp them all afterwards. You had to do a lot more of event trimming than necessary. Also: while the pre-roll is "rolling" you can still hear the already given audio on the track up to the point where the punch in starts (if you like to have that). It is a way more efficient way of doing looped take recording after all, especially if you want to do it hands free on your own. So am happy that we have it now finally. Personally I would have preferred it slightly different (just "copy" the loop feature (in all its glory) as punch in/out area), but I am fine with the way it is done.

 

[TonalDynamics]

Though I'm a rock/americana type, I've found stem separation to be surprisingly useful.

I'm a reasonably active gigging bassist that does sub work. Stem separation makes it way easier to hear the subtleties in the parts that I have to quckly learn.

I've used it to rebalance the audio on live gig videos taken with an IPhone.

And I've used it for mix references. In Metric AB (great plugin), I'll not only load in the full reference track, but the stems as well. Even though the stems have artifacts, having isolated references for the drums, vocals and bass can really help.

Heh, you're hitting the nail on the head man, I use stem sep for rehearsal and practice tracks, and mix references as well, but I wouldn't call those a 'production' task per se... like it's a POST-production task right, and not really an engineering task I'm remotely interested in doing during the actual recording process, is my point I guess.

But I want to caution you very deliberately here about using stem separation for A/B references in lieu of having the raw tracks in front of you... you're doing so at your peril basically because stem. sep's quality varies per instrument, PER song, and PER phrase — i.e., in a bass heavy song your bass sep. is going to be inferior if there's a cello playing in the same octave, and you almost ALWAYS lose overtones around 4k-7k in the HI end when separating a bass instrument... but those overtones are essential in the clarity of the whole bassline.

This generally leaves you with a 'reference track' that is VERY untrue to life; those frequencies simply get sucked out with the cymbals and guitar lines that share the same freq. range.

Also bass note attacks ALWAYS get reduced along with the kick-thump; this is not because the model is 'stupid', it's because the kick thump and bass note attack exist in practically the same frequency domain, and thus it will never be 'perfect' extraction anywhere near good enough to be used for engineering/reference purposes.

In short for rehearsal track tasks stem separation is great, but if you want a critical listening/bass reference tone, just find a section in a song you like that features a part where the bass is solo (the intro to Muse -- Hysteria being an ideal example that comes to mind). De-mixing the part just sucks out too many crucial frequencies to be used for that purpose, at least in my (quite extensive) experiments.

Like I said Steinberg leads the pack in this area and as a Spectralayers user I'll probably never feel compelled to use it in S1... I like using POST-prod suites for POST-prod tasks, funny enough.

Glad you're getting mileage out of it, you're using it in the best possible way IMO.

 

[Number6]

I was going to skip the 7.x.version, upon release there was nothing that really applied to me. But all the other releases after that, and then 7.2 forced me to pull the trigger. I'm interested in quick and easy workflow more than anything.

 

[TonalDynamics]

2. loopable pre/post roll: Nobody said that looped take/punch recording was not possible before. But the way you described it (and I guess we all are familiar with it) was from my point of view just a hassle compared to how it should have been from the start. Especially if you prefer to record a couple of tracks with multiple takes in one go and then edit/comp them all afterwards. You had to do a lot more of event trimming than necessary.

No you're not wrong, it's definitely neater, but to be clear let's say I'm loop-tracking, which takes me 5 minutes; it takes me literally 5 seconds to trim the resulting events to the precise bar/beat that I want to in order to neaten it up. So it sounds cool on paper but functionally it's not particularly useful for me while working.

Also: while the pre-roll is "rolling" you can still hear the already given audio on the track up to the point where the punch in starts (if you like to have that)

I'll push back a little bit here and say that if an artist needs a 'guide track' to help cue them for the next take, they likely want to hear the full decay of said track, as opposed to having it be cut off abruptly, which still happens with the new implementation, you just hear happen right at the punch-point which can be even more jarring.

But I do get what you're saying. I just have never worked this way in digital; on tape you HAD to punch in on the same track, because well it was tape.

In digital it makes more sense to me to simply record an artist's overdubs onto a duped track and then drag the resulting layers in...

What we REALLY need is a way to continue loop-recording on the same EVENT, even after stopping playback.

(WARNING: Slightly deep-dive into loop-recording workflows, bear with me here

Let's say I loop-record a vocalist on a particularly tricky phrase, we do 10 takes and she's getting a bit fatigued.
OK so it's time to take a breather. We hit the coffee machine, she comes into the control room to listen for a bit, we talk it over and I give guidance and direction if needed. cool.
5-10 mins. later I come back and it's time to start loop-record/punching again.

Here's the issue under the current loop-record implementation:

• Let's say I have a 20-layer track (generally enough to handle the dub/COMPs throughout that entire track for the song)
• I can't simply continue loop-recording, I have to empty the takes out into layers first; OK, I have to 'unpack takes to existing layers', delete the previous track session event off the timeline, then start recording again; annoying, but easy enough to do the first time
• She completes a 2nd set of loop-takes
• Suddenly now I can no longer 'Unpack takes to existing layers', because they overwrite the takes that I already placed in the first layer set from the first set of takes. Instead, I am forced to 'unpack to new layers', which gives me a bunch of extra layers I don't want in the track; the only solution to this is to manually drag the takes from the new redundant layers into the existing layers on my track, and then DELETE the unwanted/extraneous layers; this is immensely tedious and costs a lot of time during the actual recording/tracking process (when time is MOST critical).

^ If anyone knows a better way to do what I just described above, I'm all ears.

In light of the above I simply choose to use a dedicated DUPE track for tracking purposes as I mentioned above, and then simply 'unpack takes to NEW layers', and drag those specific takes into the master track. Sounds like this would take a lot of time, but it takes no more time than the tedious process I outlined above and it has the added benefit of not mucking about and potentially erasing shit off the 'Master' track with all the good takes in it.

(TLDR) What we really need to improve loop-recording is a way to append new takes to the SAME event container, so that we can take breaks between loop-tracking for people to recover a bit, and continue without making the giant mess I described.

I agree that the pre/post roll is a more sensible implementation, it just doesn't 'turn me on' so to speak, compared to the 2 dozen-odd FRs that I and others have been waiting on for a long time now, such as the improvement I outlined above or (gasp) automation presets for example.

As a producer 80-90% of the improvements I want to see in Studio One are refinements/overhauls of existing features, which are long overdue... but I'm not a 'new user' so marketing teams aren't particularly concerned with what I want.

 

[Number6]

As a producer 80-90% of the improvements I want to see in Studio One are refinements/overhauls of existing features, which are long overdue... but I'm not a 'new user' so marketing teams aren't particularly concerned with what I want.

Word.
And right now it looks like they are on the right track..let's see how long it lasts.

 

[danam]

Here's the issue under the current loop-record implementation:

• Let's say I have a 20-layer track (generally enough to handle the dub/COMPs throughout that entire track for the song)
• I can't simply continue loop-recording, I have to empty the takes out into layers first; OK, I have to 'unpack takes to existing layers', delete the previous track session event off the timeline, then start recording again; annoying, but easy enough to do the first time
• She completes a 2nd set of loop-takes
• Suddenly now I can no longer 'Unpack takes to existing layers', because they overwrite the takes that I already placed in the first layer set from the first set of takes. Instead, I am forced to 'unpack to new layers', which gives me a bunch of extra layers I don't want in the track; the only solution to this is to manually drag the takes from the new redundant layers into the existing layers on my track, and then DELETE the unwanted/extraneous layers; this is immensely tedious and costs a lot of time during the actual recording/tracking process (when time is MOST critical).

^ If anyone knows a better way to do what I just described above, I'm all ears.

I don't understand why you work so complicated. Why don't you just activate the recording mode "takes to layers" and call it a day? Each take (no matter how many times you start/stop the recording) gets a new layer automatically if there is already a layer with events in the area you recorded. If not, given layers are used. Comping afterwards is easy.

 

[TonalDynamics]

I don't understand why you work so complicated. Why don't you just activate the recording mode "takes to layers" and call it a day? Each take (no matter how many times you start/stop the recording) gets a new layer automatically if there is already a layer with events in the area you recorded. If not, given layers are used. Comping afterwards is easy.;

Great question!

For me it's a very specific reason:

I identify my tracking by event names, which I also apply to the .wav filenames.

This naming is highly specific to keep track of everything with my own shorthand; I know which mic, amp, cab, guitar, etc., was used on every single take due to this, right down to which pickup was used, for example (the shorthand changes depending on the instrument), as everything is right there in the layer event name.

If you record 'takes to layers' you have to rename each individual layer after they are recorded;
With my technique, you simply name the event itself, then unpack the takes, and voila, they all get labeled properly with 'Take 1-10' etc. suffixed to the layer event for you automatically.

But incidentally I actually did not realize that 'takes to layers' checked for events in the layer space and writes events into next empty OR creates a new layer; this is very cool! I tested this method a long time ago only to be dissatisfied by something (this was back before the layer rework, I think it overwrote stuff in a way I didn't like so I abandoned it but it was a very long time ago so I don't recall exactly)

Good to know that it works intelligently like this without overwriting stuff now; you've given me something to play around with.

I'd be sad to lose my auto-naming trick but you've got me wondering if using 'takes to layers' and subsequently renaming them all via copy+paste wouldn't be faster overall now

 

[TonalDynamics]

Word.
And right now it looks like they are on the right track..let's see how long it lasts.

I am saying that from the producer perspective, they are not on the right track, without going into the two-dozen longstanding feature requests focused on improving existing features that continue to go ignored in favor of 'flashier' items that in reality don't have much substantive effect on improving speed and quality of workflow.

Just to clarify that

 

[Number6]

From my perspective, looking all the way from 7.0 to 7.2, not only are they delivering flashy, they are also delivering boring workflow and UI improvements which is why I"m happy.

 

[ThomasM]

I'm thinking that I'm "content" with the updates since 7 perhaps because I get the updates for free but neither update would have had me pay for an upgrade if my license had expired.

 

[lokeyfly]

I am saying that from the producer perspective, they are not on the right track, without going into the two-dozen longstanding feature requests focused on improving existing features that continue to go ignored in favor of 'flashier' items that in reality don't have much substantive effect on improving speed and quality of workflow.

Hi TD, I think many will convey their needs for particular improvents that not only benefit them, but many on a whole. After all, a good number of requests just plain make sense. And each requester has enough background to substantiate those needed features as useful. Most of those requests dont drag performance down as well. On a whole, just use what works for you in its current iteration, and continue to politely stress as you do whats still needed here (briefly) or more in-depth on its own thread [way more visible]. Obviously, its a discussion here, and largely moot until the request is in the Presonus request forum. Placing FR ideas there doesn't garuentee anything either. We know that. Still, that location is at least a placeholder for you to link others to, when the conversation comes up. That would be a descent stratagy, if we're attempting to put our best foot forward. At least how I see it.

FWIW, I believe some of the new v7.2 features will benefit many users on a whole, over the older down rev Studio One versions. Of course those improvements will vary depending on each person's needs.

So keep the good ideas coming, but writing chapters on what's still wrong or needed in a version discussion thread, is going to simply get buried in another day or three. Just my two centavos. : )

 

[lokeyfly]

Great question!

For me it's a very specific reason:

I identify my tracking by event names, which I also apply to the .wav filenames.

This naming is highly specific to keep track of everything with my own shorthand; I know which mic, amp, cab, guitar, etc., was used on every single take due to this, right down to which pickup was used, for example (the shorthand changes depending on the instrument), as everything is right there in the layer event name.

If you record 'takes to layers' you have to rename each individual layer after they are recorded;
With my technique, you simply name the event itself, then unpack the takes, and voila, they all get labeled properly with 'Take 1-10' etc. suffixed to the layer event for you automatically.

You shouldnt have to rename each layer. A layer is only part (a pass if you will) of that track. If you name the track, the layer (while only named as a layer number) is really insignificant. That pass, or sections of those multiple layer passes will be promoted to the comped track. When bounced, they take on the track name. That track name in your case provides the mic used, and other relevant naming. This can be further seen from the audio pool. All of those passes are part of one track. That is, if we're talking about comping (promoting segments of a track). In the end, bounce the comped track, to solidify the track. Then, optionally delete the waste (or keep it as its still part of the track, only its under a different version like layer (2) instead of layer (3).

If you were to switch mics, and so forth. My guess is you could rename at that juncture, by starting a new track, place in a folder and keep everything dress-right-dress in line.
I'm only pointing this out as one observation. Another way is copy the comp elsewhere, promote whatever layer(s) you want, and bounce that. Rename as needed.

It just seems (in all respect) convoluted to rename layers, but I could be missing something.

But incidentally I actually did not realize that 'takes to layers' checked for events in the layer space and writes events into next empty OR creates a new layer; this is very cool! I tested this method a long time ago only to be dissatisfied by something (this was back before the layer rework, I think it overwrote stuff in a way I didn't like so I abandoned it but it was a very long time ago so I don't recall exactly)

Good to know that it works intelligently like this without overwriting stuff now; you've given me something to play around with.

I'd be sad to lose my auto-naming trick but you've got me wondering if using 'takes to layers' and subsequently renaming them all via copy+paste wouldn't be faster overall now

Yeah, check to your specific needs, but I think Danam's suggestion of comping, sounds right.
Mmv, but comping should be a get in and get out affair. Not store individual naming from each pass, but hey..... dont shoot me. Im only the piano player.
* Best to take this conversation to a thread. Didn't mean to side track the topic.

 

[danam]

This naming is highly specific to keep track of everything with my own shorthand; I know which mic, amp, cab, guitar, etc., was used on every single take due to this, right down to which pickup was used, for example (the shorthand changes depending on the instrument), as everything is right there in the layer event name.

I'd be sad to lose my auto-naming trick but you've got me wondering if using 'takes to layers' and subsequently renaming them all via copy+paste wouldn't be faster overall now

Ok, thanks for the explanation. If I understand correctly, you are combinig both typical usecases for layers in one track: take recording/comping AND versioning (like playing slightly different variations or playing the same part with different guitars). Maybe that is a bit of a stretch. But still possible without having to rename layers and takes manually in most cases. Just rename the track temporarily with the name you want to give the takes/layers you want to record/create.
Because you got my attention I played around with take recordings and layers and I made some interesting observations. I think you'll see it on your own in this video I just made:

Bildschirmaufnahme 2025-06-06 um 18.22.27.mp4

Shared with Jumpshare

jmp.sh

Nevertheless let me summarize:

- each take created while recording names itself according to "[track name]($ of wav file created with that track name) Take $" ($ = actual count)
- each layer created by recording names itself by "[track name] Take $"
- all takes recorded in one go are part of the same wav file and the wav files are renamed after track name + actual wav count

Now it gets interesting:
- If you record to another section of the song, S1 checks if there are already enough (empty) layers with the name it would give em and puts the takes there. Else it creates new ones !!!
- With new looped pre/post roll at auto punch each take is put into its own wav file

 

[Strom]

Hi y'all
Since updating to version 7.2, I’ve been having problems with copy and paste — it just stops working randomly. The only temporary fix is to close and reopen Studio One, which is very time-consuming.

I’ve already tried:
1.Restarting my computer
2.Uninstalling and reinstalling Studio One
3.Resetting user data via %appdata% (kept only user.license)
None of these helped.

When the issue occurs, Studio One becomes completely unresponsive. I’ve attached a video that illustrates the problem more effectively than I can describe.
This is really discouraging.

Is anyone else experiencing this issue?

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

Thanks in advance!

I have the same problem - with drag & drop of audio files (didn't try copy/paste)
Already posted it in the facebook group - but gonna copy it here:


I have a recent problem with 7.2. Been working on my audio drama in 7.1.1 for the last weeks. With a lot of audio files's dragging and dropping. Everything worked fine - as always before. Now it's the first time that I wanted to continue my work after updating to 7.2 (nothing else changed) and I just noticed that I can't drag and drop any audio file into Studio One anymore. The first 1-2 files work just fine - and than after some time the functionality seems to stop. I drag the file over the audio track and when I want to drop it (release the mouse button) it just disappears. The only solution is to restart Studio One - until it stops working again. Went back to 7.1.1 and everything works fine again?!?!?
Anybody else noticed this? What can it be? Some kind of permission?

 

[TonalDynamics]

So keep the good ideas coming, but writing chapters on what's still wrong or needed in a version discussion thread, is going to simply get buried in another day or three. Just my two centavos. : )

No I hear ya. I'm just providing 'sentiment' I suppose, I'm in the same boat as ThomasM up there really as far as not seeing anything in 7.x that inspires me to pay for an upgrade yet.

If you were to switch mics, and so forth. My guess is you could rename at that juncture, by starting a new track, place in a folder and keep everything dress-right-dress in line.

Best to take this conversation to a thread. Didn't mean to side track the topic.

No need for a diff thread, I'll just make one more post on it to 'wrap up' my loop-recording workflow rationale
(Also I guess it's kinda inspired by 7.2 since it features/has us talking about loop-recording improvements?):

In my case the tracks themselves serve as a lower order of organization, i.e. they list the instrument played, and the part that is being played (e.g., Riff A is always the 1st part for that instrument within a section, Riff B is always the overdubbed part played within the same section, and so on)

This allows me to essentially save on track space by re-using that audio track to host many passes and takes through the entire song and identifying said takes by the event names.

So as you point out I'd have to be renaming the tracks anyway, which takes the same amount of time as renaming the take-containing event before unpacking it as I do currently.

But you're right it does also mean I have to copy+paste the name before bouncing -- which I always do after I've completed a COMP, append 'COMP' to the newly chosen name -- but I don't do this until after the artist is gone/tracking is done in any case so it doesn't slow me down when time is of the essence.

Layer/take names essentially just give me more info about the recording session when I open up old stuff that I (invariably) forget about;
"Wait, which pass was this? Ahh ok so middle of the day... which mic? Oh, the 414 of course... which polar pattern? Why the hell did I use figure-8 there? Probably would sound better in Omni..." And so forth.

To be fair I am a huge nerd for this stuff, but in order to up your game sometimes you have to be.

 

[TonalDynamics]

Now it gets interesting:

Hey, thanks for taking the time to make this, very informative!

- If you record to another section of the song, S1 checks if there are already enough (empty) layers with the name it would give em and puts the takes there. Else it creates new ones !!!

Ahhh see but this won't do for me, because every time I want to rename my passes or takes with a gear/technique swap of some sort, it creates a new layer regardless of whether or not the arrangement is empty in that particular song section as you demonstrate @ 1:15

Also I'd be forced to use the .wav suffixing of (2), (3), (4), etc., to denote passes, which is a bit awkward as those numbers are often present just at the end of unintentional/deleted takes, etc., leading to confusion

My philosophy these days is "Use as few tracks and layers as possible, and no less"; so your method would bring me full circle to the same 'unpack takes to new layers' problem I outlined in my OP, essentially having to delete 'new layers' I don't want added to the track when I'm just trying to fill existing empty layers with loop-record.

With new looped pre/post roll at auto punch each take is put into its own wav file

Now this is interesting. Also proves that what I'm asking for (ability to stop/start loop-recording and keep adding 'takes' to the same event container before unpacking) is already possible within the tech.

This has been quite a good deep-dive... most stuff I knew, some stuff I didn't know.
Appreciate your insights.

 

[daw stew]

Hey, thanks for taking the time to make this, very informative!



Ahhh see but this won't do for me, because every time I want to rename my passes or takes with a gear/technique swap of some sort, it creates a new layer regardless of whether or not the arrangement is empty in that particular song section as you demonstrate @ 1:15

Also I'd be forced to use the .wav suffixing of (2), (3), (4), etc., to denote passes, which is a bit awkward as those numbers are often present just at the end of unintentional/deleted takes, etc., leading to confusion

My philosophy these days is "Use as few tracks and layers as possible, and no less"; so your method would bring me full circle to the same 'unpack takes to new layers' problem I outlined in my OP, essentially having to delete 'new layers' I don't want added to the track when I'm just trying to fill existing empty layers with loop-record.



Now this is interesting. Also proves that what I'm asking for (ability to stop/start loop-recording and keep adding 'takes' to the same event container before unpacking) is already possible within the tech.

This has been quite a good deep-dive... most stuff I knew, some stuff I didn't know.
Appreciate your insights.

Maybe I'm not understanding your predicament properly, but can't you simply use the Track Notes feature on the track you are recording on to detail the instrument, mic etc. that way you have a record of the track specific information