NRPN and CC from a Novation ReMOTE 25?

Hi everyone - I know similar questions have been asked before but I’m still struggling to figure this one out…
I’ve made a template to control my Shruthi from a ReMOTE 25 and the CC parameters work fine (Osc shape, filter res etc etc)
But I’m having no success with all those parameters that you can only access through NRPN like Mod Source etc.

Has anyone actually solved this one yet?

Update:… I tried switching osc1 par ( an easy one to control ) to nrpn using msb0 lsb1 low value 0 high value 127 and it still doesn’t work. When I switch osc1 par back to CC21 it works fine.
The display indicates that my Shruthi is receiving data but nothing happens.
Does this mean it’s not responding to NRPN or does it mean my remote is sending the wrong data? Please help! :frowning:

The Shruthi must respond to NRPN… Use a MIDI monitoring/capture program to see what the Novation sends exactly and I’ll tell you whether it’s the right format for the Shruthi…

ok - thanks
I’ve set NRPN 103 (groove amt) and the midi monitor picks up this:
11:36:44.293 From ReMOTE Control 1 Non-Registered Parameter MSB 0
11:36:44.293 From ReMOTE Control 1 Non-Registered Parameter LSB 103
11:36:44.293 From ReMOTE Control 1 Data Entry (coarse) 81

The only value that varies is the coarse which responds to slider position ( 0 - 127 )

Can you configure the controller to right-align the data entry control (send the LSB message instead of MSB)? The Shruthi uses the LSB for the 0…127 range, and use the MSB message when the value exceeds 127.

I’m not sure - here’s a screen shot of the config options… I’m also trying to set buttons to step through some of the modes

Bump… Any ideas anyone?.. Plleeeeeeaaaase!

I would give it a try to change the numbers according to Oliviers statement for LSB to 0 and MSB 128 and then retry…

It is not possible.

@tribo can you share your template ? do you know whether it will work with Remote SL MK II ?

@ cereyanlimusiki - here is the template - I don’t know if it will work with an SL MKII - give it a try! :slight_smile:
@ pichenettes - ok - thanks for looking at this problem
Phil - Shruthi.syx (2.8 KB)

>>The Shruthi uses the LSB for the 0…127 range, and use the MSB message when the value exceeds 127.

This is understandable from an IT programmer’s point of vue, but it goes against the usual way MIDI is used to handle data. When a parameter requires a value between 0 and 127, the most common MIDI usage is to put its value in the MSB and not to use the LSB (which could not be less significant than non significant). The reason behind this is to use as few bytes as possible.

I understand you want to keep “straight” in your IT programmer’s logic, but please understand this can give us users hard times programming our MIDI controllers.

All the Shruthi parameters which fall within a 0-127 range should have their values sent/received with CC#6 only, and CC#38 should be ignored, and this includes negative values -63 to 63, it’s only a matter of how they are interpreted. Please see how e.g. Roland implement NRPNs (example here). The MIDI norm says Controller 6 (called the Data Entry MSB) sets the parameter value directly, and Controller 38 (called the Data Entry LSB) may optionally be used as a fine adjustment to improve on the precision of the parameter value.

Thanks for the suggestion, but editors have already been written for the present NRPN format so I won’t change it.

I ran into the same problem with my novation and figured pichenettes wouldn’t make the change before asking, but its too bad i cant use my remote25 as a surface editor for the shruthi. Computers bad Maybe we can get a midipal filter that swaps msb and lsbs instead :smiley:

Head aches come and go, usually I don’t remember them.


I guess now you’re aware that you can chose between conforming to the MIDI logic or going against it, and that your choice can make your clients’ life easier or harder when it comes to using MIDI controllers or software.

There’s a reason why there are so many threads about NRPN. Users are not always stupid, sometimes when they complain there might be a real issue…

@herrprof Thinking of it, this could be an MI business model :slight_smile:

@Georges: You make it sound like it’s an easy alternative. Don’t forget the body of third party editors and tools that have been developed for the Shruthi. It’s in the same category as requests breaking the patch format. I’ll surely think about it for a v2.0 of the firmware (which would break patch compatibility anyway) if there ever is such a thing.

If you think I’m stupid and you would do things differently if you were sitting on my chair, then just do it! - everybody will thank you for that.

Just because big Manufacturers are not able to comply to the MIDI Specification which by the way is now 30 years old therefore the unability of some Manufactureres to handle NRPNs right is more than embarassing - means that small Manufacturers should follow this just to make some customers happier.

Making a few customers happy by not following the standard will piss of many others because standard is standard and thank God MI products comply with it, else it wouldnt work with much more gear is it would work with. You wouldn’t be very amused if PutYourFavouriteElectroniDevicesBrandHere would decide to ignore the standards in your Area and use totally different Mains Plugs and Voltages. Or some Gas Station would decide to fill something different in their Tanks…

If you want to change anything then its time to stop complaining and do it yourselves - MI Sourcode is open source and you are free to change it in any way you like - go ask Ableton if you can have their source to make their code apply to the standard. If you are not able to then you should accept MIs design decisions, just as you accept Abletons.

It’s not really a matter of MIDI standard - which is really ambiguous on the point of NRPNs anyway since it introduces state that is not as well documented as the running status, and since things got broken into multiple messages (you receive a MSB change - what should you do? Change the parameter now and introduce an extra jump if you get the LSB later? Should the MSB always be sent before the LSB? Should there be a wait period before processing a message to be sure all bits have been received).

It is whether all NRPN for a product should be sent with the same format (right aligned or left aligned). I have favored a simple, consistant, and non-ambiguous implementation in which all parameters are always sent with MSB and LSB, with right-aligned data (treating the MSB/LSB pair as a 14-bit signed number) - so that it works for all parameters. Novation has not planned for that and their NRPN implementation only addresses the MSB. Other controllers like the good old BCR2000 happily send 14-bit NRPNs with their faders.

And what I’m doing is not that silly - the Alesis Ion/Micron does it too.