robertgray3 wrote1) If I make a comp from various layers,
2) make some audio bends,
3) and then do a few pitch edits in Melodyne, occasionally those sections will have tails of the maximum allowable length after Transforming.

It seems mostly related to sections I have edited with Melodyne.

Probably best to show picture or video. See top of the forum to learn how.

You do know that 2) audio bend and 3) Melodyne should be done separately then bounced before proceeding as they both make copies of the event Or do your timing fixed in Melodyne as well.

The auto trail has to be nurtured slightly. I think largely because certain instruments, be it synthesis, or sampled sounds will have a trail to them. Even reverb will exist as a trail, which you can also choose to include, when you stem, or render to audio. So the hard truth in that decay is the rendering hears something a little different based on track to channel, plugin, or pre/post fade. Not always to our liking, but I'm glad the trail clip is there. It takes a bit of tweaking though, at times. Try it further with that in mind. It may help.

On a side note, I've found that rendering and including the effects on the new audio track help a bit. Or, remove plugin effects completely. Too many scenarios to break it all down.

The trailing clip has helped at times where I'll have some let's say, 8 bar loop, and it's a nice groove, but when the track (s) render to audio, the trailing end suffers because the decay is chopped off, and it is audibly apparent, when the section is looped. So the trailing clip can be a very good thing if handled with adjusting in mind. Mmv.

robertgray3 wrote: I can see that some long overlapping sections with long fade-outs are created in the middle of passages after Transforming, but I have "Play Overlaps" disabled so I am mystified why they even get played.

I've seen that at times as well Rob. I just forget what causes it. Like JPettit mentioned, if you provide more information, someone could answer.

Cheers.

jpettit wrote

robertgray3 wrote1) If I make a comp from various layers,
2) make some audio bends,
3) and then do a few pitch edits in Melodyne, occasionally those sections will have tails of the maximum allowable length after Transforming.

It seems mostly related to sections I have edited with Melodyne.

Probably best to show picture or video. See top of the forum to learn how.

You do know that 2) audio bend and 3) Melodyne should be done separately then bounced before proceeding as they both make copies of the event Or do your timing fixed in Melodyne as well.

Where exactly in the manual does it say that? Sounds suspiciously like we're in "user work around" territory on this one.

I scoured the sections of the manual on "Track Transforming" and I find nothing but encouragement that I can add all the edits and effects in the world then Transform it to save CPU power

Lokeyfly wroteThe auto trail has to be nurtured slightly. I think largely because certain instruments, be it synthesis, or sampled sounds will have a trail to them. Even reverb will exist as a trail, which you can also choose to include, when you stem, or render to audio. So the hard truth in that decay is the rendering hears something a little different based on track to channel, plugin, or pre/post fade.

I guess this is where a video would help, Lokeyfly. These are simply vocal tracks. Minimum crossfades (10 ms max) and minimal effects (Pro EQ, Fat Channel). No reverb, no instruments. Hence my confusion when the auto tail function gave me 30 second tails.

As for the video, I'll send some examples next time I run into it. A lot of my comping is done on a timetable, so it's difficult to find the time to save and keep track of multiple broken projects when my main priority is getting one working project out the door.

Tail lengths can be set. I see they default to 30 sec when you first go there. Have you tried altering this setting.

There are other ways to transform instrument/audio parts to audio. One is to use either the Song Export Stem mode for example. Set it to export between the loop. Set the loop as you want it.

Or simply select the instrument/audio part and do a CtrL B on that event. Then you won't need to worry about any tails etc. Especially if the situation does not require you to factor them in.

Even if I have a tail I just set the loop outside the end of a mid note etc and export for the loop duration once again. It is fast end effective.

Jemusic wroteTail lengths can be set. I see they default to 30 sec when you first go there. Have you tried altering this setting.

There are other ways to transform instrument/audio parts to audio. One is to use either the Song Export Stem mode for example. Set it to export between the loop. Set the loop as you want it.

