Ronny.G

@Fred's Gratis Scores I thank you very much for taking the test! So it seems that this issue only occurs in my specific condition and is not a generic bug (I remove the "bug" tag in my post accordingly if I can). Unfortunately I tried everything to try to solve it starting from trying to modify/check the simplest and most obvious things until reaching extreme solutions (image recovery,different CbB versions, clone the same system on virtual machine,etc...) as I wrote in my description of the problem. Nothing. I haven't worked it out in months...That's why I was happy to check (thank you again for running the small test) if it was a problem only mine or not. In case anyone had any suggestions (apart from replacing the pc...?) or if you run into my same problem let me know if you managed to figure out what the problem is or could be. Surely there must be something very strange that causes it. Also because as I could verify the SAME identical image of the disk with installed CbB, on one system generates the error on another no...I don't remember ever having a problem like this in the past. Or better in case of different processor, chipsets,cards,external peripherals,drivers, etc. for sure different behavior can happen. But in this case what it does not work properly is only the track template when you use a synth multi output (all in and out only software only)...really weird Happy to know that you solved your problem with kontakt names. Again if anyone had any suggestions or figure out what the problem is or could be please le t me know. Thanks to all

Hi, today I tried to do some experiments using the "project templates" also. I tried with one or more copies of kontakt in the same project (of course always each with its 16 stereo audio outputs set) and also adding to these additional VST synths. I couldn't recreate the problem you described. Once the various saved templates were reopened, the routing had been maintained correctly. The names displayed on the left in the column are not very indicative in kontakt since it's known that its way of calling them is not entirely optimal (I had them with some wrong names, as always, but different from yours) . usually I ignore them and I orient myself using only the names on the right of the column (1+2s, 3 + 4s, etc.), it's simpler... About my problem with the "track templates" instead the problem has always recurred even while I was experimenting with the"project templates". Example: I insert two copies of kontakt with 16out (32 tracks), check that everything is ok and save the project as a "Project template". I close CbB,reopen it and load the saved project template with the two Kontakts and all the routing it's still ok. If instead starting from the initial situation with the two kontakt 16out in the project I save one with its 16 tracks as "track template". I close CbB, reopen it and create an empty new file. I load the saved track template and is ok, but if I load this template again into the same project...the error....the first output of the second copy just inserted is set to the last of the first and the following are all translated by one number. The usual problem. Summarizing in a very simple scheme: 1-Kontakt1 / Kontakt1 1+2S 2-Kontakt1 / Kontakt1 3+4S .... 16-Kontakt1 / Kontakt1 15+16S then 1-Kontakt2 / Kontakt1 15+16S 2-Kontakt2 / Kontakt 1+2S .... 16-Kontakt2 / Kontakt 13+14S It almost seems that any saved (multi-out) track template with any vst instrument, when other VST tracks are already present in the project, can no longer identify what is the correct first output track to be inserted. And retrieves that of the VST instrument immediately above the track where it's inserted. Maybe a problem of 0 or 1 to identify it or something else? just my guess, but in fact if the track template is loaded alone in the project, it works because it has no way to go wrong. Maybe if you or even others who read this post could run the little experiment I described, probably in case there is a bug you could make the problem obvious even without using any additional VST tool (type kontakt,etc) . This is also in order to make it easier for developers to visualize the problem since the condition in which it occurs would be identical for everyone. Many thanks to all again

