Lighter approach to standalones?

Development
#1

I recently had an annoying experience trying to get a standalone working. Both @adcxyz’s approach and this one: https://github.com/dathinaios/sc_osx_standalone failed for what appear to be thorny issues with code signing on recent Mac OSX versions. Despite manually unquarantining it all still failed to work. I fear this issue is only going to get worse, and it would anyway be nice to have a cross-platform approach to standalones.

What if we did this:

  • A variant build of the SC distribution, so just another build target
  • tweaked to only read internal and local (i.e. in the same folder and subtree as the app) for extensions and plugins, so no conflicts with other SC installs
  • looks for a particular file (startup.scd or whatever) also in that location and runs it on startup
  • IDE included but could be configured to hide help and documents and only show post window by default. Could perhaps simplify menu structure.
  • For Mac a signed template distribution of this could be made available so no code-signing problems
  • Users just download the template, drop extensions in the appropriate places, add a startup file, and go

I don’t think this would be much work. Thoughts?

4 Likes
#2

That would be brilliant!
Best,
Paul

#3

SOMEWHERE in the depths of SC history, I worked on a refactor of Cmake that changed the overall structure of SC builds (on Mac), so that sequence was something like:

  1. Build scsynth
  2. Build command line sclang
  3. Build an app package wrapping sclang that can e.g. be launched on double-click
  4. Build IDE app package
  5. Allow IDE to be pointed at (and launch) any sclang app executable / app package, but defaulting to either an embedded one or one that’s next to it in the current folder.

This way, basically ANY build of SuperCollider is already a standalone - you can launch it with a double-click, you can (on mac) drag an scd to the icon to execute it, and building a “standalone” app (e.g. something like LNXStudio) is as simple as copying the regular sclang app and adding code to run at startup.

I abandoned this project because honestly it was a nightmare nest of cmake problems (not because of cmake, but because the way the SC cmake files were factored at the time was a mess). BUT: I think this approach is still fundamentally valid, and absolutely the appropriate way to proceed. This would especially benefit users of scvim or other IDE’s, since having a regular sclang “application” that behaves in canonical ways would make those workflows much smoother.

3 Likes
#4

That makes a lot of sense to me! I suppose the only small issue might be some confusion of what to start for new users, but I think an appropriate folder structure would help with that, with IDE at top level. I suppose the same could now be done for scsynth (icon and double clickable), especially since it’s now effectively a GUI application with the VST stuff.

1 Like
#5

I just wanted to say that I am both interested in this and I have made some attempts to work on standalones in the past (by modifying the existing builds, not in cmake). It worked a few years back, but it was hacky. I haven’t tried to do it more recently.

Here are a few additional points (IIRC):

  • the current “standalone” command line switch for sclang disables loading classes from ALL default locations (including the app bundle) and the class library locations provided in the sclang_conf file cannot be relative paths… It’s definitely fixable, but a hurdle currently.
  • I like the idea of creating configurable app package, and that coincides with my plan to look again at our bundle creation, possibly taking it from the scide’s cmake file into the main cmake file and making that process configurable (if that’s the best approach)
  • @muellmusik I think scsynth only becomes a gui app if a plugin requests that (correct me if I’m wrong); and since scsynth is always started with particular parameters (port number at the very least) it’s less practical to have that as a clickable app than sclang. However, regardless of an option of a “clickable” app, I think it would be good to have the option to create a synth-only bundle for use with other clients
  • I remember seeing “standalone” in cmake configure options. I meant to check how it works but haven’t gotten around to it
  • I like the idea of creating a signed standalone template, but I’m not sure if modifying such a template wouldn’t invalidate the signing (need to check that)
  • IMO it would be beneficial to have a consistent standalone creation process for all platforms, not only macOS
  • In the past, some approaches that modified bundle structure caused problems with Qt libraries with the possibility that SC would pick up Qt installed in the system instead of the one that’s bundled (or maybe tried to use both?) and this resulted in issues… but if bundle structure is not modified after the build, this shouldn’t be a problem
  • my 2c - it would be good to have an option to not have the qtwebengine included in the standalone build. It’s huge (>100MB on macOS), about half the total size of SC app bundle
#6

Thanks, Marcin.

Re scsynth: Good point though I think the defaults are sensible (is there not one for port or?) There’s probably a more complicated issue to decide there, but iac it would be nice to have a proper icon when it is a GUI app instead of the terminal one. Separate issue tbf.

Yes a cross platform approach was what I was suggesting.

