Starship Krupa

This evening while recording MIDI from my keyboard controller, I had the following happen, and am able to reproduce it every time, at will: First I recorded 2 takes in loop record mode (settings: Comping, Create New Lane, New Takes on Top is unchecked) resulting in this, which is expected and fine: Two takes, clips the full length of the loop, all data recorded and intact. Then I had the idea to try playing another, shorter take that overlapped the existing ones, and that's where things went sideways: As shown in this screen grab, I have my new take in its new lane, data intact, but the original takes have been split where the new clip begins and ends. If I had to bounce them back to one clip, that in itself would be a hassle, but a worse problem is that where the splits are, the MIDI notes have been truncated, thus ruining the first two takes. The 3rd clip in lane T3 is completely empty. Also, the first bit of T3 is unmuted. I was able to salvage the first 2 takes by deleting the newly-created clips and dragging out the remaining clip edge to reveal the MIDI notes (fortunately still there), but this seems like a lot of trouble and risk to go to (especially if it happens multiple times) and I'd rather just prevent it from happening in the first place. With the first bit of T3 being unmuted like that, it sort of looks like a punch-in, but I didn't use Punch-in because I wasn't correcting anything, I just wanted to see if a different, shorter phrase would work in the track. It's not a punch-in, it's a whole new alternate take. I'm not sure what the "Auto Punch" setting does, but I have it unchecked. I didn't want the old takes to be split and slip-edited, I wanted to keep them in place so I could audition them and hear what works best. This isn't an unusual task, I try out different parts all the time. I've had projects get messed up like this before, was fortunately able to salvage them. I'd rather not be breaking them in the first place. What am I doing wrong? Are there settings I can change to prevent it?

It helped a great deal, actually. Although I prefer to work with "Create New Lane" selected, I usually use templates modified from the stock ones, which have "Reuse Existing Lane, Unless Takes Overlap" selected. I'd forgotten to change it before I saved this one. Hence the expected unexpected results. I'm still testing it, because I've seen other strangeness with how Sonar is handling MIDI in lanes, but for now, if anyone's having trouble with getting newly drawn MIDI to draw in its own lane, make sure that you have "Create New Lane" ticked under Preferences/Project/Record. The way it works is that after you've finished playing your takes, open the lanes. Your takes will be in clips in lanes. Should be one lane and one clip for each take. In order to drawn new notes into any given lane, click on the upper half (the Smart Tool will be in Move mode) of the currently unmuted clip (which should be in the last recorded lane), and press "K" to mute it. Then click on the clip you wish to edit and press "K" to unmute it. At this point, in PRV, you should see the notes from the clip you unmuted. You will be able to freely add notes, delete them, or perform other operations on them and have those changes apply to the clip rather than creating new clips or having your changes appear in the wrong lane. To add notes in a completely new lane, first make sure that all of the existing clips are muted, then draw them in the PRV. A new lane will be created with the new data appearing in a new clip. Note: sometimes I had to collapse the lanes and reopen them for the new lane and clip to appear, but they did appear. That last step only works once. If you wish to create subsequent new lanes and enter/edit notes in them, the only way I could find to do it was to create a new lane, arm it for recording, record a couple of notes in it and go from there as you would with any already-recorded take. Open up PRV and the existing "scratch" notes you played will be visible, and any editing will be written in the new lane. For the people in this topic who are unable to enter notes in the lane of their choice, I'm not sure what's going wrong. Do you have the lanes open so that you can see which one has the unmuted clip(s)? I tried this both in Comping and Sound on Sound recording modes. Along the way I found some oddness in the way that Sonar reacts to new clips being recorded in the same track (my old hobgoblin, Sonar creating unwanted splits in the clips), but my army has had to retreat from that hill in the past and and I won't charge it again until I have better ammunition.

I at least think that it will write to a lane of your choosing if clips in all other lanes are muted and the track is selected and highlighted and editable in the PRV. I'll try it again with more lanes and see what happens. I only created 3 lanes when I tested it before. Was T2 the first lane that you played into when you started the track?

