azslow3

Lets compare.... who force you to give complete private information? azslow.com - no, norton.com - yes who is taking money from you? azslow.com - no, norton.com -yes can you get private information of concrete person which is the owner of the site? azslow.com - yes, norton.com - no So, which from these 2 sites is more dangerous? Also check the terms and conditions you have agreed when you have installed Norton. They do not promise you anything they report has something to do with reality, they explicitly refuse to take any responsibility for false (positive nor negative) information. They effectively reporting your what they want and ask you to pay for that. Note (3): my real e-mail (+address, +name, +telephone) is associated with my domain. Have I EVER got e-mail/post/call from ANY "service" which declared me as "known dangerous"? NO! At the same time when some of our servers/workstations at work is really infected, we get notification within several hours (days at most). ------- Since years I am periodically "reported"... sometimes the website, sometimes particular versions of my software, etc. Once I get throw ridiculous procedure to whitelist my staff (complete personal information is required to register on each service, then one or more e-mails, putting special files to the website, etc...), they just whitelist me. No explanation why it was blacklisted, no apologize, sometimes not even simple notification that has happened... So I no longer waste my time doing this.

Most DAWs are "supported" by simulation of some Mackie controls. That also works in Cakewalk. Is that really useful in practice? Transport works, volume can be controlled by faders (unlike Mackie there are not touch sensitive nor motorized, but still), pan by knobs and sometimes solo/mute/rec arm by buttons (on devices which have sufficient number of buttons). But in all cases, that is far from real Mackie functionality. Also note that Mackie has display, while most "compatible" devices with keyboards do not have any indication (LEDs under some buttons at most). So the only more or less convenient solution should be device+DAW specific. F.e. there should be on-screen display to show current device layout, commands/parameters should be adopted for particular device and user preferences. Is that possible? Sure. Cakewalk own ACT MIDI provides that for any controller with under 8+8+9 (8 knobs, 8 faders, 9 buttons) controls. Just without feedback on the controller. AZ Controller does the same, but for any controller and with feedback. Both need like an hour of reading the documentation and initial configuration. The fact is... the number of people which are ready to invest one hour into configuring the controller is almost zero. I mean people CLAIM they need controller, but in practice they do not (need/want). If "ready to use" solution exist, people do not complain. Controllers producers know that, so they simply write "we are compatible with these DAWs", without really doing anything. One-two users will complain the solution is terrible in practice, but all other simply never use that functionality, except may be transport buttons and occasionally changing tracks volume (VST controlling is different topic).

it is mentioned for MIX_PARAM_FX_PARAM, to specify FX and parameter (in dwParamNum). MIX_PARAM_FX does not mention MAKELONG, just "fx#". So the question is what it should be to work with the whole rack instead of particular FX.

With which parameter value it works with "rack bypass"? zero and positive numbers work with particular FXes, -1 produce an error

I have checked with X2 only, it can be something was changed since then... but MIX_PARAM_FX needs parameter number, which is index of particular FX. So it works with one FX, not FX bin.

I remember nice video how blind musician was recording/mixing using computer keyboard (Sonar 8). There is no much difference in transport or other buttons, but changing continuous parameters with keyboard is not fun. That leaves mouse as the only usable computer device for most parameters. And it is rather bad device for "shortcuts" like operations (I have written special plug-in to use it that way, f.e. press button+turn the wheel, not good in practice). I still prefer turn physical knob to change volume of my interface over mouse or keyboard buttons, I mean outside DAW. And so turning knob or moving slider feels like the "right" way.

Saving changes after surface preset selection/modification is the only general surface bug and it exist in current release only. Mentioned hotfix solve it for other, workaround is simple to apply as well. Till you give more details, problems are triggered by your particular setup or (more likely) there is no problems at all (you just expect thinks are working not the way they are really working). F.e. presets (as well as mappings) are saved/loaded or not, there is no "soft of" behavior. When you are "switching between presets" in ACT MIDI, normally nothing changes visually since most parameters in most presets are the same. But what you see as "labels" (parameter labels, control labels are fixed by preset) depends from current context and preset parameters. The context changes all the time (when you click different parts in Cakewalk interface), a label is blank in case the parameter in question does not exist. I repeat, control surfaces installation is a complex process, especially with DIY oriented devices like Axiom or BCF. Everything is logical but far from intuitive. Transport buttons (and some other controls) in Cakewalk Generic Surface can be defined more or less "by intuition", but anything else requires at least an hour reading the documentation (for device and surface plug-in in question). Bandlab Assist is rather strange program... to revert you will need uninstall Cakewalk in Windows (but better not remove "shared" staff, you will be asked what to do with it) and then install current release with Assist.

