User 905133

@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.

In the discussion sections, there are buttons to make a new topic and reply.

The Q/A sub section and the other discussion sections have different functionality. Though sometimes people use the Q/A section for continuing discussions, it seems to me designed more like a problem-solution database where (if used the way it seems intended) people can ask targeted questions, others can propose answers, and over time there will be a list of possible solutions to specific problems. Also, I suspect the top-rated answer receives numbers and rankings to show which answer more people found helpful. I have no idea if this was the intent of the Q/A section here, but that's how other Q/A forums work on the internet.

Tested hypothesis within Cakewalk. Seems to be confirmed with regard to sysex commands placed at tick 1 in *.mid files. Interesting: At tick 2 [01:01:001] the resets in tracks 1 and 3 go into banks 1 and 3 with Auto send = yes. However, the part/channel 11 switch to drums from track 2, stays in track 2, but is also inserted as bank 2 with Auto send = no. Because banks 1 and 3 (resets) happen before play starts, on my Roland, part/channel 11 did indeed switch to drums after I hit play (from the beginning). That makes sense, it was 1 tick in! For your solution, I suggest using my quicker quick fix and seeing if that works. In the sysex banks, delete the second reset and save with a name variant so you can tell it apart from the original. Maybe it will work on your Roland, maybe not. The other quick fixes might be a second and third option: insert part/channel switch to drums sysex command a few ticks from the beginning either (a) as inline hex or (b) as a call to send that bank. I saved screen shots of the changes I did and the results when Cakewalk opened the altered files. Unless someone in the know confirms that this is a known behavior (and perhaps there are reasons for it), I will share my screenshots tomorrow. If my assumptions have been correct, I don't understand why the file maker would put a reset in two different tracks at the same time designation unless they are both there in case the user has two different devices and both need to be reset. Anyhow, I hope some or all of my fixes some the issue on your Roland.

Well, I finally figured out how to make Samplitude do something other than give me error messages. So, it plays the Flintstones.mid file on my Roland Expansion Module. Unfortunately, I cannot figure out how to view midi data. I suppose to others used to working with Samplitude, it as second nature to them. To me, there is no easy path to "View Event List." It does things with something called "objects." Egads!!!!! The tune is in there; it plays. So then it tells me I have to import the midi file into a VIP project!!!!!! I now understand the frustrations newcomers to Cakewalk feel! This is unbelievably frustrating. I thought it would be easy to look at midi data in Samplitude, but one thing after another I try tells me I have to do something else and those things never show me the midi data.

I can't test this in another DAW; so, this is a guess. Perhaps the original file has the sysex commands at the very first tick in different tracks. Perhaps when Cakewalk parses the file, it sees initial sysex data at the first tick and puts them into the sysex banks based on the order they are found starting with track 1. Perhaps the first sysex command Cakewalk finds becomes bank 0, next becomes bank 1, etc. Not sure, but it might explain a few things. So, if the reset is in Track 1 and also in Track 3, with the channel switch in track 2, and I am right, that could explain the problem you found.

(1) The Flintstones file asks if I want to send auto-send sysex banks. I said "OK." Sysex banks were sent to my Sound Canvas box. Part/Channel 11 is normal/not drums. (2) I look at sysex banks in Cakewalk. (Views > Sysx) (3) I see the same problem. I delete the extra reset (bank 2) and save the file as Filntstones-changed. (4) I close it; I open it; Cakewalk asks if I want to send the auto sysex banks; I OK it. (5) Part/channel 11 switches to drums. Hope these steps help. PS: Footnote: Cakewalk can have sysex commands in a couple of different places, e.g. as sysex banks, as "inline" hex. Another option like the quick fix: instead of inserting "inline" hex (the sysex bytes), you can send the relevant bank as a bank. Based on The Flintstones file, bank 0 is the reset and bank 1 is the sysex command to change part/channel 11 to drums. Before I deleted it, bank 2 (another reset) changed part/channel 11 back to normal. (At least on my Sound Canvas module.)

(1) When you load/boot a file that is supposed to set part/channel 11 to drums, does Cakewalk tell you that there are sysex banks to send and ask if you want to send them? (2) If yes, do you tell Cakewalk to send them? (3) If no, that is a problem that should be resolved. (4) Did you look at the sysex banks? [Views > Sysx] (5) If yes, do the auto-send sysex banks send a reset after the part/channel 11 change? (6) If yes, try deleting the additional reset. (7) If no, the problem you are having might be found elsewhere. (8) Did you try my first quick fix? (9) If so, did it solve the problem? (10) If no, I'm going to put my M-GS64 away and let others try to help. (Just joking on #10; you have my curiosity; I will try the new files you posted, just because I am renewing my appreciation for Sound Canvas gear.)

Does the method used in this video offer any ideas that might help what you are trying to do?

Nice. I dragged an OGG file from a file browsing utility into the track area and within about 10 seconds for a 6MB tune Cakewalk did the file conversion.

This is a fascinating discussion. I am used to "automation" done by turning knobs and moving sliders to record CC data as needed (per auditory bio-feedback). I will have to check out doing CCs by drawing. Thanks for raising the discussion of automation. It looks like it will open up new possibilities when I make the time to explore them.

Last resort option ?

Interesting point! When I saw people mention the MIDI driver mode in the forum, I looked at my setting. It was MME and I just left it there, mainly because I saw no reason to change it. Good to know about possible issues running under UWP.