Ronny.G

I would rather report that the bug is still present in the latest release 175. It's really annoying since it makes practically impossible to save specific track templates with MIDI routing configurations between virtual instruments. Among other things in some cases I could not even reuse the saving of the entire project because in a couple of cases even this once reopened had lost the routing set (and I had not modified anything connected to the pc). However, returning to the track templates and the bug, without being able to have a working (and reusable) midi routing between various VST, you can not "create" a reausable chain to be able to modify or alter the input MIDI data with numerous plugins whose purpose is to alter the input MIDI data (arpeggiators, CC modifiers, curves, note substitutions, etc). Without being able to save anything, it's necessary every time to recreate all the route...maybe if you have a couple of tracks it will be feasible but when there are numerous tracks it's impractical to recreate the whole configuration in the project from scratch every time. I really hope this bug is fixable as soon as possible. At the moment many times I'm forced to give up the use of CbB (with great regret...) precisely because of this annoying bug. Although the bug has already been confirmed and we are waiting for a solution I invite anyone who has a moment of time and wants to try to perform also some tests to realize the problem. I obviously take the opportunity to thank everyone who works every day to make CbB a more complete and wonderful product (articulation maps and arranger have been great additions). THANK YOU!

Thank you! The problem with track templates as I have highlighted arises without changing anything. It already occurs with the CbB open, saving the desired configuration as a template, deleting everything and reload the newly saved template. I would also like to take this opportunity to point out a message that I wrote in the feedback specific thread for the last 2021.04 update, because it concerns the management of midi inputs and outputs of virtual instruments. The latest update introduced a change in the UI "MIDI Ports from synths should not be exposed to their own inputs". This is certainly useful in many cases but it can also be a limitation in others and so I asked there, explaining the reasons, if it was possible to have a selection option somewhere to make a choice about it. Thank again to everyone, users and support team for your help and work.

You could introduce an option to disable this behavior introduced with the last update and return, if desired, as it was before? There are cases where for speed or convenience it's easier to act for example on modulation and pitch wheels or even other particular controls of the VST synth that are exposed as midi out directly acting on the wheels, buttons or other within this and record them as midi events, without necessarily having them assigned to an external MIDI controller or create an additional MIDI track (useless) in CbB just to get around the limitation of not being able to activate the VST midi output on their own inputs and record these, as it was possible before the change. Many thanks you for your support

