User 905133

Thanks for sharing these! I have done some customization with themes, but (1) nothing with the FX Chain Images and (2) nothing as nice as these!! These look great!!!

Will we have a full set of colors (background, text, etc.) in the theme editor for this new folder type so we can distinguish them visually from traditional folders? Just wondering. Thanks for the sneak preview. Never mind: As chuckebaby pointed out, this is not about a new/upcoming Cakewalk feature.

JMO: With things like webmidi and now MIDI 2.0, it would be cool to have IoT capabilities! MIDI 2.0 could open up a whole new area of hacking with regard to IoT!

I agree--would be very nice. However, I'm not sure the Cakewalk devs can counteract what Windows chooses to do. For example, after some failed feature updates, even though Windows allegedly restored my settings, I started having BSODs. Most of times the "cause" (according to the BSOD) was a specific midi interface driver that had been not causing any issues. Based on other midi software triggering the system crash as well Cakewalk, I strongly suspect the problem is with Windows, not the software. If I am right, Cakewalk devs would have to second guess what Windows MIGHT do to mess up device tables (or however they are tracked). At present, I have disconnected the MIDI interfaces and have been trying to uninstall the drivers manually. My hopes are that (1) I will be able to install them again (one-by-one over the span of several days to test for BSODs), (2) the interfaces will work as they did previous to the Windows 10 Feature Update attempts, and (3) I will remember not to allow Windows 10 to attempt more Feature Updates. It would be great if Cakewalk could (1) create its own device table, (2) had options to allow users to re-scan all devices (at start up and/or on-demand) and (3) had a way to keep track of devices used in projects (maybe a separate per project file, but not in the file itself) and have an optional smart per project (or per setup/hardware configuration) reassignment mechanism. Perhaps this could be done with selectable "Preferences Presets" so maybe each project could track which set of hardware [midi/audio] preferences should be used, if available--with the reassignment mechanism triggered if the hardware devices weren't all there.

Reply to the first post in this thread removed because this topic is being discussed elsewhere.

Thanks for the insights. I think you are right, it was may have been my MOTU that did the stepping down. But now I am thinking, with my Arduino Mega 2560, is there enough program memory to write some handlers to take 4 MIDI 1.0 sound modules, wrap the data in MIDI 2.0 packets and do something with it? Glad I got the model with the quad UART, though from what I remember, there is code to simulate UARTs via software.

Thanks for contributing this to the discussion. I have put this quote here because this seems more relevant to a generalized discussion of MIDI 2.0 as opposed to the "Deals" subtopic. For me, it really depends on how gear builders, software makers, and others implement MIDI 2.0 and choose to make things (or not make them) fully compatible with existing stuff, esp. for me, all my existing gear. I haven't read the details, but this sounds to me like handshaking stuff. If its done via usb, it involves serial communication. Time-stamp handling routines should be fascinating to see how they handle information--for example information sent later but received before other information. I am curious to know if there are parallel interfaces out there or are on the drawing boards or if any hobbyists are working on parallel processing of MIDI 2.0 data.

Several years ago I watched a batch of Youtube videos on Mastering. There are many that are horrible (IMO), some that are sort of ok, and a few that had gems of wisdom in them. What I found as gems might not be the same as what anyone else would see as gems. They are more of the personal "Aha! Moment" experiences--for me things I didn't know, things that were simple and easy to implement once you see/hear them. One of my personal favorites had to do with the psychological aspects of loudness--overall loudness v. the presence of instruments in the audio spectrum so they could be perceived without being muddied by everything else. I am not a recording engineer either professionally or as a home studio hobbyist, but maybe this distinction between loudness and clarity might be helpful to you. In any case, I do recommend watching mastering tutorials (and skipping the ones that within the first 3 minutes don't match your listening/watching/learning style).

Maybe this explanation of recording modes will help? Also, are you using mono-timbral or multi-timbral soft synths or hardware?

With the above tests I didn't notice any difference between the push pins being blue (on/pinned) or grey (off/unpinned) on my system. Though I only tested it a few times, I did not see any differences. But as I said, I don't use them, so they might be doing something I don't notice. Maybe one of you can test those? If they don't work, maybe that's part of the problem. If the on/pinned state meant, "Keep this on top" (such as on top of the Console) and off/unpinned meant "OK to hide" (still leaving the recycle plug-in window the way it is), from what I can tell, that should give the options you want--pin to keep on top, unpinned to allow only the newest plug-in on top of the Console. Maybe. Glad the info is helpful. ?

For hardware sound modules I tend to use friendly names for the midi ports (Preferences > MIDI Devices). As long as I use the same usb ports for my midi interfaces and use the same 5-pin din connections, the friendly names match my gear and I can select them as needed in the track headers. To expand on this, last summer I made Cakewalk templates with about five or six modules. Not sure if I set up tracks in the template for 16 channels each or 32 channels each. Would something like that work for you? Or do you change around gear connections?

