azslow3

I have 2 comments for intended logic: "some" surface plug-ins do not need MIDI ports (gamepads, OSC, just logic without surface at all) most Cakewalk surface plug-ins do not (can not) use MIDI output how CbB knows surface is not altered? I do not see IsDirty in logs (but I am returning TRUE in any case) With MIDI was set, "ACT MIDI" has saved selected preset to default (once, in the same session I have enabled MIDI out). Just removing "ACT MIDI" and inserting it again (with In and Out) shows previous preset name but does not load it. After re-selecting it and restarting CbB, nothing (I guess empty) is loaded again. PS It seems like the "optimization" for persistence has tried to fix not broken part of CbB... sure, as usual in such cases, it is broken now?

One of AZ Controller users (Bassman) has noticed no preset is loaded on CbB startup in ~2020.05 After some "magic dance" (re-installing, re-selecting, etc.) he has manged make it working. But with 26.8.0.100 (the latest update) no magic helps. I have updated 2 computers myself. On one I could get "ACT MIDI" remember selected preset (not the first time, but after several restarts and removing ctrlsurface.dat...). On the second computer I can not make any plug-in memorize selected preset ("ACT MIDI", "Generic", "AZ Controller"), even after file removal. In my own code I see there is no usual "Save" call during CbB close (it was called at least in X2...Platinum). I have also noticed 2x "Save" calls before "Load" on preset change, that is from what I remember also unusual.

If Realtek ASIO with buffer 1024 is not working stable for you, there are some severe problems (with some luck just in software). Your system should be able to run several VSTs under buffer 256 without any tweaks. But that is true in case your are not running some "ultra" settings in some "heavy" VSTs (single VST can kill everything), so first try to reproduce the problem just with proven light VSTs only (f.e. provided by Cakewalk). Latency Monitor is not an odyssey, it is 1 button tool. Odyssey is to interpret its results in case it blames some generic Microsoft driver (it is tricky to find which device course the latency). Also check the system is successfully updated and disconnect/disable any networking. MS periodically think the system is "idle" (even if that is not true) and starts background activity. You can check system logs / task manager to spot any failing tasks, continuously re-connecting mouse, etc.

I have updated Bandlab (2020.05) and everything works as expected. Switch to plug-in mode (A and B lit). On the current track enable ProChannel EQ (for now with mouse). Switch to ProChannel Mode (long press "<<", "<<" lit, ">>" does not). Use "<<" and ">>" to switch between modules, do you see "Track-EQ" instead of "No mapping" at some point?

Note the table in the video, at 8:42. Check what you have now with 610 (note the table is for 48kHz).

Do you see "No mapping" also during learning? "No mapping" means plug-in is "not detected". Check plug-in selection buttons (and indication) in the documentation of X-Touch Mini preset, but normally clicking on plug-in GUI with mouse should focus that plug-in (also for ACT operations). I have not checked ACT in recent Cakewalk versions, may be something was checked. BTW I assume that is the only hardware controller you use and AZ Controller is the only Control Surface in the Cakewalk preferences list. Different controllers can influence each other when it comes to ACT mapping.

As first, with one device I strongly recommend to use ONE plug-in in a time. So, if you want use "ACT MIDI" you have to remove "AZ Controller" (or reversed). When you write "stops working", what exactly do you mean? So, when it "stops": Do you still see X Touch Mini in Cakewalk MIDI preferences? If yes, do its inputs/outputs still assigned in Cakewalk Control Surface preferences? If yes and you use AZ Controller, open its GUI and move some control, do you see changes in the "Last MIDI event"? Does Cakewalk display some dialogs like "MIDI device connected/disconnected"? Do you use other software with controller? X Touch Mini sometimes has strange reaction on Mackie "Bye" command (at least my does), so after running DAWs which use that protocol the device is "disconnected" when the DAW is closed (normally reconnect immediately, but not always). If you connect it throw USB hub (especially with long cable), try shorter way to the computer. Note that it will be "new device" on another port, which in turn can be problematic for Cakewalk (there are many threads about the issue, cleanup not existing instances in Windows Device Manager and delete Cakewalk MIDI INI file, search the forum in case you want more detailed instructions how to do that). --------------- In case controller is working, but Plug-in mapping "disappear" or you have other mapping issues: http://www.azslow.com/index.php/topic,297.0.html Note this utility works for all ACT mappings, not only for AZ Controller.

All these parameters are internal tweaks for Cakewalk engine. Changing these settings can help with unexpected behavior under specific conditions. Googling particular problem sometimes show recommendation to change one or more such parameters. In other words, till you have particular problem there is no reason to touch these parameters. Defaults are working well in most cases. "Large buffering plug-ins" introduce corresponding latency. Cakewalk engine is "real-time" only, it is not able to cancel latency, it can only ignore it when required. As written in the documentation and suggested in the user guide, ExtraPluginBufs can only reduce/avoid audio drops when using some of these plug-ins. The "value" should not be interpreted as meaningful by user (even so it has some internal technical meaning for sure).