Hi and thanks for your reply! it could be related, it's so strange that I can say I have seen a bit of everything (besides if there is something wrong it is difficult to establish a single way in which it can mess up the output ports). It also depends on the project probably. At some point the situation gets so messed up that sometimes it's easier to close everything and start from scratch. Unfortunately if it happens when you have numerous VSTs and dozens and dozens of tracks it is a tragedy... Once out of curiosity I separated all the MIDI/audio tracks of the various VST because I really wanted to understand what had happened...I lost an hour and a half! it messed it up a lot more... The problem is that while I fixed one output port others would crash (sometimes the inputs also messed up). I had to find which VSTs became "tied" and remove and then selectively put back the situations that were incorrigible. In the end I restored without trashing the project but it was just to see what actually happened...in reality you can not miss an hour and half for this. But at the end I have this problem so it's normal that you mess it up a bit when it occurs. Nowadays then also the port routing is quite complex and I would say necessary given all the various plugins that make use of it to modify the input MIDI signals before they reach the various VST. So audio and midi routing in a DAW software must be perfect, flexible, and so on it must always work and be salvable (track template). In my opinion it's the necessary starting point on which to build something with various plugins later. But this is another matter...here for me it doesn't work even with a simple instance of Kontakt with 16 output ports if it's the second plugin I loaded as a track template. Also for me it seems that MIDI and audio channels of the VST separated or not are irrelevant. I also noticed in my Kontakt an error in "kt.3" names but in this case it could just be the fact that Kontakt doesn't expose the name correctly but most of the time the routing is correct. This problem doesn't happen to me if the track template is the first and only thing I load into an empyt project..the problem occurs later. Maybe today I will try with a project template with my vst's multiout, like you, to see if the "track templates" problem also arises in "project templates" If you have a moment of time (it really only takes a few minutes and don't require anything that it is not already included in CbB) please try to do this small test that I indicated here:

