pulsewalk

Thank you! That solved the problem! Although a bit more work than I hoped for. There's no way to add the clip gain option to the right click menu? (Changing the edit filter will do that for the entire track instead of only the clip I want to adjust). I'm however glad that there's at least an option to adjust gain

Ohhhh!! Hahaha, man, why didn't I think of that Of course, you're correct! However, editing the freeze options was even better, then I don't need to drag the clip edges at all, as it will all be automated after I've set up the desired tail length and enabled silence removal and so forth Thanks anyway mate!

Is there a "Per clip" lossless volume adjustment? When I right click an audio clip, I cannot find an option for volume adjustment for that particular clip. I do not want to adjust the entire track volume, but only lower the volume on one clip. Also, I rather not use Process>Apply Effect>Gain, because that will "permanently" change the audio clip volume. Volume automation track adjustment is not really an option either, as it would alter the volume for the entire track no matter how many clips that's overlapping. Is there a way to adjust the volume on "per audio clip" basis?

Fantastic man! Thanks alot! This was EXACTLY what I was looking for! Perfect!

Thanks scook! Dragging the clip edge only extends silence, and not any actual recording, unfortunately. But the Freeze option settings recommended just above solved my problem!

I can't find the setting for the "Freeze Synth" tail length. With other words for how long it will record after the last note has stopped. The best would be if it automatically recorded until total silence from the VSTi, but it doesn't. And I can't find any setting for this. The thing is that every time there is a long reverb or delay on a synth I try to freeze, the audio clip is just cut before the reverb or delay is finished. A way to solve this is to put another note or anything long after the last note that one want to keep, freeze the track and then just cut the audio. However this is unnecessarily time consuming and should be done automatically by the DAW. Any ideas?

Wow, didn't know this! Will try out for sure! Thank you!

1. For now, Mute always takes precedence over Solo, but that is not always preferred. It would be very handy to have the option to have Solo precedence over Mute, if needed. 2. If one accidentally press the "all tracks"-Mute, all the muted tracks are unmuted. Unfortunately CTRL+Z (UNDO) does not work to restore the previous state, which means one will have a nightmare remembering which tracks were muted and which not. It would be very handy to: A. be able to save and recall the state of Mute/Solo buttons (but especially the Mute state) B. be able to have some undo option for accidental Mute state changes (and perhaps other state changes too) And of course in addition to a previous request of a (now missing) MUTE-button in the VSTi window header:

There is already a Solo button in the VSTi window header. Please also add the Mute button, which would do a lot for those who need to momentarily mute a VSTi, without having to go to track view and search for the right track, among maybe many many tracks, to find the right track to mute. Thank you! Example (I added a mute button in Photoshop, just to see what it could look like):

Tried that. Didn't work. On one disk, it's not getting a 8.3 file name no matter what I do.

I did a Photoshop edit on this and added a [ M ] mute button. Would this really be so bad? And as you can see, there's already a Solo button, not to mention an automation Read and automation Write button. A mute button in addition wouldn't hurt.

I'm not sure you understand what I mean. When you have a VSTi open, an instrument, a synth. You might be working with it and thus you might want to be able to both mute it or solo it, without having to scroll and search for its track in track view. There already is a Solo button, why not a Mute button? This is making it quite clear we're talking about different things here and I'm not sure what you're talking about. Once again, I'm talking about the VSTi window. Let's say you have Serum in a window. You're working on it and you play the track to hear everything with Serum. Then you might solo it to hear it solo. But then you might want to hear everything else EXCEPT the synth, thus you'd like to mute it, but you can't from there. So you'll have to go and look for its track and mute it there. Why would people wonder there's no sound? They would clearly see in the track view that a track is muted. If you mute the VSTi in the VSTi window, it would be equal to press the mute button in track view, just as VSTi "Solo" works. It's not like you mute the VSTi inside the VSTi and then it's not indicated as muted in track view, no. If you mute it in the VSTi window, it's being muted in track view too. That is exactly how Solo works today. There's a solo button and if you press it, its being solo:ed in track view to, of course. It's just being soloed, thats it. And it would be great to have a mute button there as well. If you think a mute button would be a bad idea, then I guess you find the already present solo button to be a bad feature and want it gone too?

