Bug in drum map ports and midi channels using controller events messages

[Ronny.G]

Hi to all,

I have a strange problem with the step sequencer, in the manual there is written:

Quote

Working with Controller events
You use the Controllers pane to include modulation events, such as Controller, Pitch Wheel, Channel Aftertouch, RPN and NRPN events, in your patterns. Modulation events are independent for each row.
   Note: Modulation events on one row may also affect other rows that share the same output port and channel pair

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

Edited June 21, 2020 by Ronny.G
Modified title

[user 905133]

8 hours ago, Ronny.G said:

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

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

 

Hi.  I don't use the step sequencer, but I sometimes use forum posts to expand my knowledge of Cakewalk's features. I learned a lot about the step sequencer and am wondering if this is the same issue you are describing.

I duplicated a 4-beat pattern so I had two instances of TTS-1. I put pan on some non-playing notes that go to TTS-1 Instance 2 and muted that row.  The pan setting affects all of the other notes in both instances.  It is as if the pan gets applied to both tracks /both instances of TTS-1.

 

 

 

Edited June 19, 2020 by User 905133
to simplify the post

[Ronny.G]

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

Edited June 19, 2020 by Ronny.G

[Ronny.G]

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

 

Edited June 21, 2020 by Ronny.G

[msmcleod]

@Ronny.G - can you send me a simplified copy of your project (preferably the one with TTS-1) so we can reproduce ?
 

[user 905133]

10 minutes ago, Ronny.G said:

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

Amazing detective work here!!! It would be great if someone else can confirm this.  I will see what I can do as it will be a great learning experience for me, but it would be better to have others who are more experienced than I am with the step sequencer and with drum maps.  

Update: Thanks for chiming in on this, Mark.

Edited June 21, 2020 by User 905133
to add a TY

[Ronny.G]

Thanks Mark! sent message...

Edited June 21, 2020 by Ronny.G

[Ronny.G]

 @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

Edited June 24, 2020 by Ronny.G

[msmcleod]

11 hours ago, Ronny.G said:

 @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

Hi Ronny - I've just had a look.

I believe this a limitation of drum maps rather than a bug.

Drum maps only give you the ability to route notes, not CC's. 

When you have multiple output ports and channels, the drum map has no way of knowing where to send CC messages, so all CC's are routed to each unique channel/port combination defined in your drum map (in this case TTS-1 #1 Channel 1 & 2  and TTS-1 #2 Channel 1 & 2).

