build support for older systems

.github/workflows/ck_builder.yml

@@ -14,6 +14,7 @@ on:
           - native
           - universal
           - full
+          - nomp3
           - light
       platform:
         type: choice
@@ -35,6 +36,11 @@ jobs:
 
     steps:
 
+    - name: job information
+      run: |
+        echo "OS Version: `uname -v`"
+        echo "MacOS SDK Platform Version: `xcrun --show-sdk-platform-version`"
+
     - uses: actions/checkout@v4
       with:
         submodules: 'recursive'

CHANGELOG.md

@@ -13,6 +13,12 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
 ---
 
+## [0.1.x]
+
+- Added `nomp3` build variant for a `full - mp3` build (works better on older macos systems)
+
+- Added Makefile-based packaging, codesigning and notarization.
+
 ## [0.1.2]
 
 - Added a github workflow to automate building the external (no codesigning/notarizing yet)

CMakeLists.txt

@@ -6,6 +6,8 @@ project(${THIS_FOLDER_NAME})
 option(C74_BUILD_FAT "Build Universal Externals")
 option(ENABLE_WARPBUF "Build WarpBuf chugin")
 option(ENABLE_FAUCK "Build Fauck chugin")
+option(ENABLE_MP3 "Enable MP3 support for libsndfile")
+option(ENABLE_EXTRA_FORMATS "Enable extra file format for libsndfile")
 option(ENABLE_HOMEBREW "Build using Homebrew dependencies")
 
 # use ccache if available

DEVNOTES.md

@@ -1,19 +1,41 @@
 # Dev Notes
 
-## callbacks / Python callables
+## Making Use of Callbacks
 
-@godlygeek on python discord #c-extensions sub discord:
+In order to customize the current set of callbacks (which currently just post the value of the parameters to the Max console), a developer/user will want to modify them to do something other than the default and then re-compile the external.
 
-> there aren't closures in C, but there are in C++ . In C, the typical setup is that every library function that accepts a callback (pointer to some function) also accepts a user data object (void *user_data). The library stores both pointers, and when it calls the callback it passes the user_data pointer to it as well
-> and you, as the user of that library, would pass your Python callable as the user data, and a C function as the callback. The library would call the C function and pass the user data pointer as one of its arguments. The C function would cast the user data argument back to PyObject* and then call using PyObject_CallObject or some such
+In practice, callbacks in `chuck-max` are constrained by what their function signatures allow. To do something useful one will typically want to access the pointer to an instance of the `chuck~` object which is not directly available as an argument to any the callbacks. For example, in the case of the `cb_get_int` callback, one only has the parameter name and value:
+
+```c++
+void cb_get_int(const char* name, t_CKINT val)
+{
+    post("cb_get_int: name: %s value: %d", name, val);
+}
+```
 
-Next feature request: provide callbacks which resemble the `getAllGlobalVariables` signature and take `void* data` as in:
+To get around this limitation, one can use the knowledge that `chuck~` instances are given the scripting name `chuck-<x>` where `x` is the order of instanciation and that one can get to retrieve the relevant object pointer by using `void *object_findregistered(t_symbol *name_space, t_symbol *s)` as in:
 
 ```c++
-void cb_get_all_global_vars(
-    const std::vector<Chuck_Globals_TypeValue> & list,
-    void * data
-)
+void cb_get_int(const char* name, t_CKINT val)
+{
+    t_object* x;
+
+    for (auto name : CK_INSTANCE_NAMES) {
+        x = (t_object*)object_findregistered(CLASS_BOX, gensym(name.c_str()));
+        object_post(x, (char*)"name: %s value: %d", name.c_str(), val);
+    }
+}
+```
+
+It's not elegant, but it works until something better comes along such as if `void *` arguments were included in all callbacks:
+
+```c++
+void cb_get_int(const char* name, t_CKINT val, void* data)
+{
+    t_object *x = (t_object*)data;
+
+    // ...
+}
 ```
 
 ## Build Universal Binaries again
