Sunshine Dreaming

When you say, the room has "a dip", about which range are we talking here?

CbB is Windows-Only. So either you use a PC or a mobile ARM device. And x68/x64 and even ARM uses also IEEE float: [..]The ARM floating-point environment is an implementation of the IEEE 754 standard for binary floating-point arithmetic.[..] Please tell me, to which other architecture do you refer to related to CbB?

the mantissa of a 32bitt IEEE single precision float is 23bit and that float has additionally a "sign" bit in its 31st bit, which together represent 24bits precision. The 24bit sample has indeed exactly the same "sign" bit, but in its 23th bit, not in its 31st bit of the DWORD. Additionally single float has an 8bit "biased exponent" which allows values bigger than 1.0 and smaller than -1.0 adding a total (normal) number space up to 10e-38 to 10e+38; Anything beyond that (where biased exponent == 0) would be denormals, which are avoided because of speed losses. https://en.wikipedia.org/wiki/Single-precision_floating-point_format [..]All integers with 7 or fewer decimal digits, and any 2^n for a whole number −149 ≤ n ≤ 127, can be converted exactly into an IEEE 754 single-precision floating-point value.[..] 2^24 = 16,777,216 combinations of a 24bit sample signed range : - 8,388,608 .. + 8,388,607 (these are 7 decimal digits) However, floats for audio use the mantissa (fraction) part, not a 1:1 conversion of the integers. [..]1 + 2^(−23) ≈ 1.00000011920928955 (smallest number larger than one)[..] which is ~ 10e-7 above 1.0; at this (or similar) level for example a VST3 host would add the noise floor to ensure speed advantages (avoiding denormal calculations); from VST3 SDK docs: [..]The host has the responsibility to clear the input buffers (set to something near zero, like 10e-7, to prevent de-normalization issue)[..] However, if increasing the volume much higher than +/- 1.0 the precision will become lower, but those values would completely clip on a 24bit sample, where data actually being lost on 24bit samples.

I've not fully finished with it yet. In a PM I could send you some more information, if you wish.

My suggestion; In the end any MIDI Event (at least when using VST3 plugins) are time-based positions. They are applied in a plugin at an absolute sample position, based on the current block position plus the sampleOffset field in VST3 Event struct. That sampleOffset field there itself cannot be used for negative offstes, since its only valid within the current blocksize; Some fine tuning afterwards is additionally required; Also some sort of marker in a clip should be set to have an easy indicator where the clip is located within the look-up table. This would additionally increase speed.

Did you try to fully uninstall CbB, reboot and then install with the full installer ? if that did not help, have you tried to re-install Windows?

ASIO4ALL sets the buffersize to 512 and the plugin runs correctly, without the need of running an external service. Rendering to an audio output file succeeds (The plugin does not silence the track anymore). And other WASAPI players can continue to play, but yet the live audio output is not configured. Although the VU meters show the audio level, the soundcard does not yet output any sound. I think I'll find a way also for that. but I don't think I need it, cause: Then I found FlexASIO 1.9. The buffer size can be set in a configuration file "FlexASIO.toml" (although I installed also FlexASIO.GUI, the UI does not open on my system and after another reboot it finally opens) and as backend WASAPI is used. Both settings Shared and Exclusive are supported. I chose "Shared" and finally it works! Also a bigger project plays in the same way now as it did on "WASAPI Shared" before. EXOVERB MICRO loads correctly in Cakewalk, no error message/warning. Even a media player continues its playback while CbB is playing through "flexASIO". Increasing the blocksize to 2048 improved the sound quality. I never do live recording with CbB anyway, for that I use another DAW, but also there an USB microphone does not need any interface. And if I want to use an external keyboard that also would use USB. This might not be a solution for everybody. Those who do recordings from a non-digital source might need an interface, I would never doubt the experience of those people. But if you only have digital input (like me) or stems or USB microphone and 3.5" cable monitor speakers with own amplifiers (and there are good ones) and an external sub woofer, for what do you then need that additional device? So no energy is wasted for an additional device, when finally WASAPI Shared works with this setting. For those who are interested how to set it up: on default it uses (the preferred) 882 samples and the slider in CbB is enabled, but the setting is not applied... mmh, I heard a similar problem somewhere before...), but it can be set in the configuration file; You might need to change the device name to your audio device name; that you can find through running C:\Program Files\FlexASIO\x64>portaudiodevices.exe And you can test your configuration outside CbB by running C:\Program Files\FlexASIO\x64>flexasiotest.exe Here the C:\Users\<your username>\FlexASIO.toml: # Use WASAPI as the PortAudio host API backend. backend = "Windows WASAPI" bufferSizeSamples = 2048 [input] # Disable the input. It is strongly recommended to do this if you only want to # stream audio in one direction. device = "" suggestedLatencySeconds = 0.0 wasapiExclusiveMode = false [output] device = "Lautsprecher (High Definition Audio Device)" channels = 2 suggestedLatencySeconds = 0.0 wasapiExclusiveMode = false Thanks for your help and insights.

