NDLR internal clock vs CTRL cc #72

[Ghostz_of_Moar]

When I patch my octatrack to the NDLR ctrl track....and set my NDLR to internal clock...then midi cc #72 should *not* override the NDLR’s internal clock....

In my case I have a midi patch bay...each NDLR is connected to the octatrack and share the same CTRL layer.

I like running one NDLR at one tempo and the other at 1/2 speed.

The only way I can do this now is to either use midi b from the 1st NDLR ...but then using the octatrack to change the mode/scale....doesn’t get sent as midi THRU to the 2nd NDLR...which makes concurrent midi controllable harmonic coordination unsustainable.

Yes the workaround is to use clock dividers on the motifs...but due to the way the tempo cc is set up , this affects the pad strum and the drone rhythm.

[House de Kris]

"When I patch my octatrack to the NDLR ctrl track....and set my NDLR to internal clock...then midi cc #72 should *not* override the NDLR’s internal clock...."

My user manual indicates that CC#72 is used to set the tempo of the internal clock. It appears you are suggesting that it should not set the tempo of the internal clock. Is that right? If so, it is not clear to me what your expectations for CC#72 should be then. As an easier solution, just don't issue a CC#72, and all should be golden, right?

HdK

[Ghostz_of_Moar]

"When I patch my octatrack to the NDLR ctrl track....and set my NDLR to internal clock...then midi cc #72 should *not* override the NDLR’s internal clock...."

My user manual indicates that CC#72 is used to set the tempo of the internal clock. It appears you are suggesting that it should not set the tempo of the internal clock. Is that right? If so, it is not clear to me what your expectations for CC#72 should be then. As an easier solution, just don't issue a CC#72, and all should be golden, right?

HdK

hey thanks for your feedback and I get what you are saying.

The issue I have with that.

when you are distributing the cc on advanced setups this can cause unwanted behavior...and again maybe I see things from a different perspective. When a clock is set to internal, then the clock remains internally set regardless of the midi cc. On most days the midi cc #72 is convenient, but having an option to ignore/interpret this midi cc on the NDLR's settings would be great...especially when dealing with higher level midi sequencers.

Say with a Roland MV8800 for instance, the remote setting was different in that it would accept start/stop but its BPM setting was independent.

the other idea that could also be of value is to have a coefficient variable that lets the user set the divide/multiple for the midi cc or incoming clock...in the same manner as the clock in cv.

[House de Kris]

" When a clock is set to internal, then the clock remains internally set regardless of the midi cc."

I guess I'm still missing the point, but I am trying to understand and help. If the CC# you're sending is to specifically control the tempo of the internal clock, why should it be ignored? Just don't send any CC#72 instructions.

Now, let me see if I understand your issue presented in the first post. You've got two NDLRs, you're sending them both identical strings of CC# commands, you desire them to operate differently. Obviously that can't happen if you control them identically. But, you want one to run at half the tempo of the other. Presumably you desire to change the tempo at some point of your song, as you've sent CC#72. But, you want the same data sent to the two NDLRs to be interpreted differently. I believe I can suggest two methods to accomplish this for you:

1. First method is called the Brute Force Method. Create a track on, say, CH15 which has all the CC# you want to control all aspects of the two NDLRs, including any tempo changes. Copy this track to, say, CH16. Keep all the CC# data the same EXCEPT change the data for CC#72. Change its value to a half of the other one. Set NDLR 'A' to use CH15 as control and NDLR 'B' to use CH16 for its control channel. Route the Octatrack to both NDLR 'A' & 'B.' Now they both behave the same, but one has its internal tempo set to half of the other's.

2. Second method is called the Clever Method. The Brute Force Method is clunky and needlessly doubles up MIDI CC# data. In this method, again make a channel, say CH15, have all the various CC# data to control all aspects of both NDLRs. But, whenever you have a CC#72 to modify the internal clock's tempo, write a CC#72 with half the value on say, CH16 at a slightly later point in time. Have both NDLR 'A' & 'B' set to receive control on CH15. Then, do all the necessary magic in your router. Have the router configured to send the same copy of the Octatrack's MIDI out to both NDLR 'A' & 'B' MIDI-A input. Have the router setup to bump the CH16 data down to CH15, and have this new stream sent to NDLR 'B' MIDI-B input. Now both NDLRs work the same because the both listening to the same commands. If you change tempos, they both initially go to the same value, but the second one gets immediately changed to a tempo half of the first.