The actual port &  MIDI channel in the event list is irrelevant as it has been overridden by the drum map (in the same way you can override MIDI events' MIDI channels by setting the output port/channel of a MIDI track in the inspector).

On a standard MIDI track using a standard port, leaving the MIDI channel as "None" will mean the MIDI channels for each event are respected. Setting the MIDI channel for the track will override any channel in the MIDI events and force them to the channel set for the track.

This is not the case when using drum maps. CC's are sent to each unique channel/port combination defined in your drum map,

The only way around this is to put the CC events on separate MIDI tracks.

For this example, you'd need 2 MIDI tracks: one for TTS-1 #1 & one for TTS-1 #2, with their respective ports set to TTS-1 #1 / TTS-1 #2.  The MIDI channel, bank and program should be left as None in the inspector so you are able to send MIDI events to different channels.

M.

[Ronny.G]

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

[David Baay]

2 hours ago, Ronny.G said:

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.

It's an inherent imitation of the MIDI 1.0 message types. Note On messages can be differentiated (and routed) by their note numbers. CC messages don't have that; there's nothing to 'tell' the drum map that a given CC is associated with a given note number.  Getting that capability will require imlementing something like Steinberg's proprietary 'Note Expression' or MIDI 2.0's 'Polyphonic Expression', and will require completely re-architecting  Cakewalk's MIDI engine. 

[Ronny.G]

4 hours ago, David Baay said:

there's nothing to 'tell' the drum map that a given CC is associated with a given note number.

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?

Edited June 25, 2020 by Ronny.G

[user 905133]

13 hours ago, David Baay said:

It's an inherent imitation of the MIDI 1.0 message types. Note On messages can be differentiated (and routed) by their note numbers. CC messages don't have that; there's nothing to 'tell' the drum map that a given CC is associated with a given note number.  

I knew this, but thank you for reminding me/[us]; I have been trying (again) to try to figure out why I cannot get remote control midi to work with the inspector-based arpeggiator.  Yesterday I figured out that while note data goes to the arpeggiator based on the track's echo status, CCs change the status of the virtual buttons and selectors (but not the underlying functionality) whether track's midi echo is on or off. 

Upon making the observation, I immediately thought of this thread re: the Step Sequencer channel issue and wondered "How does the arpeggiator route midi control data--even if they are being routed into a blackhole?"

I have been using CCs to try to change arpeggiator functions.  Your comment suggests to me I should test to see if there is a difference between CCs and notes; although it could be that note data is routed to the arpeggiator and CCs are just thrown away.

NOTE: Not trying to hijack this thread; was going to do more testing and either add to an existing thread on this problem or add yet another one.  Just wanted to TY for the note v. CC insight and to flag the issue here as possibly related.  Also TY to @msmcleod for his limitation v. bug comments as those observations might (or might not?) be related to the remote control/arp issue as well.

UPDATE: The note v. CC distinction appears to be a dead end in terms of the disconnect between the arpeggiator's virtual buttons / selectors and the underlying functionality. It was worth looking into and ruling out. However, @msmcleod's  comments re: bug v. limitation might be relevant (see both above and below) because the arpeggiator's channel(s) setting (1) seems to be for both input and output and (2) allows for multiple outputs. 

There is a major difference, though. In the case of the arpeggiator notes might be routed (or not) to the arpeggiator based on the (a) the echo status of the track [on/off], (b) the track's input setting, (c) the controller's sending channel, (d) the arpeggiator's I+O channel(s) setting and maybe (e) other settings. However,  in terms of remote control midi, both CCs and notes seem to be routed only to the virtual buttons and selectors but not the underlying functionality.

This bug/limitation is only tangentially related to the drum map bug/limitation at best but was worth looking into. 

Edited June 26, 2020 by User 905133
(2) to include an update; (1) to underline the phase about CCs (v. note data)

[msmcleod]

2 hours ago, Ronny.G said:

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?

Unless there is a way to map combinations of MIDI CC / Channel to another port and channel, anything else would be ambiguous.

The current behaviour is actually unambiguous in that it sends the CC to all combinations of ports/channels defined in the drum map.

It's been a while since I used drum maps, but I did used to use them on a combination of hardware drum units. In this case I absolutely wanted controllers such as CC 7 (volume) to be sent to every port/channel in my drum map - because it is in effect being treated as a single destination, and I wanted all units to respond to volume changes.

I realise this behaviour is the opposite to what you want, but the only way to get around it at the moment is to bypass the drum map for CC messages and go straight to the MIDI port if you want per channel/port MIDI Messages sent.
 

[Ronny.G]

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

Edited June 26, 2020 by Ronny.G

[David Baay]

So basically what's needed  in this case is a 'Pass-thru' option for Channel that just passes events without altering their embedded channel.

I'm thinking that actually should not  be that challenging to implement.

The alternative would having a drum map with 128 x16 = 2048 rows (!) to handle explicit mapping all possible combinations of input note number and channel. ?

 

[Ronny.G]

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.

On 6/29/2020 at 6:58 PM, David Baay said:

The alternative would having a drum map with 128 x16 = 2048 rows (!) to handle explicit mapping all possible combinations of input note number and channel. ?

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

Edited July 6, 2020 by Ronny.G

[David Baay]

 

On 7/6/2020 at 7:30 AM, Ronny.G said:

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

The messages themselves don't carry port information. There is no 'incoming port' value that you  can 'retransmit' or map to some other port. What you're wanting to do cannot be done without extending the message format beyond the MIDI 1.0 spec. For the time being, you will have to use multiple tracks outputting to separate drum maps in order to route CCs to specific ports/instruments.