Can anyone with S1 3.x or 4.x help confirming a bug?

[antic604]

They are named correctly it's just your opinion that they are not. I don't agree with you on this one.

No, they're not. What does it mean "preserve realtime state" if you haven't read the explanation below it?

Okay if you know what the functionality does why does it matter?

Because it's redundant and inconsistent. And it's lazy development.

Are you just bored and have nothing better to do?

I'm on holidays until 4th of Jan

I'm not defending whether S1 should work this way or not but the easy solution is to merge those clip regions if you have long automation on them before transforming them to audio. S1 is not going to magically know what your intention is. It's basically doing a bounce in place with metadata in the audio file. So if you have 20 clips in a track, it's going to bounce down those 20 individual clips to audio. Merge the clip regions that have long repeating delays or reverbs into one region based on sections to avoid the issue. That's just common sense. On top of that I don't know of any other DAW's freeze function that works half as well as the one in S1. Some just bounce the whole track down to an audio file and call it a day with no real editing capability.

If I merge the clips before transforming they're still gonna be merged when I'll transform it back. I don't want that, because otherwise I'd have those clips merged already.

The problem is one would expect transformed track to sound like the original - like freeze in Cubase or Live. But it won't, unless you go through the track and merge events where you expect the reverb to bleed through and/or calculate a required tail for the rest. And it still won't sound the same, for the reasons I mentioned. How is expecting the user to do all of that a "common sense"? It's only common sense if you got used to and accomodated your workflow to buggy implementation of the feature.

For now a much better solution is to simply Export Mixdown of that track and disable it.

Okay. How should it work then? Cubase works exactly like S1 in that regard, as does Logic for the most part. Live doesn't even have alias clips. Neither does Bitwig. S1 is not alone in how Ghost clips/Alias Regions/Shared Copies work. You seem to think you know something that DAW makers don't.

I don't care it works like that in Cubase or Logic and isn't implemented in Live or Bitwig?! The issue can be resolved by adding a number next to the ghost icon to differentiate between groups of shared events. Easy. And obvious. Not a rocket science. Why can't S1 be the first to have that? Does it always have to follow Cubase and/or Logic?

[antic604]

BTW, you'll be happy to learn that Support said the issue - Bounce / Marge range depending on Snap To Grid - is by design and it was always like that

At least they promised to add that info to the Reference Manual

[oneway]

Which begs the question, why don’t you just make a macro called “Bounce the Way I Want” with one step- Bounce Selection, Snap parameter set to 0? I know posting here is fun but that would take you about 20 seconds.

Or is it the same issue you have with reading the Transform menu’s information once- that you shouldn’t have to do that?

[antic604]

Which begs the question, why don’t you just make a macro called “Bounce the Way I Want” with one step- Bounce Selection, Snap parameter set to 0? I know posting here is fun but that would take you about 20 seconds.

I already made the macros for Bounce Selection and Marge Events on page #1. Thanks

Don't get me wrong. S1's awesome and the fact that it can do some of the things that caught me off-guard is great. Other DAWs I used couldn't for example play overlaping events. They wouldn't even allow for events to overlap. But there's still many loose ends here.