Or simply select the instrument/audio part and do a CtrL B on that event. Then you won't need to worry about any tails etc. Especially if the situation does not require you to factor them in.

Even if I have a tail I just set the loop outside the end of a mid note etc and export for the loop duration once again. It is fast end effective.

Yes. Thankfully, I read the message box so my main work around was to set the maximum allowable length to 0 sec. My question was why so many audio events were defaulting to the maximum allowable length of tails when there were no long fades and no reverb effects, and why on earth the overlaps were playing when "Play Overlaps" was disabled.

Thank you for the suggestion of exporting stems. Works fine, but I was interested in using Presonus's much-touted Transform feature because I can revert from Rendered to Realtime audio easily without saving and cataloguing alternate versions of the project.

I thought of the same workarounds as you guys and selective bounces and selective exports was exactly how I got through the session. My reason for posting was I suspect there may be some issues with the Transform feature when used in conjunction with Melodyne and audio bends. Looks like Lokeyfly has seen similar things in the past, so next time I have some free volunteer bug testing time I will dig into this more in the interest of improving this feature

Nailed down part of the issue:

If you use Transform to Realtime Audio and there is a crossfade between two layers, S1 will create two overlapping events with the separate fades. Unfortunately, if you have "Enable Play Overlaps on New Audio Tracks" disabled, this won't play back correctly unless you manually enable Play Overlaps on that new track. There's pictures in the link below.

Support told me this is intentional behavior and suggested making a feature request. Here it is if anyone else runs into this: Transforming Crossfades to Rendered Audio Don't Play Back Accurately (depending on preferences)

it may not even be considered a workaround, but more of a process I perform whenever transforming audio where mulriple clips are concerned. I'll simply merge any multiple, or overlaying audio clips. verify it works, or be prepared to do the necessary nudging afterwards, of seperate entitiees, tails, and so on. Like Rob said, that's not really the fix for finding certain anomolies, or perhaps Melodyne with S1 edit anomolies (Actually I havent found any, myself), but I did want to express, I simply solve for multiple clips differently. Why?, Because I simply expect overlaid clips to not behave if transformed as a group, in one shot. Another effective merge, without actually merging is to bus the output, and capture that audable end product off another track.

So are these the fixes that address the problem? well, no but in some ways the response might be "what were you trying to achieve?". A group transform, exactly as reliable as a bussed form of stamping the audio clips? Yes, you heard dropouts or even doubled output at times. Yes, selecting or de selecting to hear audio overlay works wonky in a group transform of MIDI intruments, or overlaid vocal events . I honestly don't have that answer to that, except some hunches, or general thoughts:
1. Selecting to hear or not hear (Play) overlays, is it's own option. It doesnt necessarily encompass "playing", based on some group transform of events. Thats really outside the scope of the selection. The selection works, but not to how you're using it, or expecfing it to.
2. As suggested, the workarounds we all know (given some DAW and tracking experience), really can solve the actual needs. There's often simply a better way.

Doesn't matter, from simple vocal events, overlaid, and with supplied Fat channel plugin, or some complex EMD, or huge percussive overlays. Is "Transforming" such elements the right recource, or are there not more reliable workarounds, and better methodology. I wouldn't say people shouldnt seek out hoping for reliable output by transforming multiple clips in one leap, but I might ask, is that the right end result method?

I think transform audio works pretty well in its own basic way of transforming the clips to their own content, trails, etc. Events are just seperate entities from each other, and for better, or usually worse, we hear the overlayed clips ending up being different when transformed together. Remember, clips even have different start and end points, possibly as they carry a little more of the begining and end of audio (as for some, that is even a request for the clip to have for pre/post recording, punch in/outs). It might be worth checking if that transformed clip is over extending, and that is where such dropouts might be happening.

I get the just work in one shot for what I want, or even the why doesnt it do that, and what's causing it. So in all due respect Rob, I hope you find that it ultimatly works for you. It's just that the events to be transformed have other functionality. Maybe, Presonus can act on making multiple event transforms just globally work better, or even fix any of the problems you're encountering.

