JnTuneTech

Yes - @A Tolerable Quietude if it was just about creating drum note mapping, I would totally agree - and am also glad to not really need learning all the fiddling it takes to make a full .ins file for an external MIDI device. You aren't wrong about any of that! Instrument Definitions, and Drum Maps are similar, but with different primary goals. And in fact, they both will work together great with external hardware. And both choices are fine. They both can take a lot of time to set up too! -But when done, they sure can be a helpful tool. I guess I got carried away, and should have said this 1st @Starship Krupa - my bad. -So, bypassing all the heavy (and for your case - useless) .ins file formatting, you can simply add custom note maps to the Master.ins file on your system at any time (again safest while the DAW is not running!) And then, use them to help speed putting notes in on the PRV - assigned to any synth, virtual or otherwise. -As an example, I made up a silly one this morning, and here is a screen cap of the result: -BTW - @Starship Krupa the General MIDI Drums (GM) note names are already in the default Cakewalk .ins choices. (-I prefer to use the Roland GS Standard Set for GM drums though, it has a wider range of common percussion and still matches the basic GM set) -We all can assign those at any time, right-click the notes-keyboard in the PRV on the MIDI track you want to change. Anyway, it's all about workflow, and your choices are whatever is right for you. -For me-, a Cakewalk MIDI Drum Map is for when I want to route each MIDI note to a destination, or actually multiple destinations, from one track. -When I want to just name a MIDI track note assignment, I use a section in the Master.ins file, or multiple sections if I want. That's as deep as I guess I should have gone with to start my comments in this post - sorry about that! I guess I was also assuming the average reader would not be so likely to edit a basically hidden configuration file, and so was attempting to advise how to make a basic .ins file that could be imported through the documented methods in the approved Cakewalk information flow. Again - I digress! Sorry to clutter the excellent original post so much!!

-Here is some info on a current VST3-based solution for Dolby Atmos, that could likely be used from within Cakewalk: (via KVR) Fiedler Audio announces Dolby Atmos Composer and Dolby Atmos Composer Essential -Of course, it's not free, but none of the nascent "hot" commercial formats for AV ever is. -And if Apple is involved, or even interested, -good luck!

