On Sat, 8 Jul 2017 09:42:14 -0700 "J. Liles" <[email protected]> wrote:
> 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). Thanks for the information, Jonathan. I had previously used Non-midi-mapper (nmm) in another test session because I had failed to get mididings to compile (a Boost version problem). I seem to recollect I had got nmm to work for one slider control so I am pretty sure I can go back and tackle it with more enthusiasm now. My memory has lost the details but I had pursued the mididings path partly on account of the wiki "recommendation" and partly because the documentation for Non-Midi-Mapper is brief, together with my almost total lack of understanding of the underlying technologies (OSC, midi CCs, control 'learning'). It left me thinking I would have a better chance of getting some use from the Numark controller if I tried the mididings script (dodged the Boost version number problem by using an earlier mididings). If I understand you correctly the two port numbers reported in the NSM session console BOTH refer to communications channels; one between NM and NSM and the other between NM and NT. Does that mean there is a third server port used by NM for parameter control which is not reported to the console? Don't worry, I will consult the source for the answer to that one .... maybe .... one day :~) -- Richard <[email protected]>