To be clear, I don’t think any modification of the bundle should be done by users. That’s too funky for most people anyway. I’m imagining a SC Standalone folder that has the apps and pre created folders where users can drop extensions, resources, and standalone code. I’m assuming that wouldn’t cause issues with signing, but perhaps I’m wrong? I’ve not dealt much with signing directly, except as a problem!

Building without the web stuff makes sense, though I’d suggest that be a separate feature, available for all SC builds (if it’s not already).

#7

That’s correct. On macOS, scsynth and supernova have a Cocoa event loop, but both are still background applications by default. VSTPlugin would (temporarily) transform the Server to a foreground application if necessary (e.g. to display the plugin UI).

#8

There already is the SC_USE_QTWEBENGINE option.

#9

Yes I know! My point was to use that when possibly preparing the standalone template.

#10

Here’s the branch I was working with to move toward a “launchable” standalone as part of the regular build pipeline:

It probably doesn’t make sense as a pull request, but possibly stepping through the commits will provide some ideas. Some of the required changes are quite simple and small - e.g. allowing the IDE to point to EITHER an sclang binary OR an app package containing an sclang binary (https://github.com/supercollider/supercollider/commit/400cd565bca82c684294bd30b22135e5e3147e8e), enabling running sclang without a stdin, which is the case when it’s launched from an app package (https://github.com/supercollider/supercollider/commit/5b2132340c175efec15f24a7676c55830a9c8a10).

The once piece that was slightly tricky: for a “regular” packaged SC IDE, we don’t want duplicate QT libraries for both the IDE and the embedded sclang app package. So, there’s a final stage as part of install where we just symlink the required QT libraries into sclang.app from the SC ide app that contains it (https://github.com/supercollider/supercollider/commit/80de1caf8876bcfca55f36d3dd26de9a8e11b6cd).

IIRC this branch was 95% working when I did it, but the QT library fixup step and signing were both still problems. Probably these things have changed in the intervening years anyway - hopefully in ways that make them work better :slight_smile: but at a minimum in ways that would require changes to how I was handling it.

2 Likes
#11

Hi all, interesting topic, thanks Scott!

Crossplatform standalones would be fantastic of course,
would be really happy to see that, and will try to help in any way I can.

For completeness, I tested making one with Standalone quark, and yes, this is not working anymore as it did :-/ The app fails to open, likely because the renamed internal binary looks suspicious / trips the code-signing check:
LSOpenURLsWithRole() failed with error -10810 for the file /Users/adc/Desktop/MyLittleLony.app,
and luckily -101810 is " kLSUnknownErr" :
https://developer.apple.com/documentation/coreservices/3074489-anonymous/klsunknownerr?language=objc
oh well …

In case this is helpful, the hairiest part of the Standalone quark was making sure the standalones are really fully independent from SuperCollider, and also from each other.
For macOS, that involved renaming the SuperCollider binary file to a unique name for each standalone, (and copying that name into internal info.plist), which leads the app to create its own independent userAppSupportDir and userExtensionDir when first started. Once that works, there is no accidental crosstalk between quarks, synthdefs, or any other data that SC and standalones read and write.
While a generic SCStandalone app would be great first step, I think people would soon put multiple standalones on the same computer (packaged pieces / setups), and then independence between these standalones becomes really crucial.

For simplicity, I would agree to turn off the newly made extension folders completely.
All quarks to include can go into an InternalExtensions folder (inside the app on macOS).

Most of my standalones for various projects ended up with this folder structure:
Standy/
- Standy.app/
- startup.scd ← just redirects to a project loadMe file
- projects/
– proj1/
— 00_loadMe_proj1.scd
… code files & folders …
– proj2/

2c, adc

1 Like
#12

Yeah, my idea is that a standalone is basically just a normal sc install that doesn’t look to or create support directories. In effect there would be local folders for extensions and app code (in the same folder probably rather than bundle for simplicity and in case the OS looks for bundle modification). IIUC I think that should have no issues, and would allow multiple standalones to coexist without conflicts.

I think just getting that working would be a great first step, and hopefully stable. We could add bells and whistles later if desired.

1 Like
#13

and would allow multiple standalones to coexist without conflicts.

That is very important. I think in the past there were some methods for standalones that would run but the system would still see as the SuperCollider app.

Glad to see interest in solving this! :slightly_smiling_face: Every few months I give another try to fixing sc_osx_standalone but I can’t figure it out…

1 Like
#14

Cross platform standalones would be amazing!!

  • it would be nice to have an option to exclude the IDE entirely and just launch sclang.
1 Like
#15

Just out of interest does anyone have a recent Standalone I could mess around with?
I have a couple of projects I’ve been working on and I’m thinking of putting them out there for every1 to play with.

1 Like