Thanks for taking the time to find the thread; a Coffee House thread is more relevant to my comments than the Deals thread on MIDI 2.0. So, thanks for calling this to my attention. BTW, the link you provided here is the same one that Google turned up for me this morning--the source of my "red flag." ? A footnote: Several years ago (4 - 5 +/-? ) I was doing midi tests with an arduino and discovered that the arduino could pump out midi data at 115200 baud to my PC and softsynth via the hairless serial midi tool going into the RX of an audio card joystick port midi interface cable. It was a custom Arduino C test program to generate notes and CCs on 16 midi channels based on some scales (acceptable note arrays, with randomized CC values and randomized octaves within a 2 or 3 octave range). I am not sure what did the serial rate step down (to 31250 baud), but MIDI 1.0 hardware (sound modules) had no problems. I didn't investigate where the step down took place (Windows XPSP3 PC), but it was clear that going in, it was 115200 and that the data was being passed around internally at a faster speed than my midi interface was sending it out to the hardware. (Not sure if it was my parallel port 8x8 Motu or another interface.) An opinion: Considering that an arduino is super slow compared to later processors, I hope that MIDI 2.0 gear manufacturers design gear, drivers, and OSes with the potential for digital communication speeds that will be around in 30 years.

IIRC, it used to be that SONAR/Cakewalk recognized when new midi devices were connected; however, last night the usb keyboard I have been using for about 6 months wasn't immediately recognized. Not sure if it was because I plugged it in to a different usb port or what. Eventually, it was listed in Preferences > MIDI Devices (unchecked) and showed up in the MIDI Input Track Control Widget--after I had enabled it in Preferences. Re-loading the project did not automatically assign the keyboard as the midi device for the tracks where it had previously been assigned. Just offering my experiences in case it helps point to debugging strategies. I have no idea why hot plugging midi devices no longer registers (or if that feature was removed sometime and I never noticed it) and no idea which thing I did made it visible again. NEW DETAILS: I just remembered, prior to this I had attempted (again) to update Win 10 (Features Update). As usual, it took several hours to attempt, and about 30-45 minutes to undo the failed attempt. I had disconnected almost all my usb devices (not PC keyboard and mouse) and my sound card to see if the update would work this time. (It didn't.) So, the soundcard preferences had to be redone as well--before I had only 8 ASIO channels in use and with friendly names. Upon reinstalling the card, all 32 ASIO channels were selected and the friendly names were gone. In my experience when Win 10 reverts itself from a failed Features Update, it is never 100% back to what it was. The sudden appearance of on-going BSODs was one one the symptoms that clued me in to the changes from the failed update/so-called reversion process.

I am not sure that an extensive MIDI 2.0 discussion belongs in "Deals," but that seems to be where thread currently exists. So . . . This raises a red flag for me. Though it is technically true, it is somewhat misleading. MIDI 1.0 messages are indeed one way; however, MIDI 1.0 communication can certainly be two-way. It just typically uses two one-way cables. Simple example: With WebMIDI and MIDI 1.0, one user of the same line of gear I use has created a website to poll midi ports and update firmware on MIDI 1.0 gear. Yes, the gear is connected with two one-way cables, but the communication [handshaking] that allows for the OS to be updated is definitely two-way. Notice, the above PR doesn't say, MIDI 2.0 messages are bi-directional. Since this seems to be a major premise, I am concerned that existing two-way MIDI 1.0 communication might very well be undone, made null-and-void, broken, etc. because of what seems to be a misleading premise. Just a red flag at this point--I remember how the developers at Casio messed up with their misinterpretation of "F7" in sysex communication/handshaking. With the CI model as shown and the misleading PR, it is not clear that developers and manufacturers won't make even worse goofs. If they think that two-way communication didn't happen with MIDI 1.0, they might make it no longer work--because they were misled. Just a small red flag at this point. BTW, from what I can see so far, the MIDI 2.0 and MIDI CI models / environment / protocol / what-ever-you-want-to-call it use packets. So far, I haven't gotten to the point where parallel handling of messages is described, but that should be amazing, esp. with time-stamped packets being passed around. I can't help but wonder how messages received later but with earlier time-stamps will be handled. Looking forward to reading more!!