I totally agree with what you say. I also don't always have all the external MIDI peripherals turned on when I edit a project and so also happen to me every now and then to have to reassign correctly the external peripherals and it's annoying. Maybe something could be done about this, too. If technically possible (there are probably also the limitations related to windows and USB specs, as bvideo explained (thanks) but there should be a way to manage the presence or not of a connected external device during the following project saves without having problems. Perhaps also add an alert when the project is opened again to highlight the lack of the device and ask or suggest a reassignment (perhaps taking advantage of the MIDI custom names already present in CbB). But a specific post should be opened about this, probably some connection between these problems could exist, since they always concern the management and saving of MIDI inputs and outputs (physical and virtual) by CbB but I highlighted a different problem in this post. The bug that I have reported here in this post already happens when CbB program it's open and therefore without connecting or disconnecting something (or changing USB port on pc). I really hope that the development team can understand the problem and fix it because it's very annoying. It already takes time to properly config track templates that are useful. It is obviously hoped that in doing so it will save time later by recalling them, but at the moment in the conditions I have highlighted this is not possible.

It happens if I save them as a track template when I open again the track template saved to restore it with its assigned midi input and output. This could be a related problem. In this case, from what I understanded, it should happen because every time CbB it’s started it assigns a “number” to connected external midi devices that recognizes, if one was connected when you saved the project but the moment you reopen CbB and the project is not connected, this could give problems. For example the midi device “”number 2” become “number 1” because your “number 1” device isn’t connected and that's already in itself a problem. Add to this that even if the USB devices are both connected you should always check that they are connected to exactly the same port in the pc I thought so too, unfortunately it happens also if I don’t use simple instruments tracks and I insert separate audio/midi tracks and then I set up them as needed. Same problem. I've made several attempts, simple instruments, manually, starting from the synth rack… I can also create and save templates like yours and they works but have you done some internal midi routing between them as for example I showed in the animated gif, saved and restored the template? It's a different thing. If you only assign the various VST instruments to the tracks and save a template for later, it works. The problem is the saved internal routing of virtual instruments midi input and output between the tracks that is not kept. Thank you very much for finding time to give it a try! Really appreciate It doesn't matter which plugin you use. If you see I also inserted a virtual "external MIDI device" as primary input device, precisely because doing so this variable is also eliminated. I could connect a USB keyboard or any other external physical MIDI device and nothing changes. The problem there's anyway. In fact, I noticed the problem because I was trying to set up a physical external MIDI device with CbB... And if you have done some tests you have noticed that it is even worse, try to change the ports that have been incorrectly enabled when the bug screwed them and you get out crazy, they reappear even after you remove them. You have to delete all the VST and restart. I chose to use these in my example because being small and freeware allow everyone and maybe the support team to quickly do reproducible experiments similar to what I (and now you…) have done. I didn't even notice any differences between VST2 or 3 or a mix between the two. Auto Echo On or off in CbB settings.The problem always arises. Maybe in a slightly different way. Because as others have pointed out in the past it comes in slightly different forms but I think the basic problem is always the same What could be interesting will be if the virtual midi ports exposed by the various VST instruments (after obviously enabling the midi output on them) could be saved as “midi input presets” like it is possible now for the external ones (physical or virtual). However CbB at the moment doesn’t allow this. I hope that the CbB developer team can do something to fix this bug. There are many VST's that now generate outgoing midi signals for the most diverse purposes, notes, arpeggiators, midi converters and filters and generators of all kinds, and you should be able to save a template with the configuration you need. Which is actually what the track template should allow if there wasn't this bug. Many thanks to all of you for your interest in this problem.Greetz Ronnie

Many thanks. I have now created a new bug report post in the main forum. I can't delete however this one that can now be removed. Thanks again

Hi to all, I would like to report a bug. The bug is related to midi input routing save. As you know, this is a problem that has been present for years, I have noticed in fact that users over time have repeatedly highlighted the problem in different forms and conditions. I don't know why it is still present, I think that when you route some virtual synth it is important to not have to redone again the routing work everytime (...when you can...in many cases you have to delete and load again all the virtual synths because it is impossible to delete anymore the "wrong" midi inputs added) There have been several attempts to explain the problem (modification in connected midi devices of the active device type at the time of saving and later not connected at the time of reopening the project or connected to a different USB port) or to at least limit the bug. But in reality unfortunately the bug does not depend only on the connected peripherals or not...it seems most related with virtual synth input ports. I was hoping that with the last early update, since a change had been inserted in the management of the midi ports of virtual synths, had been fixed but unfortunately this was not the case. I tried through this short video to highlight the center of the bug by simplifying it. In fact, the situation is much worse. In fact, the more complex the midi routing, the more the problem arises, with the usual randomly modified midi inputs (double, triple, all active, none...). In several cases it is not even possible to correct the problem of inputs that always remain active and you have to delete all the uploaded virtual synths and start from scratch, thus doing all the configuration again! For some it simply shows up after saving and reopening the project. In my case if the file is saved and then reopened the input midi channel assignments "seem" to be correct. But I would say that it is only luck, because every now and then the bug also occurs to me as to many others even just reopening a previously saved project. Actually as this video highlights, the bug occurs regardless of the subsequent closure and reopening of CbB under different conditions. Instead if I save the input settings of the various synths such as track settings, delete the tracks and restore the track settings save (without obviously closing CbB) the bug instantly appears as you can see. Unfortunately, this bug has been and remains somewhat annoying. You waste a lot of time reopening or editing tracks to reconfigure everything! I would therefore kindly like to ask you whether you can check what the problem is and solve it once and for all. I am sure that would certainly make so many users happy as the bug has been present for years. From my point of view, routing and managing audio and midi tracks (in this case) is a major feature in a DAW. It is the basis from which to carry out any work. It has to work and certainly once a template is configured the routing (sometimes it can also be quite complex with the various VSTs) should stay. If every time the saves made are not kept and everything has to be redone it becomes... Many thanks for your work and time Ronny

...vultures arriving on free products that begin to have an interesting user base trying to take a profit from this (with the usual scheme that even children now know..), having practically done very little beyond adding some options here and there... Good luck with your "job"

I post the message here since the bug is present in the latest update released, even if the problem has been present for years... The bug is related to saving midi input routing. As you know, this is a problem that has been present for years, in fact users over time have repeatedly highlighted the problem in different forms and conditions. There have been several attempts to explain the problem (modification in connected midi devices of the active device type at the time of saving and later not connected at the time of reopening the project or connected to a different USB port) or to at least limit the bug. But in reality unfortunately the bug does not depend only on the connected peripherals or not... I was hoping that with the last update, since a change had been inserted in the management of the midi ports of virtual synths, had been fixed but unfortunately this was not the case. I tried through this short video to highlight the center of the bug by simplifying it. In fact, the situation is much worse. In fact, the more complex the midi routing, the more the problem arises, with the usual randomly modified midi inputs (double, triple, all active, none...). In several cases it is not even possible to correct the problem of inputs that always remain active and you have to delete all the uploaded virtual synths and start from scratch, thus doing all the configuration again! For some it simply shows up after saving and reopening the project. In my case if the file is saved and then reopened the input midi channel assignments "seem" to be correct. But I would say that it is only luck, because every now and then the bug also occurs to me as to many others even just reopening a previously saved project. Actually as this video highlights, the bug occurs regardless of the subsequent closure and reopening of CbB under different conditions. Instead if I save the input settings of the various synths such as track settings, delete the tracks and restore the track settings save (without obviously closing CbB) the bug instantly appears as you can see. Unfortunately, this bug has been and remains somewhat annoying. You waste a lot of time reopening or editing tracks to reconfigure everything! I would therefore kindly like to ask you whether you can check what the problem is and solve it once and for all. I am sure that would certainly make so many users happy as the bug has been present for years. From my point of view, routing and managing audio and midi tracks (in this case) is a major feature in a DAW. It is the basis from which to carry out any work. It has to work and certainly once a template is configured the routing (sometimes it can also be quite complex with the various VSTs) should stay. If every time the saves made are not kept and everything has to be redone it becomes... Many thanks for your work and time Ronny

Hi Heinz (Bassman), there isn't a programmers manual only infos shared on the web Since this is Q&A subforum check PM's. Maybe we can create a new thread on another section of this forum to discuss what can be done for a better ATOM integration with CbB Thanks

Have you done some progress with lights? I think that probably to control its lights it will be necessary to put the ATOM in the NATIVE mode (blue logo) and not MIDI mode (green logo). Also the NATIVE mode, that it's the default mode when the ATOM is used paired with Studio One (and now also officially with Ableton live), will be better also for doing some interesting things using the wonderful AZ Controller. This because the NATIVE mode, from what I have read, put the ATOM in a state where it can also RECEIVE midi data and not only send them. A sort of slave integration. In fact Bitwig also now support the ATOM and Reaper too thanks to the fantastic research and development work carried out by some users. The possibility to connect the ATOM in NATIVE mode is the first step for a near perfect integration with CbB using the wonderful AZ Controller. It became possible to do lot of interesting things, some cosmetics like control button or the PADs RGB lights color states, and some more important. The ATOM in fact behaves differently when in NATIVE. Among other things, for example, all messages are sent on the same midi channel, there is a few more buttons that can be used, and the button status is also different (most of them momentary). In addition, from what I understand, rotary encoders also behave differently between the two modes. So in general, it should be better to be in native mode if possible. In fact, the "works" done for example to integrate it with Reaper are all based by putting the ATOM first in this mode. And for change mode it seems that is necessary to send a midi message that contains these values: ATOM MIDI MODE = Note off, channel=15 (or 16?), note=0, velocity=0 ATOM MIDI NATIVE CONTROL MODE = Note off, channel=15 (or 16?), note=0, velocity=127 I'm not sure about the channel 15 or 16 because the "works" already on the net about the ATOM indicate two different channels, some tests should be done... Do you know if it's possible to add something that can send this simple midi message to the ATOM at the start of Cakewalk in order to put the card in NATIVE mode and again return in MIDI mode when Cakewalk will be closed? I mean something like Autohotkey but integrated inside Cakewalk (needs to search if the ATOM is connected), maybe a CAL script (I doubt) or maybe something that can be invoked through a .ini (but that can also work when the program is closed...) I think that find a simple trick to change mode should be a good starting point, then maybe using the lot of researches already done for other programs try to add the remaining functions using the AZ control (one for for all activate the rotary encoders that in midi mode are endless). If someone have done some more work on this external pad controller and CbB please reply to this thread. Many thanks to all!

Hi, in the media browser, you can preview MIDI files before you import them into the project. These can be auditioned through any soft synth and the Synth Preview Output submenu lets you select the soft synth for previewing MIDI files, however: it's not possible to select also the midi channel that you want to use in the soft synth that you have selected for previewing the MIDI file So I would like to gently ask if it's possible to consider to add this possibility too. When you use a multichannel soft synth instrument (most common one Kontakt for example) it will be very useful to have the possibility to select also what midi channel to use for previewing, or you are "blocked" on midi channel 1 and the instrument loaded into. Many thanks for your time

Hi to all, given that a different use of this function will probably be made depending on both the type of music that is being composed and the instrument with which the chord will be played, I would suggest that in any way the function is implemented, the maximum possibility of customizing the database of chords by the user (in any way that is technically possible) was always taken into account. First of all doing so, even if there was no particular chord or inversion of it, each person could add it manually. That would be really important: maximum ability to add custom chords! Sometimes, in fact, it's really necessary to make use of particular combinations. Example, add the bass note to the chord, many times even two bass notes at the same time. Or when working with strings section (or brass) it is very common to reverse the chords in a particular way, add a bass note, perhaps even repeating the chord twice with both hands, etc.. In short, sometimes "simple" chords are not enough and even during sketching, it will be very useful to have "ready" these particular combinations too. If there is a customization option, every user can add to the base chord category (let's assume Cm) every variation he would like to have ready to use (with bass, inversions, ten or more fingers :-)) Too many times I have been faced with small programs that were supposed to serve to simplify the process of inserting chords, but which in the end (for me) were not very useful precisely because of some limitations: one does not have inversions or has too few, lacks chords, lacks the possibility of adding the bass note (or notes) ... in short, something was always missing. If you find a way to leave the option to add new custom chords into any combination (adding or remove/move the 3rd, 5th, a particular inversion, a low note, two, etc...), anyone can better customize the function for the use it needs to make of it. Thank you all and I hope I have explained clearly what I meant.

