Starship Krupa

You mean clips' note color, right? Because unless I'm misunderstanding, PRV currently uses the tracks' foreground color for a track's notes. Doesn't it? I change my colors up all the time, both clip background and track foreground. I'd be very sad if I couldn't set clip background colors for PRV. As far as clip (not track) foreground....I wouldn't use that, but I can understand why some might want it.

It was called to my attention that CbB's Theme Editor was originally created by end users who reverse engineered SONAR's resource files and figured out what images and color settings were stored there and how to alter them. It wasn't a product of Cakewalk until Cakewalk bought it from the end user who had published it. If some intrepid user(s) could figure out where/how Sonar is setting/storing its color settings, it might be possible to do something similar for Sonar. A Sonar Color Editor would be much simpler, because it wouldn't have to deal with images, just be able to read the color settings and change them. My (current) abilities in this department aren't suggesting where the color choices might be kept. It wouldn't be in the EXE or DLL files, because I don't think you'd want to be rewriting those whenever the user changes color schemes. The first big question is where does Sonar keep its color schemes? When Sonar switches color schemes, are the factory schemes stored in one of the executables and your selection of which one of them to use is written to the registry or wherever? That would be my first guess.

The colors I most need to be able to set are: Measure and beat grid lines. Clip pane background (goes with the above) Text (in as many areas as possible) Aim Assist line Button image (esp. note values in PRV) Button background (goes with the above) Browser text (incl. Notes) Browser background These are all colors that vary between the various factory schemes, so I know it's possible to change them. In the case of the grid lines, Aim Assist Line, and (I think) Clip Pane Background, those colors could be changed using the existing Customization/Colors dialog. The dialog is still there, but those settings have been removed. Please add them back.

Right, after all these years, Sonar still doesn't include a pad/phrase sampler. XSampler was ported from Next, but that was a year ago and XPadSampler is still nowhere in sight. Sonar now includes a "sampler," but it's not the type we were asking for all that time. When XSampler was introduced, I thought that the pad/phrase version would be following shortly, but no. It was a HUGE feature request for a long time. You and I were two of the users who were noisiest about it and I'm glad to see you checking in on it. Yeah, been requesting this since Cakewalk by BandLab first came out. Even Pro Tools has added a fully-featured clip launcher since then. Matrix is a feature that has always looked to me like it was about 3/4 implemented and then abandoned. I agree with all of the suggestions to add the functions that BandLab has to Sonar. Sonar is presented in BandLab's collection of DAW's as the endpoint, where you can start with the web or mobile BandLab DAW, move to Next, and then when you're finally ready, Sonar. The problem with that is that Sonar lacks multiple features that even the mobile DAW includes. To move from the mobile version to Next to Sonar only works if you're willing to give up a phrase sampler, pitch correction, chords and scales, the virtual instruments, and stem separation. As for using multiple EQ's in ProChannel, that would be very nice. Especially since the excellent Quadcurve EQ can't be used in the standard FX bins. Which is another feature request that occurs to me.....

Wow, huh, very interesting. My guess was that it was an in-house tool which was then released to the general population. If Cakewalk used it to create Tungsten, then I was sort of correct, except that it wasn't originally created by them. Was Tungsten something that Cakewalk created using Theme Editor? IIRC, there's nothing to Tungsten that couldn't have been done using Theme Editor. It would explain the botched MIDI Inspector strip image that I noticed and reported. I notice that TTSRES.DLL is still around.

So far we have 5 different ways to do it. I think Bass and Gregy are tied for the fastest ways. My Aux track thing requires a realtime playthrough.

I will say that although TDK-SA sounded the best on my Akai deck, Maxell always kicked their booty as far as the transport design and construction. The Ampex Grand Master also seemed to be lacking in that department.

If you want to see what colors can be changed, compare the factory stock color schemes to each other. They have different colors for buttons, Clip Pane backgrounds, grid lines, and more. Theoretically, if users are given access to those colors, we can set them to whatever we wish.

User @Maria P started a topic calling for color customization. It's near the top. Just reply to it and say "hear hear" or whatever.😄

