azslow3

If it mimic Faderport (since it looks like it), you can try this DIY solution. Note that ioStation should be in "native" (probably Studio One) more for that.

Are you using my integration with it? I just try to understand if someone does ?

I know, it could be better to test and MR instead of writing in words... But from what I remember (at 1AM), disabling redraw for the time of filling combo items can help ?

Then please read my answer one more time: CbB has NO playback/stop delay on any configuration I have ever tried it, till several days on my old system after I have managed to break something in drivers. You have started claiming "the problem happens without FXes", now you say 130 track filled with PC modules are required to reproduce. On your notebook I will say any delay in Cakewalk is "normal", such configuration could be fine for Sonar 8.5 under Windows XP, but CbB under Win8 need more CPU and RAM to run modern CPU/RAM hungry plug-ins.

130 tracks... tons of plug-ins... When I had 4GB RAM, I had to think about each powerful extra plug-in in 3-10 tracks projects. Yes, REAPER also run on RPi. Stock plug-ins are resource optimized. But that is not a reason to assume everything should have the same requirements. Complicated algos and graphics need resources.

160 tracks, each with single audio file (2x a set of 80 lengthy audio files imported into a project) - no delay on play nor stop. With "pro channel ON". Pro Channel is FX rack, "on" can be 1-2-100-etc. plug-ins per track... I have enabled 4 modules on all 160 tracks - no delay on play, huge delay on stop (interface freeze). Well, with FXes on (Pro Channel) stop delay is from them (in my case). Global bypassing FXes eliminate it completely. REAPER has different graphic framework and completely different audio playback engine. In practice that means it can work fine with "half broken" graphic drivers on not audio optimized systems. I mean that is not a good choice for comparison with Cakewalk.

Just to note... CbB by itself also does not have such issue, at least for most users. So it is something "outside" on all your systems. And it hit Cakewalk (can be "only", can be in other DAWs that is way less noticeable). If delay increase just with the number of audio tracks without FXes, almost everything can be excluded as the reason. If delay increase just from empty tracks, I can imagine just one reason, graphics (if tracks have clips, delay can be disk operations related). Can it be you was always using the same type of graphic card (f.e. only AMD/NVidia/Intel)? Note that different DAWs use different rendering (unlike most other types of programs), so each DAW is sensitive to performance of specific graphic features.

While X32 (XAir, Midas) accepts some controlling using MIDI, that is targeting Behringer control surface X-Touch, and so only small subset of operations (you can find many resources/videos what X-Touch can do with X32). These mixers allow complete controls over OSC only (Wing use different protocol). More information you can find there: https://sites.google.com/site/patrickmaillot/x32 Notice X32Reaper integration. Cakewalk has no native OSC support. You will need to use AZController and organize syncing yourself, since there is no ready to use solution. That can be extreme challenging task if you want many settings synced, but you can automatically re-call pre-made settings for X32 on project load relatively easy. Note that inputs/outputs any DAW see are USB interface channels (depending from the extension card in X32), they are not X32 analog/digital channels. You can route audio within X32

I was corrected. I forgot to mention "no audio" case. Cakewalk always use audio as long as audio interface is configured and used, otherwise soft synths couldn't produce the sound. But till there is something in the project with audio time reference, the sample rate can be switched. Cakewalk is "sample accurate" DAW (not all DAWs are like that), all audio times in the project are saved as a sample number. If there are no such "markers" at all, there is no problem to change. But once there is at least one, it has to be recalculated on change and Cakewalk doesn't have the code to do this. That is not something easy to add. In fact "perfect" recalculation is not possible at all, till the sample rate is changing from 48kHz to 96kHz (or other "perfect" up-sampling). @Dave G better keep Windows and Cakewalk at exactly the same sample rate. Set to whatever you like your final files should be.

Yes, unusual. And it doesn't look like coming for mastering plug-ins. While they also delay things, the result is visually different (also bypassing FX works for them). One more simple check: unset all audio in/outs in Cakewalk preferences, so no audio drivers are used. Check playback reaction. Also check the system activity during start/stop (HDD LED, Windows task manager and resource meter, looking for spikes in disk or CPU usage). Also there can be issues with GPU drivers, but in last 20 years you have probably changed many GPUs... If you was moving your Sonar/Cakewalk configuration from system to system, may be it is worse to try run Cakewalk in empty content, f.e. under different user.