Ok, I got an answer from the plugin vendor support. They said, I should tryout ASIO4ALL. And thats a known issue with Cakewalk. I had ASIOLink installed. But I don't know how to use that. So I will tryout ASIO4ALL.

You're right the hardware side is out of the scope of what I said. And it sort of works with some caveats (Exlcusive only and also running the Jack Audio Router additionally). WASAPI Shared is not limited to a certain sample count and its unnecessary that its grayed in Cakewalk. So whatever you want to call it. To me that is an issue or a bug. Enabling that slider would solve it. I did not say more than that that restriction is not based on a limitation of Shared WASAPI, since I successfully can use different blocksizes in different WASAPI apps at the same time. And I just found this older post, where that problem obviously also was raised:

This topic is not about interfaces, this is about a bug in CbB, which could be easily corrected. Wasting resources for devices people (like me) do not need is never a good idea, especially when its a software bug, which I simply can avoid in my own VST3 host...

When calling IAudioClient::GetDevicePeriod in the "RenderSharedEventDriven" Sample from the Windows SDK, it returns: defaultDevicePeriod: 100000 minimumDevicePeriod: 26667 devicePeriodInMSEC = defaultDevicePeriod / (10000.0); = 10msec this leads to 441 samples on 44.1kHz devicePeriodInMSEC = minimumDevicePeriod / (10000.0); = 2.66.. msec this leads to 117 samples on 44.1kHz Forcing that sample count to 512 in the RenderSharedEventDriven Sample works fine. So there's no restriction and during that test playback also another media player correctly continues to play (because its "shared" WASAPI).

Thank you for your answer. An audio interface is no option. And Cakewalk was already on WASAPI (Shared). There it has 441 samples. When switching it to MME it also failed, switching it in Cakewalk to ASIO now works; It uses 512 samples (Mixing Latency) then! It then uses the JackAudio Router (which must be active externally) Without any Windows Sound Settings changes. Setting Cakewalk to Exclusive WASAPI indeed sets it to 512 samples. And it works. Thank You! But setting Cakewalk back to Shared WASAPI unfortunately also sets it back to 441 samples, although I can change the sample rate; but 441 samples even on 48000Hz... The setting for Shared WASAPI seems to be wrong, why would it always switch back to 441 samples? When building the "RenderSharedEventDriven" Sample from the Windows SDK the buffer size is on default 480 samples, so there is no API restriction to 441 samples. Seems to me more to be a bug within CbB As you suggest in your video I've set 24bit 48000Hz in the Windows Sound settings for my output device. Makes no difference. After restarting CbB now the Shared WASAPI mode shows 480samples... (not a power of 2) After your suggestion in the video to deactivate "Allow applications to take exclusive control of this device" CbB gives this error: and if I click "use anyway" then np sound output...

Thank you for your answer. I just checked it with the VSTPluginTestHost using the Steinberg ASIO (in-built driver) from the VST3 SDK. Also there it gives that error message, But when I switch that test host to "Jack Audio Router" it also works without complaining as in my own VST3 host, which is built from that same SDK.

I installed EXOVERB MICRO and activated it. Then in Cakewalk it shows an error screen (left on the screenshot), complaining about some settings, although they seem all to be met!? Sample Rate is at 44.1kHz in my project, and for buffer sizes Audio->Sync & Caching->File System->Playback I/O I tried 8, 256, 512 in the settings menu, always same error. But when I open it with my own VST3 host it works fine (see right in the screenshot): The plugin has VST3 SDK 3.7.2. My own VST3 host (using VST SDK 3.7.9) used a buffersize of 512 samples. I use Cakewalk 2023.09 (075); Windows10Pro 22H2 (build 19045.2846); I sent the link of this topic thread already to the support of Dear Reality. Mixing Latency is 441 Samples; Could that be the reason? EXOVERB MICRO expect a buffer size with a power of 2; 441 is not such a size. I also installed the "EXOVERB MICRO Additional Samplerate Support". However, I use 44100kHz Sample Rate, so it was not expected, that that additional samplerate package would change anything; and it didn't. I cannot change that button, its grayed :