What could be simpler?

HdK

[Ghostz_of_Moar]

" When a clock is set to internal, then the clock remains internally set regardless of the midi cc."

I guess I'm still missing the point, but I am trying to understand and help. If the CC# you're sending is to specifically control the tempo of the internal clock, why should it be ignored? Just don't send any CC#72 instructions.

Now, let me see if I understand your issue presented in the first post. You've got two NDLRs, you're sending them both identical strings of CC# commands, you desire them to operate differently. Obviously that can't happen if you control them identically. But, you want one to run at half the tempo of the other. Presumably you desire to change the tempo at some point of your song, as you've sent CC#72. But, you want the same data sent to the two NDLRs to be interpreted differently. I believe I can suggest two methods to accomplish this for you:

1. First method is called the Brute Force Method. Create a track on, say, CH15 which has all the CC# you want to control all aspects of the two NDLRs, including any tempo changes. Copy this track to, say, CH16. Keep all the CC# data the same EXCEPT change the data for CC#72. Change its value to a half of the other one. Set NDLR 'A' to use CH15 as control and NDLR 'B' to use CH16 for its control channel. Route the Octatrack to both NDLR 'A' & 'B.' Now they both behave the same, but one has its internal tempo set to half of the other's.

2. Second method is called the Clever Method. The Brute Force Method is clunky and needlessly doubles up MIDI CC# data. In this method, again make a channel, say CH15, have all the various CC# data to control all aspects of both NDLRs. But, whenever you have a CC#72 to modify the internal clock's tempo, write a CC#72 with half the value on say, CH16 at a slightly later point in time. Have both NDLR 'A' & 'B' set to receive control on CH15. Then, do all the necessary magic in your router. Have the router configured to send the same copy of the Octatrack's MIDI out to both NDLR 'A' & 'B' MIDI-A input. Have the router setup to bump the CH16 data down to CH15, and have this new stream sent to NDLR 'B' MIDI-B input. Now both NDLRs work the same because the both listening to the same commands. If you change tempos, they both initially go to the same value, but the second one gets immediately changed to a tempo half of the first.

What could be simpler?

HdK

hey thanks for the reply and the insight.

midi cc 72 corresponds with VCA release time on synthesizers that follow the standard midi cc spec format.

the NDLR is spending its time and tenure sending note and time data to synthesizers.

I have rack mount synths and effects boxes that utilize that midi cc assignment...which I would like to send via the octatrack at times while other times I can use the midi cc to modulate tempo on The NDLR.

and there lies a bit of an impasse. It’s a clever function to have, but if I can’t turn off the way the NDLR reacts to it then yeah I have to formulate a work around. And sometimes I can opt for arbitrary midi port assignments(track 14,15,16 are Spectralis DSynth targets, for instance)

the other bit is how we can’t use midi cc to make an odd numbered bpm. There is no fine tune and it restricts which bpm you can set as a denominator/multiple.

and yes I have the work around, it’s just I could use a switch to let NDLR know to ignore that message.

[House de Kris]

Ah, that makes sense, thanks for 'splaining it to me. Therein lies the problem, it is unwise to combine multiple functions on one MIDI channel. Either a channel plays a synth voice, or it controls gear. Don't attempt to do two completely unrelated things at the same time on one channel.

Problem solved!

HdK

[Ghostz_of_Moar]

Ah, that makes sense, thanks for 'splaining it to me. Therein lies the problem, it is unwise to combine multiple functions on one MIDI channel. Either a channel plays a synth voice, or it controls gear. Don't attempt to do two completely unrelated things at the same time on one channel.

Problem solved!

HdK

Sure no problem House of Kris!