I know... But "tracks->lanes->clips" is "objective reality we can sense", and so we better think it is "real" (according to Lenin) ? Just keeping in mind that a lane is not a track nor a clip. I mean many things under the hood are not what we intuitively think they are or should be. So lifting the hood can be quite confusing (from my adventure into CWP structure).?

It can be coincidence, but I had the issue ONCE. And it was on Win 8.1, after I have installed ASIO4ALL. All interfaces (that time M-Audio, SB Live and Realtek) in all modes was behaving "not normal". There was delays in playback start and I had to increase the buffer size. Uninstalling ASIO4ALL (and reinstalling other drivers) has not helped. I could not find a reason nor a single tip in the Internet. The problem has disappeared after the next major Windows update (I was lucky, it was just 1 week later). Since I have not understood from where it was, I can't give you any advise if the origin is the same. But since you has that since 20 year on all systems, the origin is probably different. And no, Cakewalk is not made to work like this. before any future tests/investigations, make sure "Share Drivers With Other Programs" is unchecked in Cakewalk preferences, Windows audio is not pointing to the same device (for input or output), set the sample rate in Windows settings for audio interface as in current Cakewalk project, close all other programs. Since with single track/clip you have no delay, try to find the operation which introduce the delays. Duplicate that single track, every time checking there is still no delay. Try to record new clips. Important: don't just import clips, depending from settings that can trigger real-time bit-rate conversion which in turn under some conditions can trigger the effect. Do not add any effects yet, do not activate anything in ProChannel. Depending from the possibility to have no delay with 20-30 simple tracks you can later narrow what you can check. BTW what is your Antivirus/Antimalware software? Have you excluded Cakewalk as the program and related files as folders from continuous monitoring by Antivirus/Antimalware? While you can think that is unrelated, many people are using the same antivirus company for decades... and when it performs scans on every file access, that can introduce interesting "freezes" in operations (depending from the software, in my experience Windows Defender is most transparent in that respect... well.. not with Melodyne...).

So, you definitively use take lanes as tracks. And tracks without some features (in this case FX chains) are not as user friendly as "normal" tracks. So I think logical question is what exactly should be added to normal tracks so you can switch to them from take lanes? I mean what is the feature of take lanes representation in Cakewalk which force you use them instead of tracks? It can happened other will agree that feature(s) is(are) nice... That was mentioned (also by me) in this tread several times. But I want express that point (really the fact) in other words. Take Lane is not a Track and it is not a Clip. It is different "thing" for different purpose. It is container for Clips, and only that. And that is the only logical container for Clips, Tracks are containers for Take Lanes, Clips are not inside Tracks directly (BTW advantages and consequences of allowing that can be observed in NI Maschine 2, I mean the introduction of "clips" in Arranger view which are not present in Ideas view). Note how different (from Track) Take Lane react on all operations. I mean Solo, Mute, Record-arm, etc. Everything is "optimized" for single goal, to record/select multiple takes. Solo and Record-arm are exclusive, take lanes are auto-created as needed, recorded clip lands into "empty" space of existing lane, clips auto-muted, comping tool, etc. I understand that you try to use them for different purpose and so you ask to optimize them for different purpose. I just fail to understand what is wrong with normal Tracks for you. Long time ago there was a wish to group Tracks visually, so folders was introduced. Later there was complain Buses are in a separate pane and so visually difficult to match with corresponding tracks, but Aux Tracks can be used to solve that. May be you have yet another good idea for tracks, which I just have not understood yet

As you can guess, most user don't have such issue with Cakewalk. But there can be several reasons (and combinations of them) why you observe it. Please specify: your audio interface, Windows version, audio settings in Cakewalk (driver model and the buffer related numbers), what is approximate delay if the project has one track with single audio clip, does the delay on real project changes if you disable all FXes and either you use or have ever installed ASIO4ALL on this computer. Then the list of suggestions what to check/change/update can be reasonably small.

