murat k.

The discussion here has been concluded in this thread:

As a result of the discussion in this thread, it became clear that the problem has a simple solution. We can separate the Velocity and Gain controllers in the Track Control View and toggle them on or off as needed. This way, we will have both Velocity and Gain controls for the Instrument Track. When the feature request is implemented, the Track Control Manager will look like this: Note: If you don’t understand what I’m saying, please remain silent. This is a feature request; I am asking for a solution from the developers, not advice from forum users.

Here’s the kind of comment that should have been made from the beginning. Thank you!

Actually, OP is quite clear and straightforward. The expressions are correct and defined. Still, no one understood, which can happen; it’s just the nature of this place, so no problem. What I'm saying is that this setting, if it were 'Gain,' would be more useful: Because, as far as I can see, Gain is a control that is used more often compared to Velocity. It would be better if there were both, but according to the Track Control Manager, there is only one setting that controls Gain. In the past, both the Audio and MIDI tabs in Inspector used the definition of Gain for the relevant section, even though Velocity definition was used in Track View. It seems that this inconsistency has been resolved with the update to the Sonar GUI. Besides that, thank you for your brilliant explanations; they were completely unnecessary.

You can see an example in this thread of what happens when a user gives completely irrelevant advice: But I should congratulate you. This time, by giving advice based on an ancient version of Sonar, you’ve truly taken irrelevance to a whole new level.

Wouldn't it be more useful if the Gain control appeared instead of Velocity in the Instrument Track controls in Cakewalk's Track View? Based on my usage, I tend to use Gain more frequently than Velocity. Ideally, having both would be great, but if I had to choose one, I would prefer Gain.

Or this feature could be preserved only for MIDI CC Automation values instead of MIDI controller events. Like the plugin values, default values are created when the file is opened. This is a more convenient method compared to the other.

@Noel Borthwick, You do not need to merge and restore a MIDI file to the Track Template file for this process. It is sufficient to index the MIDI CC values corresponding to the start time in the Event List for each track as simple text and ensure that this data is recreated when the template is loaded. With the addition of this feature, a significant shortcoming in the Track Templates will be addressed.

When we change the settings of a plugin and save it as a track template, we can recall those settings. However, this feature does not work for initializing MIDI CC values. Project templates have this functionality, but they lack the flexibility of Track Templates. Track Templates would be more useful if they could save a MIDI CC value as an initialization.

AI is a tool; art needs no defense.

Because you had been exposed to the meaningless comments of a group of status quo defenders. Don't worry. In time, they will all disappear one by one.

There you go. One more.

This has always been the case, and it’s the same now. When I ask for a solution to a problem, I encounter people who neither solve the issue, nor understand what I’m saying, nor help me at all. Instead, I get unhelpful advice from those who clearly haven’t understood me. For example, when I say, ‘I’m very thirsty,’ you respond with, ‘There’s pastry; you can eat that.’ I try to explain that this is something completely different, then you accuse me of lacking empathy. I think you all have forgotten this as active users in a public forum, giving irrelevant advice without understanding a person's request can hinder their ability to achieve their goals and also frustrate them. I suggest asking yourself whether you are showing empathy before defining what empathy is.

I wanted to bring up the concept of empathy in relation to the phrase 'or log in'—not everyone has to log in. Even if I wanted it for myself, it will benefit everyone once the issue is resolved. I just wanted to emphasize that. Perhaps we could make a meaningful step towards truth by striving to understand others, rather than hastily passing judgment on them.

Hahaha, it wouldn't be the same without you. I guess I've missed you!

To be honest, you've put yourself in a very meaningless situation by giving a piece of advice that pragmatically offers no benefit in a thread clearly addressed to the site administrators. It's okay; such things can happen. But if you know who the site administrator is, you can share their name here to draw their attention and provide real help.

Dear @pwallington blunt, let's imagine we're browsing the forum and come across a thread that's two years old and four pages long. If the issue is resolved, we can reach the last comment with a single click. However, with the method you suggested, we would have to view all the comments posted on the site over the past two years one by one, which makes accessing the comment pragmatically impossible. Setting pragmaticality aside, you must acknowledge that this solution doesn’t even work for a recently posted comment in a forum where many topics are opened simultaneously. You might not fully understand what I’m talking about, and that’s okay. However, if we want to help others, the first thing we need to do is understand them. If we don't understand, it's best to remain silent. Otherwise, conflicts arise here, as we see. You came here, offered me no help or practical solution, and on top of that, you’re doing this to me. 🤷‍♂️

