User 905133

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!!!!

Same here; looking forward to a fix when they all open in one folder if the folder option is chosen. For years I have thought about a multi-timbral VSTi I have that allows for up to 19 stereo outputs. This new feature will allow me to open up to 38 mono tracks at once. I plan to create at least one new template based on this wonderful new feature! Thanks to the devs for implementing it!!

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.

I understand and probably still have my own set of progressive screen shots documenting the frustrating process. IIRC, this sounds like one of the hidden pop-ups I mentioned. Also, I think saying yes/ok to that request might also kill the residual Bandlab processes I mentioned. Glad you were able to get through it. I am adding this note in case it also helps others along with your solution sounds.

With Bandlab Assistant (not Cakewalk) I have had this kind of thing happen. Once or twice there was a small hidden dialog buried. I doubt this is the issue in every case, but I have seen it. Also, sometimes I have found that killing residual / leftover Bandlab Assistant processes in task manager will allow an update to complete itself. I also recall that even with those two "tricks," I sometimes had to download the installer manually. I have posted about these before, but my eyes are getting fuzzy and I can't look right now. IIRC one thread that has ideas from a number of people has a typo in the Topic: "Assistent." Maybe the advice in that thread will help. Sorry I can't search for the threads right now, but maybe you can find them. And maybe some of the tips will help.

I think we have here a classic example of what in General Semantics is referred to as "Bypassing." When I read this, I understood "arrangement" to refer to the way LGA arranged his [implied: own, original] melodies. When I read this, I understood "arrangement" to refer to the the song as a whole (an arrangement [implied: of someone else's material]. JMO: I don't think amiller was saying it was an arrangement as opposed to a composition, but rather that the statement was about the way the melodic material was arranged/handled/treated/etc. Sorry for the interruption. Carry on.

Out of curiosity (esp. since I might want another monitor myself one of these days), are these monitors special professional grade monitors or can I get by with a multi purpose TV that has a bunch of HDMI inputs? Also, if it's the latter (consumer-grade TV), is it best to avoid a so-called "smart" TV, or does that not affect input from an HDMI out? (Apologies if this is a bit OT since this is not explicitly a set of problem-solution diagnostic questions, but some of you seem to have knowledge about this type of technology; plus it does follow in part from the previous post's reference to future purchases.)

Thanks for reminding me of this. I can't remember when I last used it--probably in an XPSP3 environment, though evidently I did install it [v2.4 (c) 2003] on my Win 10 PC. Factory Sounds seem to have artifacts with my current settings, esp. when notes are held (independent of patches). I remember having fun with it, esp. with the colorful multi-point envelopes. I will try the "new" version and try to tweak my settings. Of course, if the artifacts remain, it might lend authenticity with the seemingly random glitchiness--maybe with mondo fx like z3ta+ fx. Its now on my list to play with some more one of these days! EDIT: I upped the sound card's ASIO latency a hair and the artifacts now seem to be gone. Still planning to route through z3ta+ fx, though for some authentic electronicky experimentalism!!! EDIT: Yup--works well for my kind of experimental music with z3ta+ mondo delay fx looper. Also, w/o the fx, it barely affects CPU on my system giving me tons of headroom for on-the-fly fx changes! Thanks for mentioning this oldie-but-goodie!!

Maybe because Win 10 is always running all kinds of things constantly to make sure it meets Win 10 specs and they have given up trying to micromanage everyone's Win 7? Just a guess.

Sorry, I am not a developer, but your issue has me wondering what your setup is. It sounds like you have more than one device. Do you have multiple drivers, too? Or is one driver attempting to route audio to more than one device? Maybe the answers are in the thread and I missed them. Also, I may have missed which device driver(s) you are using--one(s) from device manufacturers?