For example, Bounce Selection / Bounce To New Track / Export Mixdown commands for Instrument Tracks include FX Tracks processing (which, again, isn't mentioned in Reference Manual, but I disgress...) in the resulting audio event, but there's no to Export Stems with the same result, i.e. have FX Tracks processing included in stems for individual tracks. You can either have the FX Tracks rendered individually but including everything that goes through them + dry Instrument Tracks, or you have to laboriously solo Instrument Tracks + FX Tracks, disable any Master FX and Export Mixdown.

The functionality of including individual FX Tracks processing in rendered audio is already there, so why it's not available in Export Stems?

I was wrong about the above

One has to select "Tracks" as sources and not "Channels" and then it includes the FX Track processing. Awesome!

I'm just trying to make an awesome DAW even better.

[oneway]

By posting in KVR? Make a feature request on Presonus Answers, that’s the only place they look for them. That’s the only way “rename XYZ to YZX, because” will get hundreds of votes.

[antic604]

By posting in KVR? Make a feature request on Presonus Answers, that’s the only place they look for them. That’s the only way “rename XYZ to YZX” will get hundreds of votes.

Oh, I've already filled 4 actual support tickets

[oneway]

https://answers.presonus.com/ask

[antic604]

https://answers.presonus.com/ask

Those don't really work, unless it's something that everybody want like MPE, support for Komplete controllers, etc.



BTW, that export stems feature? It's described in a misleading way in Reference Manual:

Note that the audio file created for any selected Track or Channel is the equivalent of soloing the Track or Channel in the Console and listening to the result. The audio file includes the results of all Inserts and Sends on the Track or Channel. If you don’t want the Inserts or Sends included in the exported audio, disable them before exporting.

In particular the bolded & red is true only for Tracks, not for Channels

[oneway]

Those don't really work, unless it's something that everybody want like MPE, support for Komplete controllers, etc.

Funny, I've had little things I've suggested with 10 votes get added. Perhaps you should take that as a hint about the features you're requesting?

[antic604]

Those don't really work, unless it's something that everybody want like MPE, support for Komplete controllers, etc.

Funny, I've had little things I've suggested with 10 votes get added. Perhaps you should take that as a hint about the features you're requesting?

Or perhaps you were just lucky & devs were already working on the thing you wanted added and it would still get added without your feature request? Take that as a hint to think about what you're posting

[apoclypse]

BTW, you'll be happy to learn that Support said the issue - Bounce / Marge range depending on Snap To Grid - is by design and it was always like that

At least they promised to add that info to the Reference Manual

I'm pretty sure I told you that, but you were the one who considered it a bug. It always seemed intentional since it's been that way since whenever Bounce Selection was added to S1.

[apoclypse]

No, they're not. What does it mean "preserve realtime state" if you haven't read the explanation below it?

Again your opinion.

Because it's redundant and inconsistent. And it's lazy development.

How many pieces of software have you developed?

I'm on holidays until 4th of Jan

Maybe take up fishing or something, instead working yourself up to getting banned again.

If I merge the clips before transforming they're still gonna be merged when I'll transform it back. I don't want that, because otherwise I'd have those clips merged already.

The problem is one would expect transformed track to sound like the original - like freeze in Cubase or Live. But it won't, unless you go through the track and merge events where you expect the reverb to bleed through and/or calculate a required tail for the rest. And it still won't sound the same, for the reasons I mentioned. How is expecting the user to do all of that a "common sense"? It's only common sense if you got used to and accomodated your workflow to buggy implementation of the feature.

For now a much better solution is to simply Export Mixdown of that track and disable it.

The point of Transform is to be able to still edit a clips position in time when the track is "frozen". Each individual clip is bounced down and given a tail if needed. It doesn't freeze a track like other applications (Logic, Live, etc) do. It's not buggy it works as intended. If you don't believe me ask S1.

You keep categorizing features you don't like as bugs. Just because you don't like the way something works doesn't make it a bug. Transform to Audio has worked that way since S1 implemented the feature in 2.x. It intentionally designed that way and they give you plenty of other option if you the whole track bounced down or mixed down. So imo it's a non-issue. I primarily use transform for drums or vocals where the long tails etc aren't a factor for me.

I don't care it works like that in Cubase or Logic and isn't implemented in Live or Bitwig?! The issue can be resolved by adding a number next to the ghost icon to differentiate between groups of shared events. Easy. And obvious. Not a rocket science. Why can't S1 be the first to have that? Does it always have to follow Cubase and/or Logic?

That's assuming that what you are suggesting is all that useful. It isn't to me. I know just by looking at ghost clips in my project what they are and what they correspond too. Just like you as a user should be doing your due diligence to organize your project if its too confusing for you. S1 and Cubase share a lot of functionality and in this case Presonus just basically copied what Cubase is doing. I'm not sure why S1 has to be "special" in this particular functionality in your eyes.

[antic604]

BTW, you'll be happy to learn that Support said the issue - Bounce / Marge range depending on Snap To Grid - is by design and it was always like that

At least they promised to add that info to the Reference Manual

I'm pretty sure I told you that, but you were the one who considered it a bug. It always seemed intentional since it's been that way since whenever Bounce Selection was added to S1.

I understand it could be intentional. I mean even when doing the macro for 'properly behaving' bounce & merge I noticed both have a Boolean parameter 'snap'.

Buy still, it wasn't documented anywhere and - for me at least - that behaviour wasn't making any sense, because if I want to bounce / merge a bar I'll select a bar. That was my perspective.

[antic604]

How many pieces of software have you developed?

Three. Maybe five, depending how you count. But it's all internal software used at my job.

Maybe take up fishing or something, instead working yourself up to getting banned again.

Uh, oh. You'd love that, no?

The point of Transform is to be able to still edit a clips position in time when the track is "frozen". Each individual clip is bounced down and given a tail if needed. It doesn't freeze a track like other applications (Logic, Live, etc) do. It's not buggy it works as intended. If you don't believe me ask S1.

Wow, that's a pretty fascinating take on this that I obviously hasn't considered! It also explains why it's called "transform" rather than a more common freeze / bounce / render / print

Thank you!

That's assuming that what you are suggesting is all that useful. It isn't to me.

And how would adding numbers to ghost icons make the feature suddenly less useful to you? You could still color-code your stuff or use magnifying glass to distinguish between instrument parts, because for some reason Studio One decided to display several octaves of data on the event even if there's only one chord spanning 8 notes.

[apoclypse]

Three. Maybe five, depending how you count. But it's all internal software used at my job.

Then you should know how disrespectful and frustrating it is for someone to call you lazy because something doesn't work the way they want it to without knowing the kind of work hours, time and effort it took to develop the application in the first place. Playing arm chair developer, especially when it comes to commercial software doesn't help anyone.

Uh, oh. You'd love that, no?

Not really. I didn't bother me when you were it doesn't bother me that you aren't. I'm only responding to you because I don't like your insistence that intentional functionality are bugs just because you don't like the way they work. You also can't seem to understand that some people actually like the way things work or that the developers just have a different perspective about how things should work.

Wow, that's a pretty fascinating take on this that I obviously hasn't considered! It also explains why it's called "transform" rather than a more common freeze / bounce / render / print

Thank you!

Not sure if serious but if so when you re-transform the track back to an instrument or realtime state, it will keep the changes made in position, cuts etc. Again most freezes don't do that. That's why S1 renders each clip individually. It has to keep track of all that data and still be able to change back to an instrument track when necessary.

And how would adding numbers to ghost icons make the feature suddenly less useful to you? You could still color-code your stuff or use magnifying glass to distinguish between instrument parts, because for some reason Studio One decided to display several octaves of data on the event even if there's only one chord spanning 8 notes.

Considering most DAWs don't do this I guess it doesn't matter does it. S1 is doing what everyone else is doing in this regard and if you think they should change that then get in touch with the developers. No need to rant on banging the drum when nobody here can do anything about it anyway. Considering the only handful of responses (mostly people criticizing your posts) then it look like people don't actually care that much about these issues.