User 905133

Sometimes switching screensets can help locate things that are hidden. Maybe add that to the list of thin gs to try after using the menu version of the same command. Optional: Set it up as a button in a collapsed Custom module.

We all have preferred settings/configurations to help focus our attention; so, this is more of a footnote for an option others might want to consider. (I am assuming you don't want to change what already works for you.) It is possible (using Theme Editor) to set the text color for the names of audio, midi, and instrument tracks (a) in the Track View and (b) in the Console View*. [*For some reason, my console track name text colors aren't showing up.] And I agree, being able to hide types of tracks in the Console View is handy! Oh, and I looked up to see if empty tracks could have their own text and background colors [think "greyed out"]; unfortunately, there aren't corresponding colors for empty tracks.

Have you considered using a wave editing software and abutting the "clips" at zero-crossings?

(1) Do you have a bus named "Master?" (2) If so, can you expand it and post a screen shot of it? I am thinking maybe you are doing something like I sometimes do, but you left the "Master" bus in even though you are not using it. Just a guess. I believe this is why Promidi asked for a screenshot showing the bus settings. It is possible that you don't realize you can grab the divider that separates the tracks from the buses, so you can see the buses.

The last time I tried to use Jack for Windows it didn't work. Admittedly this was ages ago. Does it work flawlessly in Windows 10 and not get messed up when Windows does an update? For me, Jack for Windows was such a huge waste of time, I vowed never to spend another minute looking into it as an option. Maybe someone made it work flawlessly? If so, maybe it would be worth looking into again.

Is it safe to assume you are not using the bus named "Master" to route audio to your audio device? Also, is it safe to assume that the bus named "Master" is not routed to a valid audio output?

Not sure that I would use the Iowa Piano, but I tried it. It works. I used the link posted above, unzipped it, pointed the vst scanner to the path . . . /downloads/iowa_piano_-_64, did a manual rescan and it showed up. Note: I do not have it in either of the Windows Programs folders. I downloaded it to my Downloads folder and uncompressed it there. I then added that path to my vst scan path list. Maybe someone who is an expert on Windows can tell you if having the *.mse file in a Programs folder is part of the problem. Anyhow, hope this helps.

Thanks for detailing the debugging process!!!! You are right, any unwanted audio artifact could be coming from a least-suspected source--even ones we don't use. Clarification: I wrote the above praise before the prior post was edited to include the checklist. So, I was referring to the narrative, which to me (based on my learning style) was more helpful than checklists which people often give in lieu of the running narrative. So, thanks for leaving in the narrative and not getting rid of it in favor of the checklist. 🙂

"Easy" in terms of what? using as a GM/GS kits? convenience of clicking a minimal amount of buttons and getting something useful? tweaking/customizing patterns? adding loop packs? adding personal/custom patterns? adding samples from other places? tweaking samples? availability/convenience of support files (e.g., drum maps) etc. Please note: I am asking not just for clarification, but because I have started to use "automatic" drummers and am very interested in things like importing patterns from hardware/my own patterns, importing drums (samples/kits) from samplers (hardware/software), etc. BTW, you mention "midi and wav percussion loops from the ancient drag and drop desk." Are you aware that you can drop and drag audio and midi loops directly from BandLab? Thanks for raising this question; hope I'm not piggy-backing too much onto your basic question. It does seem to fit the topic, though, and if others will be commenting, it might be nice to have some of these features addressed in addition to the concerns you raised.

Also: https://www.soundonsound.com/techniques/programming-sonar-5s-pentagon-i-soft-synth. Note: the manuals I have say midi learn = shift+left click, but it is indeed shift+right click as in the SoS article.

Now you tell me. 😉 Seriously, not sure I stumbled onto this particular setting (Valleys), but I discovered a number of other (possibly related) issues about 4-5 hours ago--super hot resonance in spots, varied loudness from patch to patch, changes from an other versions not reflected in manuals or release notes, etc. Fortunately, almost every time a patch/setting pinned Cakewalk's virtual LEDs miles above the top, it must have been above my ears' cutoff frequency. I did hear a few, though. I think Cakewalk's audio reset button cleared the peaked meters. Also, I learned not to change patches until the sound of the current patch was quite low. BTW, when looking for a manual online that matched my Pentagon I, I stumbled onto an old trick I had read and tested ages ago--using Pentagon I as a Vocoder. On the positive side, some of the patches made me not "hear" my tinnitus--perfect for some projects I had been thinking about.

Yup. Setting the permissions in regedit did the trick. Thanks!

@scook Out of curiosity, I tried to insert Pentagon I from the DXi plug-ins and got an error. Which fix would you suggest? registry permissions edit? reinstallation from X3? other? Thanks.

Also, check to see if there are noticeable harmonics of the hum frequency.

Thanks for this piece of the puzzle. Now that you mention it, before I uninstalled BandLab Assistant, I had tried a few other methods--including killing the "left over" processes using task manager. I learned to do that because those leftover processes have caused the BandLab Assistant app to not start in the past and usually killing the processes lets me start it again. I guess we could say I manually flushed it. 🙂

Interesting details, David. I was about to add an addendum to say that a second project where I tested using buttons on a folder track worked flawlessly. Of course, when I went back to the first test condition, the anomaly/fix was still consistent. Maybe the additional details you raised make the difference between the two conditions.

