Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Minor Change Request to CC#s
#1
I'd like to humbly request a couple minor changes to the CC#s that the NDLR responds to currently. This is actually a two-pronged request, and I realize I should probably split it into two separate threads for clarity, but I'm lazy - so please treat this as two separate and independent change requests.

REQUEST 1:
I'd like to have another CC# added to control the Pause / Play aspect of all four parts, in one word. Currently there are four CC#s used, one for each part, with accepted values of 0-62 implying Pause and 63-127 resulting in Play. I'll skip the lengthy reasoning why this is difficult for me to integrate into my NDLR usage, but having one CC# for all parts would make it easier (for me). Use just the bottom four bits for control, and ignore the higher order bits. Perhaps something like:

Bit0 = Motif 1
Bit1 = Motif 2
Bit2 = Drone
Bit3 = Pads
Where, 0 = Pause and 1 = Play

This implies a 0-15 acceptable range, but if higher order bits are ignored, then the pattern of 16 valid codes repeats through the entire range of 0-127.

REQUEST 2:
I love the Modulation Matrix, but I'm disappointed that there just aren't enough sources. I'm not requesting more LFOs or preset modulators, but rather a path for user supplied external oscillators to be used as sources. Very similar to the MIDI inputs, but more of them and with a consistent usage pattern. Therefore, I propose using a block of eight CC#s from 100 to 107 as sources for the Modulation Matrix. My justification for this request stems from my past usage of an Alesis MMT-8 sequencer as an octal MIDI-sync'ed LFO generator. This would give a greater frequency range, wave shapes, phase relationships than the ones included in the stock NDLR.

SUGGESTIONS TO FULFILL REQUESTS:
I made a chart showing the CC#s as defined in the NDLR currently, and suggested changes to realize the two separate requests of this post, see attached.


.txt   NDLR CC chart.txt (Size: 8.18 KB / Downloads: 4)

This chart displays all 128 possible CC#s and NDLR uses, in addition to standard MIDI definitions of common or reserved CC#s. The vertical columns are (from left to right):

CC# - the CC#
Resr - Reserved
Genl - General use functions of NDLR
Mot1 - Motif 1 specific functions in NDLR
Mot2 - Motif 2 specific functions in NDLR
Dron - Drone specific functions in NDLR
Pads - Pads specific functions in NDLR
Prop - Proposed new functions in this request
RANGE - Indicates allowable values that are recognized per CC#
TARGET - A brief description of the CC# function

The dashes under Resr, Genl, Mot1, Mot2, Dron, and Pads visually show how each CC# is used. Periods are used in those fields for the proposed changes, which are designated with YYYY and XXXX in the Prop column (differentiating the two different requests).

I hope this makes sense. If any clarification is needed, please ask. I also hope that the level of effort in making this request gives a hint as to how much I'd appreciate having these features added.

Thanks,
House de Kris
Reply
#2
(11-22-2020, 12:42 PM)House de Kris Wrote: I'd like to humbly request a couple minor changes to the CC#s that the NDLR responds to currently. This is actually a two-pronged request, and I realize I should probably split it into two separate threads for clarity, but I'm lazy - so please treat this as two separate and independent change requests.

REQUEST 1:
I'd like to have another CC# added to control the Pause / Play aspect of all four parts, in one word. Currently there are four CC#s used, one for each part, with accepted values of 0-62 implying Pause and 63-127 resulting in Play. I'll skip the lengthy reasoning why this is difficult for me to integrate into my NDLR usage, but having one CC# for all parts would make it easier (for me). Use just the bottom four bits for control, and ignore the higher order bits. Perhaps something like:

Bit0 = Motif 1
Bit1 = Motif 2
Bit2 = Drone
Bit3 = Pads
Where, 0 = Pause and 1 = Play

This implies a 0-15 acceptable range, but if higher order bits are ignored, then the pattern of 16 valid codes repeats through the entire range of 0-127.

REQUEST 2:
I love the Modulation Matrix, but I'm disappointed that there just aren't enough sources. I'm not requesting more LFOs or preset modulators, but rather a path for user supplied external oscillators to be used as sources. Very similar to the MIDI inputs, but more of them and with a consistent usage pattern. Therefore, I propose using a block of eight CC#s from 100 to 107 as sources for the Modulation Matrix. My justification for this request stems from my past usage of an Alesis MMT-8 sequencer as an octal MIDI-sync'ed LFO generator. This would give a greater frequency range, wave shapes, phase relationships than the ones included in the stock NDLR.

SUGGESTIONS TO FULFILL REQUESTS:
I made a chart showing the CC#s as defined in the NDLR currently, and suggested changes to realize the two separate requests of this post, see attached.



This chart displays all 128 possible CC#s and NDLR uses, in addition to standard MIDI definitions of common or reserved CC#s. The vertical columns are (from left to right):

CC# - the CC#
Resr - Reserved
Genl - General use functions of NDLR
Mot1 - Motif 1 specific functions in NDLR
Mot2 - Motif 2 specific functions in NDLR
Dron - Drone specific functions in NDLR
Pads - Pads specific functions in NDLR
Prop - Proposed new functions in this request
RANGE - Indicates allowable values that are recognized per CC#
TARGET - A brief description of the CC# function

The dashes under Resr, Genl, Mot1, Mot2, Dron, and Pads visually show how each CC# is used. Periods are used in those fields for the proposed changes, which are designated with YYYY and XXXX in the Prop column (differentiating the two different requests).

I hope this makes sense. If any clarification is needed, please ask. I also hope that the level of effort in making this request gives a hint as to how much I'd appreciate having these features added.