The biggest one for me is that they dropped the font size of most of the text by a couple of points. Cranking Sonar's internal scaling up gets the text size back up, but it also reduces available real estate. Everything else gets bigger along with it. I don't know why the devs chose to do this, the spaces where that text sits didn't shrink, so it wasn't that. After that of course is the grey-on-grey palette....as soon as I figured out I could use Theme Editor and custom colors to make most of CbB's UI an easy on the eyes color on a jet black background, I was off to the races. Grey-on-grey isn't just boring, it's harder to read.

Ah Sonar. So versatile that 3 different users can each have our own way of accomplishing the same task. When I want to do this I make an Aux track with the audio output of the Synth track routed to it. Really, all of these solutions work. Choose the one that vibes with ya.

Cakewalk Next can't open CbB project files directly. Are you sure you want to transition to Cakewalk Next? The successor to Cakewalk by BandLab is Cakewalk Sonar. It has all of the features of Cakewalk by BandLab, opens CbB projects just fine. It looks very much like CbB and has the same workflow. Cakewalk Next is a separate DAW program.

Are you sure you tried the right program? Cakewalk by BandLab evolved into Cakewalk Sonar. Cakewalk Sonar keeps (almost) all of the features that Cakewalk by BandLab had and adds some new ones. It definitely has Synth Rack and supports WASAPI. Cakewalk Next is an entirely separate DAW, designed for a more stripped down workflow.

So Theme Editor started out as a 3rd party application? I always thought that it was an in-house tool that was polished up for end user use. It could be both, I suppose. Still, I thought it was something the bakers of the day came up with.

As I said earlier in this topic, I believe that a comprehensive theme editor like the CbB one is not only unlikely, it may not even be possible. Even if it were, Theme Editor was a whole separate program, and it takes resources to write a whole new program. For sure, I'd LOVE to have something like it again, I just don't think it's a realistic expectation. However, most of the aging-eye-friendly changes you mention could be covered by allowing users to set colors in various places. With that in mind, I think that lobbying for just access to color customization is the better way to go right now. The devs see "Theme Editor" and the reaction might be "we ain't doing a Theme Editor!" On the other hand, it's already possible to set a wide variety of colors; the stock factory schemes do this. Mauve buttons in "Cosmic," orange buttons in "Tungsten," blue buttons and text in "Mercury Classic," etc. It's tantalizing. It's built into the program but we don't have access to it. My guess is that colors are set in a table; you put numbers in the table and Sonar looks at the table and Sonar colors elements accordingly. In the CbB days, we could change various colors using the same custom color dialog that Sonar still has and save them and share them. The current custom color dialog still allows the user to set colors, but not for anything that's important to me. Adding some elements back to the custom color dialog would take care of a lot. For all we know, it might even be easier to change things like knob colors in Sonar. With CbB, to change the color of a knob or button, we had to fire up a raster editor and alter an image and save it. Maybe Sonar's new UI will allow colorization of individual knobs just by choosing new colors. It would be great if it did!. At the moment, I'd settle for setting the colors for clip view background, measure and beat lines, Aim Assist, and text (in various locations). Having colors and more contrast would mitigate the legibility loss from reducing text size in so many areas.

Thank you for posting again. The more people who request a feature, the greater the chance the devs will implement it. If the request scrolls off into nowhere, they may get the impression that it's not so important to us. I have impaired vision, and with the CbB custom color feature I was able to set colors for my beat and measure lines in Track View. That really helped. Between custom colors and Theme Editor, I could get the track background pitch black and use green or blue for beat lines and red for measure lines. Also red for Aim Assist, which helped. I could also change the color of text in various areas. I didn't realize how much the contrast between a truly dark background and colored (not just shades of grey) elements helped until it was taken away. From what I can tell by looking at the the current stock schemes, it is possible to change button colors, background colors, and at least some text colors. So if users get access to all of those I will be a very happy camper. At minimum with my vision issues, color for the grid lines, text, and Aim Assist. When Sonar first shipped, I couldn't even see Aim Assist in the PRV with lighter schemes. I'm grateful that they adjusted that.

