Jump to content

azslow3

Members
  • Content Count

    223
  • Joined

  • Last visited

Community Reputation

106 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. If Realtek ASIO with buffer 1024 is not working stable for you, there are some severe problems (with some luck just in software). Your system should be able to run several VSTs under buffer 256 without any tweaks. But that is true in case your are not running some "ultra" settings in some "heavy" VSTs (single VST can kill everything), so first try to reproduce the problem just with proven light VSTs only (f.e. provided by Cakewalk). Latency Monitor is not an odyssey, it is 1 button tool. Odyssey is to interpret its results in case it blames some generic Microsoft driver (it is tricky to find which device course the latency). Also check the system is successfully updated and disconnect/disable any networking. MS periodically think the system is "idle" (even if that is not true) and starts background activity. You can check system logs / task manager to spot any failing tasks, continuously re-connecting mouse, etc.
  2. I have updated Bandlab (2020.05) and everything works as expected. Switch to plug-in mode (A and B lit). On the current track enable ProChannel EQ (for now with mouse). Switch to ProChannel Mode (long press "<<", "<<" lit, ">>" does not). Use "<<" and ">>" to switch between modules, do you see "Track-EQ" instead of "No mapping" at some point?
  3. Note the table in the video, at 8:42. Check what you have now with 610 (note the table is for 48kHz).
  4. Do you see "No mapping" also during learning? "No mapping" means plug-in is "not detected". Check plug-in selection buttons (and indication) in the documentation of X-Touch Mini preset, but normally clicking on plug-in GUI with mouse should focus that plug-in (also for ACT operations). I have not checked ACT in recent Cakewalk versions, may be something was checked. BTW I assume that is the only hardware controller you use and AZ Controller is the only Control Surface in the Cakewalk preferences list. Different controllers can influence each other when it comes to ACT mapping.
  5. As first, with one device I strongly recommend to use ONE plug-in in a time. So, if you want use "ACT MIDI" you have to remove "AZ Controller" (or reversed). When you write "stops working", what exactly do you mean? So, when it "stops": Do you still see X Touch Mini in Cakewalk MIDI preferences? If yes, do its inputs/outputs still assigned in Cakewalk Control Surface preferences? If yes and you use AZ Controller, open its GUI and move some control, do you see changes in the "Last MIDI event"? Does Cakewalk display some dialogs like "MIDI device connected/disconnected"? Do you use other software with controller? X Touch Mini sometimes has strange reaction on Mackie "Bye" command (at least my does), so after running DAWs which use that protocol the device is "disconnected" when the DAW is closed (normally reconnect immediately, but not always). If you connect it throw USB hub (especially with long cable), try shorter way to the computer. Note that it will be "new device" on another port, which in turn can be problematic for Cakewalk (there are many threads about the issue, cleanup not existing instances in Windows Device Manager and delete Cakewalk MIDI INI file, search the forum in case you want more detailed instructions how to do that). --------------- In case controller is working, but Plug-in mapping "disappear" or you have other mapping issues: http://www.azslow.com/index.php/topic,297.0.html Note this utility works for all ACT mappings, not only for AZ Controller.
  6. All these parameters are internal tweaks for Cakewalk engine. Changing these settings can help with unexpected behavior under specific conditions. Googling particular problem sometimes show recommendation to change one or more such parameters. In other words, till you have particular problem there is no reason to touch these parameters. Defaults are working well in most cases. "Large buffering plug-ins" introduce corresponding latency. Cakewalk engine is "real-time" only, it is not able to cancel latency, it can only ignore it when required. As written in the documentation and suggested in the user guide, ExtraPluginBufs can only reduce/avoid audio drops when using some of these plug-ins. The "value" should not be interpreted as meaningful by user (even so it has some internal technical meaning for sure).
  7. When new audio device is connected, Windows set is as default. I guess that is expected behavior for most users. Once another device is selected as default, that decision is remembered. Reconnecting an interface from which default flag was removed explicitly no longer change default. That is consistent at least for all interfaces I have. Note that from Windows perspective the same device connected to different USB port (to different port of a hub connected to the same computer port, etc.) is "new".
  8. Then I just recommend to carefully check RTL under realistic settings for the interface you consider. Profire 610 was not bad in that domain, in the lower price segment you can easily experience "downgrade" in case you are not careful. It is easy to find posts about RTL of any interface, but check the results are really from "RTL Utility" and for the settings you have. On the same computer your buffer size will be the same as you use for 610, so do not think that "64 samples at 192kHz" is going to magically work since such setting is allowed in case you could get stable sound on 128/44.1kHz only. Not sure 610 has that, my M-Audio allows ASIO in parallel with windows sounds. Many (most) other interfaces do not, check if that feature is important for you (not so easy to find for concrete interface).
  9. If you care about latency (and in case you play guitar with software processing you probably do), you do not use specially audio optimized computer (and from your post you do not) , you do not need many channels and have the money, take RME. It is less problematic and more forgiving in mentioned conditions. As a bonus, you get full flexibility in routing (use in parallel with Windows audio, Skype, other DAWs, routing/mixing one into another when required). Note that Babyface Pro is just a pre-amp when stand-alone, only top models can work as mixers in that mode. I still have M-Audio Audiophile as my "windows sound" interface and Phonic + small usb mixer to keep all peaces of my small home audio room permanently connected (works with and without computer) in addition to M-Audio 410 and Roland VS-20 which just collect dust. But if I could go back in time, there had to be RME UFX instead. Unfortunately, I have understood that after I have bought Babyface Pro only. Nothing wrong with all other interface I have, they all work. And build-in Realtek also works (except for inputs). But with all other interfaces I hit some limits/inconvenience. With RME I do not.
  10. With relatively small RAM and no paging, the system can use only small amount for disk caching. The performance suffer significantly, especially with conventional HDD. With increased RAM and SSD the difference is getting smaller. Paging on (fast) SSD is absolutely no problem for anything except for audio applications, nothing else needs 1-2ms "warranty for execution". Note that far from every SSD is fast, there are PCI-e M2 SSDs with real speed 80-100 MB/Sec. Applications are different, one sample based instrument can consume 8+ GB. And if someone wants complete orchestra, 32GB can be filled rather quick.
  11. IMHO. If you have sufficient RAM, disable it. Note that Windows can crash in case it hits RAM limit in this case, also overall disk performance can be reduced. If you need it, put it on fastest disk may be after checking this disk access does not introduce extra system latency. The explanation. When Windows "think" it does not need something in RAM (and that something is not marked "keep it in RAM please..."), it can dump it to the disk. That happens not only when RAM is really full, but almost always. That free RAM for something Windows "think" is more important, including disk cache. Real-time aware apps, drivers, etc. should mark related RAM properly. But "should" does not mean "do". When a part of dumped data are required again, they have to be loaded from the disk. That always take "infinite" time from CPU perspective. And if that is required to continue with real-time (audio) activity, you get audio click/pop/drop. How bad/ok/fine it is you can check in Latency Monitor, it shows "missed pages" and (indirectly) related activity. Some disks/controllers can be worse then other in terms of "response time", unrelated to how fast they can transfer data. So the fastest can be not the best choice. I have i7 XPS (already a bit "old"), it is worse computer for audio which I have used. DELL has messed something in ACPI (hardware), and that trigger huge (several ms) "pauses" in the system. That does not affect anyone except audio applications with low latency, so there are no known universal fixes for that. Some people claim disabling some ACPI drivers helps, I personally only have luck by disabling any networking and background tasks when I need low audio latency (also RME drivers are more forgiving, Roland was freezing the whole system while keeping irritating cry sound on the interface output).
  12. And in case you want change "response curve", there is http://www.azslow.com/index.php/topic,275.0.html
  13. All "proper ASIO" solutions for low end Behringer interfaces are using the driver mentioned by msmcleod directly (without redirection links) on the first page. My post from the time when Behringer has switched ASIO drives on there download page: http://forum.cakewalk.com/FindPost/3294586 The "driver" is still the same, from year 2009... It works with many audio interfaces and Xenyx mixers and it still works with Windows 10 (as most drivers for Windows versions before 8). It provides ASIO and WDM, but not WASAPI (which was introduced later). What this driver really is (and how "true ASIO" it is) can be speculated, some people guess it is tuned generic WDM/ASIO (ASIO4ALL is not the only one, but widely known since "free"). At the time of Windows XP... the latency around 10ms was "good". This driver can go down to ~8ms, with some "ultra" settings (since hardware overhead is high) and so the computer has to be audio optimized to work on such settings (modern interfaces/drivers at the same latency are more "forgiving"). So, it is possible to buy an audio interfaces (as new or used) with 10+ years old technologies and related software and still use that on modern system and get original results. That results depends from the original quality (back it time) and so the price (back in time). But all companies was not sitting doing nothing last 10 years, related hardware and software are not the same. Everyone decide for himself, but in many cases "who try to save pay many times". I took the long route, started with Behringer Xenyx. Once (after 4 other "cheap" solutions) I have got "real" interface, I have understood my mistake 🙂
  14. Have you tried to send: F0 00 00 66 17 21 01 F7 F0 00 00 66 17 20 00 06 F7 D0 05 in one sequence? If it works, is should display "some" signal for channel 1 for short period of time. But we are seriously off topic with all that... This is Bandlab forum about special plug-in.
  15. General channel message is: F0 00 00 66 <dev id> 20 <chan> <mode> F7 <dev id> "17" for C4 <chan> is (if I read the source right) 0...31 for C4 <mode> can be 0, 2, 4 or 6. (4/6 - display peak hold, 2/6 - LCD bar graph, whatever that means...). "01" you see for MCU will not work. After mode is set, you use: [D<row>] [<chan><level>] (2 bytes) So "D0 05" means "row 0, chan 0, level 5". For C4 there will be more, like "D1 52" for "row 1, channel 5, level 2)
×
×
  • Create New...