@@ -674,3 +696,16 @@ shred_1 => shred_fx_1 => shred_fx_2 => dac
 and so on ...
 
 An optional additional argument to specify shred_id as in `insert <filename|code> <shredID>`, allows for specifying exactly where to insert in the chain..
+
+## Chuck Feature Request: void ptr argument for callbacks
+
+It would make callbacks a lot more useful if at least one consistent variant of available callbacks followed the example of `getAllGlobalVariables`.
+
+```c++
+    t_CKBOOL getAllGlobalVariables( void (*callback)( const std::vector<Chuck_Globals_TypeValue> & list, void * data ), void * data = NULL );
+```
+
+referencing @godlygeek on python discord #c-extensions sub discord:
+
+> there aren't closures in C, but there are in C++ . In C, the typical setup is that every library function that accepts a callback (pointer to some function) also accepts a user data object (void *user_data). The library stores both pointers, and when it calls the callback it passes the user_data pointer to it as well
+> and you, as the user of that library, would pass your Python callable as the user data, and a C function as the callback. The library would call the C function and pass the user data pointer as one of its arguments. The C function would cast the user data argument back to PyObject* and then call using PyObject_CallObject or some such

Makefile

@@ -11,10 +11,11 @@ DMG=chuck-max-$(VERSION)-$(ARCH).dmg
 ENTITLEMENTS = source/scripts/entitlements.plist
 VERSION=0.1.2
 
-.PHONY: all native universal full light dev clean reset setup test   \
-		test-fauck test-warpbuf install_deps install_deps_light brew \
-		release sign package dmg sign-dmg notarize staple sign-dist  \
-		dist-release
+.PHONY: all native universal full light brew nomp3 dev setup \
+		clean reset  test test-fauck test-warpbuf \
+		install_deps install_deps_light install_deps_nomp3 \
+		sign package dmg sign-dmg notarize staple sign-dist  \
+		release dist-release
 
 all: native
 
@@ -37,6 +38,9 @@ universal:
 install_deps:
 	./source/scripts/install_deps.sh
 
+install_deps_nomp3:
+	./source/scripts/install_deps_nomp3.sh
+
 install_deps_light:
 	./source/scripts/install_deps_light.sh
 
@@ -48,22 +52,46 @@ install_faust:
 brew: install_faust
 	@mkdir -p build && \
 		cd build && \
-		cmake -GXcode .. -DENABLE_HOMEBREW=ON -DENABLE_WARPBUF=ON -DENABLE_FAUCK=ON && \
+		cmake -GXcode .. \
+			-DENABLE_HOMEBREW=ON \
+			-DENABLE_EXTRA_FORMATS=ON \
+			-DENABLE_MP3=ON \
+			-DENABLE_WARPBUF=ON \
+			-DENABLE_FAUCK=ON && \
 		cmake --build . --config '$(CONFIG)' && \
 		cmake --install . --config '$(CONFIG)'
 
 
 full: install_deps
 	@mkdir -p build && \
 		cd build && \
-		cmake -GXcode .. -DENABLE_WARPBUF=ON -DENABLE_FAUCK=ON && \
+		cmake -GXcode .. \
+			-DENABLE_EXTRA_FORMATS=ON \
+			-DENABLE_MP3=ON \
+			-DENABLE_WARPBUF=ON \
+			-DENABLE_FAUCK=ON && \
+		cmake --build . --config '$(CONFIG)' && \
+		cmake --install . --config '$(CONFIG)'
+
+nomp3: install_deps_nomp3
+	@mkdir -p build && \
+		cd build && \
+		cmake -GXcode .. \
+			-DENABLE_EXTRA_FORMATS=ON \
+			-DENABLE_MP3=OFF \
+			-DENABLE_WARPBUF=ON \
+			-DENABLE_FAUCK=ON && \
 		cmake --build . --config '$(CONFIG)' && \
 		cmake --install . --config '$(CONFIG)'
 
 light: install_deps_light
 	@mkdir -p build && \
 		cd build && \