As do I. My eyesight only gets worse as time goes on, and I'm starting to have to make educated guesses about where to click. I don't have these problems when using CbB. Just re-enabling color settings for Vertical Beat Lines and Vertical Measure Lines would help so much. My CbB Track Pane grid colors: My CbB PRV grid:

I did a bit of experimenting and determined that if you start the track by playing in real time, notes added manually will be added to the first lane that you recorded. The workaround for entering subsequent notes in their own lane is to create a new lane and add a clip to it. Then you can enter notes into that lane. The way I'd like it to work is that you can create a new lane and then record arm it, and subsequently new notes will be entered into the armed lane.

This is a great way to put it. Especially when composing with MIDI, lanes allow for all kinds of scratchpad stuff, alternate ideas, etc. I kept my description more editing oriented, but these days, the editing process has aspects of composition. And I must remember when discussing this stuff: working with recorded audio tracks and with MIDI tracks are two different, yet similar, beasts.

There's the obvious one, which is taking multiple tries at recording, either looping or one at a time, each of which generates a lane. Then when you think you have a good one, you stop recording. Then make sure the best take is unmuted and the lesser ones are muted. I'm referring to audio takes here, there is a distinction, audio and MIDI differ from each other in some ways. So each instrument gets a track, and different takes get lanes beneath that track. Or there's comping, where you have enough takes to use parts from 2 or more to stitch together a good one, and you stop recording and set about using the various editing tools to do that. There's the Speed Comping workflow, which can be really swift when what I'm doing is recording full takes and stitching together the best parts, and then there's a more manual workflow where I kind of use it like a word processor or image editor, copying, cutting, pasting. I usually end up doing it the latter way, with clips getting copied, moved around, etc. So for instance I'll use the best take of the verse and/or chorus and copy and paste it. Having multiple lanes to work with allows me to create one or more empty lanes to use as scratch space, so instead of having to paste things into the same lane one after the other, I can paste into an empty lane. And then what started out as an empty lane ends up having all the clips I want in the proper order. If you're not moving anything around, you can also just leave clips where they are and mute the ones you don't want to use and leave the ones you do want to use unmuted, assuming they don't need crossfades. If you were to look over my shoulder for 15 minutes, you'd get it straightaway. So for instance there will be a Bass track with multiple lanes, each of which has a different take of a bass player playing the song. Let's say I did 3 tries. Take 1 is entirely too sloppy to use, so I just delete the lane. Take 2 is mostly good, but there's a glaring mistake in the 2nd chorus. If the 2nd chorus from Take 3 is good, I can use that, or if Take 2 has another chorus that will work, I can try copying and pasting a section of Take 2. Another aspect of using lanes is in situations where I'm recording an instrument with multiple mics, usually a drum kit. A track for each mic, and then the multiple takes go into lanes. Any comping or editing is done with the clips grouped so that each of the bits eventually used will be from the same take. I can't really imagine doing this using multiple tracks. The biggest advantage to having all of the takes of a given instrument in one track is that when it comes time to mix, all of that audio (or MIDI) can use the same effects, level, pan, etc. I don't know how this would be accomplished with each take being on its own different track unless eventually all of the good bits get pasted from multiple tracks into one. With MIDI, for each instrument again, there's a track. If I am recording the MIDI live from a controller, each attempt to nail it will get a lane, and things proceed similarly to audio comping. Lanes can also be handy even when all notes are entered in the PRV. I sometimes find it easier when copying and pasting multiple measures at a time to do so in Track View. Sometimes when say, a bass part has 3 variations, 2 within the verses and then the chorus, I'll give each variant its own lane. This can make it easier to keep things sorted when I want to extend the song, I can do the copying and pasting of the measures that are variant 1 individually from those operations on variant 2 and so forth. I can also do things like muting the entire lane to mute one of the variants, maybe try different variants and audition them by muting and unmuting the whole lane, etc. This is why I (and others, like David) would like it if the option to hide muted clips in Piano Roll also applied to muted lanes. Because as it stands, in order to hide unused takes from the PRV, you must mute the individual clips. If a clip is in a muted lane, it won't be hidden by choosing that option. From a composing standpoint, I may want to try different parts in different places, and having an extra empty lane can make it easier to keep things in order when moving parts around. Again, I could show you this in a matter of minutes and it would make sense. It's much more difficult to describe the process. Doing all of this using separate tracks for each take seems unwieldy to me. Seems like there would be some visual overhead involved in having the takes spread across multiple tracks, and it would especially make comping more difficult. I do understand being put off by using take lanes. The editing tools make certain assumptions about workflow that may be different from how the user is used to working or expects it to work. Such was the case with me when I first started using Cakewalk 7 years ago. But then the devs made some changes that made it easier to override some of the mechanisms for when I want to just cut, copy, paste and stitch. I did eventually learn the Cakewalk comping workflow, and it lives up to the "speed comping" name. When the project I'm working on lends itself to that workflow, I can really fly, but before I figured it out, I made some messes with it. With great power comes great ability to turn one's project into chutney. The workflow doesn't necessarily work best for every comping situation and I was happy when the devs made it easier to do more basic operations without it getting in the way. I suspect that the bulk of antipathy toward the take lanes system may have come from these advanced comping features being so front-facing. Before the changes were made, I often had the feeling that CbB was fighting me, that it was assuming I wanted to do things a certain way that was different from the simple cut, copy, paste, and move operations I was trying to do. Figuring out where the different hotspots are and what I get when clicking on them took some time. At first I didn't realize that there were different hotspots on clips that would yield different results depending on where I clicked and that was WAY frustrating.

