#381

Ive had an idea… and a kind of proposal.

Ive seen quite a few posts regarding how to use various devices (launchpad/tablets via osc) for interfacing with norns and emulating things like grids - as above, Ive been replying its quite possible, as Ive done it with the Push2 and its working fine - so developers could use that as a starting point.

but Im wondering perhaps we could/should co-ordinate this a bit, say as an ‘alternative’ firmware?

the idea/proposal is…

I would on my repo, create a number of “skeleton” implementations for alternative controllers etc,
I can do this relatively easily, as i can follow the structure Ive already done, so Ive the means to do things like “emulate” the display, the encoders/buttons , a monome grid… and other things seen in my push 2 implementation like midi controller mode and native mode.

I say “skeleton” as I don’t have all the devices to support, so this is where others could come in and contribute, they could take these skeletons and ‘complete’ them.
this will primarily mean:

  • adapting some of the messages sent (e.g. might be changing midi note numbers)
  • testing/fixing issues
  • extending to make fuller use of the controller.

once done these changes would be sent back to me as a normal GitHub pull request for inclusion.

what is the advantage of this approach/collaboration?

primarily im hoping the skeletons would reduce complexity for others to do the things they need to, leveraging whats already done.
but it also means we can share ideas about the best way to do things.

note: this needs to be collaboration, as whilst Im happy to put some effort into getting the skeletons working, I only want to do this if others are interested in taking this further and collaborating - I dont have the time (nor controllers) to do this all on my own :wink:

current thoughts for skeletons would be launchpad and osc, as these seem to be common requests.
(but we can discuss this, and also scope of each, and how structured - ive quite a few ideas on this :wink: )

thoughts? interesting? would you be able to collaborate?

5 Likes
#382

yeah, could work. but that still implies some hacking to handle the “osc device” as a “grid device” (to be able to use the former with the grid API). the virtual port helps to distinguish several devices sharing the same protocol, but doesn’t exactly allow adapters like what you propose.

#383

There is no “could” or “hacking” about it.
I’ve already done this with the push2 :slight_smile:

#384

This sounds amazing would be more than happy to chip in and help out where I can :smiley:

1 Like
#385

nice :slight_smile: but i assume you’re doing it by emulating grid add/remove and button events in your push driver which can be considered a hack, and by hacking i don’t mean something bad :slight_smile:

1 Like
#386

i think it seem reasonable to attempt an emulation layer via OSC.

it should be written in C, and generate actual events.

ie, it’d be trivial to add an OSC listener for encoder and key messages, and then create corresponding system events.

virtual grid is a little trickier. you’ll need connect/disconnect in addition to the entire protocol, but this is all possible. whereas the encoder/key emulation is just an add-on, the virtual grid functionality would need to be deftly woven into the existing grid framework.

but then how you design for using the rest of the controller (on the push, for example) to me seems a bit messier, since each not-monome grid will have a different configuration. i’d be curious to see proposals.

i’m certainly not against this direction, but i’m also very focussed on pushing forward the current set of issues and features which is a very long list.

1 Like
#387

emulating things will always be more or less messy.

perhaps the clean solution to having a norns-like configuration on the rpi can be built with hardware, e.g. a shield with an actual screen, buttons and encoders. it could even be compatible with an audio interface like pisound, but i am not sure if pisound has enough available gpios to support norns.

2 Likes
#388

I would love to help on the OSC part (specifically for iPad use/testing)

My ideal OSC functionality:
Broadcast screen frames
Receive Osc messages for Norns hardware controls
Receive/Send grid data

At that point, I would be able to throw together a prototype ui via Lemur and eventually move that to swift for a deployable app for sharing with others

Seems as though all of the functionality is already there from the push demos it’s just a matter of throwing it into OSC.

Re tablet processing power: It shouldn’t be an issue using an iPad for some processing, but I believe sending frames would be a more portable approach if the LAN can handle it

#389

Hi @TheTechnobear et al.

