#707

My Apple Magic Keyboard is functional and pops up in the HID menu. Had to change the layout to match my Norwegian key set in raspi-config thou.

#708

Does this fix your Orca keymapping problem?

1 Like
#709

Nah, unfortunately not. It works as intended in terminal, but not in HID/Orca :frowning_face:

#710

Anything Bluetooth wont work at all. It’s not yet supported in norns software (which only looks at the USB subsystem).

Still totally don’t understand why a wired USB keyboard wont work tho.

#711

Ok then - it’s gonna be something with the libs I mentioned in the Orca thread. If I had a non-qwerty keyboard I could test and figure out a solution.

1 Like
#712

Any pointers? Could try and check/poke around tomorrow. This is the layout:

image https://upload.wikimedia.org/wikipedia/en/c/c9/Keyboard_Layout_Norwegian.png

I guess I could just do a “translation” of the buttons based on the HID output and change that in the lib.

#713

If one wants to make some small kernel adjustments, even if you have everything up and running, is it safe to run make menuconfig, adjust stuff, then just run make? Or will that mess up my build?

#714

yeah, we just get keycodes from libevdev. we have to do the same localized keycode-mapping task that terminals do if we want to support different layouts.

iirc just made the tables from the output of something like this using US-qwerty keyboard

… oh right and i think looking at /usr/include/linux/input-event-codes.h

given that this layer of stuff seems independent of terminal localization settings, probably best to remap at the ‘library’ level in lua

1 Like
#715

ok so got somewhere with this got RpiNorns to recognise my keyboard by changing vport.lua line 13 from name to port, et voila. :smiley:

#716

Folks, who have used WM8731 as their DAC solution, System -> Audio -> Headphone setting has no effect on my headphone out level. Have any ideas for how I fix this?

#717

Norns uses a separate DAC and i2c commands for headphones - so this menu option won’t really work with any other DAC without some core changes.

I’ve not gotten that far, but can add it to my list of possible enhancements with my WM8731 DAC board.

2 Likes
#718

I didn’t know Norns uses separate DAC for headphones. It’s not super important for me but it would be nice to have that control. Thanks Steven.

#719

to clarify, it’s not a separate DAC, but a separate headphone driver. basically a i2c-controlled amplifier.

if anyone if interested i wrote up all of the details to the norns hardware here: https://github.com/monome/norns-image/blob/master/readme-hardware.md

5 Likes
#720

hi there would it be possible for me to alter your tb2.0 code for two push2’s to work as an 8x16 emulation without too much bother or would i need to rewrite a lot of code if so which areas would i need to delve in to uncover such wealths. by the way i dont hve two push2’s (££££££££) i have aquired another launchpad mini for £10. and with your help got that to act as an 8x8 grid with success. :wink:

1 Like
#721

anything is possible , its SMOP :wink:

as you say the $$$ is the issue… how many have 2 push2s? how to test etc.

as for code changes, most of the code should be totally fine with 2x push2.

the only assumption I’ve made about ‘singularity’ is where it was necessary in the Norns code.
e.g. one that springs to mind is the the emulation of the screen - norns has no concept of more than one screen in the lua api - so the Push2 registers its screen as the display for norns. but that could easily be made optional by configuration.

I think it should be possible for the push2 ‘native api’ to allow access to a specific push2s display.
(it might even be there already, I’d need to check) - I cannot see why you would want to use multiple push2 without using their displays given the $$$$ we are talking.

in summary, I don’t think there would be many changes needed, its likely just a matter of testing, and resolving any small issues… which means finding someone with 2 Push 2s… Ive not got the spare $$$$ to do this :wink:

however, I think what I would do first, is look at the concept of combining multiple physical grids into a compound grid - this would be done at the ‘virtual grid’ layer, so that individual scripts would be oblivious to this… this would be a pretty simple change (if its not already supported?!)

then this would mean that you could use 2 x push2 , or a much more affordable solution with 2 x launchpads!

(it would also be cool to extend the norns lua screen api to support multiple displays, but I think that is probably not something many need, so low priority - though might take a look at this when FATES becomes available )

2 Likes
#722

Many thanks for this with some fiddling can get norns to recognise grid presses from both launchpads. the problem seems to be how norns sends light information to launchpads as none are showing up on launchpad2 . would this problem be in matron or lua as the 2 grids are being recognised in devices/grids and sending correct presses just not receiving the blinkin lights. :grinning:

#723

is this only a problem with the 2nd launchpad… or are you saying its specific to launchpad2 (model?)

if it’s the former, do you have them setup as separate midi controllers? and then send midi msgs specifically to that second controller?

honestly, Ive not tried to send midi data to a second midi device, so perhaps there is a bug or lua api has specific calls for non-default device … I guess first step is to work out if the issue is specific to the launchpads, or just sending data to a second device is not working as expected…

#724

yes only a problem with the second launchpad. ive tried them as seperate midi controllers and as the same midi controller with the same results. when i plug the second launchpad in it becomes the default launchpad and the other loses its lightshow although as ive said it still recognises pad presses. thanks for the troubleshooting ideas, something to go on. :wink:

#725

did you base this on my push2 code?

see in the push we have

int push2_grid_set_led(lua_State *l) {
    if (lua_gettop(l) != 4) {
        return luaL_error(l, "wrong number of arguments");
    }

    luaL_checktype(l, 1, LUA_TLIGHTUSERDATA);
    struct dev_push2 *push2 = lua_touserdata(l, 1);
    int x = (int) luaL_checkinteger(l, 2) - 1; // convert from 1-base
    int y = (int) luaL_checkinteger(l, 3) - 1; // convert from 1-base
    int z = (int) luaL_checkinteger(l, 4); // don't convert value!
    dev_push2_grid_state(push2, x, y, z);
    lua_settop(l, 0);
    return 0;
}

so first parameter is which push2 to use (its passed around as an opaque pointer thru lua layer)
… this is used then to set the state on that push2 , which then the midi write thread for that push, then inspects to decide which CCs to send out. (simplified) - so it should be fine with multiple grids(*)

if you have based it on the above, the you could ‘print out’ the push2 pointer, and just check you are getting a different pointer for each grid… if you’re not then, somewhere in the lua layer, you’re mixing up the two grids possibly.

( (*) the reason the screen is different is none of the LUA screen calls take a ‘screen id’… but by native push2 api does, that means multiple push2 , one would have the ‘default’ norns screen , but the other could be used push2 display could be used natively)

#726

It’s probably a bug in the way the midi devices are handled - perhaps because the name of the devices is the same.