azslow3

If you have such real device: And see that on display (mix mode): and then switch to (ACT mode)... and may be to (PC mode)... For me that looks more usable then "Remote control". I will never remember which knob controls what there, also the position is initially not in sync. I guess you have no problem to find which knob you should turn on BCR to change CA-2A gain, even so you have never worked with it, right? And the value is always "in sync". I mean for long session with Z3TA, "Remote control" (when connected to real device) has advantages - finite knobs are more "playable" then encoders (at least for me). But for controlling DAW in general, including mix/effects - no way...

By ACT I mean the approach, not "ACT MIDI Controller" plug-in. That plug-in is in fact limiting and its limitation has triggered me to write my own ACT plug-in. I mean AZ Controller (https://www.azslow.com/). Standard Mackie (and all other) is also ACT plug-in. Creating own virtual surface to make a project one single "instrument" under its control, so "Remote control" the same way as "MIDI Learn" in soft-synths, is a valid approach. But that is different from generic DAW control, I mean using one device with arbitrary projects. At the beginning I was creating project specific presets, major problem was remembering what controls do in particular project... With one preset which always works the same way there is no such problem (I guess that is the reason for MCU and alike popularity). What also helps are actual labels for controls (another MCU/C4 and alike advantage). MIDI does not allow the last, you need OSC (f.e. https://www.azslow.com/index.php/topic,295.0.html) or at least a window with such labels (what "ACT MIDI" GUI does... well, not perfectly...).

"Remote control" was superseded by other approach long time ago. In Cakewalk it is called "ACT". (N)RPN is a protocol which allows way more parameters and better accuracy then standard MIDI CCs. Yes, technically it is using CCs you have mentioned. But logically it works as "A knob on my controller sends NRPN 20". So you specify "20" in the configuration (and hope the controller and Sonar agree how to send/receive NRPNs, they usually do). In case of motorized faders, LEDs and in most cases encoders (CME VX-5+ has motorized faders and encoders), there is no "generic" definition how that should work. MIDI by itself was oriented toward finite knobs/sliders without any feedback. So the solution has to be "complicated". That doesn't mean it should be difficult to use, you normally can switch the device into Mackie emulation mode and use corresponding plug-in. But when you switch to "Custom solutions", in case you don't like what Mackie emulation does, the setup is more complicated. Still can be done in 1-2 days. Only when you want DIY everything yourself (write own controlling logic in supported by the DAW language, in case of Cakewalk that is C++), it can take a while... But as you probably know, I have proved even that is possible in less then 15 years

I am glad I could help. When something is working fine, after a while I also forget what is required to make it working

You need to load Faderport 2 preset into AZ Controller. Int the top left corner, after "Presets:", you should see "AZ Faderport V2 0.5" (or 0.0 at the end, depends which preset you want). In the screenshot that field is blank, also there is some "Detached 0" control, there is no such in mentioned preset. In case you have forgotten how to get it, download from https://www.azslow.com/index.php/topic,444.0.html (attachment to the second post for 0.5), import from Utilities/Cakewalk Plug-in Manager), then you can select it. Select it when some project is loaded. Save the project. Close Sonar. It seems like that way selected preset will be preserved (there is some misunderstanding between Sonar and AZ Controller about the time preset is modified and should be saved, AZ Controller was written at the time Sonar was always saving the preset...).

First find what is not working. is your latest screenshot where it doesn't work? The screenshot looks ok for me, FP2 is found and assigned to AZ Controller. if AZ Controller does not "appears" as surface , even so Sonar shows MIDI ports and assignment: Sonar or hardware (including software loopers) issue, Sonar "think" device is not there (can't open, etc.) if AZ Controller appears as surface, open it and check "Last MIDI event". When you press/move something on device, do you see new messages are coming? if yes, select FP2 preset. If still doesn't work, press stop (square) button and let me know what you see in the "Last MIDI event" if no (no messages are coming), recheck "Record" settings (your previous screenshot was fine, but something could change in between). If everything is fine there, Sonar has probably messed your MIDI devices. Delete its TTSSEQ.ini (correct one, if you have CbB / Splat / etc. installed, each has its own). In Windows Device Manager show hidden devices and "cleanup" duplicates (ghosts). if you can't get what you show on the latest screenshot. Delete TTSSEQ.INI and cleanup ghost MIDI devices in Windows Device manager. Recheck you use MME driver Unlike with other surface plug-ins, AZ Controller shows what it is receiving. So easy to check what is going on. But Sonar has to instantiate it first and assign proper MIDI ports. Apart from locked ports ("no memory" error, Microsoft has assigned the same error code to real "no memory" and "MIDI device is in use"...), there is probability Sonar still can mess with MIDI devices (till Mark has managed to get it under control ). As I have mentioned, every product has own settings file, it can happened CbB has managed to create "stable working" configuration for FP2.

