Logic Pro (X) better way to edit continuous control data when it's NRPN, not just CC (Prophet 12 Synth)

[AlexDingley]

So, I'm playing a lot of synth tracks live & making tweaks to the MIDI data in Logic...before finally capturing it as audio. One of my main synths is a Dave Smith Prophet 12 (it's great, btw)

I've been using this synth for a few years and what I'm describing seems to be identical behavior in Logic Pro 9 and Logic Pro X... so really, it seems that we're dealing with a simple MIDI implementation issue. I've tried simplifying this by controlling the Prophet12 with just regular CC# commands, but the control isn't very precise, when the value-changes are mapped across parameters that have more than 128 value-positions... this results in very stepped-sounding filter sweeps... they're smoother when it's done in real-time and or when it's performed & captured as NRPN midi data moments. So I'm seeking some help with either editing or drawing moments that will map more elegantly via NRPN groupings.

The parameter knobs on the actual Prophet12 send midi data in NRPN format... so, when I sweep the LPF frequency, the Prophet is sending 4 CC messages.

CC#6 - value = 0 (and sometimes 1)
CC#38 - values 1-127*
CC#98 - value = 0
CC#99 - value = 90 (that is the designation for "LPF frequency cut-off"

Now... the trouble is this: The Prophet12 has LPF Frequency cutoff values from 1-164 (NOT just 1-127)...I notice that... when I record MIDI from the Prophet12, I get those lovely colorful lines of continuous control data with tons of plot-point dots for the values over time. It seems that the Prophet12 auto switches the CC#6 value from 0 up to a 1, to get more values for the CC#38. That covers the range of 1-164 in the by using a combination of values. And that means that, if I'm editing the MIDI data for that track... I have 4 different lanes of MIDI control data to adjust... and I can only see one at a time.

Here's the example of a common workflow:

I play a track from the prophet and capture the MIDI notes in Logic. Then I go back over with another track to do my filter-sweeps / knob moments on the Prophet12... capturing that MIDI data into Logic as well. I might or might not eventually merge those two tracks into one... but it doesn't matter. When played back, the playback is great (or at least as great as I was able to perform the knob-moments). But sometimes I accidentally sweep a filter too far / too quickly / too slowly, and I desire to go back into logic and move the control-data line... making sure it would fit into the time I need... or moving it's value up/down little.

Here's the trouble with doing that elegantly:

Since each of the 4 CC# messages that are simultaneously recorded from my knob movement on the Prophet12...end up on different CC lanes, I cannot view all 4 data types at once / cannot edit them all (cannot reposition dots from different CC# types at the same time. It seems that if your synth is responding to NRPN-grouped data... then for every plot-point that CC#38 moves, there needs to also be a plot-point on the lane for CC's 6, 98, and 99... and when you max-out CC#38, the CC#6 has to change value up to a 1, so that you can finish out the range on the prophet12, since it's values exceed 128 total. This is certainly complex... and I'm really struggling with how to best approach this.

I'd like to do either of the following

a) Find a way to elegantly grab & manipulate / re-draw the 4 different lanes of CC info that get captured SIMULTANEOUSLY, so that I can get my real-time performances of the knob-sweeps to be more refined after the fact. ...or

b) I'd like to find a way to build a Logic Environment Fader object that can more fluidly control the Prophet12 Parameters in a 1-for-1 way... instead of the 128-164 or 128-255 way... which results in the very stepped-sounding parameter changes.

I'm happy to create a video of my screen that further clarifies what I'm describing. I realize this is complex to discuss solely via text

 

[Markdvc]

Hi there, welcome to the LUG.

Just to clarify an obvious one:

if I'm editing the MIDI data for that track... I have 4 different lanes of MIDI control data to adjust... and I can only see one at a time.

Have a look at the attached screenshot. Here I have set up a simple logic project with a single external Midi track. I switched automation on, selected Midi Control Channel 6 and drew some automation in. I then added a second sub track to the external Midi, selected controller 38 and drew some automation. I then added another sub track, added CC 98, and finally another with CC 99.