Sample Rate is important. Any project has fixed sample rate and it can't be changed. So, if your project is already 44.1kHz, you can't change it later. That is why the setting is called "Default for New Project", that is one time decision at the project creation. Also Cakewalk use the audio interface with current project sample rate (only). For several reasons, if you always use the same Sample Rate in Cakewalk better set the same in Windows. Bit depth of everything can be changed any time. And it can be different for different settings at the same time. Obviously the change has no influence on already recorded material, if you have recorded in 16bit, the file will stay 16bit after you change the setting to 24bit. Cakewalk internally process in 32bit (floating point) or 64bit (if 64bit engine setting is activated). Normally render bit depth should be 32bit. 32bit engine data will be saved "as is" and in case of 64bit engine, 32bits is still sufficient (extreme and artificial processing is required to produce any difference in sound between 32bit and 64bit files, such processing is never used in real projects). But record bit depth should be as high as your audio interface support. Most interfaces support 24bit. Note that 16/24bit are fixed point numbers, audio interfaces always sample into fixed point numbers (even so drivers in some modes can transfer the data as 32bit and some interfaces claim they are 32bit). Real bit depth is around 20bit on good interfaces, extra bits are just noise (if you know SNR or Dynamic Range of your interface, you can estimate meaningful bit depth by dividing this number by 6). But every single bit is around 6dB, which you can have as a "headroom" during recording to get equivalent precision. Note that record bit depth is not used till you record audio (probably the case in your setup with Realtek).

Putting FX on a take lane is using it as a track. Making a separate track from that take is not a workaround in such case, it is the way Cakewalk is designed. Sure "repeating" processing is not the way to go, original track and this new track should be routed to a bus where common processing happens. Technically that will not complicate signal routing nor produce extra load. Clips are on "another level". Achieving the same effect as clip FX without corresponding feature require creating a separate track for every clip. So that had to be called a workaround. PS. in one other DAW takes are strictly property of a clip, they always have the size of the clip and only one take can be active. That effectively prevents "misusing" them for other purpose ? But in that DAW tracks are hierarchical (any track is also a bus and there is just one track type, which process arbitrary number of MIDI and Audio channels). Every DAW has own view how things should be organized.

Nope... these RGB LED feature is NOT the same as for gaming motherboards an GPUs. It is more toward RGB LED use on Ableton (and some other) controllers, you can configure how buttons/faders/VU-meters should indicate its status. F.e. I wish my NI keyboard has such feature, depending from ambient light I have troubles to see the status of some buttons... These interfaces, if they work stable, can be a good alternative to some Zoom and Rode devices. If someone will try to explain inexperienced person how to use RME to record a podcast, he will soon realize then even the best music interfaces is pure choice for that purpose. But from the specification and the documentation it is clear that music creation is not the selling point.

I think at the moment there is a wish to insert "take lane FX", it is time to create a separate track from that take I think the idea behind takes is to make a choice between different versions of the content. It can happened some particular clip needs processing to "match" the rest. But if all clips on the lane need the same processing and it is different from all other lanes, this lane is not just "random" collection of versions. I have written "random" because some parts can be recorded 2 times, some 5 times and other just 1 time. So "Lane 3" as a whole has almost no meaning when take lanes are used as "take lanes". Lanes have some controls which exist for track, f.e. solo, but that does not mean the goal was establish full track functionality for takes. The "main stream" mixing structure in Cakewalk is still "Track->Bus->Bus->....->Bus->Output". Even so folders, take lanes and Aux tracks till some degree allow different internal and/or visual hierarchy.

PTN to MID was never a real problem, till people have tried to "escape" Cakewalk world. Sonar/CbB can load PTN and save as MIDI (f.e. as described in my first post, even faster with DnD). Originally I have thought to include that into utility (so giving PTN produce MID), but since that is natively supported, I have not implemented it. PTN files are fully usable in Project5 only. I don't see how a possibility to create files usable in a single program can be considered as a selling point for that program. While initially Project5 and Sonar could be thought as complimenting products, most (all?) features of Project 5 was later added into Sonar. Note that container format used in ARP/PTN files is still in use by CbB (CWP files). If I understand the documentation right, Project5 could work with MID. So Cakewalk still has the code and it is a matter of adding an extra option into Export menu and calling that code... But in practice PTN files make sense for arp only, and lets face it, arp in CbB is not the best arp on the market (I guess it is verbatim Project5 code, which in turn is the primary reason why it works with PTN...). I think the problem is that CbB still supports archaic DX MIDI FX only. So routing VST MIDI effects is troublesome. And so when for someone Cakewalk arp provides wished functionality, it is the easiest to use. There is a least one DX MIDI FX style/arp plug-in: https://midi-plugins.de/#Plugins/VirtualBand but I am not sure it is still possibly to buy it...

