Firmware V1.28 Test Version

[Renzki]

Howdy, here is a question about NRPN in relation to the new mapping tool on 1.28b

I have read this thread: https://xor-electronics.com/forum/showth...p?tid=1021 and many other papers available about NRPN (I never used it)

I'm trying to record an NRPN signal from the Arturia Minilab 3 that controls let's say, the analogue cutoff of the Erica Synths Black Dual VCF. I have entered the following on the mapping tool:

00_MCC_CH1_#6    > CV_PICH_CV1
01_MCC_CH1_#98  > CV_PICH_CV1
02_MCC_CH1_#99  > CV_PICH_CV1

On the keyboard, I have knob 1 configured to NRPN 1:1 (I tried all scales).

The ctrl message goes to the VCF, however there is a scale issue or something that keeps coarse scaling, I can hear it like it has only 128 divisions when moving the encoder, still far down from the 14bits.

Is there anything I'm doing wrong?

Thanks

[XORadmin]

Howdy, here is a question about NRPN in relation to the new mapping tool on 1.28b

I have read this thread: https://xor-electronics.com/forum/showth...p?tid=1021 and many other papers available about NRPN (I never used it)

I'm trying to record an NRPN signal from the Arturia Minilab 3 that controls let's say, the analogue cutoff of the Erica Synths Black Dal VCF. I have entered the following on the mapping tool:

00_MCC_CH1_#6    > CV_PICH_CV1
01_MCC_CH1_#98  > CV_PICH_CV1
02_MCC_CH1_#99  > CV_PICH_CV1

On the keyboard, I have knob 1 configured to NRPN 1:1 (I tried all scales).

The ctrl message goes to the VCF, however there is a scale issue or something that keeps coarse scaling, I can hear it like it has only 128 divisions when moving the encoder, still far down from the 14bits.

Is there anything I'm doing wrong?

Thanks

NRPN is a subset of CC messages and what you actually do in your mappings is only using the plain cc values which would need to be calculated together to get your result. This is theoretically possible by making calculations on the #98 , #99 receptions to get the NRPN number and #6 and #38 to get the value, but it’s not an elegant way.
I was planning for NRPN support for the mappings but I am not sure if it will make it into this release.

[yrn1]

There are too many pages on this thread. We urgently need a new one called ‘Firmware V1.28’  

[Renzki]

NRPN is a subset of CC messages and what you actually do in your mappings is only using the plain cc values which would need to be calculated together to get your result. This is theoretically possible by making calculations on the #98 , #99 receptions to get the NRPN number and #6 and #38 to get the value, but it’s not an elegant way.
I was planning for NRPN support for the mappings but I am not sure if it will make it into this release.

What do you mean by NRPN support?

I prefer elegance to depravation however I only miss on the dress code. If you can point me towards a direction, I will be happy to read things in order to dress the part.

[XORadmin]

NRPN is a subset of CC messages and what you actually do in your mappings is only using the plain cc values which would need to be calculated together to get your result. This is theoretically possible by making calculations on the #98 , #99 receptions to get the NRPN number and #6 and #38 to get the value, but it’s not an elegant way.
I was planning for NRPN support for the mappings but I am not sure if it will make it into this release.

What do you mean by NRPN support?

I prefer elegance to depravation however I only miss on the dress code. If you can point me towards a direction, I will be happy to read things in order to dress the part.

NRPN as mapping source / destination.

[Renzki]

That's okay for now, there are plenty of fancy hex calculators online and I can gobble the information available on midi.org

Are you planning to implement midi 2.0 to NerdSeq at any point in time?

[XORadmin]

That's okay for now, there are plenty of fancy hex calculators online and I can gobble the information available on midi.org

Are you planning to implement midi 2.0 to NerdSeq at any point in time?

If you use only one controller then you could use the results of controller 6 and 38.
Shift left controller 38 for 7 times and add or OR it with the value of controller 6.
You would miss 2 of the 14 bits here but it probably does the job already.
Trust me you won’t get too happy reading the information from the original midi.org document.

I don’t think midi 2.0 will be a thing for the upcoming few years. As long as it is only implemented by some demo synths of major manufacturers it doesn’t make sense. I don’t see it implemented at all in all smaller equipement. And there has been the new midi since a long time and it bever took off. So probably wasted time for now.

[XORadmin]

Howdy, here is a question about NRPN in relation to the new mapping tool on 1.28b

I have read this thread: https://xor-electronics.com/forum/showth...p?tid=1021 and many other papers available about NRPN (I never used it)

I'm trying to record an NRPN signal from the Arturia Minilab 3 that controls let's say, the analogue cutoff of the Erica Synths Black Dual VCF. I have entered the following on the mapping tool:

00_MCC_CH1_#6    > CV_PICH_CV1
01_MCC_CH1_#98  > CV_PICH_CV1
02_MCC_CH1_#99  > CV_PICH_CV1