Hi to all, some time ago I had already posted a message in the thread related to update 2021.06 (since in that update some changes related to the handling of inputs/outputs had been made). I would like now however to report everything I found until now in a specific thread concerning the problem since it's now a problem that I encounter with any version (I tried until the recent 2021.11 U1). I had tried to wait in case some update solved the strange bug that I find in the allocation of vst multi outputs channels once loaded any multi-out vst track profile saved previously as a "track template". Unfortunately to date the problem is still present and is not easy to identify as I will describe later. It's incredibly annoying or better say it's a disaster. When there are many tracks I would say that it's at the limit of the impossible to use the track template function. If you decide to insert an additional multi-output VST it happens a disaster. This output assignment "shift" bug not only means you have to correct all the channels manually, but after loading the profile into the project this also causes numerous other conflicts in the outputs of the other VSTs that were previously working properly. There are VST instruments that make sounds on audio outputs of other tracks also, others that stop altogether, sometimes it also messes up the inputs. On the other hand, something is wrong and therefore probably creates problems a little everywhere on the project. Like I said before the problem its a bit weird. I have spent many days trying to isolate it in a reproducible manner, but it's not so easy because it seems to be dependent on the PC where CbB is installed (and not reproducible in virtual machines). Very strange and really I don't even understand how this could be possible, but seems so. I tried everything to understand why it happens, but I couldn't figure it out. I also reinstalled from scratch the OS and CbB (of course, before I made an hard disk image). I have not installed any drivers in windows aside from the "standard" default ones that it recognized. I also left it disconnected from the network. This for have the more clean and raw system possible and eliminate any possible conflict (obviously this is only a test). Nothing, always the usual problem of wrong inputs/outputs assignments. It doesn't depend on Windows configurations, drivers installed, devices or CbB options...but the PC (?). I have done a lot of tests with clean hard disk bare metal images, VMs and so on excluding pretty much all. But the most absurd thing is that, if after checking the problem, I do an hard disk partition image of the "real" pc system that has the problem, and load this one in a virtual machine inside it (with the limitations that this entails, of course) then the inputs/outputs are assigned in an correct way 1+2 - 3+4 - 5+6 ,etc, and not 7+8(TSS-1) - 1+2 - 3+4 - 5+6,etc like in the video. Really weird. The same exactly system image executed in the "real" machine generates the problem, in a virtual machine it doesn't. I don't really understand where the problem is but unfortunately I need it to work in the real machine...It's a bit complicated to explain all the tests I have done, so before writing a "book"? for explain all and even to keep things simple...I would like to gently ask, if you have some spare time, if you could do a simple test for check this, so I could better understand if others have this strange error too. The error appears when a track template with vst multi-out is inserted in a project (kontakt or some drums VST are good examples). However I have isolated a situation in which is visible (at least for me it is) and that should be reproducible by all, without additional VSTs (all is already included in CbB) and only in some seconds of time. Try this on new project: Insert from Track Templates-Soft Synth Track Templates - Session Drummer3-LinnDrumm Tight and warm (in case it's not installed it's normal that gives you a " missing plug-in" error, ignore it and go on (ok), it doesn't matter for this test) It should load: SD3 MIDI track input Session Drummer3 (but the first couple of ports named only "primary") 1 + 2 kick input Session Drummer3 3+4 Snare input Session Drummer3 5+6 HiHat input Session Drummer3 7+8 Toms input Session Drummer3 9+10 Overheads ALL OK! Now on a new project try this: Insert the Instrument TTS-1 ((it's important that a virtual instrument is already inserted into the project)) then add also Insert from Track Templates-Soft Synth Track Templates-Session Drummer3-LinnDrumm Tight and warm (again, in case it's not installed it's normal that gives you a " missing plug-in error, ignore it and go on (ok), it deosn''t matter for this test) It should load: input 7 + 8 TTS-1 Kick (THIS is the ERROR!) input Session Drummer3 (again the first couple of ports named only "primary") 1+2 Snare (the ports are moved by one position) input Session Drummer3 3+4 HiHat (the ports are moved by one position) input Session Drummer3 5+6 Toms (the ports are moved by one position) input Session Drummer3 7+8 Overheads (the ports are moved by one position) It happens also to you? You have to correct all the inputs stereo couples because by mistake it inserts the last one (in this example 7+8 of TTS1) of the VST instrument loaded first and then it moves all subsequent inputs stereo couples. Ignore the fact that the firts output of Session Drummer3 is named "Primary Output" and not "Session Drummer3 1" as it should, probably doesn't mean nothing for the problem. It seems only a "name" error that appears with SD3. Other VSTs like Kontakt,etc have all the correct port "name" for the first one. I upload also a small video of the problem. I hope it's clear. I tried to also upload a .gif video, however the forum always give me "-200 error" so I zipped the gif video. Animation23.gif.zip Many thanks to all for your help!

Solved in the last release 2021.06. Many thanks for your work!

Thanks for the suggestion. In fact I seemed to remember, but I was wrong, that this new conversion feature was introduced in a version before 2021.04, instead in fact it was introduced for the first time only in the latest release 2021.04. Maybe in case it will be not noticed I will make a further report in the thread of 2021.04. Thank you Posting in the thread of the "early" 2021.06, from what indicated, would be not entirely appropriate, since in that thread you have to report only specific problems of the "early" version and not of other versions. This bug is not specific to the early preview 2021.06 since it was already present in the previous one...

Hi to all, Yesterday I noticed a bug in the midi CC to/from automation envelopes conversion function that I would like to report. I tried both in the last release 2021.04 and in the latest "early" 2021.06. If the values are of pitch wheel type, there are two distinct (or maybe there's a connection between the two, I don't know...) bugs depending on whether the transformation is performed from envelope to MIDI CC or from MIDI CC to envelope. 1) Automation envelope to MIDI CC: There is probably an error with ( + / - ) in the code of the conversion function because the result is this strange curve. 2) Midi CC to envelope: The peak value never reaches the maximum (+8192) in this case but there is a strange "beveling" on the tip. With other type of midi CC's the conversion function is correct. It's the pitch wheel values that generate problems, probably for the -8192 / + 8192 range of values. I hope that this bug report can be useful in finding the error. It seems to occur only in the presence of values of type pitch wheel in this very useful conversion function that has been recently introduced. The addition of this conversion function has actually proved a lot for me. Be able to visually work with the CC values directly under the midi track (using all the shaping functions available for envelopes) while still retaining the possibility of convert them to the piano roll view. Really useful! Many thanks to all

Hi, the problem seems solved to me in the last beta release. I have run some test and now the midi routing is saved correctly in the track template. Thanks again for your work on this!

@msmcleod I am very happy with the news!? Thanks to the entire development team for taking care of the bug. For now, as you write, I will no longer use the track template function at all just to be sure ? so as to wait for the release of the fix and see if the problem is solved. I will report here. Then I will start create again new templates, just to be sure to not mix for error those that have midi routing with the "normal" ones, starting from scratch. Many thanks again for your and the entire development team, interest and work on fix this annoying bug

