Hi, I don’t have a real Organelle, but I think they are great, and am working on an SDL hardware def for OrganelleOS, so it will run on desktop and other devices (like a pi) with official firmware.
I have it mostly working, but the menu doesn’t seem quite right. I notice you can navigate past the menu items. Does a real one act like this when you turn the rotary-encoder?
Yes it does. And I’ve always wondered why.
That’s awesome, thanks @johannes! I think maybe the reason is that the menu is designed very decoupled from the hardware (which actually makes it easier to drop in a new SDL OLED/encoder-driver, like I am doing) so the code to read the encoders doesn’t care about the current position of the menu. The upside is that you can write a few lil things and have it call back to the menu code (which I guess could ignore over-scrolling) but the downside is that there is no way to tell where the menu stops in the hardware-layer. I don’t super-mind, as long as I didn’t set it up wrong.
I made a PR here. Hopefully it will get into upstream. It helps getting this to run on lots more devices, and it’s handy for testing (on my mac, for example.)
Thanks for looking into this stuff, and for the PR. I look forward to trying it out! It would be great to have it running more easily on other platforms, and this hardware layer looks like a great way to achieve that.
Too bad the encoder on the Organelle M/S isn’t connected to GPIO… then this SDL OLED/encoder hw layer could replace the current one by enabling the requisite OLED SPI framebuffer and encoder GPIO kernel drivers. (right now the encoder is connected to shift registers with the rest of the keys and polled in user space as part of the current hw layer)
hmm, the scrolling past the end of the menus might be fixable. I remember it being a little bug in the early early versions, then kinda just got stuck in there!
I am happy to help more with other parts (like the menu scrolling thing.) For real rotary encoders, I could add a little encoder-code for pi, but I was trying to keep it easy to use & generic on desktop (so I could easily test stuff, and use it on gameboy-like linux handhelds.) I have worked with the pi accelerated kernel rotary-encoder drivers, and they are pretty easy to use and have lots of nice stuff like debouncing and clean input-device support and keyboard-emulation built in. You basically just add a couple lines to the kernel params, and they work directly, without having to poll GPIO or anything.
We could make a bunch of little hardware definitions for other combos, like SDL + pi rotary, or SDL + i2C/SPI , or whatever. I think this is a good start for any hardware that has a regular screen that works (for example on a standard pi with HDMI plugged in, this would run fine with or without X.)
I would also like to be able to navigate with midi. It would mean a very simple pi with only an LCD could run it (since I would have a midi controller plugged in anyway.) I made anotehr PR for OSC messages that trigger manu-nav, but it could be much nicer if midi-input was integrated into mother cpp program.
I am starting to think the target is the wrong name, though. Should probly be sdl not sdlpi, since it’s not at all specific to pi. In naming the hardware-layer, I was trying to prevent a clash with “sdl” named stuff.
I merged your changes and it seems to work well. Compiled without any problems on my Mac and the SDL menu window popped right up! On my Ubuntu laptop it also worked and even started Pd just like the Organelle. It requires a few objects not part of Pd vanilla (for the OSC stuff), but I imagine if I added those it would be fully functional Organelle on laptop, at least for running patches (all of the system menu stuff is mostly platform specific scripts, but these can be altered and included as a new platform target).
Yeah, perhaps sdl-generic or something for this hw definition since this one works on multiple platforms. And having a bunch of hw defs for other combos would be cool!
I wonder about having MIDI coming right into mother cpp… it has always been a bit of a mess how to best handle MIDI as there a bunch of ways it can go, e.g. a user patch can do their own thing entirely using regular Pd MIDI objects that might conflict with any expected global MIDI features.
Compiled without any problems on my Mac and the SDL menu window popped right up!
Nice!
It requires a few objects not part of Pd vanilla (for the OSC stuff),
You can add these in the UI in latest vanilla (under “Help” / “Find Externals”.) Purrdata is also a nice modern & cross-platform alternative you can install on mac/Ubuntu, that mostly runs the same, but has all the basic core stuff, although it may still be missing some of them. Since the filename (.pd_linux) doesn’t account for arch, it still adds some complication to just pre-compiling them for arm/linux (like it will work on pi, but not linux on x86_64.) On my mac, I used latest vanilla to test, added a few libs in the UI, and set it like this:
So maybe I could just write instructions for getting all the required pd externals, or make some little zips for different platforms/arch combos.
all of the system menu stuff is mostly platform specific scripts, but these can be altered and included as a new platform target
Yes, I was thinking same. Currently, there is separate folders of stuff for organelle-m/organelle and I could see just pointing to a different dir to get access to the scripts and stuff. I could make a platform dir for mac/windows/pi/etc and it would just be all ready-to-go.
I wonder about having MIDI coming right into mother cpp… it has always been a bit of a mess how to best handle MIDI as there a bunch of ways it can go, e.g. a user patch can do their own thing entirely using regular Pd MIDI objects that might conflict with any expected global MIDI features.
Yes, I really like that idea, but thought the same (might conflict with pd.) Maybe if it switched off reading MIDI when it leaves “menu mode”? Like essentially once mother.pd loads, it switches to showing things a bit differently, so we could only listen to midi when the menu is showing. Another idea I had was to open a separate pd patch or python script that sends OSC to menu (using that other PR I added) while it’s in menu mode, and closes the midi/osc when it’s not.
I started some work on organizing the different features as separate pieces, so they can be mix & matched a bit more (i2c-pi rotary-encoders with SDL OLED, for example.) Once I get that all setup, I think we will have lots of different ways to combine the parts, and it should be fairly simple to implement other pieces (I was thinking direct i2c vs 3-gpio/event-interface, for rotary, on pi might be nice, for example.)
Do you think it would be possible to make some patch which allows you to ‘cast’ the OLED from an Organelle to this SDL version?
I’m not sure I understand. Can you explain?
So my idea is if in theory you could have this SDL ran Organelle on your computer and make a patch that could act as a host and listen for messages over UDP or OSC and then if you have a real Organelle, set up in the mother file a way that forwards the OLED messages to the host and display the OLED on your computer?
My hope for this is that I could have this set up for use in OBS for live streaming some development streams or do workshops in Orac and have my VNC session, Organelle OLED, and a camera on the Organelle all in a scene.
If you think this is a possibility and there’s nothing that I’m not taking into account, I will work on this as my next project!
Also I was able to get the SDL version compiled and running as well on Manjaro. However, I do not know where to place the Patches folder to actually run anything 
The readme has some hints about file-locations, now, but that is sort of out-of-scope of the SDL thing.
So my idea is if in theory you could have this SDL ran Organelle on your computer and make a patch that could act as a host and listen for messages over UDP or OSC and then if you have a real Organelle, set up in the mother file a way that forwards the OLED messages to the host and display the OLED on your computer?
Still not really following. If you mean to remotely view the Organelle screen, I don’t think it’s related. You can currently run the organelle and connect to the backend with OSC and send it commands, just like the mother.pd does. Really the SDL code just replaces the OLED screen on the Organelle for devices that don’t have the same kind of OLED (for example I have handheld gameboy like computers it would work on, that have a nice screen, sound, a joystick, just not a 128x64 OLED or rotary-encoder.)
That’s true, I guess I’m mostly wanting it to appear as close as I could to the Organelle screen is all. I’m still kind of trying to figure out the best way to just be able to have the screen show up remotely haha
Here is the start of the structure I was thinking, with base-classes for NoteKeys/Footswitch/Pots/LED/OLED/Rotary, and then they are extended for each particular hardware-implementation, so you can mix & match them with defines. I still need to write all the classes, but I think it should be fairly straight-forward.
Does that make sense?
I guess I’m mostly wanting it to appear as close as I could to the Organelle screen is all.
I mean that’s fine, but that is not what the SDL stuff does. If you modified mother.pd to send to multiple hosts (the local driver for OLED, and the remote host where your computer is) you could make it work I think, and run the full organelle OS on your desktop. Might be easier/better to just look at the real Organelle screen, though 
Maybe another lateral solution would be to get cheap webcam and aim it at the screen, then send it OSC messages remotely.
Sure that makes sense, it will be very flexible this way.
