azslow3

When your new "product" is so bad that no one want it... normally it is a good idea to (a) make your new product better (b) make completely different new product. Steinberg decision: "When our new "product" is so bad that no one want it... we will force everyone discontinue old product". That is the story of VST2 -> VST3. They have first declared VST2 "obsolete" (long time ago). Then they forbid new developers write VST2 (since 2018). They drop support in own DAWs now. Well... I hope as the result people just switch from Cubase. And I hope other DAWs developers switch from VST to something else (on Windows). In fact only tiny code in one framework should be written, in case Juce support something else on Windows, VST3 will die. Just some "highlights" of VST3: no MIDI 1.0, many parts require terrible workarounds and since not documented well can fail in particular DAWs; the documentation at many places doesn't match there own SDK; ABI is made in hope/luck/wish different compilers are compatible, they are at the moment, but no one ever has claimed they must be compatible and that level; bug fixing takes years, even for obvious bugs (several lines of the code, with bugs almost in every line, was not touched for... 2 years after detailed report). BTW "gray" licensed VST2, fortunately allowed by EU rules, can have own life apart from Steinberg. Simple, well documented and without any special assumptions, that was great invention. The same with ASIO. So technically brilliant ideas, made far from perfect just by bad licenses...

The explanation for the error I have given there: Microsoft can't fix that. In Windows Device manager, set option "show hidden devices" and cleanup unused MIDI ports (if any). Every time you connect keyboard to different USB port, the system think is is "new" (the consequence of USB MIDI standard, unique identifier is not foreseen and so there is no way to match "old" to "new"). Keep Device manager open and visible. Do you see periodical "updated" of the tree? That normally indicate some device is reconnected. Happens when the cable or USB socket on device is unstable. I had that with several devices, especially with portable MIDI keyboards since you normally continuously move them and so move the cable and the socket. Note that Cakewalk doesn't like "on the fly" reconnection more than some other software, also it can react unexpected when that happens with any device, stable keyboard can glitch when other is reconnecting.

Since I don't have the device, I can't tell what exactly M-Audio is emulating in Mackie mode. They also don't write that in the documentation. With one fader and 8 knobs it is hard emulate 9 faders and 8 encoders, not to say around 100 physical buttons, jogger, etc. That is why I have written "more or less" work, just the way M-Audio has foreseen. BTW close to the same functionality you will get in many other daws in which this controller works as Mackie (f.e. REAPER and Cubase). Just from photos it is clear that this controller is Ableton oriented. No wonder it gives most it can when used there, out of the box. MIDI learn technic is good to use with instrument plug-ins. Most of them support such learning. Also changes will be recorded into MIDI items and edited as CCs. "Universal" plug-ins control, including FXes, use "ACT Dynamic mapping" approach. It exists and works well, once configured right. You can try it if you try "Generic Surface" approach mentioned later. There are long living related bugs, you will need "AZ ACT Fix" utility to use it in practice (some people claim they can use it without... my mapping file was always broken after a while, so without that utility I had no joy). For DAW controlling, some (more smart then MIDI learn) integration should be used. If Mackie mode will be "no go" for you, the next bet is Generic Surface. For that you will have to learn more (under 1 hour for reading M-Audio documentation), to make DAW mode on M-Audio not try emulate Mackie and send simple CCs to DAW port instead (any... just different for different controls). "MIDI learning" inside Generic Surface is then as easy as in VSTi - select parameter, click "Learn", press/turn control, repeat for other controls. I don't recommend "ACT MIDI" for that device, that plug-in is strictly 8+1 buttons and 8+8 continuous controls oriented. Your 8+1 continuous controls + 8 buttons + 16 pads do not "fit" into it (multiple "ACT MIDI" instances, suggested by some people, is looking for troubles). If you need the "next level" (so you find Mackie and Generic Surface insufficient), you will need AZ Controller. But that is more then an hour time investment...

Cakewalk supports a lot of staff, including DAW control and plug-ins control. Normally it is up to hardware producer to integrate with Cakewalk (you pay them, not Cakewalk). M Audio does not (as well as all other producers). Making the device more or less work with Cakewalk takes about 1 minute. F.e. see my post in mentioned thread. Could M Audio at least write that in documentation? Yes, they could. But they have not. Are lengthy changes of setting mentioned in the thread required? Not really. But some people like hard ways. Finally, are there some reasons to take "hard ways"? Yes. If you don't like what and how is controlled by default, you can setup it the way it does what you want (from available in Cakewalk features). But that requires background in MIDI and surfaces, as well as time. But primary factor is the wish to accomplish the task. In most cases with Cakewalk and surface, it ends with "I wish someone else has done that already...".