btw, I was experiencing dropouts when importing songs into Projects, but that was a different issue. Yes, these gremlins can surface at times.

Lokeyfly wroteI simply expect overlaid clips to not behave if transformed as a group, in one shot.

OK, that's fair. After more and more testing, I understand that you have to play soft-ball with Transform to Rendered Audio but perhaps what confused me was the user manual. When you look up "Track Transform" in the user manual it doesn't come with a long list of disclaimers and exceptions. It simply says that right clicking on the track controls and using the Track Transform feature preserves the track in a rendered state to save on CPU. It doesn't mention any additional steps to make it play back how it did before you Transformed it.

Either way, I'm just trying to improve a function I use a lot in Studio One. Thanks for the help and input, especially the suggestion to merge events before performing a Track Transform. Surely that will help preserve some edits without bouncing.

For better or worse, I've always looked at rendering clips, a quick and dirty path for saving cpu energy, and that the best method of stamping multiple clips, on any single overlaid, or multiple tracks is to bus the required outputs.

Somehow, when S1 renders clips, and trailing edge of even a single event (via its tail, or overlay of clips), it isn't tapping the same output path that we hear so smoothly, and its lead and trail edges where combined don't always translate well. That's when I started to step away from the process completely. It often didn't work for me. However, it's good you bring it up Rob. Rendering could be further improved on, and perhaps a few additional options for rendering numerous clips so that render is a more viable option. Because, I think we both agree, it's not. I just see it as a band-aid, but agree render could be more.

I had a chance today to catch up on finishing two songs. They needed a lot of finalizing of percussion, so having the Good Friday off, it was a nice long session to catch up material, and utilize some of what was spoken here.  I proceeded to do lot of moving transients with the bend tool, and some Melodyne work. The songs are both in the 30 plus tracks range, three effect sends, and each channel with various EQ, channel strips and/or summing. 4 bussed, and no VCA tracks. Lots of bend marker adjusting just before the zero bar/beat markers, so if something was going to be out of time, nudged diferrently, or audio anomalies, I'd probably see it (he said).

 I had no issues, or saw any differences coming from Melodyne events, or comps, where I tried rendering before or after edits. It's probably worth pointing out, that these songs are near completion, so I handled most of the conversion of tracks from Instrument to Audio, by stemming. Occasionally, after save, I would go into reckless abandonment, and try renderings tracks to audio and just not save, to see the results, but I haven't seen any different nature of how S1 handles rendering, it's use of tails, or the degree of where I buy into using Render Tracks to Audio feature. It's a great feature, but requires as you say Rob, a little soft ball.

There are times where I'd prefer rendering, over stemming such as in a lot of grouped events through a song, with large gaps where there are no events, such as three verse sections. If I choose to stem, I either have to create three seperate stems ( 1 for each verse), or stem the whole track, which captures a lot of wasted silence. The other option is to render, which will handle this operation all at once, but the choice to include tails, include seperate outputs, length, etc have to be considered. Also, when including multiple outputs is checked, the stemming process, along with tails can be quite long, resulting in minutes of waiting. At times, I thought, "what did I just do?" After waiting over four minutes of processing. would have been quicker and more to what im looking for, stemming 3 individual sections.

The rendering result was all good, but as usual, tails if overlapped into an event behind, will play and allow the event from behind in time (and underneath), to sound but I don't see those notes, as they wete blocked by the tail, showing no notes. So I end up pulling forward or shortening the tail to uncover what I need to see. I think in the case of tails, they work well even when laid over other events as described, but the resultant image, leaves me having to fix things. The flip side is if no tail is chosen when rendering, then one needs to observe that the end of the event is the cutoff point. If notes, or processed audio occurs after, too bad. It's subject to the chopping block. I suspect tails (when selected) simply sound always, and are not treated like standard event overlays. Probably a good thing, but visually, a needs to be understood or accepted part of the process. For me, it was more visually bothersome, but showed no signs of audio problems.