Interesting. So a workflow that is common for me, enter a part by playing, then add notes to it later, is uncharted territory for Sonar. They get entered, but there's no official rule as to which lane. One way I think would work would be if newly added notes were added to whichever lane is currently selected in Track View. Unless someone else speaks up, I guess the process is to play a couple of notes in from the controller to make the new lane the active one and go from there. Or as you suggest, enter a few notes to find out which lane Sonar wants to use, then move the existing data out. Or just create a whole new track. I guess the assumption is that for a given track, either the user is going to be entering notes manually or they're going to be playing them on a controller.

Yes, that would work too, as well as the other workarounds I've described, but it still amounts to observing where Sonar is adding new notes and then shuffling existing data around to make room for it. What I'm trying to learn is what logic Sonar uses to decide where newly added notes are going to go, and if possible make them appear in an otherwise empty lane.

Situation: I'm working on a song where I recorded a synth bass part by playing it in in real time, then tidying the performance. I got another idea for a bassline, so I recorded another one, repeat tidying. Now I have 2 existing lanes, and yet another idea for a bassline, which I would like to enter entirely by using my mouse in the PRV rather than playing it on the controller. The problem I'm running into is that I can't figure out how to enter these notes into a new, third lane. When I enter notes, the appear in clips overlaying the clips in one of the existing lanes (always the same lane). I've tried creating a new, blank lane and clicking its header to select it before flipping over to the PRV, and that doesn't work. Rearranging the existing lanes and empty lane changes nothing. All clips in both existing lanes are muted. Just for laughs, I tried unmuting the clips and any new notes still went into the same existing lane. Of course the path of least resistance would be to record a couple of random notes using my controller, which would create a new lane. Then I could delete the random notes in the PRV and continue on my merry way. But I dislike not understanding things, so what am I missing here? What's the correct procedure for this? Obvious workaround suggestions like creating a whole new track, entering the new part, then copying the clips to the existing track are discouraged. I've already figured out multiple ways to get around the issue, I'm trying to satisfy my curiosity about how it's supposed to work. There must be some logic to how Sonar's choosing what lane my manually entered notes will go into.

I find it best in situations where both wired and wireless connections are available to make sure that Windows is only using the connection I want to use. With notebooks, there's usually an automatic switching back and forth, but not always. With my desktop, I always have to manually disable the wifi adapter when I'm plugged in. I'm not sure why it causes problems, but I think that sometimes Windows doesn't know which adapter to use and switches to the other one. If it switches in the middle of downloading a file, wacky hijinks such as what you are experiencing may ensue. Choose one or the other, and make sure it's the ONLY one enabled.