Thanks for adding the articulation maps in the new 2020.11 release! I think it's one of the most important upgrades that have ever been done (for me but I think I'm not alone...). I can't wait to try it! It also represents, in my opinion, a right step in the direction of not only imitate Ableton and its numerous clones in simple "drag and drop block" composing. Don't get me wrong, even "blocks" composing tools are useful I know, but for other tasks there is need of also different tools that are more useful in orchestral composing, like this long awaited one. As far as I am concerned, this awaited update is a very good step in the right direction for Cakewalk. Try to continue to be also a more advanced DAW useful also for orchestral composition (read Cubase...). Sum the best of "both worlds" in making music! Keep it up! and thanks again for your work to improve cakewalk!

probably yes but there is also the port to be sent not only the channel, all two are ignored.... or maybe, like I have suggested, a selector switch in the drum map manager panel that can switch the behaviour between "omni" and "per port and channel". So if someone prefers, like Mark said, that the controller be sent to every port/channel in the drum map (as a single destination so that all units can respond to controller) this can be done but if someone (like me...) needs to have a "per port and channel" correct routing even this can also be selected as an option. this would not work anyway because the problem is that the "for port/channel" assignments are not "retransmitted" as they are inserted in the drum map manager but they are "altered" and replaced with and "omni channel mode" (also "omni port port mode"). This is the behaviour at the moment for the drum map manager. From my point of view it's a bug. The drum map function with its virtual ports is an additional layer between what is received inbound and what is sent outgoing, if there is an option, as there is, to assign each note a midi channel and a port these should also be transmitted in the same way as entered. Just my opinion