OK - getting a little bit better on the examples, all while I am adding some new drum synth default mappings and re-learning the .ins formatting that works for me. So - in my initial simple example (above, and posted more completely in the Instrument Definitions sub-category here, I left things out on purpose. But I want to show a more clearly structured piece, so anyone reading can get it working a bit more completely. In the example (above), for ".Patch Names", -I have updated it a bit. ---------------- .Patch Names [RME TMix MCP] 0=RME TMix Ctrl In ----------------- -This helps CbB use the file a bit better, -as long as you match the bottom section of the .ins file, like in this screen cap: Now, I don't particularly use all of what this does, but if you are experimenting, it helps illustrate the structure better. When you select a MIDI output - which you have already mapped in Preferences, The Instrument Definition [Name] is used in the MIDI Channel dialog. The bank [Name] listed in .Patch Names & referenced in the bottom section, is what is available then in the Bank= dialog. Then, you can also select the patch name(s) you entered under the bank name... and it all then points the PRV note view to the note names you defined & reference. -This again only helps if you are using the output section of a MIDI track set to one that is a pre-defined mapped output. -In order to use just the note map (as I mostly do), it's really just easiest to change the PRV note view preference, on any track (but usually one pointed to the VST it applies to!) manually - and it nicely sticks with the project when it is saved. -I think that change happened in early CbB updates. -Works very nicely for me! -I missed a "0" first time around - only stopped automatic mapping to the PRV notes, but hey!

Yes - it is a helpful method. -Not quite the feature that is being described by the OP though. Great info - option to be sure, I will add this info to my toolbox! So far, I only recall (no pun intended) using that feature once some time ago, but since my live input status needed to change on a track, it didn't seem to do what I needed back then.

I definitely agree with @Andres Medina - that type of feature should be presented in the feedback loop as a feature request. @jegenes - In reading your scenario, I can see it really could be more helpful to the creative process you use - recording raw audio tracks first, and then to be able to copy the mix properties from other projects easily. I would like to do that too, rather than having to pick a mixing format first (before recording), or of course building it all up each time. -Nice!

Thanks for posting the topic @Starship Krupa - in fact, I just got fired up more by it now - and found some note number-to-names data that I can extract easily, from a different DAW mapping someone created, and copy right into my missing note number sections for some Abbey Road kit patches I use a lot... Oh, it's still a lot of copy-paste, but afterwards I can program drums so much easier in the Cakewalk PRV! All I can say is -Keep at it!

So, - I (temporarily) gave up trying to find "legitimate" (or smarter than me) source links for what I had used to edit & create instrument definitions, years ago, but here's a simple starter you can try first, and hopefully also start learning more ourselves! -And, I noticed I had a few errors in some of my past complicated ones, that didn't show up in the ways I normally use them, so I'm planning on using this topic as a reminder to clean those up anyway! I am going to use a trimmed version of the basic RME TotalMix .ins file I posted the other day for this. -As I recall, these were the minimum lines that it needed to be, at the time, for Cakewalk to recognize the file and allow me to import it. It only helps change the view in the PRV when desired, mainly. -Other available options may be discussed later. Perhaps this can help you create a basic map for your own drum or other instrument using this option. First - if you want to try it, backup your current Master.ins file. Just in case. -I've never had anything major happen to anything else doing these, and they are easily removed, but still, just back up before you experiment, just in case. And, never change that file manually with CbB running. Here is the plain text for the example - I would advise copying & pasting it into a text editor, to make sure no Web or browser formatting gets added. Start copy after this line (there is one blank line): ; ---------------------------------------------------------------------- .Patch Names [RME TMix MCP] ; ---------------------------------------------------------------------- .Note Names [RME TotalMix Ctrl] 16=Mute f1 17=Mute f2 18=Mute f3 ; ---------------------------------------------------------------------- .Controller Names [RME TMix Control] 16=Pan1 (L65, R1) 17=Pan2 (L65, R1) 18=Pan3 (L65, R1) ; ---------------------------------------------------------------------- .Instrument Definitions [RME TotalMix Ctrl] Control=RME TMix Control Patch[*]=RME TMix MCP Key[*,*]=RME TotalMix Ctrl End copy before this line. -Hopefully this text isn't against any forum rules. -In any case, you can use the text above as a template. Just change the names & numbers to suit your test. Then, you can remove the test instrument definitions afterwards if you want. -OK. So, going down the filled -in file sections, from the top: In the example, for ".Patch Names", -I basically botched this section, to make CbB accept it, but it works anyway. -Again - this is a minimum-condensed set of commands, lots of stuff is missing, by design-. I didn't really need a patch or bank for my purposes. -Anway -change that naming (inside the brackets) to whatever suits your needs. It will still be needed to match the final section below it. In the example, for ".Note Names", -I only put 3 note names, by design. you can add or subtract. -The bracketed section needs to be the same text that you will be calling - basically the instrument, in the bottom section. For this exercise, it is about the most important part! Then, immediately below that, note numbers and the names you want to give them - follow in numerical order. -Maximum of 128 numbers, use only numbers you want named, and keep them numerically contiguous. In the example, for ".Controller Names" -I added that for testing. It does allow me to add the controller to the PRV, and then is identified thereafter in the controller display, and for automation. -Without any extra info lines, it works for RPN level port numbers, and the usage is the same as the previous note names section. In the example, for ".Instrument Definitions" - I used ONLY the basic parts. It wouldn't import if I left anything more out. -I know that's a terrible explanation, but well, there you are. It works for me! -The basic bracketed sections must exist, and match the corresponding names in the sections above. -"Key.." actually refers to Note Names, but most of the rest you can match fairly easily. Also, since @Starship Krupa mentioned the "diamond" note display: To change to that (instead of notes that show length & such as normal), add the following, below the "key..." line: Drum[*,*]=1 (That basically indicates all PRV notes in the track -to which that output-patch-keyboard layout is assigned- are to display as drum or rhythm format (diamond), instead of the default. -In practice, this only works for me if it is assigned to any Cakewalk MIDI output(s) and channel(s), and then you select one of those in your MIDI track properties. It won't work by just changing the default assignment view in the PRV, for instance. -But you can easily fake it - if you use an output you really don't have anything connected to, temporarily, when you are editing MIDI for instance.) So, basically, the simple version here, allows me to import and optionally assign these choices. You can also remove them, and I think replace them with updated versions easily from the Cakewalk Preference interface. -But being bold, I also sometimes just edit the Master.ins file (with CbB closed), and also look at all the other pre-populated material for learning. -Also, it won't hurt to start the editing in a basic text file, and then copy or change the file extension as needed, when you are ready to apply it. -Copy any .ins file, rename the extension to .txt, -observe & experiment! -Carefully, of course!

I definitely concur, not just regarding Cakewalk of course, it's part of the way coding for common platforms works, I would imagine. So many entry points to doing certain functions have to be matched, and matched to expected standards, and of course if one method doesn't work, someone somewhere will go nuts. -I really have to hand it to programmers on big public works projects, -it's amazing Cakewalk has been as good as it is, but of course, nothing is perfect. I would have to ask, for instance @msmcleod - does keyboard shortcut interfacing still get as much priority as say, GUI menus, or how is that all going? It must be hell to keep it all in sync. -And then allow for custom keyboard mapping! Wow.

@Bruno de Souza Lino- Thanks, got it. As I say, I haven't had much luck using layouts myself either, so I add that as testimony!

@John Vere One thing I realized - for myself anyway - is that giving tech instructions can be tough for people who worry about all the differing opinions and methods. So, sort of as @mettelus suggested, maybe just make sure to point out that this is what you find works - at the time you made these instructions. Then cut to the chase, as they say. But wow - isn't searching for anything seemingly innocuous - on the Web, absolutely bonkers? And now we will get AI suggestions in the mix... Yikes!

This is another "so many ways - personal preferences... " type of thing. -I happen to have been frustrated recently when adding new plugins too, so I changed the view option. -Where is says "Plug-in Layouts >" in the screen shot - I pop that out and choose "Sort by Type". Then, next time I use that menu - below the recent used list it shows the groups first - VST3, VST2, DirectX - and then manufacturer names, and then the plugin(s) names for each. -Anyway, for me, then I usually see all (non-hidden) installed plugins that way, or if not, try toggling/refreshing that view setting preference... But that's just one way. You can also create plugin layout(s), but I found I had to update those a lot. -Maybe it was just me though!

P.S. @John Vere We are all just searching for answers to similar things here, but who knows what "smarter" really is!! You are too funny. -Or is that considered an insult these days... I never know any more. -I suppose smarter people do though!!

I don't know about "dreaded" - for me it was easier than going back to find an old Sonar, or the full Cakewalk installer, -when I installed them a few months back. -But I understand your trepidation. And from what I recall, you have to find the steps to the additional component installation tool of the assistant app, I had to research the current method! After that, I also recall having the SI installers saved for a while, though I kinda cleaned up & let them go not much longer afterwards...

I can sympathize, truly. One of the least user-friendly features, unfortunately, at least in creating & modifying. It's been some time since I got my reference links together - I will see if I can find some time today and look for what I managed to source on editing format & rules for .ins files. -And I definitely use Notepad myself, but any programmer will have their favorite text editing app. Some can really streamline things, but you would have to ask around. -But .ins files are really just a rather simple text file, you don't want to accidentally introduce anything other than text, so don't use Word, for instance. .ins files, -for me-, have 2 major uses: #1 - if you want to change the PRV to display the keyboard notes as names you define. -That works for any MIDI track, regardless of output. -VSTi, no output, -whatever. #2 - they are definitely originally designed for - mapping to an assigned MIDI output, so that when you select that output choice in a track, the PRV will automatically use that note naming, and external instruments with patches & banks will match. -But you don't have to use that at all. It's also not necessary to have multiple banks, or name very possible note, bank, etc. Also, as to the mapping that causes "diamond shaped" notes in PRV - it is a one-line choice in the .ins file, as to whether the patch is designated as a rhythm instrument (diamond shaped notes), or notes (normal full note view). -Again, I need to find my documentation links, I'm just going off of memory here at the moment. -And maybe someone else will chip in before I do - this place is full of experienced folks! -As to using the bank/patch features - it is mostly a legacy thing, and will only work probably with GM-compatible VST2 synths (and external gear, of course), as VST3 seems to have done away with GM MIDI bank/patch features entirely. That has really taken a lot of use out of these types of things, so they will probably be going away, or at the least, being buried like the documentation is now!

Yes, but maybe not as complicated as you are worrying it will be. -Time consuming, for sure, but really, you only have so many pads, even tweaking them one by one isn't terribly hard. Usually the defaults for sensitivity, response curve, should work fine, although as some hardware ages, the pads lose some of that sensitivity, I have seen that happen. But anyway, -generally, you may only want to get your kit piece custom note assignments mapped out - I tend to do it on an actual text document, or heaven forbid a piece of paper ? - Doh! The rest of it you simply decide - do I want to map the kit notes to the VST, or the other way around. -The default maps you find will most likely be based on Roland defaults, but since you want to mix 2 sets, making your own map may be easiest. Then, as far as the CC element is concerned, each (good) VST has a manual that describes the default assignments for notes to drum samples, and how to change that. In there, they point out which note number(s) respond to hi-hat CC control, and I think there is a standard that links those together. -But at first, you may be best to try a default mapping the VST has (hopefully) for your pads/module, and then you can test it for hi-hat response, and then look at that preset mapping and modify all the other pieces to match your specific pad numbers, etc., leaving the hi-hat set as recommended. -Does that make sense?

I have to ask - do you remove the VST3, save, close & reopen the project for the comparison? If not, undo could be keeping the VST3 running in the background, - just a thought.

As far as transferring project settings to an already existing project, I have not done that in Cakewalk. The closest thing I have done towards that type of procedure is to create a copy of an existing project, with all the data removed from the tracks. Then I generally name it as a template. -Not nearly as easy as what you are looking for, - I know. But since I do have some often used layouts I like to start from, it really helps. Saving often used FX chain presets, and ProChannel presets (with FX chain presets in them) can also speed things up, like entire track templates, but on a more granular basis of course. -On a side note, empty (but not blank) template creation also makes it easy to switch between project audio data rate settings, because as long as no audio data exists in the tracks, the project will open in the currently selected audio mode that Cakewalk is in. I have even used that to convert a project base from one audio rate combo to another, by copying the project to a different folder, without any of the related audio, then bypassing the locate audio dialogue. That even leaves the audio clip names & positions there for reference, and I have then replaced re-sampled versions of the audio clips in the previous locations, and thus already had the same mix tracks, busses, outputs, FX, envelopes, etc. already in place. -Lots of good uses for templates, including entire project templates.

Hit the proverbial nail on the head there with that one! -Maybe it was written by another one of those "superintelligent Star Trek giant brain person" types you mention. ? It has taken me years to learn some of the "basic" original MIDI programming terms & uses, beyond making keyboard "a" set to channel "x" plug in and connect with synth "b" on channel "x or is it y"... And we haven't even begun to see how MIDI 2.0 is going to add to it! -I was just getting the hang of NRPNs - a few years ago now, -jeez!! I am still stuck in the middle of editing some of my Abbey Road Drummer and SD3 definitions - the ones that don't really follow the basic "pattern" that you would think, or have been published (at least when I try them)... It takes so much copy & paste, looking at the darn routings in the synth... But well, I still use the heck out of the ones I got working!

Well,, that is all subjective, and unfortunately changes every time new software comes out, or is updated, for instance. While it may be true that the modules are designed for the matching hardware, and may do some functions better, that one function (hi-hat emulation) is really a tough one. And so far, the way the earlier Roland gear has sounded to me, even their own hi-hat solution was lacking - to my ears anyway. -I haven't tried a real decent current TD system though. All of the digital recreations still have a hard time recreating a true acoustic hi-hat. -Think about it (I know, it takes away the magic of just enjoying music, but if only for a moment) - there are so many ways a hi-hat can change the sound of hitting two cymbals. -Normally, a sampler can take into consideration velocity (volume and/or layer triggering, etc.), note and positional (per kit piece) hit information, from single pad hardware, but think of all the variations there are in the sound of an acoustic hi-hat being played dynamically! It literally takes digital recreations tons of sample layers & control sensing just to come close, and then deciding how the pedal you supply can trigger those... I have to hand it to drum software designers & programmers. It's tough. -Probably even AI will take a while to get better at that one. Anyway, you will get into all that as you go along. It still wish I could track my stuff with a real hi-hat. I know many drummers still mix & match real & electronic pieces for that reason. -Sometimes though, we just don' t have that choice though, do we! Money, resources, location... always some challenge for musicians, that no one even hears when they just enjoy a performance... - but such is life!

Indeed, but where that is actually the case, the user probably knows and is installing it on purpose. - Sincerely, I do hope the solution listed indeed works for the OP - great find! But I still have to say: -The case with Logitech - I install so many of their devices - love them generally, but when they make a forced addition to your startup items, and also prompt to download their software without explanation of the choices, it really bothers me. -The truth is, in most cases, basic mouse, headset, and camera functionality for the average user is present in the basic Microsoft-supplied (through Logitech submission) drivers for those items - unless you are needing a specific extended function. I say that, because if the OP here has issues pertaining to mouse configuration, it can be tough to know which way to go with the "repair". If they are already using extended features (accidentally or not) of the mouse via the vendor-specific software, and is unaware of how that works in general, there can be more problems ahead, other than just moving things in Cakewalk. -Be careful! Personally, I ignore the download prompt for Logitech software that happens upon adding a new Logitech device, and go immediately to the Windows Settings - Apps - Startup section, and turn off the Logitech Download Assistant that was just installed. Then, I use the device with the default drivers (except in rare cases where that is not possible), and if I find I need any of the extended features, I read up on it on the Logitech Web site, and download & install - what & when I choose to. At the least I also think I get less system clutter & background data reporting to Logitech doing it that way, though one can never be sure about that anymore these days. -Sometimes the simplest things, like a computer mouse, can get so complicated! -Sorry about the info overload. Do of course be aware of odd system device drivers & behaviors in Windows, and then fix those before they complicate things in Cakewalk, Or any app for that matter!

Well, not necessarily "special" - but things like the Roland system use a combination of different notes for different positions, and a constant CC value sent so that some software can use that to determine the sound layer and/or other features that make the sound engine respond more realistically. -That feature is probably not in SI Drums at all, and so you are only getting note changes - that only happen at open and close on the pedal, - I am guessing. That has nothing to do with latency.

Sadly, in my experience, there is no such standard, with major PC vendors anyway. Even Dell has offered some of the most bizarrely configured combinations of features, and at all price ranges, when I have had to order for clients over the years. -You really have to research & be aware of what each system offers. -At least Cakewalk itself will run fine on almost anything, for sure, but as the answers to the OP point out, using SSD storage is at least a reliable option for a simple upgrade. It is so hard to find those things out in advance for most folks. But that can be very important if you do a lot of big Cakewalk projects, to be sure. -Sad thing - even trying to buy a "performance" machine, often you will not know those things until after the sale. And even more frustrating - if you try the "bleeding edge" configurations, often you become the guinea pig for troubleshooting new problems... It can be so tough to buy a new system. Generally though, upgrading something that already works fine, and can use an SSD storage configuration instead of a spinning platter time-bomb, is a great way to go. As mentioned, there may be a few hiccups with licensing issues for things that use disk IDs as validation (not so many - but MS will throw a fit if you change too many devices at one time, FYI), but cloning nowadays is really great for moving to an SSD primary drive without a reinstall. And, theoretically, the SSDs will outlast the spinning disks without degrading, though we are all still running that experiment... But I know for sure spinning disks degrade significantly over time & use, and are way more prone to physical damage.

(P.S. I don't know anything about BBCSO) - If it is a multi-timbral instrument (sounds like it is), you may want to try checking things one track at a time - I know it's tedious, but finding the problem is hard when you just throw everything on all at once. -But, there are so many ways to do things, just keep working at it! Troubleshooting mode - only provide MIDI one track at a time - until you find one(s) that don't cause the problem. -Just a suggestion.

This can be found in Cakewalk Preferences - Project - MIDI - Other Options: MIDI Event Chase On Play. -When a project is open (it is set per project). The other options can be important too!

Yes - and in a perfect world, we musicians would have been taught basic MIDI standards, at least since the 1980s or so! ? -I guess we should be glad that those manufacturers aren't forcing users to buy a spiffy new specialized MIDI controller in order to make their program work in the fashion they designed. In most of the cases of CC1 being used for volume, that I have seen, it is because that is the only generally implemented physical control on a keyboard that often easily accessed to push or snap back to a set value. -So it's sort of a cheap workaround to implement easy volume swells, -sort of like a swell lever on an old Hammond organ (in fact.. many organ sims use CC1 in default setups for varying alternate uses, -cough cough- N.I...) -Still, they should at least have a big warning notice & mapping choice when you install the software, you know? @sadicus If you are sure that there is no embedded MIDI CC in any/all the tracks pointing to the instrument that is changing volume (embedded CCs use channel value, not necessarily the track they are in), then maybe you need to turn off MIDI chase in the project settings when that happens. I know I have a few orchestral arrangements, with long notes in them, that seem to "hang" and then double in volume, when I am stop-start editing in the middle of sections with those long notes, until I turn that setting off temporarily.