The onus as I see it, isn't Studio One's execution of handling renders, though perhaps a few added options for the user to choose from could serve well, like an option to "Auto Merge Tail to Rendered Audio". That would make the render one complete body, which includes any tail if there is one.

It does get to be of an overkill of every tail being the same length, when rendering numerous events at one time. Perhaps an other options might be to "Auto tail". This would produce a tail based on audiable detection. The user instead of adding a time length, would need only one other field to input, if so desired. How much decibels are the cut off point. If left open, S1 determines that as a default. Perhaps 0.2 dB.

IMO and mmv of course, but I think the onus IS on us, the user when rendering, to make the necessary choices when choosing tails, length, outputs, etc. Yes, there that learn by doing curve we all face, as to what works, or doesnt. Also the user needs to do the necessary housekeeping, merging, especially right after comping, or finalizing Melodyne, or bend marker edits. Not that you have to, but you minimize the chance for error.

Rendering works, but there's room for improvement. I didn't experience any snags along the way.

Lokeyfly wroteI suspect tails (when selected) simply sound always, and are not treated like standard event overlays.

OK so you observed the issue that my original post was about but you think it's by design. That's fair I guess, but none of this is documented. When you tested all of this, were any of your tails generated at an incorrect length?

I made two screencaps of the test case where this came up. I now identified an additional issue- it seems like on the track I'm testing, the generated tail fades don't go away when you Transform to Realtime audio. So now if you try to restore the track to its Realtime state, it will play back differently. What's more, I didn't see "Play Overlaps" having any effect on the overlaps even in REALTIME state. If I'm simply being careless, I'd love to know what I'm doing wrong!

Before anybody asks, yes I fully reinstalled Studio One 3.5.6. No, it didn't make a difference.

My two questions are:

1. In the first screencap, why are the tails in the first passage so much longer than the tails in the second passage? At the beginning of the video I quickly scan through every clip- there are no overlapping events there.

2. In the first screencap, why does Play Overlaps have no effect on whether or not the tails play back together? In that crossfade issue I brought up earlier, Play Overlap was required to play back the Transformed Track properly. Here, it makes no difference, both ways result in simultaneous events playing. If this is by design, can we at least agree it's inconsistent?

3. In the second screencap, why does simply Transforming this track back to Realtime audio result in the overlapping audio? I don't recall that being the track I started with.

Auto Tails generated too long sometimes, and Play Overlaps has no effect on overlapping tails.



Generated Auto Tails still there when Transforming to Realtime Audio, and Play Overlaps has no effect on their playback.

Found out more about the long auto tails and the tails remaining after re-Transforming.

TLDR: Until this is fixed, if you run into the problem with erroneously long tails in Transformed events the solution seems to be to merge affected clips with Melodyne edits before performing a Track Transform

Long Auto Tails when Transforming Tracks with Melodyne Edits to Rendered Audio

Narrowed the erroneously long tail issue down further- it has something to do with Melodyne being used as Event FX.

After I removed Melodyne as Event FX the Track Transform-generated Auto Tails looked like this, as opposed to the gif in the post directly above this one:



Not just that, but there isn't any sign of the overlapping audio that lead to stacked audio on playback. I removed some events to make this clearer here.



I'll do some further testing to figure out what exactly causes this. The other sections with Melodyne edits later in the timeline also had the same issues, but I haven't tested it thoroughly to see if this is something that always occurs or not.

Before people chime in again with "just merge your Melodyne sections before Transforming!"... I already do this, because it's the only way to do it currently. I'm trying to identify areas for improvement in the Transform to Rendered Audio feature.

Separate issues: Strange Behavior with Auto Tails (bugs or just design shortcomings?)

Auto-Tails Playing Back Regardless of Play Overlaps settings

I'll have to dig into this more, I suspect it has something to do with the Event back-to-front ordering system. If anyone else understands the Event ordering system more than me, I'd love some input here. This might be an issue of how Track Transform orders events when rendering.

Tails Persisting when Transforming to Realtime Audio

