Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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.
  3. 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!
  4. 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
  5. 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
  6. 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?
  7. 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
  8. @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
  9. 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
  10. 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
  11. 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
  12. 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
  • Create New...