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.)