As for the tails remaining after re-Transforming to Realtime audio, it looks like the playback is impacted by the Event back-to-front ordering system.

This is a separate design-related issue and has nothing to do with Melodyne apparently.

Here is a picture of the tails above, after I performed a "Transform to Realtime Audio" on the track.



If Play Overlaps is enabled, the remaining tails lead to doubled audio. If Play Overlaps is disabled, some of the Event ordering leads to tail fades cutting off audio in other events. I could theoretically manually fix all this, but is that the point of Transforming?

From the Official Reference Manual:

If you check Preserve Original Track State, it is possible to transform back to the original Track, with effects inserted on the corresponding Channel, by [Right]/[Option]-clicking on the Track and selecting Transform to Realtime Audio from the contextual menu.

Doesn't sound like this is in the spirit of Transforming. This was not the original track. Even if everything is ordered correctly, the newly lengthened events as well fades at the beginning and ends of overlapping events lead to dropouts that were not there when I first Transformed the Track.

Sorry, was away for the day, and couldnt decipher your vids text from my phone, but i got the jist of it. Keep the videos handy if you report this.

From your two videos post, only.

Auto Tails generated too long sometimes, and Play Overlaps has no effect on overlapping tails.
On a few of your examples, the clips you are trying to render are very, very short. Also, are you trying to promote comped segments, then render? I've never seen that degree of tails, resiiding over other tails, so there might be a large degree of problems there. My apologies, if I'm not interpreting that correctly. Why would you render over such short events, or promoted comped clips? I'm keeping to earlier points dicussed by merging, (or bouncing) all, prior to render, there.

On the play overlaps, I am at a loss, except again, tails might not be treated not as overlaps, but perhaps always play. Not sure. Yet, you reduced the gain by lowering the grip, which changes volume in all my cases. So that's a problem. Also, you mentioned,"Let's try it with Play overlaps Off", but you proceeded to lower the grips. Did you mean, let's try dropping the gain to zero"? They're effectively not off, but your point holds true, that they still sound.

Generated Auto Tails still there when Transforming to Realtime Audio, and Play Overlaps has no effect on their playback.

Big no-no, IMO. I cant say i ever tried generating tails, along with audio events in such short layers form (or any manner, that way), then tried to transform them. Maybe I'm just a stickler for merging first. Then, it's already rendered. I'm not saying your workflow is wrong. Far from it. But I think generating tails especially on such global overlays is cause to expect error. Then again, perhaps the devs were fine with that, and you found something. My gut tells me, to not render tails, over stuff in such a concentrated way, but hey, I've been wrong before.
The play overlaps has no effect, because of the same dialogue. Either tails are different entities, along with you're trying to render a tail, mixed in with highlighting other parts to render.

I know, I'm probably not helping as my degree of rendering audio is on very larger segments. Typically either on whole tracks, or large areas that are either highlighted, or designated by the loop markers when stemming.

I think your examples are very helpful (though kick the text up some). Unfortunately, your vid's cant be paused, so trying to capture parts, and reading text parts gets tricky (my equilibrium is just coming back). But you have enough fodder to support your claim. Good job there, just the same.

I think we repectively just work different. If I had more time, I'd reduce clips/comps very small and try them, but I'm pollishing off some time contrained work. But I'm sure you'll get some responders who can work out those details you've pointed to.

Are youre examples or questions unconventional? Probably not. I do some pretty time complex stuff, some polyrythms, jazz, electronica, and acoustic stuff, and a good deal of comping, but I havent had to resort to render in the ways you're pointing out. Nonetheless, your questions, I suspect are legit. Sorry I couldnt confirm all, but I hope I added some rethink possabilities, if they at all help.


One more thng. Thought just popped up. I think you might benefit from eliminating the tails when rendering altogether. There's often so much density, and re applying rendering of tails going on. If you need the rendered tails because, they contain the necessary audio, but you're experiencing these clip anomolies, I'd think you woukd almost have to bounce the event. You'd still have so many re edit possabilies thereafter. You could duplicate the track so that there's no permanent damage to what you're currently trying. Anyway, just sharing.