Check your Firewire card is working. In Windows Device Manager check it is found, has drivers installed and currently has no problem (without drivers you will not find it, but there will be some "unknown device"). Or just try to reinstall related drivers.

If you want a bit more from the controller in Cakewalk, try: https://www.azslow.com/index.php/topic,393.0.html You will need install AZ Controller for that (there are instructions/videos/etc.) and find out which mode AKAI should be set into (Bitwig can be incorrect). I no longer know what the preset does, but from quick checking you will have transport, volume/pan/mute/solo/rec and a possibility to use ACT Dynamic mapping (plug-in control), some button should switch between modes...

Taking into account a possibility to make the interface almost unrecognizable as REAPER (f.e. https://ultraschall.fm/ ), own (open source) and quite genius approach for basic multi-platform (and accessible, unlike in other DAWs...) GUI and own (not open source) working space GUI engine, I don't know why you think "they" have no interest for UI. And when you write "they" and what "they" push, you better check the complete list with names and related comments at https://www.cockos.com/team.php I mean many things "they" "push" should be interpreted with some sense of humor 😏 BTW many decisions was driven by technical part, far from easy to understand for non-programmers, but possible to follow with sufficient effort ("they" also answer on related questions, when asked correctly, the question make sense and the explanation is way smaller then a book...) https://www.azslow.com/index.php/topic,406.0.html describe some differences in approach, what is converted, how and why.

From your own published pictures, the noise profile is NOT the same. There is no 660Hz pike and in 24bit mode (which Behringer doesn't have) the profile is way lower (when pre-amp is off). From where the profile comes, I have already explained (see signal picture on previous page), including why for 24bit it is lower. The only topics which are not covered yet is why it looks like you see it (in this plug-in) and why it is different (higher) when pre-amp is used (even in 24bits): converting "jumps" (and 1 bit jumps are still jumps) into frequency domain is done by approximation using continuous sin waves. How it looks like you can fine elsewhere (the topic is well covered in the Internet), important is that (a) such jumps need all (infinitely high) frequency for perfect approximation (b) not perfect approximation (we have frequency limit (Nyquist), strictly related to the sampling rate) has some oscillations around jump (c) these oscillations have frequency dependent absolute amplitude, which bring approximated signer higher then original. And so, strictly -96dB level in the original signal (the lowest bit in 16bits) produce slowly rising up to -72dB frequency spectrum (at least in this plug-in) pre-amp is there to significantly amplify the source. Up to +60dB. So, in case your input (connector + whatever wires till pre-amp) has SNR -120dB (which is rather low), you amplify this noise up to -60dB. Even when nothing is connected to the input, it (depends from electronics) can receive external noise. Connect one wire of 1m, and you have perfect "antenna" to collect all waves around (approximately the same happens when you connect e-guitar). There are many factors which influence that (the quality of wires, shielding, "connected" to the wire "human body", etc.). But there is some noise, always. Note that interfaces differ not only in basic digital noise but also in many other characteristics, some of them have good visual representation (check deep audio interfaces reviews), other are simpler notice by recorded/played sound (in direct comparison).

The device will not do anything in Cakewalk out of the box. With Cakewalk standard surface plug-ins you can get partial functionality, like transport, but it will be rather limited (no LEDs, touch sensitive motorized fader will work as dummy fader, etc.). If you install AZ Controller and use mentioned preset for it, the device will have reasonable functionality in Cakewalk (and with some effort you can adjust/extend it).

Faderport V2 is not supporting Cakewalk officially (unlike old Faderport). But there is solution: https://www.azslow.com/index.php/topic,444.0.html

I am not a big fun of Cakewalk online documentation, so I prefer (big) PDF documentation: https://bandlab.github.io/cakewalk/docs/Cakewalk Reference Guide.pdf Starting page 1388. There is no explicit comparison there, so in short: Mackie has fixed functionality. Your device doesn't have sufficient controls to imitate complete MCU. As the consequence, things will probably work not the way you like and you can't change that. ACT MIDI supports 16 continuous controls (faders or knobs) and 8+1 buttons (the last one is "shift"). That is its primary limitation (in case you need more controls). It is relatively flexible in assigning, but you have to do this yourself (no pre-defined functionality). No feedback (no LEDs). Generic surface supports unlimited number of physical controls, but unlike ACT MIDI it has not "banks". So physical control will do one thing (till you use banks on device level) AZ Controller supports almost everything possible for Surfaces in Cakewalk. But it is more difficult to configure compare to other (till someone upload ready to use preset for particular device, I don't think that exist for the moment).

Use Cubase mode on keyboard and 'Mackie control' surface in Cakewalk. In 'Mackie control' configuration, set "Disable handshake" option. Do not insert "ACT" (nor any other) surface plug-ins (so, there should be exactly one 'Mackie control'). Enable one pair of input+output which you think is DAW control. Based on your text "Mackie" (other write MIDIIN3/MIDIOUT3) and assign these to 'Mackie control'. Check transport is working. Enable primary MIDI input, the one which transfer keys, so you can play soft-synth. PS There can be difference in resulting functionality, but transport and faders will work the same way in case any Mackie mode is selected on keyboard. But it should be some Mackie mode. Cubase and REAPER are Mackie modes. Other not sure (and some for sure not). PSPS There are other approaches to use this device with Cakewalk. And there are some advantages and disadvantages of these approaches. That is no "one consistent way", there are "many consistent ways"! But watch out... some suggestions in this thread are not really consistent...

Cakewalk can work with Mackie or HUI (both with standard "Mackie control" surface plug-in, check that plug-in configuration dialog). Note that original Mackie/HUI has completely different type of knobs, control 8+1 strip and has more buttons then your controller (including all piano keys...). So it can happened you are better served by ACT MIDI or Generic surface. If you still can't configure everything the way you like, there is AZ Controller (not a part of Cakewalk, should be installed separately). In all cases, reading the documentation from M-Audio (for your device) and Cakewalk (how to use particular plug-in) is recommended.

2i2 has 2 big advantages in comparison with UMC22: in can record in 24 bits. Not that its SNR is really on the level of 24bits (-144dB), in fact best interfaces have it not lower then 20bits. But artifacts from 16bit interface are significantly higher, you will have to keep your gain as high as possible to minimize it and that is looking for troubles till you have (analog) limiter on input. ASIO allows lower latency and it is reported correctly. If you plan to use soft-amps, you would like lower latency.

But does is start during the first count-in measure or at 4th count-in measure? In other words, does the time (absolute) between count-in start and device start depends from the count-in (absolute) length or not?

With gain all the way up, that noise level is in fact great (even for middle range interfaces of the same age). I have just re-measured one of my interfaces, with the same plug-in it hit -48dB at 20kHz with full gain (well... not sure gain ranges are comparable). What I have not realized before in that UMC22 is 16bit interface. For 16bit signal the profile you see (except 660Hz pike) is almost the best you can get. If you look at real samples, you will see something like: So, least significant bit is flipping. When "converted" to frequency domain, you get the profile you see. When you record in 24bit, least significant bit has smaller amplitude. So overall profile is lower. But switching to 16bit (on the same interface) produce the same level as yours. Fazit: change interface to 24bit capable one if you want lower noise profile. Note that is not a claim you really need lower profile.

Was your Gain knob all the way left or not? In other words, is pre-amp working? The pattern (continuous increase) is normal. A bit more at 50/60Hz is also fine. 660Hz can be your setup specific (or interface specific... I don't have this model). In any case, if your Gain knob is all the way right (max possible amplification), with disconnected input -72dB is better then usual for middle-range interfaces (sure, that is also max gain value dependent). If you get it with Gain all the way left, that is too high noise level for middle-range interfaces. But (a) this interface is entry level, (b) -72dB is not bad for home studio (c) guitar produce way more noise (especially entry level guitars).

To scope, you can use "MIDI loop" driver (so something which send output to input), f.e. loopMIDI, and scope itself which can display what is going on, f.e. MIDI-OX I guess Presonus developers used the same logic as you. Studio One sends "Start" after count-in, so from device perspective count-in does not exist. And they don't send clock when transport is stopped. REAPER sends "Start" at the beginning of count-in and immediately start sending clock, so from device perspective count-in is the same as recording start and so device will start playing in count-in. Clock is not sent when transport is stopped. So build-in clock logic is troublesome, but there are "workarounds" with VST or script based plug-ins which can do things differently. Cakewalk follows MIDI specification with count-in. It sends clock when transport is stopped (but with previous active transport rate, possibly different from current project/position). I mean 3 different DAWs use 3 different approaches. And all of them are MIDI specification conform. But I think Presonus way is most "compatible", at least for this century equipment. --------------------------- From device developers perspective it is unclear how to do things most user friendly way. MIDI specification does not help solving the issue: master CAN send clock when transport is stopped, so some do (Cakewalk) and some don't (Studio One, REAPER). And so device, to be user friendly, should assume there are periods of time when there is no clock and switch to own clock (transport is stopped in some DAWs, DAW exits, DAW crash, etc.). the specification has solution for that, Active Sense. When used, device at least knows when the master is still active. So many devices support it (Roland, Korg). Unfortunately that is an OPTIONAL feature, all mentioned DAWs does not support it (I am not 100% sure, but I have not found related options). between "Start" and clock there can be significant time, as in case with Cakewalk. So, device has a choice. It can follow MIDI specification and "freeze" itself till clock is there or user explicitly reset synchronization or ignore the specification. So my whole original guess is that Roland has decided ignore the specification when Active Sense is not in use, to don't freeze the device.

I don't think most software/devices really follow all specifications. F.e. Cakewalk doesn't follow MIDI specification in part "clock should be sent at the current tempo when transport is stopped (in case it is sent at all)". Changing position to different project tempo doesn't change the clock rate till playback/recording is started (unlike with soft synths). 🙄 I don't have TR8S, so the rest is just a speculation based on its documentation and MIDI chart. With count-in set, Cakewalk sends "Start" at the beginning of count-in, but pause the clock till recording starts. It never sends Active Sense (does Cakewalk support it ?). All that is correct behavior according to the MIDI specification. Since Roland start playing early, it can happened Roland violates Active Sense rule. It should ignore "silence" in case it has never received Active Sense. But it can happened Active Sense timer is always active, so after timeout it thinks there will be no clock. And since "Start" was given, it starts playing (syncing later, when it receives clock again). My guess is easy to check: make count-in 5 measures. Does Roland still start playing during the first count-in measure? My theory is proved then.... Sorry for the noise otherwise 😏

GPT should not be forgotten... especially in case boot settings have compatibility mode enabled, so during installation the system/Windows can decide to use legacy boot instead of UEFI, and that is looking for possible troubles in the future (and sometimes in present). From my knowledge, splitting disks make sense in case you want backup/restore them separately. On 3 generations of my computers I never had a wish to re-install OS from scratch but keep something on the same disk. But many times there was a wish some disk is not split (on foreign computers), the situation when one partition is full while other is not is inconvenient. The difference in speed/safety/integrity is virtually zero (for solid state disks).

Theoretically, everything is possible 😉 But practically, as far as I know, ReaCWP is still the only existing converter which deals with more then just audio tracks (at most with volume automations). I guess DAW developers don't want people transfer whole projects away from own eco-system (internal converters exists, f.e. Cakewalk <-> Bandlab). Another aspect is the format. There are several interchange formats (Cakewalk supports OMF), but there are for audio/video only. MIDI, FXes and other staff is not foreseen. REAPER has a text based and so a kind of open (not really officially documented) project format. Cakewalk use proprietary binary format. And so converting from Cakewalk is hard, but way simpler then converting to Cakewalk. Converting to and from REAPER is technically not a problem (and the reason more export/import projects exist). Converted projects have Cakewalk signal flow. That signal flow is not obviously limiting when you work in Cakewalk itself, but once observed in the "freedom universe" of REAPER, things in fact look fancy. MIDI and audio are separated, Synths are in general different from FXes, buses and tracks are not the same... BTW the signal flow is converted with explicit sends. While REAPER folders could be sufficient in most cases (Cakewalk strip always has one "primary" output), "unrolling" the project to make it more "native" will break routing otherwise.

Sorry, I hit some bug in the webform editor, can't enter/edit in previous post... Check that Digital Input switch is NOT pressed. According to the documentation, it works as "Loopback mode" when pressed and no digital signal detected.

@Paul Logue

So, uncheck "X18..." in Inputs and Outputs, then you can enable "zero controller" again. Sure, that only make sense in case you don't want MIDI tracks from Cakewalk control your XAir. I mention that since the feature is not bad, you can automate XAir from Cakewalk. Also since XAir has OSC over SYSEX and Cakewalk supports SYSEX, you can f.e. setup the mixer when particular project is loaded (with some programming to covert required settings into SYSEX form). So, it depends from your use of XAir+Cakewalk combi.

Note that option is global and it is here for a reason. If you are not explicitly controlling your mixer from MIDI tracks, it is better not enable it as MIDI device. Otherwise you probably hit related problems in the future, in case you use any MIDI. Just imagine you send some MIDI by mistake to that port, that can change random and difficult to find settings in the mixer.