It is fairly straightforward to add sub tracks - simply click on the white sub track disclosure triangle in the lower left part of the track header. After that, you can add as many sub tracks as you need.

HTH, kind regards

Mark

 

[Peter Ostry]

NRPN is always an issue under two circumstances:
1. If you need to manipulate it manually
or
2. if you have more than one MIDI stream in parallel, which may mess up your NRPN messages.

I can only suggest to keep NRPN as isolated as possible and don't let messages on the same MIDI channel in.

 

[AlexDingley]

Just to clarify an obvious one:
Have a look at the attached screenshot. Here I have set up a simple logic project with a single external Midi track. I switched automation on, selected Midi Control Channel 6 and drew some automation in. I then added a second sub track to the external Midi, selected controller 38 and drew some automation. I then added another sub track, added CC 98, and finally another with CC 99. It is fairly straightforward to add sub tracks - simply click on the white sub track disclosure triangle in the lower left part of the track header. After that, you can add as many sub tracks as you need.

Thanks Mark... I appreciate the thought on that suggestion, but it doesn't work very well ... given the nature of NRPN messages. When I real-time record my knob-movements... I get these string-of-pearls patterns on the midi cc line... and the line for every CC value is slathered with dots... because every time a value changes (using NRPN) it has to send ALL4 values across ALL4 CC parameters. It's a thick blast of data... See the compiled screen-shot below, called "4_layers"

I'm also posting a video Linked Here (it's about 10min long... forgive me: I'm trying to be thorough in explaining all of this) showing off the reason for why I'm trying to solve this (there is an audible difference when using simple CC messages vs NRPN-grouped CC messages) as well as some of what I've been trying to do to better-solve this. ... and ultimately, where I'm stuck.

Also... Thanks Peter, for chiming in...

NRPN is always an issue under two circumstances:
1. If you need to manipulate it manually
or
2. if you have more than one MIDI stream in parallel, which may mess up your NRPN messages.

I can only suggest to keep NRPN as isolated as possible and don't let messages on the same MIDI channel in.

...but That input doesn't necessarily sound sound very hopeful... Have you worked with NRPN data much before & have you found yourself successfully able to edit-after-the-fact without going, painstakingly through each different CC message lane?



Anyway... I'm hoping that someone out there can show me what I'm missing / doing wrong... or if there's a solid trick in Logic to make the arduous task of editing these multi-lane CC messages a little faster.

 

[Peter Ostry]

Have you worked with NRPN data much before

Occasionally I have to work with this stuff. Last time with a digital mixer that is controlled by NRPN. One single stream was no problem but if more then one stream was on the way, one flew into the other and everything got messed up. Data chaos because of wrong timing.

have you found yourself successfully able to edit-after-the-fact without going, painstakingly through each different CC message lane?

Yes, but only for isolated events. I do not edit streams (see reasons below) and normally I use the event list.

—

How NRPN works:

An NRPN message consists of 4 successive CC messages (actually 2 pairs of CC). They need to stay together and have a certain order. Only complete messages with all 4 CC messages get accepted.

NRPN works with MSB/LSB (Most/Least Significant Byte). This way we get a much greater range than 0-127, but we have to describe each value by 2 numbers (hence the "pairs" of CC I mentioned above). In one MSB/LSB pair, the lowest value is MSB 0 and LSB 0. You can turn LSB (fine tuning) up to 127, where the MIDI range ends. Then you set MSB = 1 (coarse tuning) and LSB can again be set between 0-127. Then set MSB = 2 and get another range 0-127 for LSB. And so on, over and over until both, MSB and LSB reach 127 where the game ends. Overall range is 128*128=16384 possible values.

Let's look at the controller numbers you posted and what they do:

CC#99 = Parameter MSB = Most Significant Byte = coarse data
CC#98 = Parameter LSB = Least Significant Byte = fine data
Together, these two events tell the number of the parameter to control.

CC#6 = Value MSB = Most Significant Byte = coarse data
CC#38 = Value LSB = Least Significant Byte = fine data
Together, these two events tell the value of the parameter.