Correction to prior assumption: With a full screen Browser in the Multi-Dock, if I select FX from the bins on the tracks, they show up, one-by-one (i.e., not hidden) on top of the Browser. Possible work-around: Instead of re-opening FX from the console (if that's what you were doing), open them up from the Track View on one monitor with the Console View open on the other monitor. With this set up, they also re-opened one-by-one (not hidden) on top of the Console.

For some of us, making the buttons smaller would be a step in the wrong direction. However, just as there are options for different "sizes" (or orientation states) of modules within the Control Bar (as well as other visual options), I would not mind at all if there were some way to have some choices in the sizes of things like buttons. That way people who can see tiny things can opt for small buttons, etc. and people who can't even see "normal" sized buttons, etc. can opt to have them larger. A number of users have suggested things like adjustable graphics; For my needs, I am not sure there needs to be infinite gradations, as than might totally change Cakewalk beyond easy eye-to-brain-to-hand usage. Fortunately (JMO), with the Theme Editor we can do a fair amount of customization. One user has even created a very helpful (IMO) guide to help others with customizing themes as the elements (colors and images) are currently accessible. BTW, I tried another DAW that was absolutely impossible for me to read (bad fonts and too tiny) and there was no way to change that. Wish I could get my money back!!!!

Thanks for confirming that! Not sure if its a property of the Multi-Dock, the open plug-in process, or maybe the screen drawing mechanisms. Clearly multiple plug-ins can be (1) opened and dragged on top of the Multi-Dock and (2) can be saved and restored to be on top. I tend to get confused by too many things staring me in the face at once. That's one of the reasons I like Workspaces so much. But those might not fit well with your workflow. Also, having a 1/2 screen console or flipping the console in and out (maximize/minimize) so you can see all the plug ins at once might not be practical. D (as a shortcut) seems to allow toggling between seeing all the open plug-ins on my test project and having a full screen console. So, I can quickly see them all, maximize the Dock, and then look at the plugins by choosing them one at a time from the FX bins. Not sure this work-around is what you ultimately want. Test of Monitor 1 v. Monitor 2 and plug-ins: I moved all of the plug-ins onto Monitor 1 (on top of the Track View) then closed them. Then I selected them from the FX Bins on the Console (Monitor 2). Sure enough, although they overlapped based on where I placed them, re-opening a plug-in did not hide the ones already open . This is what you want on top of the Console on Monitor 2. (Not sure if its a Monitor 2 thing or a Multi-Dock things. I will switch them, retest, and update this post in about 15-20 minutes. ) UPDATE: It appears to be a Multi-Dock issue, not a Monitor 1 v. Monitor 2 issue. So far, I have only tested this with the Console, but I am assuming that it would be the same for other things selected in the Multi-Dock. Over the past several months I have thought of making some requested features related to the Multi-Dock based on some drawing bugs. I have not made them because I am undecided (1) if I should ask for multiple panes within the multi dock or (2) if a single, multi-purpose, switchable Multi-Dock is out of date with users now having multiple screens, easily switchable Workspaces, etc. With the Multi-Dock as it is, I can understand the rational for hiding plug-ins as new ones are re-opened. It will save some users (depending on their workflows) from having to constantly move plug-ins around and/or close/minimize them to see what's underneath. However, for your workflow I can understand the need for an "Always on Top" option for re-opening plug-ins on top of the Multi-Dock. I am not sure if that is a trivial or non-trivial change. Maybe one of the power users or staff knows of such an option or other work-arounds, etc. If you can't find options that jive with your workflow and want to request a feature, maybe this thread will help. I learned a lot; so thanks for starting thread and to you and Starship Krupa for helping to expand my knowledge base. I hope my explorations help find a workable solution.

Is it possible additional plug-ins are just hidden, not closed? Screen show 1 shows the result of having a full Console on Monitor 2 and then pressing each plug-in from the FX bins one-by-one. As each plug-in was opened, the one before it seemed to disappear. But when I minimized the full screen console, they were all there! To clarify: In my last set of tests, the plug-ins disappeared, but did not close; they were hidden. Is it possible that is what happened in your case? If so, that would seem to be a different issue than recycling the plug-in window on monitor 2. Still an issue I would think .

One of my workspaces has the track view and a full console in a multi-dock on monitor 2. I totally get that. See the first screenshot below. Right below it is the exact same project but with a different workspace. The second one has some FX plug-in where I placed them on top of the console. There are other difference as well--on the main monitor. I think I now see the issue--it depends on where you open the new plug-in--maybe. See next set of screen shots (next post). BTW, there's black space in the screenshot (not on the monitor itself) on top of the left side (monitor 2) because I have the two monitors at different resolutions.

Sometimes when I select a track I get more indicators than you show. See below, Track 4. Maybe someone can explain the difference between what I did and what yours shows. I think there's a difference between a track being "active" and a track having "focus," but (1) I am not sure and (2) I don't understand a lot of the nuances of the UI. I just move my hand, my keyboard, the mouse, etc. and they seem to know what I want. If not, my brain says, "try something else."

Not sure if this is part of the issue, but worth mentioning, just in case: If you were using a Workspace and then moved the floating windows to the second monitor, but the workspace wasn't resaved, depending on the Workspace store/restore options, the next time the project is opened, the plug-ins might be back where they had been before the move. Again, I am not sure what the final goal is because the workflow has not be laid out. But if the above quote is part of the workflow, then the implications of a Workspace save and restore might account for whatever it is that is unwanted. And if so, then perhaps using Workspaces might solve the issue--regardless of whether or not monitor 2 doesn't respect the status of the push pins in the same was as on the main monitor. Not sure. Too many options can be dangerous!!!

Thanks for the explanation @Starship Krupa . I don't pay attention to the push pins. I just put my plug-ins where I want and leave them there for the next time I load the project and/or reload a workspace. I am pretty sure it works the same way on my main monitor and monitor 2. I will try to see what happens if I turn Recycle Plug-In Window back on. I guess what the OP is saying is that if I do that the two monitors will behave differently from each other. Thanks for helping me to understand what pinning is about. UPDATE: I think I understand. There are at least four different things: (1) placement of plug-ins, (2) pin status (on or off/pinned or unpinned), (3) status of the recycle plug-in window box (checked/recycle or unchecked/not recycled), and (4) the difference in the behaviors based on where the plug-ins are. (There might be more variables I haven't found yet with this problem.) Another possible set of factor (5) where the plug-ins were (a) when the project was stored and/or )b) when the current workspace was saved. I am not sure, but with your clarification I think the OP is saying that on monitor 2, the behavior of (1), (2), and (3) differs depending on (4) and maybe (5a) and (5b). I did find that on monitor 2 and recycling off, the pin status of each plug-in makes a difference, though I only tested with 2 plug-ins so far [both pinned, both unpinned, and one of each]. This is the danger of having too many options. That's why I just put the plug-ins where I want and leave the window recycling off. My plug-ins tend to be different sizes, so with recycling on that seems to refer to the upper left corner of the window position. This if I have a larger plug-in replace a smaller one, I usually have to move it. So my preference is just to put them where I want them and slide them around as needed. When I reboot the project, they return to the stored locations no matter what monitors they were on. But I can see that if someone is using the same sized plug-ins they might want them to show up in the same place no matter which monitor they are on. I didn't get that from the original set of comments when I read through the thread and am guessing that's what the goal is (not 100% sure, though). Thanks for helping me to focus on a new-to-me feature--plug-in push pins.

