Noel Borthwick

Read the help. Its all explained in there.

The workflow is to use the browser which has the preview functionality you are looking for. Drag and drop from the browser into XSampler.

Build 109 has been released. We recommend that all users update to it since it fixes many startup issues and also has optimizations. Optimizations and Stability Transport start/stop is now fast when "Zero controllers when play stops" is enabled and many midi ports are in use. Optimized Sonar startup to run faster on PCs with slow internet or when running offline. Resolved failures when uploading and downloading BandLab projects when using a slow or unstable internet connection. Fixed: Duplicated Instrument Track with Input Echo enabled does not show correct button state Browser/Track Manager fail to draw correctly after maximized Dock/Console Sonar crashes on startup when opening certain projects Sonar can hang on startup when no internet connection present Track Manager tooltips don't update after changing setting in Preferences Clicking Input echo from Inspector fails to show updated Input picker Notes fail to Link in Step Sequencer Lasso node selection not working correctly in some cases Time ruler "jumps" at certain zoom levels. Crash Loading ProChannel Preset Underscore added to Exported filename for project with multiple hardware outputs Input Echo on Instrument Track shows Auto-Thru when turned ON Auto Echo MIDI not working on Instrument Inspector/Console View strip Projects can Fail to Upload to BandLab

I'm not sure why you are editing the colors like that. If all you want to change the strip color this is how you do it.

Nothing has been lost. You can easily add custom commands to the custom module like this. See below where I've mapped goto from/thru to buttons on the custom module.

@Matthew Carr I've sent you a PM with a build to verify. Please respond in the PM.

Thanks but having awareness wont result in a fix. Only a concrete recipe can help if at all its an actual bug and not a 3rd party issue.

If you send the project file I can take a look at why it's resetting.

What was your driver latency set to in preferences when you did the bounce? I can't think of any change in Sonar that would do things differently at the midi note level so it's almost surely a difference in how you have CBB and Sonar set up. If you can repro this, do a careful comparison of a bounce in cbb at the same buffer size and other settings compared to sonar. If you have a reproducible issue send us a project file.

We're actively working on some plugins that will be arriving soon. Plugins are not a trivial pursuit since they now also have to be DPI aware and modernized to fit our new architecture etc. I think there will be some nice surprises down the road for paid members so don't worry.

You need to do that from an admin command prompt

Can you send me the project as well as a dump file of the crash?

Definitely not seeing this here. In fact I was testing a bunch of stuff completely offline today. Sonar launches in about 2 seconds here. If you can repro this please PM me a dump of the process while it is hung in that state and I can take a look.

I get some users want "eye candy" and its a personal preference. OTOH, its actually more fatiguing to stare at a photorealistic screen for some people for many hours in a day because there is too much detail.

There is a fine line between expressing personal opinion / usability feedback respectfully and throwing generalizations around which is why some threads are getting locked. We all know that some users dislike a flat look. Literally any change to UI is going to be divisive. We went through the same thing when the UI was changed in X1. It's been explained innumerable times that this decision was made to make the UI scalable on high resolution displays to handle modern high DPI displays. The approach of using bitmaps which is the only feasible way to handle 3d like imagery, like in past versions of Sonar is gone. And before you ask, there are no plans to have both images and vectors - its simply not feasible to do. That said there are some legit complaints about improving things for users with vision impairments or special contrast requirements and in time we'll do it. There are also plans to add better color customization that should alleviate most of the concerns about contrast etc. FWIW. As a counterpoint, I wear glasses and I stare at the Sonar screen for 8-10 hours a day as part of my work. I find Sonar infinitely easier on my eyes than Cbb where I'm always trying to focus past all the graphics clamoring for attention. If anything, that causes more eyestrain for me. I use the dark gray theme fwiw. Many if not most users have adjusted to the new theming, some quicker than others.

Looks like you have the file association set up to launch CBB instead of Sonar. There was no change in the build itself.

This is incorrect. Sonar uses significantly less CPU for most projects. This is at the heart of most of the optimizatons done.

@Sergei Pilin there is no cookie cutter one size fits all way to handle load balancing because there are too many CPU/Hardware combinations and Windows itself isn’t a realtime OS. Additionally the actual load varies from project to project based on track count, plugin count and the actual load of individual plugins. Also notably there are different types of cores - virtual cores exposed by hyperthreading on Intel systems, and in some more modern hardware there are e-cores and p-cores. In general reducing the thread count lower than the number of cores, could have a detrimental effect on large projects, which is why by default Sonar exposes one thread per core. We allow you to tweak it to your personal requirements. It may or may not improve performance in all scenarios. There is now also support for management of p-cores and e-cores which you may not be aware of. See this help topic. You can instruct the engine to avoid using e-cores. Some users with such systems reported improved performance, but others did not. As noted above mileage may vary. In general Sonar is vastly improved over CbB because I streamlined many core operations that led to suboptimal multi-threading which is why you see better distribution of load in task manager. More importantly low latency performance is drastically improved allowing projects to run at very low latency that would choke the CPU before. PS: you didn’t mention what CPU are you running on. How many cores does it have and what version of windows are you using. Also have you changed settings in the BIOS or made other system level tweaks that would impact how the cores are used?

He's referring to the project itself routing to multiple hardware outputs. If you export everyone's mic in that scenario you are summing all the outputs which is likely something you did not intend to do. For example if you had a headphone output and main out, both with be summed leading to doubling the output.

Not surprising. thats a very old plugin and it was known to have some problems esp with 64 bit processing. Its also possible that the plugin internal state was corrupted in a preset. Changing the preset and editing the settings may resolve the issue.

This is unlikely to be related to updates or installation. One of your plugins is misbehaving. If disabling all plugins from the main toolbar restores audio then its one of the plugins. Also try turning off 64-bit double precision in the audio settings if it's enabled, in case one of the plugins has a problem with it.

This is l likely an incompatibility with your graphics driver and opengl which the lps use. I think there is a way to disable opengl with the plug-in via an ini setting. I don't remember the value right now.

@brundlefly if I remember correctly I made this fix to resolve problems you were having 😂 And no there is no way to send a single message that's not how the API works. Anyway I'll move this to a PM so we don't clutter this thread with the details.

Its good that you were able to narrow down your delay. This is not a bug. In Sonar for hardware MIDI ports, we intentionally introduce a 1 msec delay before rapidly sending CC's across all 16 MIDI channels to reset the MIDI hardware. The reason for this is it would found that there are some MIDI drivers that will hang if you rapidly send CC's to them. MIDI is a serial protocol and there is no working around that. If there are many ports it can add up since its 16 channels per port. Overall, its much better to introduce a small delay rather than hang some devices. If you have a lot of MIDI out devices not being used, consider disabling them in preferences or simply turn off the zero controllers option if its not doing anything specifically useful to you.

Follow the instructions in this link and submit a hang dump.