Thanks,
House de Kris
Hey Kris,
This is definitely the most thoroughly documented feature request I've come across. I'll be sure to pass this along to Steve and see what he thinks. 
My two cents is that it seems a little bit fiddly to use the bit values of one channel for the Play/Pause, rather than individual on off CCs. I can see it being really hard to use for people with a MIDI controller slider or knob, no? It would seem to be simpler to just add a CC, I could see that working more predictably anyway.
I don't imagine any major expansions of the ModMatrix are likely but I will for sure run it by the man and see what he thinks. I do see how that would be pretty neat. 
Thanks for taking the time to present these ideas, your feedback has always been top notch. I can't say whether or not they get implemented but I imagine we will have more time to look at these in March after the MRCC is launched. 
Best,
Jesse
Reply
#3
(11-22-2020, 06:43 PM)Jesse Johannesen Wrote: Hey Kris,
This is definitely the most thoroughly documented feature request I've come across. I'll be sure to pass this along to Steve and see what he thinks. 
My two cents is that it seems a little bit fiddly to use the bit values of one channel for the Play/Pause, rather than individual on off CCs. I can see it being really hard to use for people with a MIDI controller slider or knob, no? It would seem to be simpler to just add a CC, I could see that working more predictably anyway.
I don't imagine any major expansions of the ModMatrix are likely but I will for sure run it by the man and see what he thinks. I do see how that would be pretty neat. 
Thanks for taking the time to present these ideas, your feedback has always been top notch. I can't say whether or not they get implemented but I imagine we will have more time to look at these in March after the MRCC is launched. 
Best,
Jesse

True, my first request may seem fiddly at first, and it would definitely be a nightmare for those using a slider or knob controller. But, this was a request for a CC# 'in addition to' and not 'instead of' the existing four CC#s optimised for physical controls. I don't know what you envision with "be simpler to just add a CC," but I'd like to hear your thoughts if it would accomplish similar control.

At any rate, the issue I'm trying to work around is that the individual Play/Pause is truly a pause, and not a mute. Although that is obvious, the ramification is that if a lot of effort is put into the rhythmic patterns of Motif 1 and Motif 2 so that they create a complex interplay with each other, there's very little chance of pausing the parts and then successfully unpausing them synchronized again with the front panel finger buttons. The only way to do that is to use CC# controls. I bought a Synthstrom Audible deluge for live control with hopes that it's CC# sequencer would make this happen. Alas, programming of its CC# data is through a knob (it is a Continuous Control, after all). This means the exact timing of data WRT its timing within a measure is hard, if not impossible, to get precisely correct. The result was still Motif 1 & 2 getting out of sync with a couple pauses.

My solution that did work was to program note data on four MIDI channels, and then process this into CC#s to control Play / Pause. The timing relationship of Note data can be precisely controlled by the user. But, because NDLR's Play / Pause control is spread out over four CC#s, I had to use four MIDI channels. Plus, I also had to use all four of the processors in my MIDI number cruncher to translate MIDI channels into CC# and Note data into CC values. It worked great, but took lots of resources.

My request of a single CC# to control all four parts of the NDLR would allow me to program notes with a specific bit pattern on a single channel of the deluge, use only a single processor to translate this to CC values, and get precise control of NDLR parts.
Reply
#4
Can you not use expression to effectively mute a channel?

With the deluge, if you have learnt the MIDI cc, you can press and hold the pad and put the exact value in for that step in the sequence. Put expression (or volume) of 0 to mute, put 127 to unmute.
The Puppeteer
Godlike Productions
Reply
#5
Cool! Thanks a bunch for that tip. I'm still pretty new to the Deluge, so I much appreciate any hints like this. I will try this out at my earliest convenience.
Reply
#6
This reminded me of a short video Steve made way back before we went into production.


https://youtu.be/O9cw6IP3pIY
Reply
#7
My 2 cents on Pause/Play is, I prefer to start all the parts together and use the mixer to turn them up and down. It sounds a lot better (less abrupt) that way and your parts stay in sync. You can also you the All button to stop and resync parts.
Reply
#8
(12-07-2020, 06:09 PM)The Puppeteer Wrote: Can you not use expression to effectively mute a channel?

With the deluge, if you have learnt the MIDI cc, you can press and hold the pad and put the exact value in for that step in the sequence. Put expression (or volume) of 0 to mute, put 127 to unmute.

I fumbled around with this, getting the deluge to learn CC#s, with no success. Then I got wise and simply assigned a CC# to "Custom 1" of the MIDI channel of choice. For whatever reason, I'd forgotten about "press & hold" to set specific values. It worked! So, using Custom 1-3 I've got easy access to precision NDLR control of three parts on a single deluge clip. All I have to do is to filter Note On/Off with an external processor, and I'm golden!

Thanks so much for the hint.

(12-10-2020, 12:09 PM)Darryl Wrote: My 2 cents on Pause/Play is, I prefer to start all the parts together and use the mixer to turn them up and down. It sounds a lot better (less abrupt) that way and your parts stay in sync. You can also you the All button to stop and resync parts.

I checked out that video a while back, before buying a NDLR. I get your point, though - just use direct CC addressing instead of going through the Modulation Matrix. I was hoping to use generic full-scale LFO waves, and use the Modulation Matrix to apply gain and offset to the values. But, I could just process the data externally and do direct CC control. That takes care of Request 2 then.

The "just use the mixer" idea doesn't work in my typical use case. I usually send all four parts to a multi-timbral synth. Changing levels of a single channel is not quick nor easy, and pretty much impossible to do two channels simultaneously. I'm aware that I could use the nifty MIDI CNTLR Volume page on the NDLR, but the suggestion from The Puppeteer above has got me on track to accomplish what I seek. That takes care of Request 1 then.

All my issues are solved, and nothing has to change! Excellent. Thanks to all for the ideas.
Reply


Forum Jump:


Users browsing this thread:
1 Guest(s)