I hope you're not rendering a comped group of parts, without merging, or better yet, bouncing that group of comped layers, first. Looks like some of that is the case in the 1st vid, amd possibly, a by product in the 2nd.

robertgray3 wrote: TLDR: Until this is fixed, if you run into the problem with erroneously long tails in Transformed events the solution seems to be to merge affected clips with Melodyne edits before performing a Track Transform

This has been a point all along. And not just merging clips with Melodyne, but merging them by bouncing (also much faster). I suspect after such a merge, the clip plays ball, the way it needs to for overlays and such.

Lokeyfly wroteThis has been a point all along. And not just merging clips with Melodyne, but merging them by bouncing (also much faster). I suspect after such a merge, the clip plays ball, the way it needs to for overlays and such.

As I stated in previous posts, yes, merging the events does circumvent the issue of erroneous auto tails. Wouldn't we prefer if Track Transform didn't produce the erroneous tails in the first place?

I'm not getting eronius conditions, the way I handle rendered tails. I never render tails that are not a permanent part of an event, though.. As mentioned, I see render to audio, a bandaid to recouping CPU resources, and that is spelled out somewhere in an older manual. I believe around the v2.5 addendum, but I cant be sure where I read it. Numerous places though. So rendering tails for me is like putting a bandaid over bandages. They certainly work on some larger event of a few bars or more, and the results should always be merged or bounced to make them unified, at some time of the composition.



I was hoping to hear if you are promoting comped clips to be rendered. If so, to me that's inherently the choice many or hopefully most won't make. Especially, when some are so small. Can you do it. Sure. You can also cross cut wood, with a rip saw blade, but expect rough edges. Sure, we all prefer that combination saw blade, but I think you might be working outside of the intended process. Example: you have 7 overlaid tails, and are still trying to process them further. That might work, but either you're working too close. Or I'm seeing too far out (which we're both willing to be agreeable to).
In any case, even if some are not comped clips, then some are pretty small and appear to be one word size events. That's going to also produce a lot of tails overlaid on each other, when grouped in the manner your trying to get results with.

Perhaps the inconsistency of rendered tails questions you have will be beneficial (where reproducable, and I believe your examples are, as you re created them). Or the process of redefining intended results by working some other way help. The merge and export possibilities everyone here including you know work, and resolve much discussed. I'm leaning on that being the answer, Rob.

I'll leave room for others so that they may assist. All the best, though.

So if anyone actually wants to test the exact issue that I posted about, here are steps to reproduce the Melodyne Auto Tail issue.

I would love to know if these two issues occur on Windows 10 or High Sierra as well, as I've only tested Mac OS X 10.12.6.

ISSUE 1 - Melodyne as Event FX Interferes with the Auto Tail function of Track Transform.

1. Create a mono audio track
2. Load in an audio file, preferably a few bars long so you have more room to work.
3. Create a few splits in the event with the Split tool (3)
4. Highlight all the events that you just split and edit with Melodyne (CMD + M on Mac)
5. Right click on the track's Track Controls and select Transform to Rendered Audio
6. Enabled the Auto Tails option and keep the maximum value at 30 seconds.

All the Transformed events should now have fades extending to the last of the events with Melodyne.

These tails, for whatever reason, play back regardless of your play overlaps settings. You can test this by reducing the gain of overlapping events to 0 db. Even though they overlap, the event underneath it will sound out.

ISSUE 2 - Auto Tails persist when Transformed back to Realtime Audio, and Play Overlaps has no effect.

7. Right click on the track's Track Controls and select Transform to Realtime Audio

The events' are now longer than they were when you first Transformed them (their tail lengths persist), and they play back simultaneously even if Play Overlaps is disabled.

Picture:



Can anyone duplicate these issues after they follow these steps?

I always bounce multiple events into one before editing with melodyne.

I bounce it again after editing in melodyne to remove the overhead processing.