On Sat, Jul 8, 2017 at 8:54 AM, Richard <[email protected]> wrote:
> Hello to the List on a gloriously sunny Saturday, > > I should be outside trimming hedges or fixing cracks in a concrete path, > so I will make this brief. > I have been trying to test the "non-mapping.py" mididings script from the > wiki page; http://non.tuxfamily.org/wiki/UsingMidiWithNon > > Success is mixed. I can make it work with a standalone non-mixer but not > at all when used in an NSM session. The problem seems to be the correct > identification of the OSC port used by non-mixer. > > Method 1: launch non-mixer from console > The correct OSC port number appears immediately after the non-mixer > sign-on. I copy this port number to the script and launch "mididings -f > my_script". I use qjackctl to connect my Numark Total Control midi > controller to mididings and the slider controls I have mapped produce the > desired effects on the two Pan and Gain controls (as described in the > example non-mapping.py script but using different CCs) in the mixer. > > Method 2: launch non-mixer from console with the --osc-port=nnnn option > The expected OSC port number appears immediately after the non-mixer > sign-on. I launch "mididings -f my_script" having configured the > pre-selected port number. I use qjackctl to connect ... the rest is the > same as above. OK so far. > > Method 3: Launch NSM from a console and choose my mididings test session > (mixer as above and non-timeline connected so I can hear the results) > The first step is to stop the NSM-Proxy controlling mididings because the > configured OSC port number will not be correct. Next job is to examine the > console output to find the sign-on message from non-mixer and its OSC port > number report. Copy this port number to the mididings non-mapper.py script > and launch it. Use qjackctl to connect my Numark Total Control midi > controller to mididings (jackpatch may have done this already). Testing the > operation of the midi controller slider controls shows that nothing is > working. Re-scrutinising the console output from the NSM session shows > that there is a later reference to the non-mixer osc port, but it is a > different port number. Stop/start Non-proxy to re-edit the non-mapper.py > script and use this alternative port number and the results are the same - > no result. > > The typical output in the console from NSM starts with > > The Non-Mixer 1.2.0 -- Copyright (c) 2008-2013 Jonathan Moore Liles > OSC=osc.udp://Caldera6.local:13198/ > > but then we get this: > [non-mixer] Announcing to NSM > [nsmd] Got announce from Non-Mixer > [nsmd] Client was expected. > [nsmd] Process has pid: 3881 > [nsmd] The client "Non-Mixer" at "osc.udp://192.168.1.89:14701/" informs > us it's ready to receive commands. > > after a lot of LADSPA exploration from non-mixer and some connection > fixing from jackpatch we eventually get a sort of confirmation of the first > stated port number from non-timeline: > [non-timeline] Got hello from NON peer Non-Mixer (1.2.0) @ > osc.udp://Caldera6.local:13198/ with ID "Non-Mixer.nQSGM" > > Sadly neither 13198 nor 14701 appear to be usable by non-mapper.py - I try > both. > > Is there a good reason for having two identified OSC ports? > Is it significant that the sign-on report uses the machine name and the > later report from nsmd uses dotted quads? > > Any suggestions will be gratefully received (unless it is to go and trim > the hedge:~) > > > > -- > Richard <[email protected]> > > > It's a little confusing because NM is using two OSC ports speaking two different protocols. One for communication with NSM and another for parameter control. Anyway, there's a much easier way to do what you want: use non-midi-mapper. Just add it to an NSM session and then connect your controller to it, and use the MIDI learning functionality in non-mixer to assign all your controls. Non-midi-mapper does the translation between MIDI<->OSC is able to deal with the dynamic OSC port non-mixer providers (by discovering it through NSM).