Hi Mark, I understand and thank you again for the explanation. Actually there may be cases where sending the same signal to all channels can be useful, unfortunately it's not my case and as you say I'm in exactly the opposite situation. My previous message was more to clarify that according to MIDI specifications (1.0), CC messages are transmitted per channel, and therefore "normally" you can send different CC messages in each of the 16 channels. If you do not use a drum map in fact everything works properly as it should (if not also the forum would be full of people with problems everyday with multichannel virtual synths like kontakt...) Rightly as the user David also mentioned CC messages are not transmitted per note but this is another matter. In a drum map there are notes, yes but there are also midi channels and normally CC messages should be trasmitted per channel (and in the configuration panel of drum map manager there are midi channels and ports specified for each note). The current behaviour of the drum map, as you kindly confirmed after also testing my little sample file, is to sends the CC messages to all combinations of ports and channels defined in the drum map, that's why I had started to consider this issue as a borderline situation between a "limitation" and a bug. Normally they should be trasmitted per channel but using "virtual ports" in a drum map they are no longer trasmitted per channel. Unfortunately for my case that's actually the behaviour of the drum map function. Maybe as I suggested a few posts above it could be very useful if developers could look again into the function and think some change to remove this "limitation" behaviour to the drum map so as I already said before it can best express its potential. Perhaps by adding an "omni" or "per channel and port" behaviour selector. Just a suggestion based on the problem I've encountered in using this feature. Many thanks again