I have some personal workspaces that use a second monitor. Not 100% sure what pinning plugin windows means. IIRC I have plugins show up based on where they are stored/restored via workspaces even on monitor 2. For me, they are just floating windows; I haven't "pinned" them. I'd be interested in helping if I had some steps that tell me what to do to pin plugins. Not sure I can help, but I'll try.

I test drove the web-browser-based Bandlab two or three times. As a long-time Cakewalk user, I'd say they are quite different. Not saying one is better than the other; I think they both serve different needs. When I saw this yesterday, I looked, but didn't see a forum. There is a searchable "Knowledge Base." I didn't mention that yesterday because I got the sense that you were looking for a forum like we have here. I believe the social media focus of Bandlab lends itself to sharing projects-in-progress with others who use that platform (specific people, IIIRC) . I don't remember if there is online chat. I do remember getting help from someone from here and also looking at one of his Bandlab Projects through the Bandlab interface. I did explore (very minimally) the potential to export Bandlab projects (*.blx) and then import them into Cakewalk. So, I know it can be done; I just can't tell you how. I do know you can drag loops (audio and/or MIDI) from the Bandlab Assistant App into Cakewalk. For me, the audio loops were not of the highest resolution. Clearly Bandlab (the app and the site) is directed towards people interested in social-media connectivity. I explored it because someday I might want to take advantage of that focus. Right now, for me/for what I am doing, it took too much time to figure out the logistics of the online composing process. If you are interested in learning more about exporting Bandlab Projects and importing them into Cakewalk, I can look up the links--but I think the sections are in the Reference Guide and in one of the Feature Updates a few updates ago. Hope this helps. PS: I didn't explore this, but perhaps there is interactive stuff (help) there. PPS: It looks like there are some people listed in the tutorials link that use Facebook for Q&A. I don't have Facebook (being not very sociable), but maybe that is the way the social-media crowd interacts (as opposed to forums).

JMO: If all the people who (1) equated MIDI with song files that could be downloaded in massive numbers and played in media players on sound cards and then (2) declared "MIDI is dead" when audio files could be downloaded in massive numbers take to social media platforms to condemn MIDI 2.0, I don't think the people who actually use MIDI for their creative efforts will be able to counteract the negative PR. I, for one, hope that massive downloading of MIDI files is dead, that nobody tries to make all existing on-line MIDI files 2.0-compliant, and that "all those people" don't learn of MIDI 2.0.