Starship Krupa

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.

Watchers of this space may be familiar with my fear and loathing around Cakewalk Sonar's drum map system, which I have been beating my head against since Cakewalk by BandLab shipped 7 years ago. Usually I've just wanted to display the drum kit piece names over on the left and use the drum grid to compose/edit and have been amazed at the obstacle course of hassle and confusion I've faced on the way to that (simple, I would think) goal. This time, I took on something much more involved and that makes deep use of the utility of what drum maps were originally designed to achieve. And in the spirit of fairness (as well as gloating), I'll tell the tale of how I used a drum map to accomplish something really useful that might not be possible with other DAW's. That is, the mapping of a given MIDI note to whatever you wish to map it to, to and from a hardware unit and/or virtual instrument. The function that when I've ranted about the hell I've gone through just to get note names to display with a drum editing grid, certain beloved users would sound off with protestations of "drum maps is the most magnificently awesome way of being able to use my original Roland Octapad to drive the brain of my Casio MIDI drum kit!" Which. Wasn't. What. I. Was. Talking. About. At. All.😡 "Of course I don't use drum maps just to display the note names, for actual programming and editing I use an instrument map and the normal piano roll view." Yes, of course you don't, because IT'S A MISERABLE HASSLE. 🤦‍♂️ But this time, what I wanted to do, were I able to pull it off, would use the note mapping function to map MIDI notes Background: "why would I deliberately inflict this on myself" tl/dr: I've been a fan of A|A|S' products ever since the DAW I was using 10 years ago started including a bespoke 2 soundpack version of their A|A|S Player, which is a synth that allows you to use A|A|S synth preset packs ("soundpacks") without having to buy the full synths the soundpacks are designed for. There is absolutely no control of any parameter, delay and reverb (often too much for my taste) are baked in and will be there until you buy the synth(s) that the soundpacks were designed for. Most of the soundpacks include up to a dozen drum/percussion single hits. Kicks, snares, hi hats, toms. I've never quite understood what I was supposed to do with these. Load up an entire virtual instrument just to get one note out of it? At least I determined that multiple instances of A|A|S Player share the same already-loaded engine, so overhead isn't so bad. Although these single hits often sound as compelling and complex and unusual as I expect from A|A|S, I've tried making multiple MIDI tracks (kick, snare, hat, tom) and it was too clumsy to have 4 separate MIDI tracks for drums, and it also makes it harder to visualize what the patterns are. Also, it's not really feasible to use Step Sequencer to program patterns if there are 4 different MIDI or Instrument tracks. But what if there were some way to have 4 synth tracks driven by a single MIDI track for simpler editing? And what if I could use the drum grid and even Step Sequencer for editing? Turns out my hunch was correct: it IS possible, and a custom drum map from scratch is the answer. Rather than starting with a GM or Default or even "blank" drum map as I normally would, I started a completely new one, for the first time following the "New Drum Map" menu selection to the letter. I created entries for note 36 (GM standard for kick), 38 (snare), 42 (closed hat), and 50 (hi tom). I loaded 4 instances of A|A|S Player into Synth Rack (a feature I never use for anything but troubleshooting) and named them AAS Kick (huh huh), AAS Snare, AAS Hat (huh huh huh), and AAS Tom. Then I set the Out Ports for each of these notes to the appropriate synth instances, and lo and behold, it worked: Maybe I could get even fancier with it and have the drum map send patch selection info to the synths. That's for another time. At the moment, I'm just having too much fun opening the different instances of A|A|S Player and trying different sounds. I still need to load the 4 instances of A|A|S Player before applying the drum map, so I'll make an A|A|S Beat (huh huh huh huh) project template with everything loaded up and ready to go.

I took "we stopped using that 20 years ago" to mean that they stopped using it for active development 20 years ago. Not that they purged all code that used the library 20 years ago. The library that Glenn found was dated 1999. There's plenty of Sonar, both in the UI and under the surface, that dates back as far as 2005. I remember using a version of SONAR over 20 years ago that had the same Staff View as still exists in Cakewalk Sonar (minus the menu bar at the top, which seems to have been updated with the new vector UI). Dialogs and guitar fretboard and all else looks the same.

😄I knew that Audio Git would wind up with an Ozone Elements license before he could blink. I checked to see if I had any extras floating around, but didn't find any. I was kind of surprised.

I am (and always have been) impressed by the amount of love that the Sonitus FX suite still gets. It seems that Cakewalk, Inc. knew what it was doing when it bought the suite (was it the entire company?) over 25 years ago. My nderstanding is that they began life as a premium commercial suite, then Cakewalk bought up the suite for inclusion with their DAW. They are kinda homely by 2025 standards (and the UI's are tiny), and I have resisted usiung them because they are effectively "DAW-locked" and can't be used in other audio and video hosts. I like to be able to use the same processors when I switch back and forth between different programs. But when I've tried them, they seem to sound great and have good workflows (esp. given that they are now over 25 years old). The multiband compressor and delay especially seem to have a lot going for them. Craig Anderton likes them so much that he uses a DXi-to-VST wrapper to be able to use them in other hosts. I'd love to see them get more contemporary (flatter, darker, resizable) UI's, and ported to VST3. And yes, while we're at it, making the Cakewalk linear phase EQ and multiband compressor available would be nice. They're great processors and would make good additions to Sonar.

Right, there's even a name for this process, "comfort reverb," to help the performer relax and deliver a more natural performance, rather than be confronted with a dry sound in the cans (revealing every detail).