On the keyboard, I have knob 1 configured to NRPN 1:1 (I tried all scales).

The ctrl message goes to the VCF, however there is a scale issue or something that keeps coarse scaling, I can hear it like it has only 128 divisions when moving the encoder, still far down from the 14bits.

Is there anything I'm doing wrong?

Thanks

I did some research and I am not sure if the Arturia products send proper NPRN messages which use the 14 bit range for values at all. All I can see is that they send either coarse or fine and not both at the same time. (Like typically 3 packets instead of four which is theoretically OK following the Midi specs. But the specs are very inconsistent here and totally allow incompatibility between different gear) 
So you could send only one of these 2 parts per controller while you need both parts to create a 14 bit value. And each part is 7 bit = 128 divisions. What you end up with are a high amount of possible controllers bit each with only 128 steps. Using NRPN with these controllers would be a step back compared to just send CC.

[Renzki]

I did some research and I am not sure if the Arturia products send proper NPRN messages which use the 14 bit range for values at all. All I can see is that they send either coarse or fine and not both at the same time. (Like typically 3 packets instead of four which is theoretically OK following the Midi specs. But the specs are very inconsistent here and totally allow incompatibility between different gear) 
So you could send only one of these 2 parts per controller while you need both parts to create a 14 bit value. And each part is 7 bit = 128 divisions. What you end up with are a high amount of possible controllers bit each with only 128 steps. Using NRPN with these controllers would be a step back compared to just send CC.

I will email them up to find out if indeed those NRPNs are proper, as in, as per the midi.org information.

Talking about midi.org, I did find a table called something RPN https://midi.org/specifications-old/item...ta-bytes-2 and found some values that were similar to the ones I had played with last time, but the result was similar, as in still in the 128 div range, but here again, I aint an expert with that, so I may post my question to Modwiggler and see if I can gather anything of interest.

I mean, I can start with creating my live system with only midi cc values but I'm so close to get a definite response to see if its possible or not that it would be foolish for me to let go of my diggings. Even though, I may find a work arounds, who knows.

This midi 2.0 makes a lot of sense to me, and yes I remember that the last upgrade didn't take off, but this time it seems like they are onto something definately of interst, at least for those like myself who wants to record modulations and be able to recall knob positions out of a midi click.

[XORadmin]

I did some research and I am not sure if the Arturia products send proper NPRN messages which use the 14 bit range for values at all. All I can see is that they send either coarse or fine and not both at the same time. (Like typically 3 packets instead of four which is theoretically OK following the Midi specs. But the specs are very inconsistent here and totally allow incompatibility between different gear) 
So you could send only one of these 2 parts per controller while you need both parts to create a 14 bit value. And each part is 7 bit = 128 divisions. What you end up with are a high amount of possible controllers bit each with only 128 steps. Using NRPN with these controllers would be a step back compared to just send CC.

I will email them up to find out if indeed those NRPNs are proper, as in, as per the midi.org information.

Talking about midi.org, I did find a table called something RPN https://midi.org/specifications-old/item...ta-bytes-2 and found some values that were similar to the ones I had played with last time, but the result was similar, as in still in the 128 div range, but here again, I aint an expert with that, so I may post my question to Modwiggler and see if I can gather anything of interest.

I mean, I can start with creating my live system with only midi cc values but I'm so close to get a definite response to see if its possible or not that it would be foolish for me to let go of my diggings. Even though, I may find a work arounds, who knows.

This midi 2.0 makes a lot of sense to me, and yes I remember that the last upgrade didn't take off, but this time it seems like they are onto something definately of interst, at least for those like myself who wants to record modulations and be able to recall knob positions out of a midi click.

Well they follow the specification. But the specification allows to just use 128 steps with just not sending another additional packet.
They are enough discussions out there, also about Arturias implementations.

...recall knob positions out of a midi click.

That is called program change :-)

From the RPN sheet of Midi.org you linked to (Where RPN is similar to NRPN with it's packet arrangement)
"2. To set the selected Registered Parameter to a specific value, send a Control Change messages to the Data Entry MSB controller (Control Number 6). If the selected Registered Parameter requires the LSB to be set, send another Control Change message to the Data Entry LSB controller (Control Number 38)."

This shows it nicely:
The LSB is optional which makes it a really weird thing as the receiving side can't really wait until that last packet for the LSB comes or doesn't come. So if the sender allows only 128 steps anyways, then they most probably skip that last byte, but then it doesn't make sense at all to use NRPN for it (except if you have more than 128 parameter types on the receiver side). Then it is 2 or 3 bytes vs. 9 or 6 bytes for the same thing. Also if it uses 14 bits, then it is even 12/8 bytes and that would mean that higher resolution comes at a cost of midi data traffic AND a significant delay until the complete package is sent out (people even say that this is audible).
Just to be sure, this is not a NerdSEQ issue! I will allow it to receive 14 bit NRPN messages. But the 7 bit ones don't make sense here and will not be supported.