azslow3
-
Posts
756 -
Joined
-
Last visited
Posts posted by azslow3
-
-
2 hours ago, pwalpwal said:
I guess x2 was around the time they were trying to do that "mac version"
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.
-
On 2/18/2025 at 6:11 AM, Pathfinder said:
Power limitations:
The USB standard provides a relatively small amount of power, which may not be enough to adequately power the audio interface's components, especially when using high-quality mic preamps or multiple channels simultaneously.
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.
-
1
-
-
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.
-
1
-
-
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.
-
On 2/21/2025 at 6:05 PM, sjoens said:
Most of the time this is what it shows. Only once it actually displayed the name of the track it was focused on. Oddly the maker (Nektar) said they've seen the same thing. They also said Cakewalk handles controllers differently than most DAWs so I have no fantasies of it ever working 100% as expected.
I've never used it with other DAWs but I might try it with Mixcraft. However, I don't think MC displays things the same way so maybe Cakewalk is asking more of it than do. ¯\_(ツ)_/¯
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.
-
May be not relevant comment, but who knows...
There was CbB versions (I mean I am not sure that was fixed) where what was visible in Control Surfaces preferences was not the reality. I mean MIDI ports assignments was already broken, but preferences was still showing everything is fine. Changing port to something (+"Apply") and then changing to desired values (+"Apply"), so visible results are the same as before, was solving the problem.
Also periodically checking "hidden" ports in the Windows Device Manager is a good idea. F.e. connecting device to different USB port produce "a clone", which persists till manually removed.
Unfortunately devices like MIDI don't have unique IDs. The system can't be sure the same device is "moved" or new device appears when something is different (f.e. another USB port). The same for DAWs. Some software guess mapping of MIDI devices better then other, but there is no perfect solution.
-
2
-
-
PRV must be lanes aware to conveniently use lanes with MIDI. PRV in Cakewalk is not. May be some day they implement that in Sonar...
-
4 hours ago, mettelus said:
click on drop down at the top of the Amplitube VST window where is says "VST2" (or "VST3") and select "Enable MIDI Input").
If you see "VST3", that most probably will not work. You need VST2.
The problem is that Amplitube VST3 is not reacting on PC (at least for me, and as you can find in the Internet for other as well...) and Amplitube can only change to arbitrary preset using PCs. That is not Cakewalk specific.
But if you want "Next/Previous" preset, that can be done by CCs (and so it works with VST3).
PS. In general, changing presets "on the fly" is rarely perfect approach. That only works without glitches in case plug-in can change presets "instantly", so when there are just several parameters and everything is already in RAM. That is not the case with most plug-ins since they need to load something on preset change. And the result can be "old preset still works for a while after preset switch", clicks/pops or other glitches in sound and in some cases audio drop...
So, if switch should be reliable during performance, it is better choose other approaches.
One is make a preset which includes required variations and then control these variations. F.e. just some parameter.
If you use completely different presets, you can have more then one instance of plug-in, each with static preset. And then you change routing on the fly, switching which instance get input at particular time. Note that consumes more RAM and CPU.
-
1
-
-
18 hours ago, Sock Monkey said:
This new Midi protocol has much lower latency because it can send and receive the midi data stream muliplex where as the Midi 1.0 sends data serial one event at a time.
Example is if you play a 8 finger chord and engage the mod wheel all that data used to with midi 1.0 go one event at a time. It’s like you have 100 cats and only one cat door. With midi 2.0 you have a barn door wide open.
When someone has defined something which potentially can do things faster or with reduced latency, that doesn't mean everything is magically faster and has reduced latency... USB, especially USB 2+, is not limiting factor for MIDI size/speed data. Are there real tests with "USB-IF MIDI 2.0" which prove it has less latency with the same hardware?
MIDI 1.0 has hardware protocol, which is slow. The throughput is limited to ~1 event per mSec, so 8 finger chord + wheel can take up to 10ms to transfer. MIDI 2.0 has no special hardware. So the difference is in "USB-IF MIDI" 2.0 vs 1.0 ( proprietary "USB MIDI" drivers could and was better then generic).
All (modern) computer external communications are serial, technically all transfers are "one bit at a time". "Multiplexed MIDI stream" is defined by USB-IF for MIDI 1.0 (from 1999). Primary difference of "USB-IF MIDI 2.0" is support of "Universal MIDI packets" (UMP), which can be 4 times bigger then MIDI 1.0 packet (32bit only). 2.0 also has sections which try to address hi-speed and jitter. But as I have written at the beginning, someone has to implement all that and have a prove it "works better" in practice. Only then we can write "new MIDI has..."
-
8 hours ago, Misha said:
"this particular setting is just displayed confusing way. "
I don't think it's just displaying,
7 hours ago, Sock Monkey said:I had just bought my Zoom L8 and installed the driver and when I was checking that everything was working I noticed the Tascam was showing in the Sync Caching latency dialogue.
And as always you can’t change it. So I had to delete it in the Reg Editor.People, have you ever tried to CHECK which latency compensation is applied? I mean the one you see when you open the dialog (so just randomly the first interface in the system) or the one for currently active interface? You don't even need precise loop-back test, just set huge different values so you can notice the effect easily.
I don't advise keeping disturbing drivers in the system. Some are well known for influencing other drivers (especially ASIO4ALL). But many users have many interfaces and so they are all installed. And MY observation is that dialog in question always shows the same interface, independent from currently active one. And that is not a problem.
May be the behavior on your system is different, but that conclusion should be from real observation... Only then there is a chance Cakewalk will try to pin and solve the bug. So far (and there was many threads about that particular setting) there was not a single evidence there are problems with it.
-
9 hours ago, Misha said:
Thanks for additional info. I've never seen a realtek installing Asio shell by itself... As I've mentioned, most likely it was installed by another DAW. Again, as long as it works, I don't want to touch anything, as I have no clue why Cakewalk keeps on switching to something else instead of Yeti specifically here : Preferences > Audio > Sync and Caching, while everywhere else in Cakewalk it is pointed to correct driver.
This particular setting is just displayed confusing way. It is technically a table with all interfaces, so you can set custom latency for any. You probably see the same list as in Audio/Devices. The dialog starts with "the first interface", even when it is not active.
-
2 hours ago, Sock Monkey said:
Is there a way to transfer VST user presets between Daw's? I dug around and cannot find any info about this topic.
Or is the answer PS CWP2song? Is that on your web site?
I will try to extend the answer from @pwalpwal
The problem is that "user preset" content is not something standard. It is up to particular plug-in to define what it is and how to use that.
The problem is even more complicated since there can be several ways to save "preset", even for the same plug-in.
- most "compatible" way is to use plug-ins own export/import, when it has it. But there is no warranty everything will be included, some parts (f.e. samples) can be somewhere in the system and so not included into such preset. Plug-in on the same computer will (should...) be able to use the preset in another DAW. Note some plug-ins can't load preset saved in VST2 into VST3 (and some DAWs no longer allow both formats working in parallel). Still, when that method doesn't work, other will most probably fail as well.
- DAWs have own functionality exposed to users to "save/load preset". In standard formats (.fxp/.fxb for VST2, .vstpreset for VST3). Sometimes the first options doesn't exist, than this one can be tried.
- obviously DAWs save "preset" into projects. But here the fun begin. It seems like the way particular DAW does that can be sufficiently different between DAWs and even from exposed to the user "save/load preset" in the same DAW. I mean resulting "preset" can be different, even when format is the same. When the result of Cakewalk way is "compatible" with format expected by another DAW, CWP2Song will give you usable presets (yet, it is on my site).
As usual, the evil is in details. F.e. some DAWs just have bugs in preset saving, so what they produce can't be used in other DAWs (I have reported one such bug with .vstpreset in REAPER, and it can happened it is still there). Also when DAW can load preset "from project", that doesn't mean it will be able to load it with "save/load preset" (I remember there was at least one plug-in which was happy loading saved by Cakewalk preset from .song, but was unable to use it when loading explicitly).
When the number of VSTs you use is limited, just check what is working for each of them. BTW you can estimate what is included by the size of preset file. F.e. if you know you use custom samples in your preset and preset file is just several bytes, these samples are obviously not included.
-
8 hours ago, Sock Monkey said:
Thanks @azslow3 for you valuable insight on this topic. I have no problems myself transferring CWP projects to my other 4 Daw’s.
As midi is the heart of most of my projects 80% is as simple as saving my Sonar project as a midi file. This gives you the tempo map, the arrangements and most of the hard work that was done.
Then I export the audio as stems.Both dry and wet.
I take screenshots of all my instruments and effects.As you know, many details are lost during that procedure. Just to mention some:
- clips boundaries / names / looping / fades (for audio)
- take lanes
- automations
- routing (buses and everything related)
- instruments and effects settings
Yes, you can save separate clips manually and make screenshots of VSTs. But restoring settings from screenshots can be long and error prone. And you still have to record on which track/bus it was, in terms which track/bus was sending there and with which level. And all that can be affected by automations.
Sure, since your DAW project is created "manually" it is possible write down all settings and then manually restore them. But lets face it, for any serious project that is ridiculously ineffective process.
PS CWP2Song can be useful even in case you use manual conversion to unrelated DAW: it has an option to save tempo map and separate MIDI clips (structured as in the original project) as well as effects and instruments presets. If preset loading is working fine (some VSTs or VST+DAW combinations are a kind of "buggy" and can't restored such presets correctly), that is way faster then restoring settings from screenshot.
-
1
-
4 hours ago, Ted Raven said:
So I take it, that you are not going to implement DAWproject into Cakewalk to get in touch with the outer World?
DAWproject format is not a way to get in touch with someone... Badly documented and with several general problems, it is more or less supported just by one DAW (Bitwig). The second DAW mentioned in the "official" support (Studio One) has rudimentary, almost unusable implementation. "Community" implementation in REAPER is in the same boat - that DAW ideology "doesn't fit" into format which has to be called "Bitwig project LE".
I have implemented R&D quality converter from Cakewalk into DAWproject before coming to that conclusion.
4 minutes ago, Sock Monkey said:There’s 3 really good Daw’s that are using it so far. And two are Sonars closest competitors.
Seems not getting involved is going to be yet another reason for some people to switch.Into 2 of them you can convert Cakewalk projects. Not absolutely everything, but way more then DAWproject supported features. There is no "way back". But that is up to Cakewalk 😏
-
1
-
-
Have you seen Cakewalk in the Faderport v2 user manual? It is not there. Normally at that point you should extra check for compatibility. Good idea for MIDI controllers, computer components, auto accessories and everything else which potentially can be incompatible 🤪
But your controller is compatible.
-------------------------------------
You have 2 options:
The first is MCU and HUI modes on controller with Mackie Cakewalk surface plug-in. If you try HUI, don't forget to set corresponding option in the plug-in (and unset it otherwise). "Disable handshake" is probably also required. Not everything will work as labeled and you can't change the functionality. But till the goal is not to make "every labeled button work as labeled", that can be sufficient solution.
The second is using native mode with AZ Controller: https://www.azslow.com/index.php/topic,444.0.html
(note I have forgot that preset when posting into this thread 4 years ago... sorry, I never had this controller and I don't remember for which controllers I or someone else have created some preset already). In this case you can modify the functionality at your wish.-
1
-
-
Control surface integrations are designed to send some MIDI depending from DAW status (f.e. to sync LEDs under transport buttons). Works not time accurate, but may be sufficient (default "delay" is up to 75ms, can be reduced to 25ms). If you can't program in C++ (using Cakewalk API), you can use AZ Controller (www.azslow.com). If you go this way, I can write an example configuration.
-
For "Sync and Caching" / "Record latency" (appearance can be confusing):
Roland is not known for low latency, but as suggested before, you can try to tune the buffer size. Use Rolands own ASIO (sometimes can be opened from Cakewalk, sometimes from system tray only, note you need to "Stop audio engine" in Cakewalk during tuning, there is an icon in the Transport module). How far you can get depends from your computer audio optimization (default BIOS/Windows settings are not audio optimized).
Audio interface latency is important only for "throw the DAW" monitoring during recording. Since you record TD sound, you probably want that sound... and so you probably want to listen it during recording. And so there is no reason to route it throw the DAW (during recording). Headphone/speakers directly on TD or mixer (FR can play that role) are not influenced by interface latency.
Played sounds (f.e. metronome, previously recorded tracks, etc.) and recorded material will be "at correct time" as long as interface latency is known to Cakewalk, it will compensate (ASIO reported latency is more or less correct for TD and FR). You can also mix some "not time critical" effects (like reverb) from live (drum) sound, just don't use in DAW dry sound during recording.
If you want record MIDI, record it while still monitoring original TD sound. For monitoring with drum VSTi you will have to tune latency. MIDI latency is in general "gray zone", it is not reported and unclear how it is accounted. And it can be significant. Later quantized by audio buffer size, delayed by audio output latency, apart from possible "plug-in delays" (keyword PDC), the result can be disappointing. I mean that is not worse the effort in case of "self sounding" source recording.
On 1/4/2025 at 7:43 PM, Glenn Stanton said:with drums, even a 2ms latency will be audible to most people. so a 28+ms latency will be nearly impossible to ignore (basically the premise for this entire thread).
Note that the first sentence is "most people may notice extra 2ms latency under some conditions". "Natural latency" of acoustic drum set is around 1-2ms between peaces plus 1-2ms for all (sound speed is ~34cm/ms). So in practice if your e-drums have 2-4ms latency and you play with headphones, the latency will be not worse then "natural". When you change from headphones to monitors, the latency will increase by yet another 2-4ms (the distance from your head to monitors). Yet most people still do not perceive that as "disturbing". But there will be person dependent "border" after which you notice "unusual delay". And when extra 2ms cross that border, you notice that "extra 2ms".
Our brain is "smart compensating" "natural" latency of the sound you listen (just imagine you can really feel 1ms latency... you will be unable comfortably listen someone who is moving more then 30cm when speaking/singing without mic). So critical is your own voice only - the distance is small and fixed (head size) and the brain knows it
-
1
-
-
On 1/6/2025 at 8:24 PM, reginaldStjohn said:
There is a guy names @azslow3 on here who created his own midi control software from the Cakewalk source that they open sourced a while back. He would have more information.
Check out his web site. He may have a solution for you.
Yup. A25/A49 are M32 with different keys (at least originally). So the same solution should work.
https://www.azslow.com/index.php/topic,604.0.html
In short, it provides more functions then this device provides in other DAWs.
BTW that solution is easy to find, even with (degrading more and more...) Google. I had to record YouTube video to make that happened (Google almost ignore everything without related videos...). Should not take "several weeks" 😏
PS. using two identical (from computer perspective) devices without unique IDs (MIDI keyboards are such) is looking for troubles. Especially with Cakewalk, but not only with it. Replace one of it with different brand.
PS.PS. If you are ready to sell these devices just because you don't get DAW integration, both in fact can be wrong choice for you. NI keyboards are primary to control KK instruments, that works (almost) independent from the DAW integration. As clearly visible from the list of usual features, NI has added generic DAW controls as a "small extra" (except for Maschine with corresponding controller).
-
On 12/30/2024 at 2:09 PM, RexRed said:
Pure Power 12 M 1000W | ATX 3.1 | 80 Plus® Gold | Modular Power Supply | for PCIe 5.0 GPUs and GPUs with 6+2 pin connectors | 12VHPWR Cable Included | Silent 120mm be quiet! Fan - BN506
Better not... BeQuiet has made a mistake in new fans design. Even DarkPower is no longer "quite". Also they have just 5 years warrantee (my has died after 5.5 , badly, after rare occasional reboots). I have switch to "original" (BeQuiet is just a mod) FSP PSUs (cheaper, have 10 years warrantee and no bad fans so far).
-
Unfortunately I don't know the way to copy whole Matrix content/settings between projects...
-
1 hour ago, Pablo Jones said:
Wish me luck as I try and get started on this.
Good luck 😏
And just in case you will not stop with this controller (and/or will be disappointed by it)... here are some other:
- NI M32/A49-61/S49-88 have good control over instrument parameters. Especially if you use NI synths (or KK aware synth). All of them have almost the same set of controls (S have display), M32 is one of the cheapest controllers available (even if you don't use its keys).
- Behringer XTouch Mini is in NanoKontrol price class.
The primary difference is encoders instead of finite controls. So you always start tune parameters from current position, they will not "jump" to current knob position nor you need to "catch" current position by knob. While that behavior loose "hardware like feeling" you get with finite knobs, switching between instruments / DAW control changes experience from "not usable" to "usable". BTW original Mackie (the device NonoKontrol tries to imitate) has encoders and motorized sliders.
With NI controllers you can also select the synth from device (well... only with S that is more or less convenient).
For NI M/A and XTouch Mini there are AZ Controller presets for Cakewalk (since I have them). NI S you probably will want to use in Mackie mode.
P.S. keys of NI M32 are worse I have ever played (subjective). I can controls the sound with Akai MPK Mini, but not with M32 ("AZ velocity MIDI" helps with both, but when hardware doesn't send distinguishable velocity values, software can't compensate). For fixed velocity use that is not a problem, but playing "piano" is almost impossible.
-
1 hour ago, Pablo Jones said:
I bought a NanoKontrol in order to switch between VST's and control some parameters in my Virtual Instruments.
From you question, it seems like you have first bought the controller and then have started to search how to use it. That order is not optimal (even so you probably have just bought the cheapest controller and you are not the first with such approach
).
Almost all controllers just send MIDI messages (f.e. CCs) when you operate them. But what these MIDI messages do is up to software. In general, there are 2 approaches:
- send MIDI from controller to Virtual Instrument, so the same route as you send MIDI keys / pedals / wheels. In this case it is up to particular instrument to interpret these messages. Unlike with notes / pedals / wheels, most CCs meaning do is up to instrument. Some use fixed CCs to control something, so you setup that in Korg software. Some can "learn".
-
let the DAW to interpret the messages. The result is DAW and particular mapping specific, MIDI proposals are normally completely ignored in this cases (f.e. "PitchBend" messages are used to control track volumes). In Cakewalk you have two possibilities:
- "learn" some DAW control, f.e. particular track volume
-
let Control Surface plug-in do special interpretation. There are several such plug-ins, including:
- Mackie control. For DAW controlling. It uses fixed MIDI mapping.
- "ACT MIDI", "Generic Surface", AZ Controller (not stock, I have written it to escape limitations of the first two). Here you can configure what controls should do, first by "learning" midi messages from controller and then defining the action. So the mapping is not "CC -> Volume", but "CC -> knob 1" followed by "knob 1 -> volume". The first mapping stay the same during operations, while the second can change (f.e. at some point "knob1" controls volume, at other it controls VST parameter).
Each way has advantages and disadvantages. Up to you to decided what you prefer.
-
1
Presonus faderport
in Cakewalk by BandLab
Posted
Presonus has a little bit "abused" the label:
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...).