Computers still seems very buggy, but I would have hoped they are more stable now 😃 Now serious... "ACT" means different things: (a) it is general API to be used for writing controller plug-ins for Cakewalk, (b) sometimes people reference "Cakewalk ACT MIDI" plug-in as "ACT" and (c) (since related buttons was labeled as such) as a part of API related to VST plug-ins steering. Note there are other MIDI (and sometimes controlling) related features in Cakewalk, which are NOT ACT: "Remote control" for Cakewalk related parameters, MIDI "shortcuts" and (direct) MIDI control for plug-ins. All these features can fight for the controller and the result can be rather confusing when you mix them, at least when you mix them without careful planing. All incarnations of "ACT" are in fact working well (for years). Correct initial setup is a must and there can be some bugs (as in all programs). The issue number (1) exists in one single release of Cakewalk. Settings saving was properly (in case of one controller) working before and we all hope will proper work in all following versions. For this single version use mentioned workaround, for most users (which do not change controlling plug-in presets all the time) that is one time several clicks operation. From (2) and (3) I guess you incorrectly interpret general ACT approach: you first explain controlling plug-in how to work with your device and then assign what controlling plug-in should do with changes sent by your controller. Sometimes both are pre-defined (Mackie), sometimes are defined in parallel (Generic Control Surface) and sometimes truly independent (ACT MIDI and AZ Controller). Sorry, but proper setup and understanding what is going on is required for your controllers: Behringer and M-Audio have not prepared "plug&play" solutions for Cakewalk. I recommend to start with one device and one surface plug-in of your choice, read corresponding documentation (ACT MIDI and Generic Surface have detailed documentation in PDF reference guide, my site explain AZ Controller) and not mix ACT with other approaches, at least not for the same physical control (f.e. do not use the same knob for "Remote control"/MIDI Learn and ACT plug-ins). F.e. for (3), you will need to "learn" some physical controls (in surface plug-in), then enable "ACT" (as VST Dynamic Mapping) for these controls and then "ACT Learn" corresponding logical controls in particular VST. When done properly, you will get "ACT Learning" confirmation dialog (except with some VSTs/parameters, for these you will need to use other assigning approaches, f.e. AZ ACT Fix utility).

From my experience (and many reports in the Internet) Dell XPS (and some other models) have latency problem for years. Somehow it is related to ACPI, probably bad design or/and bug(s) in hardware (as with almost all parts in my, now a bit aged, XPS. USB-C, wlan, audio, etc.). DELL has never confirmed general problems there, but some firmware updates had "latency improvement" in Changelogs (without noticeable difference in practice). Some update has broken ACPI compatibility with Linux (my XPS was running Ubuntu like 20 years old Celeron after that update... I have found some discussion where Linux developers have refused to mitigate clear DELL bug on there side...), after that I run on old firmware. In practice, with network and all services/tasks disabled, XPS can run audio applications without dropouts (at least with RME). Any activity which access system information (and I guess SupportAssist does) can introduce "blackout" for several ms. That is indirectly confirmed by many users which disable corresponding drivers, so services/programs no longer can request information. But disabling some related drivers has consequences and it is unclear which service (especially DELL own) access which device/driver (and when).

@Heinz Hupfer Try switch "Send 0 as Off" to "Send 0 as On" in feedback. Still, 127 had to work. May be worse to try other values like 1,2,etc But that make sense in case August is ready to do these tests...

Just in case Heinz is sleeping now (probably) and you do not (depends from location... 😉 ) "Forget MIDI" for WAI_UP and WAI_DOWN (they should not have any MIDI assignments). And reassign WAI_Left and WAI_Right.

Those who are asking for Open Source DAW for Windows, try to find (legal) version of Ardour with ASIO support (tip: it does not exist, till you compile it yourself after signing agreement with Steinberg). And from all current plug-in formats under Windows, there will be DX. It will be hard to host VST3 since its Open Source incarnation is strict GPL3 (means whole source should be not only Open Source but also GPL3 or compatible license). VST2 is "gray" (like with ASIO, but not even possible to sign post 2018). PS. People who write open source programs rarely ask such question as OP, they know the answer...

That is known problem in the current version (only), for workaround see

Note that is V2, it has no native Cakewalk support (unlike the first version). Also the price in the link is a bit high... it is ~€180 in Europe (so should be $300). DIY solution for V2: http://www.azslow.com/index.php/topic,444.0.html Several (different) controllers can independently work in parallel. TouchOSC can be used: http://www.azslow.com/index.php/topic,295.0.html , but TouchDAW covers more. Transport without app (from phone/tablet): http://www.azslow.com/index.php/topic,288.0.html Cheap controller with good functionality coverage: X-Touch Mini. http://www.azslow.com/index.php/topic,377.0.html Korg Nano has many controls, but no encoders. Good to control "fixed" set of parameters (f.e. just 8 tracks), not good for for switching between tracks/parameters (needs bringing controls "in position" after switching blocks of tracks).

ProChannel modules have no GUI. What you see is "standard" GUIs which are auto-constructed in that case (also shown for other VSTs without GUIs). With Console that is a bug (known). The fact ACT MIDI tries to open interfaces for ProChannel is just not nice. AZ Controller tries to avoid that 😉

@Devils you are not using AZ Controler with Mini 😉 I do not know how you could get feedback on encoders without it... In fact ACT and surfaces in general are working fine, as long as you have MCU or use AZ Controller (with everything else). ACT mapping you can easily preserve, once you use AZ ACT Fix... For current problem (with the latest CbB only, not loading presets at startup) there is a workaround: after selecting required preset in Surface dialog, visit Control Surfaces in Preferences. Change In or Out port to something else, apply, change it back, apply. Current preset will be loaded after CbB restart (tested with ACT MIDI and AZ Controller). In case the preset is changed (selecting some other preset or by direct modification) repeat port switch.

I have done "clean" test: removed ctrlsurface.dat started CbB inserted Mackie (standard Cakewalk one, shows (C) 2019), with In and Out (not to Mackie device, but who cares... ports exist) changed F8 and disabled handshake restarted CbB Mackie is loaded with default preset 🤒 I mean how you test to AVOID that behavior?

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).