When new audio device is connected, Windows set is as default. I guess that is expected behavior for most users. Once another device is selected as default, that decision is remembered. Reconnecting an interface from which default flag was removed explicitly no longer change default. That is consistent at least for all interfaces I have. Note that from Windows perspective the same device connected to different USB port (to different port of a hub connected to the same computer port, etc.) is "new".

Then I just recommend to carefully check RTL under realistic settings for the interface you consider. Profire 610 was not bad in that domain, in the lower price segment you can easily experience "downgrade" in case you are not careful. It is easy to find posts about RTL of any interface, but check the results are really from "RTL Utility" and for the settings you have. On the same computer your buffer size will be the same as you use for 610, so do not think that "64 samples at 192kHz" is going to magically work since such setting is allowed in case you could get stable sound on 128/44.1kHz only. Not sure 610 has that, my M-Audio allows ASIO in parallel with windows sounds. Many (most) other interfaces do not, check if that feature is important for you (not so easy to find for concrete interface).

If you care about latency (and in case you play guitar with software processing you probably do), you do not use specially audio optimized computer (and from your post you do not) , you do not need many channels and have the money, take RME. It is less problematic and more forgiving in mentioned conditions. As a bonus, you get full flexibility in routing (use in parallel with Windows audio, Skype, other DAWs, routing/mixing one into another when required). Note that Babyface Pro is just a pre-amp when stand-alone, only top models can work as mixers in that mode. I still have M-Audio Audiophile as my "windows sound" interface and Phonic + small usb mixer to keep all peaces of my small home audio room permanently connected (works with and without computer) in addition to M-Audio 410 and Roland VS-20 which just collect dust. But if I could go back in time, there had to be RME UFX instead. Unfortunately, I have understood that after I have bought Babyface Pro only. Nothing wrong with all other interface I have, they all work. And build-in Realtek also works (except for inputs). But with all other interfaces I hit some limits/inconvenience. With RME I do not.

With relatively small RAM and no paging, the system can use only small amount for disk caching. The performance suffer significantly, especially with conventional HDD. With increased RAM and SSD the difference is getting smaller. Paging on (fast) SSD is absolutely no problem for anything except for audio applications, nothing else needs 1-2ms "warranty for execution". Note that far from every SSD is fast, there are PCI-e M2 SSDs with real speed 80-100 MB/Sec. Applications are different, one sample based instrument can consume 8+ GB. And if someone wants complete orchestra, 32GB can be filled rather quick.

IMHO. If you have sufficient RAM, disable it. Note that Windows can crash in case it hits RAM limit in this case, also overall disk performance can be reduced. If you need it, put it on fastest disk may be after checking this disk access does not introduce extra system latency. The explanation. When Windows "think" it does not need something in RAM (and that something is not marked "keep it in RAM please..."), it can dump it to the disk. That happens not only when RAM is really full, but almost always. That free RAM for something Windows "think" is more important, including disk cache. Real-time aware apps, drivers, etc. should mark related RAM properly. But "should" does not mean "do". When a part of dumped data are required again, they have to be loaded from the disk. That always take "infinite" time from CPU perspective. And if that is required to continue with real-time (audio) activity, you get audio click/pop/drop. How bad/ok/fine it is you can check in Latency Monitor, it shows "missed pages" and (indirectly) related activity. Some disks/controllers can be worse then other in terms of "response time", unrelated to how fast they can transfer data. So the fastest can be not the best choice. I have i7 XPS (already a bit "old"), it is worse computer for audio which I have used. DELL has messed something in ACPI (hardware), and that trigger huge (several ms) "pauses" in the system. That does not affect anyone except audio applications with low latency, so there are no known universal fixes for that. Some people claim disabling some ACPI drivers helps, I personally only have luck by disabling any networking and background tasks when I need low audio latency (also RME drivers are more forgiving, Roland was freezing the whole system while keeping irritating cry sound on the interface output).

And in case you want change "response curve", there is http://www.azslow.com/index.php/topic,275.0.html

All "proper ASIO" solutions for low end Behringer interfaces are using the driver mentioned by msmcleod directly (without redirection links) on the first page. My post from the time when Behringer has switched ASIO drives on there download page: http://forum.cakewalk.com/FindPost/3294586 The "driver" is still the same, from year 2009... It works with many audio interfaces and Xenyx mixers and it still works with Windows 10 (as most drivers for Windows versions before 8). It provides ASIO and WDM, but not WASAPI (which was introduced later). What this driver really is (and how "true ASIO" it is) can be speculated, some people guess it is tuned generic WDM/ASIO (ASIO4ALL is not the only one, but widely known since "free"). At the time of Windows XP... the latency around 10ms was "good". This driver can go down to ~8ms, with some "ultra" settings (since hardware overhead is high) and so the computer has to be audio optimized to work on such settings (modern interfaces/drivers at the same latency are more "forgiving"). So, it is possible to buy an audio interfaces (as new or used) with 10+ years old technologies and related software and still use that on modern system and get original results. That results depends from the original quality (back it time) and so the price (back in time). But all companies was not sitting doing nothing last 10 years, related hardware and software are not the same. Everyone decide for himself, but in many cases "who try to save pay many times". I took the long route, started with Behringer Xenyx. Once (after 4 other "cheap" solutions) I have got "real" interface, I have understood my mistake ?