I was thinking of VSTi's as in VST Instruments, but the same would of course be applicable to FX VST's. You mean it's not possible to display the mute button? Oh man... In that case the developers really need to add one. I see it as a very basic future to quickly be able to mute the synth you're working with, without the need to look for it among the tracks or in the mixer to mute it. There's a solo button, which is very good and as it supposed to be. But why no mute button? It is just as important! To the developers: PLEASE add the mute button in the VSTi windows upper right corner just where the solo button is! Thank you!

When you have a VSTi open there is a Solo [ S ], an Automation read [R] and an Automation write [W] button, in the upper right corner of the window. But where on earth is the [M] mute button (which is used "all the time" by many users)? Where in the preferences do I enable it? Hell, I could even see a [*] Record button there for certain cases. I've looked everywhere in the preferences AFAIK. Anyone who knows where I can find and enable it?

Changing the plugin dll file name doesn't do anything here either. However, different 8.3 file names does. So this seems only be affecting the 8.3 file name part. Unfortunately, that cannot easilly be detected in Windows explorer by default and the user would need to have deeper knowledge about what to look for and how to check it. I guess many users have struggled with that and finally just scrapped the whole automation and built it up again. But that's not really an ideal option, so lets hope it can be fixed! I'm not sure how other DAWs handle this but I've not experienced this before. I don't know if that is because other DAWs are handling the issue differently or because there simply have not been situations in my case with 8.3 file names being changed. At least now I know a workaround. Not the most ideal sort, but at least it works with not too much effort. It'll be a hell though, when I need to open other projects which will be looking for the other 8.3 file names, then it'll start all over again 😟

Tried that, didn't work. It seems to be some central setting so the 8.3 file name is added no matter how I move it back and forth. And the same thing when moving it around in the other location, where the file does not have a 8.3 name, then it stays that way. Another problem is however that it doesn't matter really what setting one choses 8.3 or not. If a Cakewalk project is already created with a VSTi with a certain dll file setting (either 8.3 on or off), that is it. Then I guess the entire project will have to be finished that way. I'm not sure if that could be corrected inside the project somehow. To somehow saving the automation data/project file. Then after that correct the 8.3 naming problem, and THEN continue on the project like nothing happened. I guess that's not possible. So if the affected user have different projects using the different named (8.3 or not) plugin dll files, that user will have to continue to use the same file settings as long as he is working on the project and as long as he needs to reopen it. That's bad news I'm afraid

Alright. So just a quick update. On "computer 2" where I get the "orphaned automation envelopes"-problem, I get the problem when enabling the plugin dll which is on drive C. Now, this file actually have a 8.3 name too. However, when moving the same file to the D drive on the same computer, the 8.3 name disappears and thus the "orphaned automation envelopes"-problem also disappears. Oddly enough, running: "fsutil 8dot3name query" gives a state 2: "The registry state is: 2 (Per volume setting - the default)." on BOTH the C and D drive!! I wonder why. 8.3 is enabled on both drives (not to mention also on computer 1), but still when moving the plugin dll to some locations the file loses its 8.3 name, and with that also creating the "orphaned automation envelopes"-problem. I imagine I'm not the only one in the world having these problems, but now I at least know what could cause it and thus may be able correct it.

I've checked and there is actually a difference. On the first machine/computer 1 (where the project was created) the plugin dll does NOT have a 8.3 name. However, on the other newly installed computer (computer 2), the plugin dll DOES have a 8.3 file name. Oddly enough, running: "fsutil 8dot3name query" gives a state 2: "The registry state is: 2 (Per volume setting - the default)." on BOTH machines on the same drive where the plugin dll is located. I don't know how to strip a file from its 8.3 file name, but if that is possible, it might solve this problem for me. I'm not sure how more I could "reenable" 8.3 support as you suggest, as fsutil (obviously) states that 8.3 support is already a state 2 (with other words: enabled), on both machines on the drives where the plugin dll is located.

