recoding the patch is one way to go, but has to be done for every patch!
the other approach is to emulate a grid - I have the push2 emulating Norns, a Grid, and Midi, simultaneously 
(note: although this is shown on a rPI3, this code would work on Norns hardware)
the code is a bit lower level, but Iâve already done it for the push2 , and its available in my repo/ push2 branch.
this code could be quite easily adapted for a push 1. its mainly just removing the display code.
(note: i cannot do this, as i donât have a push 1 anymore)
emulating the monome grid was pretty simple, as it has quite a restricted api (things like set, refresh) ,
if there was a will this could be done quite easily, not only for push, but also other grids like launchpads, using the same/similar approach.
there are older monome grids that are 8x8, so surely the apps should be being written in such a way to allow for these!?
to cope with this on the push 2, I just âvirtualisedâ the grid to appear to be 16x8. (trivial to emulate a 256 too 
)
this actually worked very well for almost all functionality, not many functions need access to both sides of the grid at once.
also bare in mind push has so many extra buttons, so these can easily be reused (with custom code) to move a lot of grid functions to dedicated buttons e.g. you dont need a alt func +grid key to do quantise, as push has a dedicated quantise button to use.
this obviously means patch changes, but is fairly simple, as your not actually affecting the grid code, rather supplementing it with new âshortcutsâ
a push 2 screen is no more complex than the norns lcd , and in fact can be programmed in pretty much the way (once the usb comms is don) - the similarity is why I was able to replicate the norns UI on it, and it can be all run on the norns, which is a computer after all
push 1, now that is different⌠as its a character display rather than bitmap (like norns/push2)
this means that you cannot just hook into the norns display api and render as done on the push2.
rather youâd have to create your own UI, this would not be too difficult (e.g. just look at the lua code for displaying/changing parameters) and the midi/sysex model for push is really easy to code.
also you can see this as something of an advantage, as you can redesign the UI to reflect the push closer, e.g. using dedicated buttons (mix, tempo, bpm, etc) and also using the 8 encoders and paging system.
so sure some effort, but the results would be worth it!
of course would not help for patches which are graphically oriented, so only patches that are mostly parameter/grid driven will work âout of the boxâ
but you still have the option to create your own patches, and/or adapt existing patches, which again can make use of the full push hardware.
an even simpler way, if your using the norns hardware is to not try to use the screen this way.
rather, turn the encoders into CCâs which can then be used with norns built in midi mapping, and then use the pads as an 8x8 grid (or virtualised to 16x8 as discussed above)
Its an interesting areaâŚ
its seems most norns users have monome grids, so unsurprising thats where the main support lies.
but the new grid api allows for multiple grids, so perhaps this might generate more of a demand for other grids too be support as âsecondaryâ grids.
anyway, not saying any of this is 100% perfect , rather that its definitely viable, and if you have a push (or other grid) - why not!