Mark lives in Scotland. That would be like sending brown ale to Newcastle. 😄

Frank Sinatra based his whole musical career around that model. As do most symphony orchestras.😄 Performers writing their own material didn't become a litmus test for "authenticity" until the 60's. Not everyone who's good at singing or playing is also good at writing, and vice versa. As for artists who usually do write their own material covering entire albums, or covering entire albums in different styles from the original, it's either for the laughs and/or out of genuine respect for the original material. The Moody Bluegrass project turned out so well that they eventually got Justin Hayward to sing with them. The whole thing was based on a pun in the name, but it so happens that the blokes in the Moody Blues wrote excellent songs that transplanted well to a different genre. I think that more people have realized that one of the reasons that people who manage to earn a living by writing, playing, recording and selling their own music become famous is that it happens so rarely, like airline crashes, shark attacks and earthquakes. All of which get extensive media coverage because they are so uncommon.

I got a free license for Antares' vocal ensemble plug-in, and once I saw what Codemeeter was doing (it ran its own service, complete with a tray icon), I uninstalled it. I actually liked what the plug-in could do, but I already have Quadravox and had no desire to have this licensing server running at all times just so I could use this one plug-in very infrequently. Recently I got email from Antares announcing that they were switching to iLok. PACE also installs a service, but since I have a couple dozen iLok'd plug-ins, I don't mind. So I downloaded their latest installer and ran it and lo and behold, while they had switched to iLok, the installer still installed the Codemeeter crap. So I tried getting rid of Codemeeter manually, deleting its files and disabling its service, and it didn't affect the Antares plug-in.

Thank you for replying to this. The more information we give the companies the better their chances to fix it. Preguntas: Do you have projects where this happens every time? When the crash occurs, do you get the following dialog? Have you tried contacting A|A|S' support and Cakewalk support through official channels? The more people who report a problem, the greater the chance that developers will use resources to fix it. One person reporting it is usually seen as a fluke, two people reporting it starts to form a pattern, and if we can get three reporting it, then it's way more likely that they will put attention to it. If you see the above dialog when it crashes, it would be of great help if you were to attach the .dmp file shown in the dialog to a reply in this topic or to me in a private message. If you have a project that crashes every time, or most of the time, it would also be of great help to send it (or a simplified version) to the developers (both A|A|S and Cakewalk) as well. If you would rather contact me directly to forward the files, I'd be happy to. I've been in contact with the development staff at Cakewalk and at A|A|S and know where to send them directly. I like to refer to plug-in problems as "compatibility issues" between the plug-in and host rather than try to figure out whom to blame. In the end, the products should work well together. Cakewalk SONAR Platinum once bundled 3 different A|A|S instruments, and my projects don't crash Cakewalk by BandLab, so this issue seems to be something new to Sonar. If Sonar has introduced an issue in its new code or the new code has exposed an issue with A|A|S' ( very popular) instruments (or both or neither), it's in both companies' interests to fix the problem. For my part, A|A|S' synths are without question my favorites, I've spent more on them than all of my other virtual instruments combined. If this problem persists, I'll be very sad.

Looks like we didn't have to wait until late 2025 to at least see MIDI 2.0 support and the new faster USB driver. I want to try this on my Windows 11 test system. It may be the tipping point for upgrading all of my Windows systems. https://www.thurrott.com/windows/316785/microsoft-releases-windows-midi-services-with-midi-2-0-support-in-public-preview I guess I'm not surprised that writing a real ASIO driver for the Realtek CODEC is taking longer.😂

I'm still using my Pro 40 on Windows 10 and it works a treat. I haven't tried it with my Windows 11 test system, but maybe I should. I know of no inherent reason that Firewire wouldn't work in Windows 11. Are you considering installing Windows 10 instead of 11 in order to be able to keep using your Pro 40? Or are you weighing the possibility of buying a newer USB interface? If the day ever comes that my Pro 40's (I have two of them) stop working with Windows, I hope to still be able to use their 8 inputs via ADAT connection to a newer interface.