Yes I use the same plug-in format and same 64-bits too. As a matter of fact, it was enough to just move the plugin .dll file to the same folder location as on the computer the project was created, and automation worked again. That indeed should mean that plug-in installation path is stored in projects, which is actually what I assume is a bug, because I can't think the developers would do something like that on purpose? I cannot see the logic in that, on the contrary, it would make project sharing and project transferring between computers/producers difficult and in same cases even impossible (say the initial computer where the project was created have a E: drive where the VSTi's are installed, and the project is sent to another producer that doesn't even have an E: drive but only a C drive or maybe only C + D, then what? having to create virtual drives or buy new harddrives and start reinstalling/moving VST's, and by that creating other problems instead and what not?).

Yeah, but then how can I replace the synth without affecting the automation, as you suggest here: How do I do that? When I do that, it does affect the automation, it is deleted. But how can I do it so its retained as you describe?

So, I just tried this to make sure. But it did not work. In fact, it made everything even worse. When I replaced the VST synth with itself (same synth), not only all the track automation disappeared, the patch was set to "init" so everything got reset. Actually, the same happens if I do the same (replace synth) on "computer 1", where the project was created - everything gets reset, automation gone, patch to "init". I'm not sure if that is configurable?

Oh, sorry, didn't see that, I probably wrote the reply in the meantime while you changed it. So regrading your new edited input: I'm not sure but I think I tried to replace the synth just as you suggested. I can try to do that again just to make sure. As that would be an easier solution than reinstalling or moving VSTi .dll's. However, it should not be that way anyway, so I think that should be fixed by the programmers, if at all possible (should be?). As for MIDI automation, yeah, that could be used too. I'm not sure if it works just as good and smoothly with the various VSTi's but I guess then I'd have to assign the controllers to MIDI CC#'s and whatnot in order for it to work. Question is also how effective that would be compared to direct automation. If the MIDI automation would result in added latency or sync issues or anything. It might be worth a try, but once again, it should not be needed, automation of the plugin directly should work perfectly regardless off plugin .dll location on the computer.

I don't know anything about Cakewalks inner workings either, but I don't know why two different plugins would have the same name? Perhaps same file name, but same "plugin name"? Either it is brand X and model X, or it isn't, I guess? Nevertheless, plugin identification for a track is one thing and I see it as the "first level" identifying process. Of course Cakewalk needs to identify the same plugin so the track will play as it is intended. So if a track is a Serum track, or Massive track or Sylenth track (or whatever), it should be identified upon loading the project. If the correct VSTi is installed, everything should be fine from there. Automation data for the track itself, I see as the "second level" of identifying process. With other words, if the "first level" of identifying is correct, and the same VSTi plugin is available on the computer, all the automation data should point to that plugin and call that plugins envelope control "identifiers" or whatever they would be called, so it's calling up "filter cutoff 1" or anything which would determine what parameter to control. And it should only request the plugin itself, not its entire installation path. Where it is installed should be entirely irrelevant. It's like if one could not open a Photoshop .PSD file or a Illustrator .AI file on another computer without problems, unless PS/ILLY is installed on the exact same drive and in the exact same folder path on both computers. That would not make any sense, if you know what I mean.

VSTi track automation data is linked relative to plugin .dll including its installation path, instead of relative to the plugin .dll itself. Why? I discovered this during my problem described in this thread about orphaned automation envelopes. Problem NOT solved even though project is saved as Cakewalk Bundle .cwb file. Cakewalk PLEASE solve this, otherwise it will not be possible to do collaboration work on project files on different computers, unless the project receiving computer has an exact mirrored installation (of VSTi paths) of the "project sending"-computer, which I would think is not always the case or even many times or even often varies between users (not everyone put their VSTi installations in the same folders). Please FIX this.

UPDATE! This is quite unbelievable, but moving the plugin .dll file to the same folder on computer 2, as it was located on computer 1 (where the project had been created), made the automation lanes/envelopes work again! The reason being the location of plugin .dll was suggested by scook in an above post, thank you! This must be a BUG. It means Cakewalk assigns automation data, to not the plugin itself but, to the plugin's dll location! Cakewalk should assign automation data relative to the plugin itself, not relative to the plugins location on the computer. Not everbody on earth have their plugins located on the same drive and same folders. This means that people cannot send projects between one another without making the project FUBAR, even though the receiver of the project have exactly the same plugins/versions installed. This have to be a BUG!?