Hopefully, this change on the site wasn't implemented as a result of a deliberate decision, and the site admin resolves the issue; otherwise, we will be left with a user's suggestion to view all activity in the forum everytime when we're simply trying to find a single comment. When someone requests a solution to a problem, if you can't resolve it yourself, choose to support them rather than offering suggestions you think are pragmatic, if you genuinely want to help. In this way, you'll avoid unnecessary commenting and actually provide meaningful help.

🤷‍♂️

If you can't solve the issue on the website, you might consider using your empathy to think about the benefits that restoring a useful feature would provide for everyone, or don't comment 🤷‍♀️

I haven’t visited the forum for a while. While browsing through it, I noticed that a feature for users who aren’t logged in is missing. Previously, when we clicked on the date next to the last comment in the thread, it would take us directly to that comment. Now, however, the link only directs us to the thread where the comment is located. Using Wayback Machine to look back, it appears that this feature was removed with an update in August 2023. Before August 2023, the link associated with the last comment’s date contained &do=getLastComment at the end, but now, it seems this is only generated when users are logged in. This was a useful feature, and bringing it back would make navigating the forum easier for everyone.

Variorum, I really appreciate your plugins. I think they include all the MFX features that Cakewalk has needed and that I’ve always wished for. Thank you so much for that. However, there isn’t an arpeggiator plugin on the market that can directly convert a clip into an arpeggiator like Z3ta+ does. Unfortunately, with that one, the arpeggio we generate can’t be converted into real notes we hear using the ‘bounce to clip’ method for use in another plugin. Would you consider revisiting that arpeggiator plugin you left unfinished? It doesn’t need to be anything complex—just a simple MFX arpeggiator plugin that converts a MIDI clip into an arpeggio via drag-and-drop would be more than enough.

Thank you for supporting the idea. Initially, I thought the problem could be solved through a general setting like in other software programs. However, considering that Cakewalk already has a feature like MIDI Input Preset, it occurred to me that developers could achieve the desired outcome with minimal effort by adding a preference like the one in the image, without the need for any new menu. Other than that, what developers would need to do is simply add a procedure of applying the default MIDI Input preset to the track creation operation. If this feature were added, it would permanently resolve an issue we encounter in projects where we need routing between tracks. However the main question here, I suppose, is whether such a feature will be added to the final version of Cakewalk by BandLab. As we know that from the statements the latest CbB version will be released not to introduce new features but to give the software a final form with bug fixes. Before learning this, I thought that, like in other DAWs, there would be an updated but limited version offered for free. Perhaps the company may consider such an option in the future. However, even if such an alternative exists, we cannot guarantee that MIDI Input Presets will be included in the free version of Cakewalk Sonar, as in the past, MIDI Input Presets were not supported in SONAR Home Studio, which was a lower-tier but paid version compared to Cakewalk SONAR. Of course, the company may consider it more appropriate to include such a feature in the paid version, after this point, it's entirely up to them.

Or a Default MIDI Input Preset would work as well. Also with this method, we can achieve the desired result with minimal intervention in the software's interface.

When we add a synth, the default input comes as "None." If the "Enable MIDI Output" option is checked in any existing synth within the project, the "Always Echo Current MIDI Track" feature starts to become problematic because having "None" as the input means "Omni" for all inputs at the same time. However, generally we use one input tool that we use for each track. Currently, Cakewalk users have two options that they have to repeat every time: either keep the "Always Echo Current MIDI" option disabled and enable the "Input Echo" option for each instrument they play or change the input value for the default input they use for every newly added instrument. As a workaround, we could consider using "Project or Track Templates," but what would we do when we want to add a new instrument to an existing template? Perhaps, to avoid this, we might have to create separate single-track templates for each instrument, which can be cumbersome. To solve this issue selecting the default input option from the Preferences can eliminate the need to make such a setting for every instrument we add. This is not a new topic; it has been discussed multiple times before: Having such a feature in the final version of Cakewalk by Bandlab would resolve one of the important issues with MIDI routing in Cakewalk.