Unfortunately today the bug has also manifested itself with CbB and a project opened. So it can also occur under these conditions unfortunately. I was doing some tests on a project using virtual synths. With a project opened at some point I lost the sound coming from a plugin with a previously working midi routing properly set. I checked then to understand the cause and the midi inputs were suddenly all wrong! Probably when I loaded an additional virtual synth (and enabled its midi output) in the project, by mistake, CbB also modified the other MIDI inputs previously set on other tracks. Unfortunately, as usually happens when the bug occurs, it was impossible to manually change the midi inputs set in the individual tracks for MIDI routing and restore the pre-existing situation. Once in fact this bug occurs, it seems that CbB no longer allows any changes to the MIDI inputs in the tracks, and therefore despite trying to reset the correct midi inputs these are no longer accepted (or at the limit even if accepted, in fact, checking immediately after, you find yourself with random settings...). I had no choice but to trash the project and start all over again, trying to transfer all the changes already made in the tracks (synths, midi routing, aux, bus, sidechain, etc.) in addition to the MIDI recordings already made. What a waste of time...and even worse, just when I had had a couple of ideas and was trying to record them... Almost certainly it's always the same bug that occurs in various situations. It's not about "external" MIDI peripherals (even with these there is a problem, but it is caused by a different problem from what I understand) but it concerns the enumeration and management of midi inputs and outputs of virtual instruments by CbB. In different situations they are not maintained (now I know...even with open program and project). Obviously if this bug creates problems also to you, please post your experiences and maybe even some small videos, so that they can also be of help to the developers to better understand and solve this bug. I don't think I'm doing any particular operation, I'm just trying to insert and manage virtual instruments that also have midi outputs to insert into other virtual instruments. I hope I'm not the only one who gets into trouble with this bug. I think it should also cause problems for many others. Without making a precise list of the many synths that have MIDI outputs. there 's plenty of them. Strange that there are not many reports, probably a different workflow. Thanks to everyone

Hi to all and thanks for your replies. The small video I uploaded allows you to recreate the bug if you perform the same steps as shown. So there is a way to recreate always the bug, at least in this case. This was also confirmed by others who kindly performed the same test. Unfortunately from what I understand there are two "macro versions" of this problem with MIDI inputs. The first "version" concerns external MIDI peripherals connected to the system at the time of saving the project. This trouble also depends on how Windows handles USB peripherals. If the connection order is subsequently changed for some reason (e.g. the physical port to which the MIDI device its connected is changed, or isn't connected at all ) this confuses CbB that it is not able to assign the same "numbers" to the MIDI connected devices again. The second " version" the one I indicated in this thread concerns instead the "virtual" MIDI peripherals (example VST) that are inserted in the project. These can also have MIDI inputs and outputs like physical peripherals. Unfortunately when you save a track template after configuring routing with virtual synths that have MIDI inputs and outputs, this is not maintained once you reload the saved track template. And this is a CbB bug. It does not depend on external factors since it occurs with CbB open, without changing anything in the connections of any external devices that could affect the "virtual" ones. However I think it's clearly visible from the small video of the bug I posted. I read your interesting and detailed post (many thanks), hard to tell if there is a link or not with what I reported. It is probably the management of MIDI inputs and outputs by CbB that should be checked in general because there are several problems. However, my message only concerns a bug in the presence of VST instruments and track templates so it is limited to a specific problem. It seems to me your case falls more into the first "version" of the problem and then it's about the link order (or lack of these...) of external physical MIDI peripherals that were connected at the time of saving. Unfortunately I also have regulary the same problem reported by you. As a small tip, Since from what I've seen it looks like you only have external peripherals, you tried saving your inputs using "presets" and "Manage presets" in the INPUT menu and then calling up and using these saved presets to manage external peripherals instead of selecting them directly in the menu? You can create presets for MIDI inputs "external" and from what I noticed it seems that in this way you can in many cases bypass the problem. If you have time, give it a try.

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.

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

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"

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.

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