(More 'splaining.)

well it depends on the midi spec, the user needs and the gear.

Some gear's midi specification requires that you reserve a specific channel for use with the NDLR. point in case. Spectralis Digital Synth is set to 14, 15, 16...and the A-synth is set to 13...So four channels of the 16 are immediately taken off the table. 

other times a synth can be set to an omni mode and it doesn't matter which channel the CC is coming from...it just jumps the shark and redirects the midi to the channel in focus at that very moment.(roland MV8800, Emu command station, Emu 5k Ultra)...the term is "omni" mode for the EMU's and the MV8800 would rather be "in charge" of everything...so its a great sequencer but its a chore working outside of "omni" mode.

So often with more extensive setups one does indeed need to be situationally aware of errant midi signals going and coming from certain midi channels....
it's part of working with hardware sequencers and synthesizers due to the designers adhering to midi specifications and then injecting their own flavors based on their desired functionality.

which is why an accept/ignore/clip function on the sequencer is a great compromise...mainly because it could save people the time and effort from hunting down a midi signal and put that back into noodling.

why?

because it's a bold enough aspect of the creation/design process....the clock by which sequences depend on articulation(pad strum, drone rhythm, melodic rhythm and clock division) ....and on the other side of the pond....a VCA attribute that tells a digital patch how long to taper off.

thanks for all your insight!

[House de Kris]

Sounds like you've got a reasonably good handle on things in your situation. You're dealing with things many people have had to contend with over the decades. I, too, have gear that listens in omni mode. I use it as an advantage as a means to easily switch focus on different MIDI channels. I'm pretty sure your E5k Ultra can be set to multi mode, and specific channels can be individually disabled. That's how I use my E6400 Ultra. I think the only time I use omni mode on it is when I'm trying to find a patch to use in a song.

Anyway, in a well designed usage of MIDI channel scheme, I'd be surprised if there were any 'errant MIDI signals' floating around. I guess that's the part I'm still having difficulty seeing.

Good luck!

HdK

[Ghostz_of_Moar]

Hi House of Kris always a pleasure to hear from you!

thank you so much for your well wishes!

here is the thing: when dealing with the midi specification and legacy hardware that is often either vintage(EMU company not in existence), abandoned(Roland mv8800 and everything they release after 1-2 years), or no room to grow(radikal technologies spectralis has its entire OS on 768k)...its often on the onus of the newest product being introduced to help make life a bit easier in regards to connecting to the legacy they seek their product to be a part of(i.e. customer support)

In this case it's the NDLR and the gracious use of midi cc assignments(versus sysex) to control just about each and every aspect of the sequencer. The last sequencer that was capable of controlling the bpm assignment in my possession was the DSI evolver/polyevolver...and in order to do that had to be switched to the master of the chain.

I understand the why's and how's of what we all had to go through to get here. I also understand the difference of perspective and opinion that you are articulating in regards to feature depth and firmware updates/niggles/prioritization.

I would still want a simple filter switch to be able to control this kind of behavior due to setup. It's a nice idea in some situations and in others not so much, as I have gone into detail on previous posts. This is me noticing that the midi cc affects NDLR tempo in a bit of a clumsy (5-127 multiplied by 2...so no odds nor decimals). Mind you in certain circumstances this can lead to undiscovered worlds of temporal dialect where one is free to shunt from 1/4 to 1/2 to double time to normal time...and that propagate down the sequencer's tree....(but even then the options are limited due to the unavailability of odds and fractions)

I also get that maybe you just might come from an age of "just do without", or "just do it this way"...and I am not at all unfamiliar with that particular take...its just I would like to shield the bpm from inside the NDLR regardless of whatever data was entering through the midi's internal ports. This comes from being accustomed from companies like Elektron who provide an ear and consistent support to their once small now massive user base. Users get accustomed to features and being able to scrutinize the purchase they made with their discretionary income. Manufacturers in their right mind should love and look forward to hearing feedback of people who put the product through all the paces and test the limits and explore each and every nook and cranny. In that case users do what prototype and beta tester can't always find time for...(test , incorporate the product and assess in as multiple scenarios...whilst reporting and scrutinize their findings.) I also understand that this might be confusing to you and even have little value to you and of course you can also just scroll on and we leave it at that as I log my issues with the behavior on the site for the dev team to see.

Take care and stay blessed

[House de Kris]

You are absolutely correct, I am not on the development team. I was just trying to understand your issue and offer help if I could. It's just my nature. My apologies if my interjection derailed your narrative in any way. I just saw your initial post languishing for a couple days and wanted to let you know that people do read these things and offer support. I'll let the development team address your needs. Again, sorry to offer unsolicited efforts to help.

HdK