user905133

I don't use the PRV. I tend to use the Event List to examine suspected issues with MIDI. However, from your description you could problem-solve this by looking at the track headers to make sure each midi track is playing (pointing to) its own soft synth. This assumes you are using different tracks (as opposed to putting the midi data in one track). Please note: I left out steps on how to do this assuming you know where and how to set the midi track widgets.

I did the following artwork a couple of days ago, but thought I was overthinking your issue--surely others here will be able to help problem-solve the issue without complicated images. So, for what it's worth, here it is. I still have no idea from the discussion where you see sound and where you don't. BTW, there are other places to see sound, such as on track meters, but those should be reflected in the Console. Hope this helps. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Not sure this will help, but I was inspired by your situation to do a little artwork. I had no idea what " . . . they played but there was NO SOUND from my computer . . . " means. If they played, to me there should have been sound and the audio path should have shown a visual representation of the sound at several points along the chain.

This might help--scroll down to the section describing a recent Feature Overview on Workspaces.

I agree!! As chuckebaby said, they are very powerful! Also, another self-teaching exercise: Try creating a custom Workspace for a specific task. For example, I created Workspaces that work for me to enter note data by a usb keyboard and edit it mainly in the Staff view and Event List. I created another set of Workspaces for dropping in old audio tapes, listening to them, and marking them for later editing. We all have different preferences and workflows and it helps me to stay focused when I have just the GUI elements I need where I want them and with preferred sizes.

Also, as a self teaching exercise, try creating a minimal Workspace. I learned a lot by creating one I call "NO VIEWS." Very important lesson I learned this way: If something is excluded from a Workspace (and therefore, it is not to be found in the menu system), the related functions will also not be in the Workspace. This includes things like short-cuts. PS: This is why if I find a function not working, some of the first things I do are (1) look at the Workspace and (2) test by switching to other Workspaces. For me, this is an early step in diagnosing issues related to functionality.

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