I’m walking into this conversation super new (still trying to understand the whole thread narrative), but I am very interested.

Is this the best place to start, before engaging?

Please advise on the quickest way to catch up.

Thanks.

#390

ok so been studying the push2 code got rid of screen stuff and changed push 2 to launchpadmini getting this error when compiling ./waf:-

Waf: Entering directory `/home/we/norns/build’
[ 1/52] Compiling matron/src/events.c
[ 2/52] Compiling matron/src/device/device_launchpadmini.c
[ 3/52] Compiling matron/src/device/device_list.c
[ 5/52] Compiling matron/src/device/device.c
In file included from …/matron/src/device/device.h:10:0,
from …/matron/src/device/device_launchpadmini.c:5:
…/matron/src/device/device_launchpadmini.h:4:20: fatal error: libusb.h: No such file or directory
#include <libusb.h>
^
compilation terminated.

am I missing libusb.h ?

edit
was libusb that error gone, now getting a zillion others, will wade in I guess :roll_eyes:

#391

sudo apt-get install libusb-1.0-0-dev

That said , you won’t need it except for the push , as it’s just to drive the display.

#392

ahh ok got it to compile eventually but fear I removed too much of the good stuff (code) for it to work properly will give it another bash tomorrow. thanks for the help. :wink:

#393

Necro-bump

I am revisiting the arc support PR by @scanner_darkly

New PR here: https://github.com/monome/norns/pull/638

2 Likes
#394

Long time away from the community but I’ve also been working on getting the norns software running on a Raspberry Pi.

A few observations:

  1. The CPU scaling governor is being reset by service named raspi-config. Looking into it, it doesn’t appear to do anything other than this. I’ve disabled it by running systemctl disable raspi-config with no adverse effects so far.

  2. Taubaland’s osc.c file appears to be missing the correct properties for the key events, although I might be using an outdated version of the file :grimacing:

Even after building the kernel, I’m still getting noticeable latency, could this be due to using a USB audio interface or are there other things that can be done?

Much love for this community as ever!

1 Like
#395

Hi, the current working versions are as follows:

osc.c (4.2 KB)

norns-control.touchosc (494 Bytes)

I’d suggest the latency is due to the USB interface, you can check the /etc/systemd/system/norns-jack.service for any jack settings to play around with.

#396

I’ll have a fiddle with that, thank you :slight_smile:

I see, I have those files, shouldn’t the key events have the properties of ‘key’ and ‘val’ rather than ‘enc’ and ‘delta’?

#397

I did try that, but they need to be enc and delta. Far greater minds than I can probably explain why.

It seems to work fine for me (also maybe @martindunne).

Has anyone else tried it?

#398

the key and enc event types are the same size, have equivalent fields, and are just accessors for the event_t union; only difference is sign bit of value field. so i’m not surprised it works with the wrong accessor.

in looking, i see there is a rather hilarious copy-paste error in norns gpio.c, in which key events used the enc union, maybe this is the origin. i just changed this and it works fine (on norns):
[ https://github.com/monome/norns/pull/639 ]

so - i am surprised it doesn’t work for you with the correct accessor.

#399

OK so have tried this a few times with no joy. At the moment I am going through your commits in the technobear/norns repo to see which files have been altered and then alter accordingly for a launchpad mini. Is this the correct way. :thinking:

#400

I’m trying to install Norns on a Pi3B+ I’m following the instructions from https://github.com/okyeron/norns-image/wiki/Norns-Build-on-Raspberry-Pi
When I tried to sudo mv dt-blob.bin /boot/ I got the following error
mv: failed to preserve ownership for '/boot/dt-blob.bin': Operation not permitted
Will this be an issue for the rest of the installation ?

Second problem: git clone --depth=1 https://github.com/monome/linux/tree/norns-4.14.y gives
fatal: repository 'https://github.com/monome/linux/tree/norns-4.14.y/' not found
Is this command inaccurate ?

Thanks !

Edit: I read that 4.14.y is now the default branch, trying again with https://github.com/monome/linux