On Sat, 8 Jul 2017 11:52:32 -0700 "J. Liles" <[email protected]> wrote:
> 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. > > -- Thanks for the hint about OSC::Signals. I found another reference to this in an old list message (Re: [non] Controller with feedback for G/linux audio - from 2014-01-30) so nonlib src is on my list of things to investigate. It may be useful for a silly little toy project I wrote a few years ago - it's just a GUI written using Gambas 3 to control Jack_capture + jkmeter/meterbridge + something else I've forgotten. I am re-visiting it to see if I can find a way to make it NSM-aware and controllable/controlling by OSC. Should keep me busy for a winter or two. Right now though, I am re-examining my previous successful use of Non-Midi-Mapper to see if I can understand what I did. (did you ever find yourself looking at code you wrote a while back and not remembering writing it? Happens to me all the time :~( Thank you for all your help (past & present) -- Richard <[email protected]>