Everything is right, except the word "VST" should be removed. That is true for all types of plug-ins. In particular, all Sonitus effects are DX, not VST. Using top-bar preset management is better option as long as you stay with Cakewalk. You can review / export / import these presets centrally from Cakewalk Plug-in Manager (Utilities menu). To be on safe side, backup from there (I mean don't try to find and backup related existing files). If you need to save preset which should work in another DAW, it is better to use plug-in own preset management. That is plug-in specific (there is no standard), but saved by Cakewalk presets are not usable in other DAWs. For VST plug-ins (so, not for Sonitus) there is yet another option for saving presets, also available from the top-bar. You can save presets in standard formats defined by VST developer (Steinberg). They are (supposed to be) usable in any DAW. In practice, there is no warrantee that will work. Also note that even in case you save preset using one of these 3 methods, it can happened it will not work on different computer or after full re-installation. Better to have full system backup. And when computer change is planned, check all important projects are playing there as desired, before abandoning (giving away/reformatting/etc.) the old one. PS. there is still no universal, user friendly and standard preset system. Major players have tried to introduce such systems, but somehow they work inside "own world" only. And so in most cases there are 3 formats: plug-in type specific (VST2, VST3, etc.), host specific and plug-in specific. Host can be a DAW (f.e. Sonar) or plug-in wrapper (f.e. NI NKS). So, depending from the method you use to instantiate plug-ins, you can have presets in more then 3 formats (even when you are working in one DAW).

Presonus has a little bit "abused" the label: long time ago there was "FaderPort", known as such, single channel controller. at some point they have made new "FaderPort", another single channel controller. It is incompatible with the first one. But instead of using distinguishable name for new device, they are calling old one "FaderPort Classic" and new one "FaderPort". Shops don't like such confusion, so they normally call it "FaderPort V2". and they they have made "FaderPort 8/16", completely different multi-channel controllers. So in all these names "FaderPort" is a label for all Presonus controllers, not a name for particular device (like most companies do). PS. Behringer does the same with "X-Touch" label. "X-Touch Mini", "X-Touch Compact", "X-Touch" and "X-Touch One" are 4 different controllers, with different controls and functions (not a "newer version" nor "extended/limited" as people can think based on common name). PS.PS. for AZ Controller there is no separate preset for FaderPort8. But "Mackie" preset should work. Even so I don't recommend it, till original Cakewalk Mackie limit you and you want better matching to device functionality (unlike "X-Touch", "FaderPort8" doesn't have exact Mackie layout). For FaderPort16 I don't have ready to use preset at all (Mackie preset has to be extended using "slave" instance connected to the second pair of ports, but that is not an easy task...).

From what I remember "mac version" was later... But googling I have found CbB under CrossOver installation tutorial, so may be I will give it another try with Wine (I still support my utilities and I was always developing under Linux, and I was stuck with X2 all that time):

The last version which can work without problems with Wine under Linux is Sonar X2. Sonar X3 can run with some tuning. I have not manage to run SPlat and I have never tried CbB.

That is the reason bus powered interfaces have limited number of IO channels, especially pre-amps. But these people know what they do (or at least they should) and they obey USB standards. I mean good device specification on paper match the reality. For the rest. The power on USB socket from particular PC/Notebook can be unstable/low/etc. Then you have a "bad power supply". But external/build-in power supply can also be "bad". So listing possible consequences is like concluding "all electrically powered devices are bad since the power supply can be bad/broken, I refuse to play e-guitar to avoid such troubles" 😏 I mean there are several good reasons to prefer separately powered interfaces, but "all bus powered interfaces are bad" is not one of them.

There is no separate monitoring level inside Cakewalk. Recorded level is solely controlled by your interface. Then it goes throw "Input Gain" -> FX -> (Pre Sends to buses) -> Track Fader -> (Post Sends to buses) -> Track Output. Live processing is the same as playback processing.

You first have to found what is loud, then you can adjust volume of it... 1) open "Views"/"Console View", check in "Strips" "Hardware outputs" are selected. Adjust the size of "Console" to see faders and meters. 2) move faders of Hardware Outputs all the way down. Play guitar. If you still hear it, the sound comes not from the DAW. Check direct monitoring / mixing matrix levels in your UA interface panel. If you don't here the guitar, move the faders back to unity (double click) and 2) without starting playback, play your guitar again. Check where you see meters moving. It can happened your have: 2.a) more then one track with input from guitar and input echo enabled 2.b) "pre." sends from your guitar track to bus (so track fader is not changing sends level)

"Target audio" (mp3) as well as "Source Audio" have tempo 89BPM (precisely, so not 90). MIDI file has tempo 178 BPM, so double of 89. MIDI file also include tempo, f.e. if you open it "as a project" in Cakewalk, it will set 178. If you want project in 89 BPM, you should stretch MIDI clip (not the same as trim it). Note that MIDI always follows tempo since Notes are specified in "beats", audio is seconds based and it doesn't follow the tempo. So normally when aligning MIDI to audio you start with audio, find its (precise!) tempo (can be variable, but not in this case) and then MIDI is automatically aligned. In this case, for unknown reason, MIDI was created using double tempo and so has to be stretched (precisely). PS audio can follow tempo when you mark the clip as grooved and set its originally tempo correctly. But that feature is not for your case.

This text is set by plug-in, in this case by Nektar. But I have never tried to use it with international characters. So, if you expect ASCII (english) there, it is Nektar bug. If your track names are localized, that can be encoding issue. Whatever I was displaying as status many years, as long as that was in english, it was displayed correctly. -- The only big difference in handling controllers by Cakewalk is that handling is officially documented in public (GitHub). "Most DAWs" hide it, so those who have access to it (f.e. Nektar) can write anything to users, users can't check the claim... At least in DAWs for which handling is known (Ableton, Bitwig, REAPER), the handling is similar. Nektar is controller producer which hide protocols. For Impact there is nothing they can really hide, but for "smart" controllers like Panorama that prevents 3d party developers using controllers. Even for NI controllers (which publish no technical details in public) it is possible to get the documentation. Other companies have it in open or don't prevent RE documentation spread in the Internet. I mean it is not wise accept as trues everything Nektar writes to you. They know you can't check.