Working SDL Organelle Firmware, need advice

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?

sdl-organelle

3 Likes

Yes it does. And I’ve always wondered why.

2 Likes

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.

1 Like

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!

2 Likes

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.

2 Likes

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?