24 Mar
2010
24 Mar
'10
3 p.m.
Nick Copeland wrote:
What I'm thinking of is to map controllers
e.g.
CC 7 + data byte should become CC 10 + data byte
CC 6 + data byte should become CC 7 + data byte
CC 6 doesn't need to be used in context with RPN/NRPN
It's a little bit harder to map CC to SysEx
CC x + data byte should become SysEx with a data byte and checksum. I'm
not sure if a checksum always is required, e.g. just for changing a filter.
Some people only have got a keyboard with a data
slider, e.g. the DX7
has got one, sending CC 6 (RPN-/NRPN-Controller). I once wrote an app
for the C64 converting those controllers that can't be changed by the
keyboards them self, so I was able to control any other controller for
my Atari ST, resp. hardware synth and effects.
I guess such a CC mapping manager is useful for Linux too and would
solve Louigi's problem. Unfortunately I can't help, because I can't
program for Linux, but such a task isn't something that needs much
effort to be programmed for people who are familiar with the OS and C.
I agree that RPN/NRPN could be better handled but that does not get
around the issue that NRPN #1 to Ableton Live will mean something
different to another softsynth - the uses are not registered, as such
what they do is inconsistent and was the main reason I advised clearing
the controller settings.
I can put RPN/NRPN support back into bristol but it still means the
controller needs to be reconfigured so that the NRP ID assigned to
the bristol synth controller mappings do not conflict with those used
by any other synth on the chain. Will forward the offlist discussion and when I have
better results from
some tests with Louigi we can submit a resume.
Thank you. I guess RPN/NRPN fortunately isn't used very often. Btw.
http://de.wikipedia.org/ is off, I wanted to take a look, I can't
remember how exactly RPN/NRPN is handled. I have to be out now. I bite
back any comment about RPN/NRPN for now.
Ralf