I had probably mistakenly assumed, seeing the drum manager configuration panel with notes/output ports/midi channels matrix, and reading what it is written on the manual, that among other purposes the creation of a drum map by the drum map manager using this matrix also served to "virtually" create this association and therefore also the limitation caused by MIDI specifications about CC's and note number could be overcome, also considering that in my example every note have its dedicated midi channel (and when necessary port but that is another story...). Even if I have a simple drum map with 16 notes on 16 different midi channels the CC's don't route correctly. I think they should and in fact if I don't use the drum map they are routed correctly....I have lost something?

Hi Mark, and thanks for your work. Now that I know that there is this "limitation" in the drum map function I start to better understand why using that in combination with the step sequencer or the drum grid and CC's causes these problems. Unfortunately, this limitation has become apparent because, also according to the manual, the step sequencer is ideally suited for drum programming...so I have tried to use it and the drum map together for a more complex situation. Let's consider this drum programming scenario with a multichannel virtual synth, TTS-1 (or kontakt in my case but this is irrilevant, the problem is the same) and always considering the need to use CC's. A large library of percussion sounds, so there are many instrument patches (big drums, snares, pitched, fx, ensemble, solo and so on) and I would like to create a "selection" from them to have fast access to the sounds during the sequence creation. I can load one instance of kontakt and fill it with 16 different instrument patches and use it with the step sequencer ALONE on one midi track. All is fine, even if doing so I lose the chance to save a drum map for this configuration for later use because if I create a drum map I can't use anymore the CC's messages. But there is the big problem...let's say that I would like to have 20 different instrument patches at my disposal (it can happen with large libraries) The options are: 1) Load another instance of kontakt with only the four more instruments. However it is impossible to add this second instance of kontakt on the same midi track with the step sequencer created before (even if this new instance is listed in the row menu if I try to also use it, cakewalk crash, probably port conflict and seems logical as there isn't any "virtual ports" in use). So I have to create another midi track with only these four more instruments...a bit uncomfortable and not as immediate as having them all in the same panel. 2) Create a drum map and group the two instances but there is the "limitation" of CC's not routed. So there is no solution, I can only have 16 instruments at my disposal on one midi track/step sequencer (and I can't even save a drum map for it if I need to use CC's). If the drum maps and their virtual ports could do the CC's routing (how logical it seemed to me to think) you could first save a map for later use and also and more important get over the MIDI 16 channels limit easily. Maybe this problem, that is in a borderline situation between a bug and a limit, can become a suggestion for a feature change/addition. I think it could be very useful to remove this "limitation" to the drum map manager so that it can best express its potential! Thanks again for your time and interest in my problem

@msmcleod - I wanted to kindly ask if the project I sent has already been examined and if the bug has been confirmed. Many thanks again

Thanks Mark! sent message...

yesterday I carried out several further tests to try to identify which function is responsible for the problem (the drum map or the step sequncer?) . After these tests that unfortunately made me waste a lot of time, to me it turns out that the function responsible for the problem is the drum map. The drum map that is created using the drum map manager simply doesn't work, the assigned ports and channels are simply ignored in the case of CCs being sent. Using, for example, other tools to check the messages trasmitted it clearly shows that, when using a drum map, CC data are always sent to the "first" saved channel on the drum map even if it is not used and CC are assigned to another channel! Also ports are ignored, not only midi channels, if you have two ports that use the same midi channel (that is correct in the purpouse of create a custom drum kit from several MIDI devices, that can use the same midi channel but are on different ports) the same CC message is transmitted on both even if you want to send it to only one port! and so on...at the end of the matter the functionality is broken. If you use the step sequencer without creating a drum map, which is not very easy to do because even in this case small bugs (temporarily solvable) pop up when assigning tools and channels, the routing of CC's seems correct. As soon as you create the drum map... disaster! Of course it's practically useless to use the step sequencer (or drum grid) without a drum map but at least you can understand that the problem is in the drum map and its virtual ports. What can be done to elevate this problem as bug and so be fixed in the next release? if someone, like kindly User 905133 did, could also do some small tests in order to confirm the bug I think it could be useful in order to elevate the problem to "bug". Many thanks to all

Probably yes, I think that is the same problem. It become evident more or less in every situation where the drum map virtual ports are used and CC's assigned to different channels. Like I said before (I have edited my post later) the bug is already visible if you even have only ONE instance of a softsynth (TTS-1, Kontakt, don't matter) loaded with two instruments assigned obviously to two different MIDI channels. After the configuration of the two drum map notes (1 port / 1 synth out / 2 MIDI Channels) try to add some CC's message on one row of the drum map grid or the step sequencer and this CC message (in our example CC10:Pan) will be sent to ALL MIDI channels and so ignoring the channels assignement. The entire controllers pane function of the drum grid or step sequencer for me is unusable at this state as the drum map don't "route" correctly from the virtual ports to the the "real" ones assigned. If I have to create a separate MIDI track for each drum sound when I have to use CC's, what's the point of having this controller pane on drum grid or step sequencer? also this defeat the purpouse of the drum maps... What I find strange is that a bug evident like this (I presume it's a bug) didn't had noticed before. No one tried for example to send a different pan CC or another CC message to two different drum sound on two different midi channels using drum grid or step sequencer using the drum maps virtual ports before? very strange

Hi to all, I have a strange problem with the step sequencer, in the manual there is written: I have streamlined the "case" for a better understanding of the problem itself with only two instances of TTS-1 Synth on two different ports with the standard drumset loaded on midi channel 1 and a midi track on the project. Port 1/Channel 1 - TTS-1 Synth - 15360 Preset Rhythm - Standard Set Port 2/Channel 1 - TTS-1 Synth - 15360 Preset Rhythm - Standard Set Drum map manager (example): (56) Cowbell - channel 1 - Out port Cakewalk TTS-1 1 (50) High Tom - channel 1 - Out Port Cakewalk TTS-1 2 Step sequencer: on first row Cowbell (56) - Out port Cakewalk TTS-1 1 - channel 1 on second row High Tom (50) - Out port Cakewalk TTS-1 2 - channel 1 I create a basic sequence on the first row (cowbell) adding also using the controller pane a CC10:Pan message, however if I play the sequence the CC10:Pan from Cowbell is applied also on High Tom that is on another port and instance of the TTS-1 synth in drum map manager (even the midi share led indicate this, however they are on different ports...) UPDATE: I have tested again today (also changed CbB version) and for me the bug with step sequencer is even worse... it happens also even with only one instance of a virtual synth (I have tested with Kontakt) loaded with two different instruments, so 1 port and 2 different midi channels. Drum map configured. If I apply a controller pane message like CC10:Pan only to the first row instrument it is applied also to the second row instrument. In my case in Kontakt I can see the two instruments pan sliders that are moving together...it seems to me that the midi channel is ignored like an "Omni mode" for the control change messages. Definitely there is something that doesn't work correctly. I have done a lot of test but I still haven't understand why this happens? a bug or I have not understand something? You have seen this problem before? Many thanks to all for your help

Thank you for your help Heinz and James

Hi, I'm trying to write chords progressions directly in CbB and I found a reference about this script in the old forum...however the cakewalkproaudio Yahoo group is gone. I would like to try this CAL script that will create chords (including strumming). Someone still have this script? Many thanks to all