I don 't know the answer (can the behavior be changed/fixed), but this caught my eye and seems to be an easy thing to test and to expand the way I use Cakewalk. Testing with TTS-1 in Synth Rack (and Synth Rack showing) 2019.09 (build 70): Solo button in track solos/unsolos TTS1; button in Synth Rack changes, too. and vice versa. Mute button in track mutes TTS1; button in Synth Rack does not show muted status. Wait a second!!!!! I did something and now the Synth Rack Mute button does indeed follow the change in mute status from the track!!! (And vice versa.) What did I do to get it to work???? I muted from the track, then I muted it manually in the Synth Rack. After that mute button on track and synth rack worked as expected. I will stop tune and try again. AHA!!!! In my limited test, I confirmed the problem. And found a partial quick fix solution that worked for me--mute in Track then mute in Synth Rack; then mute/unmute from track. Unmuting from Synth Rack at that point breaks the quick fix until it is fixed again. Give it a try. Maybe there's a better fix than this quick test. Hope it helps in the short term. Addendum: Anomaly/quick fix seems fairly consistent, but one time when testing I had to press the mute button on the Synth Rack twice in a row before it unmuted.

Well, I finally updated to BandLab Assistant v5.10. Thanks for all the suggestions. Here's what finally worked for me. (1) Find where BandLab Assistant is installed; run the uninstaller. (2) Using Opera (which I hardly ever use, but it seems to be a bit "lighter" than other "full-featured" browsers), I went to BandLab and downloaded and ran the current installer. (3) When "Windows Defender" protected me (just one of several pieces of protection software/apps I use), I allowed it (as Administrator of my PC). That seemed to solve the problem for me as it allowed me to OK the new/newest "consent" and now BandLab Assistant seems to work again (without the nag to update/endless fail loop). I had no need to turn off various other protections (which can sometimes be time consuming). Also, no need to power-cycle the PC!!!!! 🙂

Good to know about! Thanks!! I suppose I never noticed this because I have done 99.44% of my Cakewalk stuff over the years using either wrk or cwp files. I assume the option only applies to MIDI files based on the description. "Always use Sysx Banks for MIDI Files (Instead of Sysx Data). " "If you check this option, Cakewalk puts any sysx data contained in imported MIDI files into sysx banks instead of a stream of sysxdata events (except for auto-send data, which is sent before playback). These banks show up in the Event list as bank events. If you don’t check this option, imported sysx data remains as sysx data events if it is up to 255 bytes, and is put into banks if it is 256 or more bytes."

This is the problem in a nutshell. The reset at 91.4.00 should not be sent at the beginning. (IMO) Please do a simple test--uncheck Bank 4. If that solves the problem, you can put a call to Bank 4 at the end of the file. Thanks.

>> Why is it that I can't see the SysEx events in the Event List? (1) Sysex Banks: Normally these do not show in the track event lists. These can be marked as auto send = yes [a check] or auto send = no. (2) Sysex data (what I am calling in-line hex): These are visible in the track event lists. (3) Sysex banks (what I am calling bank calls): These are visible in the track event lists >> I wonder if it is possible in Cakewalk to fire a SysEx event . . . at a specific position in the middle or at the end of a song. Yes!! That's (3) above if you insert a sysex bank. Or, you could use method (2) above by inserting the "hex code".

Good point! Based on my tests of a month or so ago, multiple timing sources is indeed an issue. (1) I slaved Cakewalk to midi to an external midi clock source and varied the incoming midi BPM. That worked for midi. (2) The metronome BPM matched the transport's display (initial tempo + tempo map changes) regardless of changes to the incoming midi clock. (3) An imported audio file played at a constant rate no matter what. (I did not test SMPTE sync. Though I do have an old cassette deck and tapes with a sync track, I didn't try that, either. I did not do timing/sync tests with Groove Clips.) Re: track 12 example: All midi tracks in my tests followed the incoming midi clock. The Cakewalk reference guide and the on-line help pages state that audio and midi may not be in sync ("Digital audio will play back, but not necessarily in sync."). I was thinking that your external sync data would be constant (as opposed to my wanting to vary the BPM from the external midi clock) and that with the right settings you might be able to get both audio and midi to track well together based on a non-varying external sync. I think I saw some video tutorials recently that showed how to create a tempo map based on an audio track. Maybe that might be an alternative to using the external sync track if the free-wheeling method is less than satisfactory. I'd be very interested in hearing about your sync methods and your results.

Have you tried P [Preferences] > Project > Clock [Advanced settings, not Basic]?

Thanks for posting your misadventures with BLA. A few hours ago, I kept getting the note saying a new BLA was available and despite several attempts to update it, it did not update. So I tested the Apps > Cakewalk > Open buttons. That resulted in a BSOD!!!! So I left it as is. Maybe tomorrow I will try your suggestion--uninstall BLA, power-cycle PC, reinstall BLA.

Excellent point!! I used to have a link to a very detailed, technical analysis of those cheap 1x1 usb interfaces. If I have it book marked, I haven't been able to find it for a few years. I seem to recall that two-way I/O was just one of the problems. A few years ago, I picked up an iconnectivity mio 1x1 usb interface primarily to test sysex between the Casio CZ line and midi-ox. Bulk data dumps (patches and sequences) worked to and from the mio. I have not had problems (including bulk sysex dumps) with a number of E-Mu PCI cards and the E-Mu 2x2 usb interface. On the other hand, e-magic's mt4 (usb 2 in 4 out ) couldn't even handle the one-way stream of aftertouch from a Casio DH-100 without issues.