Have you tried to send: F0 00 00 66 17 21 01 F7 F0 00 00 66 17 20 00 06 F7 D0 05 in one sequence? If it works, is should display "some" signal for channel 1 for short period of time. But we are seriously off topic with all that... This is Bandlab forum about special plug-in.

General channel message is: F0 00 00 66 <dev id> 20 <chan> <mode> F7 <dev id> "17" for C4 <chan> is (if I read the source right) 0...31 for C4 <mode> can be 0, 2, 4 or 6. (4/6 - display peak hold, 2/6 - LCD bar graph, whatever that means...). "01" you see for MCU will not work. After mode is set, you use: [D<row>] [<chan><level>] (2 bytes) So "D0 05" means "row 0, chan 0, level 5". For C4 there will be more, like "D1 52" for "row 1, channel 5, level 2)

Unlike for original Logic Control (almost MCU Pro), I have not seen C4 documentation. So the source code is good source... Check MackieControlLCDDisplay.cpp, especially SetMeterMode (and called from it SendMeterModeSelect). What you mention (0x21) is "Global meter mode" (which declare "vertical" or not). I guess you need channel meter mode (0x20) with proper parameters.

Can you believe such common format as VST no longer allows you to process all MIDI "as is"? You still can process some MIDI messages, but far from all (and everything except Notes is transferred rather tricky way). That is VST3... Note that no new developers are allowed to created VST2 (not possible to sign the license). Cakewalk still support DX MFX only, but curiously that can be an advantage in not so distinct future. At least everyone can write DXes without rather "fancy" VST3 license. F.e. everyone who has signed it agree to switch to ANY next format, so VST3.10, VST4, VST5 within fixed time period... Steinberg has learned that declaring VST2 "obsolete" many years ago does not prevent this format is still in use. So they have decided to solve the problem in advance...

Strictly speaking not everything. Audio and MIDI output created by using Cakewalk is yours, as long as used audio and MIDI material allows that (f.e. mentioned in the license terms to use provided by BandLab content). With that output types user is free to do anything he/she wants. Which rights user has for other "outputs" is unclear. At the end of Sonar I have opened a question about user rights over Sonar Projects. User is allowed to use these projects with Sonar (and now Cakewalk, since BandLab has bought rights for Sonar). And user has all rights for the "output" of own projects (mentioned audio and MIDI). What else is allowed to do with these files is not well defined. For myself I came to the conclusion I can use all the information I put into project myself the way I want (f.e. automations, tracks layout, tempo map, etc.). Legal background and related precedents exist in EU. But that is probably not the case f.e. in US. Here the evil is in formats: common audio and MIDI formats are open, plug-ins presets standard file formats are property of plug-in format creator (so not particular DAW), text based project formats are also open in general (at least the text related to the user activity can be legally extracted). Cakewalk projects have binary proprietary format (fortunately not encrypted, breaking any encryption is prohibited even in EU).

Please note that: I do not think there are any presets for MMcL (nor original Cakewalk) Mackie control surface plug-in. 'Configure layout' is to set relative physical position for several Mackie devices (f.e. left-to-right MCU+XT+XT vs XT+MCU+XT and so on). Related information is displayed on devices, not on computer monitor.

Yup... and Studio €150. While all changes are on Assistant "level". Version 4 had good cross-grate sales, while quite some features for Studio. Version 5 has no new editor/studio features and no sales. Better voice processing is a good thing, but too expensive for noobs like me (just because I like multi-track, so upgraded to Studio before).

I remember up to Melodyne 4 there was clear table with versions comparison. I can not find it for 5. I mean they want more for Studio -> Studio then for Editor -> Editor, while I have not found "Studio only" marks in changes. Sure, I can just demo and check myself... EDIT: the table is still there, in "What can Melodyne do?" So all "New" features are in Assistant

You know that Roland has sold Cakewalk, right? And shortly after that Roland has "discontinued" related hardware, including $5k VS-700 (no official Windows 10 drivers). You can try to ask for "DAW CTRL" MIDI protocol documentation. Some companies just make that open (Novation, Ableton, etc.), some give it to developers only (NI), but other keep it "secret" (for no apparent reason). That is most realistic way to make transport (and other controls) working with Cakewalk (and most other DAWs). FA-x keyboards could be set to Mackie mode, so at least basic transport works. For Fantom Roland mention nothing in that direction in the documentation.

Integrating Fantom as control surface is more challenging then Novation. Novation provides the documentation, Roland does not. From the guide about Logic, Fantom waits for some "handshake" from the DAW and probably will refuse to provide DAW CTRL till it receive it.