Yeah, subjective. That's a thing where our eyes get into the act. I'm waiting for people to start claiming that Sonar sounds more "clinical" than CbB. I'm starting to wonder if it's even possible for our perception to eliminate how the program looks from the equation. If the UI looks "cozy," which the Mixbus UI does, how could the listening experience not be more pleasant? I don't do blind A/B tests, but I do close my eyes and focus hard on what's in the cans. And I do always use cans when I'm scrutinizing things like this. I have a long history with it. When I was a teenager back in the early 80's, I had my girlfriend help me with blind testing (not double, she knew what she was playing) different brands of cassette tape. I recorded the same Steely Dan song from vinyl to 3 different cassettes. Then I put on my Sennheisers and asked her to swap the tapes in and out at random when I said "switch." I remember it was Maxell vs. TDK vs. Ampex Grand Master. I had always preferred Maxell, but most other hi fi heads around me said that they liked TDK. Ampex came out with this Grand Master tape, and I was all excited about it. Tape from a California company rather than a Japanese one? The company who brought tape recording to the US? Bing Crosby, Les Paul, et al? The results: TDK on top, followed by Maxell, followed by Ampex. 😥 What I noticed was the way cymbals sounded. Those amazing drum captures that Roger Nichols got back then were so revealing. On the TDK, they sounded clearer, on the other ones there was a sort of pfft in the very high end, like they just couldn't quite record it. Now I believe that my Akai deck may have been biased with the TDK, thus giving it an "unfair" advantage. Whatever the reason, from that day forward it was all TDK. Even with my 64 year old rocker ears, when I listen, I close my eyes and focus on transient reproduction, highs, reverb tails (what is it with reverb tails anyway?). Does the playback sound like it's constrained to the speakers/headphones, or does it sound like it's somehow wider? I don't use Aja any more, my current fave audio playback music is Radiohead's "Everything in its Right Place," which has just so many little ear candy things going on. Sound snippets panned hard, reverse echo and reverb, breath noise. The more of them I can hear, the "better" I consider the playback system to be. Best sounding Windows music player so far: JRiver, but I ain't payin' $75 for a license for a friggin' media player. It's not THAT much better than Music Bee and AIMP. It's a great program, though, the only one I know of that can host 64-bit VST3's. JRiver with Morphit or VHS or whatever was a lot of fun during my demo period. Again, I really didn't want to hear a difference, I wanted it to sound no better than my freeware ones. For heaven's sake, they're just sending ones and zeroes from the disk to the DAC, right? If I have a bias, it's a weird one. Something I'd really like to be able to do is test digital audio streams for jitter, 'cause I think jitter may be the thing that can make a difference in audio perception. I've read whitepapers that say that humans can perceive jitter degradation in digital audio playback, and what they describe is the same thing I believe I can hear, which is dulled transients and constrained sound. I don't lose sleep over it, but I am curious.

I didn't mean system wide, I meant within Sonar. It surprises me that the devs, with all the complaints about legibility, don't seem to mention Sonar's internal ability to scale.

Bapu did? How did I miss that? Was it on the old forum or within the past 7 years? Do you remember what conclusion(s) he came to? I see that Harrison's pitch is that the sound is "inspired by Harrison's legendary analog console sound & workflow." "Inspired by?" Like they were thinking about the hardware product line while designing the DAW? The first DAW that ever had a console or mixer view was "inspired by" legendary analog consoles. Because why reinvent the wheel?

At last!! Playback engine tests!! But not really last, Whytse admits that there are still further tests he can run, AND Luna didn't null. Major props to him for paying attention to the comments and not stopping the moment he got the results he was expecting. (I really wish he had bypassed the plug-ins with the dithering noise when he was doing the playback tests) I'd really love for him, or someone, to do similar tests on Mixbus, which straight up claims to sound different. And FL Studio, the one whose bass supposedly sounds "better." I still want to check Mick's Craft vs. Sew Gnar. Regarding FL Studio, if I'm producing EDM, do I want a DAW whose playback has a bass emphasis? Seems like that would result in mixdowns with attenuated bass, but what do I know? Maybe they also apply that bass bump in the render.😄