The 4 events form what I call a "block of data". A block must stay together and have the correct internal order. This directly leads to a couple of potential problems with editing NRPN in a DAW.


Potential editing problems:

If you shift all values together up or down like normal CC events, you shift the whole blocks. Since one block contains the whole description (parameter and value), you finally control another parameter and within a range it is probably not programmed for.

If you have the parameter (CC#99 & CC#98) in one track and the value (CC#6 & CC#98) in another track, it is easier to leave the parameter as it is and only change the value by editing LSB (CC#38) and, if necessary, MSB (CC#6).

All 4 events on different tracks may be fine if you want a better overview. Just be careful to only move them vertically. Horizontal movement changes the order of events during the playback and disordered NRPN messages do not work.

Attention with graphical editing: LSB numbers (fine data) can be continuous and often they are. But MSB numbers (coarse data) set the range, they are never continuous. If you have a line from one MSB number to another one and this line actually sends contionuous data, the MSB will switch somewhere between and you can never tell where. The data range will jump and produce weird results.

Changing the time of events: If you move only one of the 4 messages in time, you may destroy the block of data and it does not do what you expect. Similar, if you cut one block and paste it right into another block. This destroys the other block and may also render the pasted block useless because of orphaned leading or following events which do not fit.

In Logic you can change the timing of NRPN messages in one or more tracks, or you can edit and copy/paste them in the event list (preferably with just one track/region). Be careful to always grab whole blocks with all 4 messages each. With this knowledge, editing isn't too hard for single blocks. With a stream like from a knob or fader it goes harder. Finally, with multiple streams like from a couple of knobs, manual editing gets complicated and you will find out, that recording the knobs again is much more effective (and probably more musical) than fiddling with thousands of numbers.

Another problem can occur if you turn 2 or more knobs on the hardware at the same time. The streams (the "blocks") may get mixed, losing their internal order and therefore the relationship between the values. A wrong parameter may get changed, parameter values may wildly jump or nothing may happen at all if the target does not understand what it receives.

MSB/LSB can introduce some difficulty with editing. Let's assume you want to edit a value, for example to make a filter more aggressive. You can shift the LSB (CC#38) up and down between 0-127 like a normal CC event. But the adjustable range is rather narrow, because the system expects the wider range of NRPN. If you want to go higher than 127, you need to increase the MSB value (CC#6) and pull the LSB (CC#38) down to start the new range. This is doable if you deal rather with switching than with continuous control. But in a long stream it can easily lead to errors which are hard to find.

More editing: Imagine a kind of modulation, where the value moves around the border between MSB numbers. For example, if the value goes 120-136-124-142 or like, cycling within and outside of 0-127. Editing such a thing means to constantly alter the MSB and the LSB numbers. Honestly, my brain is not built for things like that, I give up when I run in such situations.


My suggestion:

You can successfully and relatively easy edit NRPN if you switch parameters or set new values from time to time, with enough space between to identify the event blocks easily in a region or in the event list. You rather not want to edit continuous NRPN streams. In this cases I recommend to record the movements again.

This is only my rule of thumb, your milage may vary.

 

[AlexDingley]

You rather not want to edit continuous NRPN streams. In this cases I recommend to record the movements again.

This is only my rule of thumb, your milage may vary.

Peter, Again— thanks for the detailed reply. This is still very discouraging. and it makes me want to look into a 3rd party plug-in that supposedly handles all of these control issues through an actual insert option. It's just that the company who makes the plug-in doesn't seem super-robust / responsive, so I'm wary of paying for something that won't have great support / continued support over time.

I'm just gonna keep dangling lines in forums like this for a while to see if anyone else has more clever ideas of ways to approach it so that I CAN edit after the fact. I get the idea of "play it again" / "play it better" but I'm talking about really intricate movements that occur very quickly while playing very intricate synth solos...etc. So, I know my limits— I'm not gonna get that good.

 

[Peter Ostry]

A plugin that receives and sends NRPN and MSB/LSB may help. I don't know such a thing. Maybe you find a programmer who can script it in the Logic Script Editor.

John Pitcairn has an old Logic Environment patch in his website, that handles MSB/LSB. I don't know if it can help you or not, haven't looked at it for a long time. It is called "event_routers.lso.sit" and you can download it from here: https://www.opuslocus.com/logic/

 

[slipperhero]

Just to mention Alex that i'm experiencing exactly the same issue with my DSI Pro 2, so i feel your frustration! If you do find an elegant solution to edit NRPN data in a single Midi Draw lane, please be sure to post your findings. I will of course do the same if i find a solution first.
Good luck!

 

[Tangra]

Hi,
The most powerful Logic feature for controlling such hardware synths is called "SysEx Fader".
You can create any Environment Fader/Knob and assign its Output definition to "SysEx".

1. The "SysEx" Fader opens a wizard which is similar to the Logic Event list. Here you can create multiple MIDI messages you want to be sent out.
Note: You must select the messages (in that "Sys" Event list) which have to send variable values during the single "Input" message (see below).
Non - selected messages in the list will send constant values!

2. The Fader "Input" definition can be assigned to any CC#. In this scenario you can draw or record a single CC line and output multiple CCs (or any MIDI events) via the Sys Fader Output. E.g the "Sys Fader Out" behaves as a MIDI container which can send multiple MIDI events programed in its "Sys" event list.

3. Finally if the "Sys Fader" setup works with some of the hardware Synth (main) parameters, you may need to create a complex Logic Environment setup where you have to use lots of Transformers and objects to follow the hardware specifics.

 

[AlexDingley]

Okay — this thread has languished for a while, and I had basically given up on solving this... So much great advice was provided here, but yeah— the answer was NOT within Logic, nor the environment.

I ended up springing for the Plug-In that acts like a virtual instrument, but really just uses a GUI from the plug-in to NRPN / SysEx control the Prophet12... and it's awesome: SoundTower makes a whole series of these GUI plug-ins and the prophet one is linked here.

I just installed it, and it runs beautifully. I'll probably end up putting a blog post up about it because it works so well.

 

[paulnajar]

Sorry only just noticed this thread. I too have a Prophet 12 and have the same challenges with NRPN’s.

I have on occasion been able to edit NRPN knob performances in automation lanes but it has been guess work. Edit a line, play it back see if there’s a change etc. This got me where I needed to go but like I said it was guesswork.

It’s a shame there’s not a plugin to extrapolate all 4 CC’s and interpret it into an old fashioned single CC lane.

Just dreaming...

 

[AlexDingley]

It’s a shame there’s not a plugin to extrapolate all 4 CC’s and interpret it into an old fashioned single CC lane.

I never really thought about a MIDI-plug-in for something like this... but that would have been cool. That said, the Sound Tower plugSE plug-in is REALLY GOOD. You end up using Automation lanes to run the knobs of the plug-in... which, in turn, send the NRPN data to the Prophet, and it works gorgeously... So, in truth, there is a plug-in that does this... it just doesn't happen on a CC lane in the Piano Roll Editor. When I have a little time, I'm going to put together a little annotated graphic, or a video to explain this further because it really is impressive to work with. You get knobs for EVERY parameter across Engines A & B of the Prophet12 (and each one seems to transmit the full resolution, even though I'm using Logic's automation lanes which, I don't believe, are far more detailed than regular MIDI CC values)... so it's actually going to open new possibilities for me

 

[paulnajar]

Interesting you went for the Soundtower plugin. I tried that and while the editor part worked well, having the plugin on created an unacceptable midi delay when trying to play the synth form it’s own keyboard in Local off mode or trying to trigger the synth from another Midi controller through logic (the normal signal flow) I tried to get support for this as I liked the idea of the plugin but couldn’t get a clear answer from the developer on this. Maybe he fixed it? I went with the standalone version instead. I’m more used to that workflow as I have the editor for my Prophet 08. I’m a bit of a DSI fanboy I suppose...