Script Loading PMAP Files?

Is it possible for a Norns script to load a PMAP file?
Or to push preset mapping data for particular controllers into an existing PMAP file (and subsequently make those mappings ‘live’)?

1 Like

Just bumping this one, as I’d really like to know if there IS an official way to do this.

hi hi! hope all’s well :slight_smile:

since PMAP files are one-per-script, the pmap.read function doesn’t currently accept a filename – it just searches the data/<script name> folder for the <script name>.pmap file and loads it into the params.

your script could repurpose the pmap.read function at a script-level, but mapping also infuses the device slot (eg. dev=3) into the .pmap file, eg:

"out":"{cc=100, in_hi=127, value=0, ch=1, out_hi=5, out_lo=1, accum=false, dev=3, in_lo=0}"

this means that the user also needs to assign the controller to the same slot as your template mapping – not a terrible inconvenience, but could be a point of unnecessary extra support. if the end-goal is to distribute a script for a specific controller, then i’d recommend the paths laid by Sempra 1.0.6 and Haze - four track live granular looper, which are loosely:

  • at script boot, query all slots to find the intended device
  • interpret MIDI events from that device and assign incoming values, channels, etc to control different parameters in your script (eg. using params:set(<parameter>,<value>) to show changes in the params UI)
  • optionally, push data back to the device with state changes (useful for rewriting LEDs on a MIDI Fighter Twister, for example)

hopefully that points toward the desired outcome, perhaps with the ref page for MIDI as well as the MIDI section in study 4? if there’s any specific trouble / ambiguity, happy to help – just lmk! :slight_smile:

2 Likes

Hi @dan_derks thanks for the detailed reply.

I may just suggest some assignments for particular devices, in that case.

Sounds like it might be worth my writing some kind of framework for preset mappings for particular controllers, in that case, or maybe having a go at adding parameter feedback to MIDI devices to the existing middy add-on.

Is some equivalent to PSET save/load for PMAP files in the roadmap for future development?

Might not be the right place for it, but I have a couple of other suggestions

You’ve already touched on one - feedback to MIDI controller. How about also adding some different options for “soft takeover” of params when MIDI hardware controller pots etc. become “out of sync” with the value of the parameters they’re mapped to (ie following recall of a preset)?

its trivial to make those pmap.read() and pmap.write() accept path arguments, but in the end reading an arbitrary fle is still a desructive operation on the default .pmap (which will be overwritten on script unload/SLEEP etc.) so i’d kinda favor leaving it as is - if your script wants to populate the default pmap on first run (or any time) then that’s fine. (probably nice to save a backup if it isn’t first run.) (yes this is slightly less convenient than using an API but maybe that’s appropriate)

making a menu for PMAP management would i guess be straightforward but of course more work and potentially breaking for scripts. no plans to do that right now.

i think we have an issue thread on GH regarding two-way controller binding. nobody really seems to want it badly enough to take it on as a project.

That was my initial thought, I have to say. I wasn’t sure if the new settings would become active immediately, though, or if the script would have to be reloaded.

I’ve fallen back on a stripped-down version of Middy (don’t need the loop-recorder functionality right now), with a map file for the particular controller. Not sure whether I should modify the script to check for that particular device and auto-load the map or leave it to the user to load it via the Menu.

That’s a shame, but understandable. It’s reflective of the fact that relatively few MIDI controllers would benefit from such a feature, I guess. The LaunchControl XL I have here has some illuminated buttons/pads, and it would be nice to have them light up to indicate the status of some binary-type params, but it’s not a major priority.

On the other hand, I have a FaderFox EC4 I bought recently, and that has endless encoders rather than sliders or rotary pots, and a display that can show the current values of all the controls. Parameter feedback would be really useful if I were to use that.

UPDATE 2022-06-10

I’ve decided, for the moment at least, simply to have my script copy across a pre-prepared .pmap file for the Launch Control XL controller from …code/scriptname/ to …data/scriptname on first run.

The .pmap file specifies slot 16 for all controls, so I’ll add instructions in the script docs to add the specific controller (assuming the user has one) to slot 16, and it should “just work”.

I’ve also added an options in params to clear the .pmap or restore the default mapping by copying it across again.