azslow3

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.

All roads lead to... In any case, most people who want multi-asio don't realize that: (a) something has to sync interfaces, on hardware level (b) most restrictions for ASIO come not from technical difficulties, but from its license...

Check (in Cakewalk preferences) you haven't enabled MIDI inputs/outputs to/from XAir, at least not those which control it.

Try to use ASIO mode with native drivers. That always provide the best possible for (any) interface latency. In case you can't set the buffer to 128 or lower in ASIO, check computer optimization for audio. The rest depends from your PC and used plug-ins. Note that without native drivers Windows and the interface add huge latency which is just not shown. If you don't want optimize the computer and ready to accept consequences, WASAPI sometimes can produce reasonable results (I guess ASIO drivers assume you are serious about audio and so some of them are not forgiving related computer problems).

I guess everything over ~20k (as you can see quite a lot...) lands somewhere under 20k (with full "weight"). The synth can also try to use resulting frequencies later in the own chain. Just imaging a band 30-40kHz is used to modulate sub 100Hz band. What I mean, end result is not limited to just digitally aliased frequencies, any kind of distortions can be triggered. BTW such spectrum is a definitive confirmation the plug-in/preset creator has done something wrong. Audio plug-ins should not produce ultra-sonic components. That is no longer "audio" since there is no equipment which can reproduce it (and even in case such equipment is created, no one is able perceive it, except resulting analog world distortions and aliasing).

What you mean by "right"? May be the person who has created the settings was using 44.1kHz, and so that sound is intended. May be he/she was using 96k. And it can happened it was 192... There are way more frequencies in 44.1 version. I am not an expert, but that can be aliasing results from math. I mean everything over 22kHz calculated in 44kHz rate produce something inside 22kHz. Your "96kHz" mp3 is 48kHz, only you can see (on original 96kHz track) what is inside ultra high range. Plug-ins/preset developers who care check that generated (also intermediate) frequencies are always in reproducible (by sample rate) range, and oversample + LPF when not. Other don't care. Fortunately Cakewalk can do that too.

That is well known effect. It comes from bad math inside plug-ins, but used as an argument 96kHz sounds "better". In Cakewalk you don't have to do everything in 96kHz (that is one time decision since you can't change sample rate in existing projects), you can use "local up-sampling" when make sense http://www.noelborthwick.com/cakewalk/2015/10/24/improving-your-synth-sounds-with-real-time-upsampling/ Some people just use 96kHz for everything, to not think about possible troubles with plug-ins. If you do that, check what you send to your monitors doesn't have high frequency (apply LPF to the limit of your hardware).