That is a great test of what their rendering engines do when importing a finished song, then exporting it without doing any processing or panning. Which is what I would expect, having done similar tests, albeit with a soft synth and 50L/50R panning. And not all of my renders nulled with each other. What it doesn't test is how the DAW deals with mixing tracks together, panning tracks, using plug-ins, summing, and, most importantly, what playback does vs. what rendering does. How about importing stems and then rendering? That would test the summing process. How about importing stems and panning the stereo tracks 50/50? That would test panning. How about putting the same compressor using the same preset on one of the tracks? That would test handling plug-ins. Also, weirdly, given that he's testing what they all sound like, he spends zero time listening to what playback sounds like. For all we know, FL Studio could be putting a slight oomph into the bass on playback but not on rendering. There's no law that says they can't. When we try to test it objectively, like Whytse and this guy did, we'll get the same results they did. To put it metaphorically, concluding that two DAW's "sound the same" after importing a single audio file and rendering and successfully null testing is somewhat like concluding that two automobiles "drive the same" after driving from one city to another and arriving at the same place both times. Please understand that I'm NOT saying that "different DAW's sound different." All I'm saying is that it's possible. Trust me, I would love it if thorough, objective tests proved otherwise. There are enough things to weigh when selecting a DAW without introducing sound quality questions. I'm perfectly fine with the idea of my own perceptions of Mick's Craft's playback sounding different from CbB's having been a matter of my brain's reaction to the differences in UI. I would find that even more interesting, really.

Their M(Whatever)MB plug-ins.

If it's possible on your system, go into Preferences/Display and try cranking Sonar's own scaling. I set mine at 115%, which makes the text the same size that it was in CbB. It has drawbacks as far as screen real estate, but give it a try and see if you prefer it.

The tests I was running when I came to the conclusion that virtual loopback might not be the tool for the job were tests of different driver modes. When an ASIO playback nulled perfectly with playbacks using MME, WDM, and WASAPI Shared, I got kinda suspicious. I still want to do my comparative tests of playback using different driver models, but next time I'm also going to include comparative tests of playback using the same driver model using different DAW's. I'm already pretty confident that there's no perceptible difference when it comes to rendering engines, but not yet as confident about their playback engines. Not so much these days, with the rapid increase in computing power, but say, 10 years ago, there were solid reasons to come up with clever ways to reduce the amount of CPU power that playback uses. Test methodology is tough. Rick Beato "proved" a few years ago that there's no perceptible difference between lossless audio files and MP3's. He did this by setting up comparative listening tests offered up by a web server and having some of his interns, presumably a group of people who would be capable of hearing any actual differences, choose which version of the song under test they thought was the high bit rate, lossless, whatever. Since it was done via web server, he also opened it to the general public. Whaddaya know, the tests "revealed" that not even trained listeners could reliably tell the difference until you really cranked the MP3 compression up. That's what he thinks he demonstrated. I took a look at the setup and decided that what he had actually proved was that when you play them back through a friggin' web browser, which then goes through the OS' mixer, most people, including trained listeners, can't tell the difference. What he didn't test is whether they could perceive a difference when the different files were played back through Music Bee or AIMP or JRiver or some other media player capable of using ASIO or WASAPI Exclusive set to "event driven." In other words, his tests proved that the web browser's native player, compounded by sending its output through the Windows system mixer for a few rounds of resampling might be capable of masking the sonic differences between these file formats. I pointed this out in a reply to the YouTube video in question, but of course nobody paid any attention. The Great Beato had spoken. But for something that is actually within reach of my ability to set it up, I'm not going to be satisfied with "appeal to authority" arguments or hand-waving. I'll find my answers when I or someone I know completes null tests of multiple DAWs' playback engines. NOT rendering engines. I ran my own tests on those, and it seemed that while they didn't null perfectly, there was no way my ears would be able to pick out any differences. Until then, I don't know whether their playback engines sound alike. I seem to be able to hear differences, but I'm not going to trust subjectivity when the perception could change based on what color theme the DAW is using. I'm not trying to prove a theory, I'm trying to answer a yes or no question. It's odd that some people push back so hard on even asking the question.

That's Premium jibber-jabber to you, son!