-		cmake -GXcode .. -DENABLE_WARPBUF=ON -DENABLE_FAUCK=ON && \
+		cmake -GXcode .. \
+			-DENABLE_EXTRA_FORMATS=OFF \
+			-DENABLE_MP3=OFF \
+			-DENABLE_WARPBUF=ON \
+			-DENABLE_FAUCK=ON && \
 		cmake --build . --config '$(CONFIG)' && \
 		cmake --install . --config '$(CONFIG)'
 
@@ -151,7 +179,7 @@ clean:
 		externals
 
 reset:
-	@rm -rf externals
+	@rm -rf externals examples/chugins/*.chug
 	@rm -rf build/CMakeCache.txt build/CMakeFiles build/CMakeScripts build/Release build/build build/sine.ck
 	@rm -rf build/chuck-max.xcodeproj build/cmake_install.cmake build/install_manifest.txt build/source build/build
 	@rm -rf build/thirdparty/faust build/thirdparty/install build/thirdparty/libfaust build/dist

README.md

@@ -1,25 +1,30 @@
 # chuck-max
 
-A [project](https://github.com/shakfu/chuck-ma) to minimally embed the [chuck](https://chuck.stanford.edu) engine in a Max/MSP external.
+A [project](https://github.com/shakfu/chuck-max) to embed the [chuck](https://chuck.stanford.edu) engine in a Max/MSP external.
 
-It currently has one external (`chuck~`) with the following features and limitations:
+This repo is itself a Max package with one external (`chuck~`) which has the following features and limitations:
+
+- A Max external which embeds the chuck 1.5.2.5-dev (chai) engine.
 
 - Generate and process audio via an embedded chuck engine by running chuck files with `global` parameters controlled and adjusted in realtime by Max messages.
 
 - Layer sounds from a single instance by running multiple chuck files concurrently.
 
 - Add, remove, replace audio and audio processes on the fly using Chuck messages via Max messages.
 
-- Includes most of the [base ccrma chugins](https://github.com/ccrma/chugins) including `WarpBuf` and `Fauck` or `Faust` except for the following:
+The package also includes the following:
+
+- The complete set of current chuck examples
+
+- Most of the [base CCRMA chugins](https://github.com/ccrma/chugins) including `WarpBuf` and `Fauck` or `Faust` except for `Fluidsynth` and `Ladspa`.
 
-  - Fluidsynth
-  - Ladspa
+- Many Max patchers to test and demonstrate usage.
 
-- Note that `chuck-max` has a sibling in the [pd-chuck](https://github.com/shakfu/pd-chuck) project.
+- Contributed patchers and code examples.
 
-This project is currently built on the chuck 1.5.2.5-dev (chai) engine.
+Note that `chuck-max` has a sibling in the [pd-chuck](https://github.com/shakfu/pd-chuck) project.
 
-*Quickstart*: packaged binary pre-releases and releases of the `chuck-max` package can be downloaded from the project's [Releases](https://github.com/shakfu/chuck-max/releases) section.
+*Quickstart*  binary pre-releases and releases of the `chuck-max` package are available in the project's [Releases](https://github.com/shakfu/chuck-max/releases) section.
 
 ## Overview
 
@@ -40,15 +45,14 @@ It is recommended to choose 2 channels for stereo configuration. If a `<filename
 
 4. Use Max's `locatefile_extended` search function to search for the `<filename>` in the Max search path. The first successul result will be used.
 
-
 ### Core Messages
 
 As of the current version, `chuck~` implements the core Chuck vm messages as Max messages:
 
 | Action                            | Max msg                      | Max msg (alias)              |
 | :-------------------------------- | :--------------------------- | :--------------------------  |
 | Add shred from file               | `add <file>`                 | `+ <filepath>`               |
-| Eval code as shred                | `eval <code>`                |                              |    
+| Eval code as shred                | `eval <code>`                |                              |
 | Remove shred                      | `remove <shredID>`           | `- <shredID>`                |
 | Remove last shred                 | `remove last`                | `--`                         |
 | Remove all shreds                 | `remove all`                 |                              |
@@ -79,7 +83,6 @@ The core set of chuck vm messesages is also extended in `chuck-max` with the fol
 | Launch chuck docs in a browser          | `docs`                       |
 | Clear Max console                       | `clear console`              |
 
-
 ### Parameter Messages
 
 Once a shred is running you can change its parameters by sending values from Max to the `chuck~` object. To this end, ChucK makes available three mechanisms: global variables, global events, and callbacks which are triggered by events. `chuck~` maps these chuck language elements to corresponding Max/MSP constructs as per the following table:
@@ -127,39 +130,9 @@ In addition to the typical way of changing parameters there is also an extensive
 | Set int associative array value   | global variable    | `set int[k] <name> <key> <value>`    |
 | Set float associative array value | global variable    | `set float[k] <name> <key> <value>`  |
 
-
-**Developer Note**
-
-In order to customize the current set of callbacks (which currently just post the value of the parameters to the Max console), an *advanced* user will want to modify them to do something other than the default and then re-compile the external.
-
-In practice, callbacks in `chuck-max` are constrained by what their function signatures allow. To do something useful one will typically want to access the pointer to an instance of the `chuck~` object which is not directly available as an argument to any the callbacks. For example, in the case of the `cb_get_int` callback, one only has the parameter name and value:
-
-```c++
-void cb_get_int(const char* name, t_CKINT val)
-{
-    post("cb_get_int: name: %s value: %d", name, val);
-}
-```
-
-To get around this limitation, one can use the knowledge that `chuck~` instances are given the scripting name `chuck-<x>` where `x` is the order of instanciation and that one can get the retrieve the relevant object pointer by using `void *object_findregistered(t_symbol *name_space, t_symbol *s)` as in:
-
-```c++
-void cb_get_int(const char* name, t_CKINT val)
-{
-    t_object* x;
-
-    for (auto name : CK_INSTANCE_NAMES) {
-        x = (t_object*)object_findregistered(CLASS_BOX, gensym(name.c_str()));
-        object_post(x, (char*)"name: %s value: %d", name.c_str(), val);
-    }
-}
-```
-
-It's not elegant, but it works until something better comes along.
-
 ## Build Requirements and Options
 
-Please note that this external is currently only developed and tested on macOS, although a Windows version is on the TODO list (any help on this would be appreciated).
+Please note that this external is currently only developed and tested on macOS, although a Windows version is on the TODO list (any help on this front would be much appreciated).
 
 ### A. The Base System
 
@@ -199,7 +172,6 @@ Now it should be possible to buid the base system with the following two build o
 
 - `make universal`: build the external using as a `universal` binary making it compatible with both Mac architectural variants. This is useful if you want share the external with others in custom Max package or standalone.
 
-
 ### B. The Advanced System
 
 The advanced system consists of the base system + two advanced chugins, `Faust.chug` and `WarpBuf.chug`:
@@ -222,7 +194,6 @@ After these are installed, it will be possible to build using the following opti
 
 - `make light`: Same as `make full` except for `libsndfile` multi-file format support, which means that (.mp3, flac, vorbis, opus, ogg) formats are not supported in this build. Only `.wav` files can be used.
 
-
 ## Usage
 
 Open the help file `help/chuck~.maxhelp` for a demo. Check out the `patchers` folders for further examples of use.

TODO.md

@@ -4,10 +4,6 @@
 
 - [ ] Refactor `ck_run` / `ck_add` relationship
 
-- [x] Add github workflow
-
-- [x] Fix universal builds on macOS
-
 - [ ] Add Windows Support
 
 - [ ] Add Doxygen docs

package-info.json

@@ -24,9 +24,9 @@
         "livecoding",
         "midi",
         "osc",
-        "faust",
+        "faust"
     ],
     "extensible": 0,
-    "version": "0.1.2",
+    "version": "0.1.x",
     "website": "https://github.com/shakfu/chuck-max"
 }