On Sat, Jul 8, 2017 at 11:19 AM, Richard <[email protected]> wrote:
> 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 :~) > No, just two. The OSC::Signals protocol has multiple levels though, a lower level accepting basic OSC messages and a higher level with the discoverable signals with feedback etc. that Non-Timeline speaks. Neither MIDI nor OSC are very user-friendly at all (obviously), what with all the CC numbers, port numbers, message paths etc., which is why I recommend going the mapper/learning route. One tip: If you want to reuse that mapping, the best way to do so ATM is to create a blank session with the stuff you plan to use (strips/plugins, etc), do all the mapping/learning, then save that and use it as a template for your real sessions via the NSM duplicate function. You can transfer a mapping to an existing session, but you'd have to do it by copying files around---there's no support for that in the GUI. > > -- > Richard <[email protected]> > > >