I could implement multi-file support, GUI, DnD, etc... but I have decided to keep it "simple", at least for the moment. The utility is so small that calling it for single files from batch/gui wrapper should take almost no time. With advantage it is simpler to analyze when particular file fails. for /R %f in (*.arp) do <path to>\cakearp "%f" called from a copy of "Cakewalk Core" took around 5 second to extract all ARP files I have. PS. well, if for whatever reason you still think that is useful... the utility accept any number of arguments now.

Cakewalk has build-in MIDI arp. In addition to "usual" for arps sequences, it can use custom note sequences as the basis. The only supported format for these sequences is PTN. Cakewalk by itself can load PTN files, as MIDI clips and as a part of arp configuration. Cakewalk also can save arp configuration (including the pattern) into ARP files. But for some (which?) reason Cakewalk can't create PTN files nor extract them from ARP files. The following utility tries to provide missed functionality. It is command line program which accept single file name as the argument: if the argument has an extension "arp" (or "ARP"), it tries to extract PTN file from it. The extraction is verbatim (PTN files are saved "as is" in ARP files) if the argument has an extension "mid" (or "MID"), it tries convert it into PTN file. Note that conversion is not "1 to 1", only Notes, Wheel and CC events are converted and all other parameters in resulting PTN file are constant (I don't know what they specify). In my tests that is sufficient for arp operations, please let me know if I have overseen something (I mean the result does not work as expected) Background information about PTN files. PTN are "Project 5" proprietary format to store MIDI clips. In general it seems like the format support all information in MIDI clips (and some extra, f.e. flam). But only a part of that information is used by Cakewalk arp. Converting MIDI clip into PTN. Prepare a MIDI clip, by loading existing PTN file (f.e. File/Import/MIDI..., select "P5 pattern" as file type) or from scratch. Original tempo will be reproduced with 1/32 setting in the arp (note that factory ARP do not follow that rule, so even if you load PTN extracted from an ARP into the same ARP, the tempo can be different). The first note defines the "origin" for transposing the whole clip according to actual note on the track. Select the clip. File/Export.../MIDI groove clip. Use the utility with created MID file name as parameter.

May be I have overseen and you have mentioned that already... but have you switched nanoKONTROL2 into CC mode? Leaving it in DAW mode is looking for troubles till you use MackieControl plug-in. For RPN/NRPN/CC/etc. , find some source for reading about MIDI messages. "MIDI 1.0" standard from what I remember is not free and midi.org web site is getting worse and worse with time...

It is possible to use ACT MIDI in parallel with Mackie-Control. But there are some conditions for that: Mackie Control should not react on control you use with ACT MIDI. Otherwise engaging the control will produce both operations. Taking into account Mackie Control defines something for all Mackie controls and "compatible" devices send use subset of that controls, in practice that mean you need to redefine what particular control sends insert ACT MIDI as the first in the surfaces list, before Mackie Control. Otherwise messages from all controls not defined in ACT will "leak" as MIDI input.

The format is simple. "Sufficiently old" programmers can recognize it in a HEX editor ? But "trial and error" is problematic without a program which can generate the files, since in such condition we can only guess what is saved inside. I mean without the knowledge what is saved, it is a kind of pointless to search how that is saved. At the moment we know there should be MIDI notes with standard number of attributes. These I have found already. But there are several more attributes for every note, something apart from notes (may be CC/etc... now since I know loading PTN into Cakewalk is possible I can check) and something for the clip as a whole.

Since they still can read these files, I think they still have the code to write it. But I can write external utility. That is why I have asked which features to check and may be try to implement. In P5 documentation I have already seen how to mark notes as "flam" and there is corresponding control in the arpeggiator. MIDI in Cakewalk does not have such flag (or I am not aware about it), unlike f.e. Step Sequencer.