Advice: yes, do update the BIOS, but check to see how many revisions there are between the version you have now and the latest. The only time in my 35 years of computing that a BIOS update bricked a motherboard was when I was resurrecting a hand-me-down motherboard and updated its original BIOS to the last released one. Did some research and it was a known issue. If updated incrementally, it went fine, but with too large a jump, brickdom happened, with no way to get back to the original BIOS. You don't necessarily need to do them one by one, but do research to find out how BIOS updates have gone for other users of your model.

Bork happens.

Shedding tears for ya, mate. Missi looks like a real sweetie. My departed doggy Kittery was one of the finest souls it's been my pleasure to encounter in this life. One day she will have a successor, replacement is impossible.

From my "white box" perspective, and longtime experience with A|A|S synths, I strongly suspect that it's something to do with Sonar sending data to the plug-in, and the plug-in not outputting data fast enough when Sonar expects it to be there. Or the plug-in not being in a state that Sonar expects it to be. Due to processing being diverted to drawing the UI or something. There's a race condition happening or something. Given that much has been done recently to speed up performance, specifically as regards plug-in performance, I have to suspect that it's down to that. Something that used to have enough time to happen now doesn't have enough time to happen. I recently crashed Sonar by scrolling through Vital's preset list too quickly, while the project was playing. Not a divide by zero error, but it crashed Sonar with a minidump. So a lot of UI drawing going on in the plug-in, and boom, down she goes. The developers so far can't get my submitted projects to crash on them, and it's very difficult to fix a problem that won't manifest its symptoms. Laypeople, I think, sometimes expect that programmers can just open their code and figure out what's going wrong by reading it, guided by the user's description of the error. While that's not impossible to do, it's very unlikely to happen. Especially when it's not being reported by hordes of users. But it can't be just me, it happens on two very different systems.

Information has been submitted in great detail, including the fact that the same projects work fine in CbB. I usedta be a pro software QA engineer, and believe me, I've thrown everything I have at this, trying to inform both companies. It's especially odd because Cakewalk and A|A|S were once bundle buddies. And Strum Session is one of the instruments that will trigger it.

No. For instance the same projects run fine in Cakewalk by BandLab. It's always the same, divide by zero.

I've been experiencing regular crashes specifically when using A|A|S instruments. What happens is that I start playback and as soon as the A|A|S synth tries to produce sound, Sonar crashes. This occurs on two very different systems, my main DAW and my Dell laptop, so I have a hard time believing that it's specific to me. However, I've submitted the crash dumps and test projects to both Cakewalk and A|A|S, and apparently they can't reproduce the crash. So for now, my favorite DAW and favorite virtual instruments don't get along.

Drum maps is a powerful, complex feature that's hard to get one's head around. But it can allow you to do neato things like this. And I like a good challenge too. What I dislike about Cakewalk's drum maps feature is that it's also necessary to employ it to perform what I believe should be a simple task. To my thinking, needing to go as deep into it as one must in order to display the drum editing grid with the names of the instruments you're using....it's as if you had to write a .CAL script in order to rename a clip. I'm reminded of this when I see how often another DAW I use tells me in its update dialog that it's adding new drum maps to the program's library of them. In that DAW, to use a drum map/drum editing grid, when you're in the Piano Roll, you click on the Scale selection button and there is a vast list of available drum maps you may use. This is actually kind of a step backward; it used to have a button in the PRV header marked "Drum Map." Imagine being able to apply a drum map from the Piano Roll, the actual place in the program where you use a drum editing grid! Rather than having to go to Track View or Console View. I'll never forget helping out a longtime Cakewalk user who started using this other DAW as a secondary and was befuddled as to how and where to apply a drum map. He couldn't find it because it was in the simplest, most obvious place for it to be. He was probably expecting it to be somewhere in a track header or console strip. But y'know, the reason that this other DAW is now my secondary where Sonar is my primary is Sonar's versatility. Routing and so forth. Also, I've never tried doing note remapping in that DAW, I'm not even sure you can do it.