Conversation
Feat fw v1.14
Update check-installer-project-version.yml
Fix xcode proj files
feat:upload build artifact on mac workflow now adds drivers
…lds with the correctly updated dependencies for software
WalkthroughAdds a new GitHub Actions workflow to create draft releases and reorders a trigger in an existing workflow. Updates .gitignore. Refactors multiple Xcode projects: reorganizes resources, dependencies (OpenSSL/JSON), schemes, deployment targets, icons, and Info.plist keys. Bumps Windows installer ProductVersion and updates README addon references. Increments ofxEmotiBitVersion to 1.12.2. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Dev as Developer
participant GH as GitHub Actions
participant Repo as Repository
participant WF as Artifact Workflows
participant Rel as GitHub Releases
Dev->>GH: Close PR to master or manual dispatch
GH->>Repo: Checkout
GH->>WF: Query latest successful runs (dev) for mac & win artifact workflows
WF-->>GH: Artifact metadata (run IDs, artifact lists)
GH->>WF: Download EmotiBitSoftware-macos / -Windows artifacts
GH->>Repo: Parse src/ofxEmotiBitVersion.h -> vX.Y.Z
GH->>GH: Generate release notes and config.txt
GH->>Rel: Create draft release (tag vX.Y.Z) with assets
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
🔭 Outside diff range comments (3)
EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-arm64.xcscheme (1)
33-43: LaunchAction has no runnable; running the scheme in Xcode may failLaunchAction no longer contains a BuildableProductRunnable, so running/debugging the app via this scheme can break. Add back the runnable pointing to the same BuildableReference as BuildAction.
<LaunchAction buildConfiguration = "Debug" selectedDebuggerIdentifier = "Xcode.DebuggerFoundation.Debugger.LLDB" selectedLauncherIdentifier = "Xcode.DebuggerFoundation.Launcher.LLDB" launchStyle = "0" useCustomWorkingDirectory = "NO" ignoresPersistentStateOnLaunch = "NO" debugDocumentVersioning = "NO" debugServiceExtension = "internal" - allowLocationSimulation = "YES"> + allowLocationSimulation = "YES"> + <BuildableProductRunnable + runnableDebuggingMode = "0"> + <BuildableReference + BuildableIdentifier = "primary" + BlueprintIdentifier = "8EF01B542E4544B600BF0971" + BuildableName = "EmotiBitOscilloscope-arm64.app" + BlueprintName = "EmotiBitOscilloscope-arm64" + ReferencedContainer = "container:EmotiBitOscilloscope.xcodeproj"> + </BuildableReference> + </BuildableProductRunnable> </LaunchAction>EmotiBitDataParser/EmotiBitDataParser.xcodeproj/project.pbxproj (1)
1002-1014: Post-build signing script strips x86_64 unconditionallyThe script runs lipo -extract x86_64 on every framework/bundle, which will fail if the slice doesn’t exist (e.g., arm64-only). Consider using lipo -info and only extracting when the arch exists, or using --remove for non-existent slice handling.
- lipo -extract x86_64 "${ITEM}" -o "${ITEM}" + if lipo -info "${ITEM}" | grep -q 'x86_64'; then + lipo -extract x86_64 "${ITEM}" -o "${ITEM}" + fiAlso applies to: 1028-1040
EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/project.pbxproj (1)
1817-1844: Same lipo x86_64 unconditional strip risk as DataParserThe signing script unconditionally tries to extract x86_64 slices. Use a guard to avoid failing on arm64-only items.
- lipo -extract x86_64 "${ITEM}" -o "${ITEM}" + if lipo -info "${ITEM}" | grep -q 'x86_64'; then + lipo -extract x86_64 "${ITEM}" -o "${ITEM}" + fiAlso applies to: 1830-1831
🧹 Nitpick comments (14)
EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Release-x86_64.xcscheme (1)
26-32: TestAction uses Release but has no Testables; confirm intentWith no Testables, switching TestAction to Release is a no-op. If you intend to run tests in Release for parity, add the test targets; otherwise consider dropping TestAction or aligning with Debug for consistency.
.github/workflows/check-installer-project-version.yml (1)
7-7: Trigger reordering only: no functional change detectedReordering to place workflow_dispatch after pull_request is fine; behavior remains unchanged.
If you’re standardizing workflow structure, consider adding explicit permissions for GITHUB_TOKEN (e.g., permissions: contents: read) at the workflow top for least privilege.
EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-x86_64.xcscheme (1)
55-70: Profiling with Debug may skew performance measurementsProfileAction now uses Debug. Profiling optimized Release builds is typically preferred for realistic results. If this scheme is strictly for developer debugging, this is fine; otherwise, consider using Release for ProfileAction.
Apply this diff if you want profiling parity with shipping builds:
- <ProfileAction - buildConfiguration = "Debug" + <ProfileAction + buildConfiguration = "Release"EmotiBitFirmwareInstaller/openFrameworks-Info.plist (1)
25-26: Avoid opting out of Retina/HiDPI unless strictly requiredSetting NSHighResolutionCapable to false disables HiDPI on macOS and will blur UI on Retina displays. If there isn’t a specific rendering bug you’re working around, prefer enabling HiDPI or removing the key to use the default.
Apply this diff if HiDPI is supported:
- <key>NSHighResolutionCapable</key> - <false/> + <key>NSHighResolutionCapable</key> + <true/>README.md (1)
59-60: Clarify addon link labels for consistencyUse owner/repo style in link text for clarity and consistency with the script below.
- - **ofxSerial:** [EmotiBit ofxSerial](https://github.com/EmotiBit/ofxSerial) - - **ofxIO:** [bakercp ofxIO](https://github.com/bakercp/ofxIO) + - **ofxSerial:** [EmotiBit/ofxSerial](https://github.com/EmotiBit/ofxSerial) + - **ofxIO:** [bakercp/ofxIO](https://github.com/bakercp/ofxIO)EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/xcshareddata/xcschemes/Debug.xcscheme (1)
64-64: ProfileAction should usually run with Release configurationProfiling Debug builds can skew performance characteristics. Prefer Release for realistic profiling.
- buildConfiguration = "Debug" + buildConfiguration = "Release"src/ofxEmotiBitVersion.h (1)
6-6: Optional: Prefer an inline constexpr string in headers to avoid per-TU std::string instances.Defining a non-extern std::string in a header creates a separate object per translation unit. A constexpr string literal avoids dynamic allocation and ODR pitfalls.
-const std::string ofxEmotiBitVersion = "1.12.2"; +inline constexpr const char ofxEmotiBitVersion[] = "1.12.2";Additionally update the write to not call c_str() on a literal array:
Outside this range (for your reference):
- Change line writing to file to: mFile << ofxEmotiBitVersion;
EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/xcshareddata/xcschemes/Release.xcscheme (1)
64-81: Profile/Analyze actions switched to Release; double-check intent.Using Release for Profile/Analyze is common, but if you rely on debug symbols or assertions during analysis, consider keeping Analyze on Debug. Otherwise LGTM.
EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-arm64.xcscheme (1)
3-4: LastUpgradeVersion regression (0600) — likely unintended downgradeChanging LastUpgradeVersion to "0600" effectively declares this scheme was last upgraded with Xcode 6, which is far older than the rest of the repo and can cause churn. Recommend reverting to the current Xcode’s value or leaving it untouched.
- LastUpgradeVersion = "0600" + LastUpgradeVersion = "1420".github/workflows/create-draft-release.yml (3)
112-144: Trim trailing spaces flagged by YAMLlintYAMLlint errors on trailing spaces reduce CI signal quality and can break strict linters. Clean up the heredoc block.
- }); - + }); ... - }); - + }); ... - - Extract the downloaded zip file. + - Extract the downloaded zip file. ... - +Lines with whitespace-only tails: 54, 99, 131, 144 in this file. The above snippet shows the idea; please remove the extra trailing spaces on those lines.
146-151: Version grep is brittle; anchor on the initializer to avoid false matchesIf the header gets additional references or comments, this grep could extract the wrong string. Anchoring to the initializer improves robustness.
- VERSION=$(grep src/ofxEmotiBitVersion.h -e "ofxEmotiBitVersion" | grep -o '"[^"]*"' | tr -d '"') + VERSION=$(gawk -F'"' '/^\s*const\s+std::string\s+ofxEmotiBitVersion\s*=\s*"/ { print $2; exit }' src/ofxEmotiBitVersion.h)
109-144: Release notes placeholders — ensure they’re filled to avoid confusing draft contentThe firmware link is a placeholder and some headings are empty. Consider templating these from PR titles or CHANGELOG to avoid publishing incomplete notes by mistake.
Would you like me to wire in automatic PR aggregation for the “PRs completed” section (e.g., using the GitHub API to list merged PRs between tags)?
EmotiBitDataParser/EmotiBitDataParser.xcodeproj/project.pbxproj (1)
360-368: Massive OpenSSL header references in the project file increase merge churnListing dozens of OpenSSL headers as file references adds noise and increases the risk of merge conflicts without build benefits (headers don’t need PBXFileReferences to compile). Prefer relying on header search paths only and keep groups logical (virtual).
Proposed cleanup:
- Remove individual PBXFileReference entries for OpenSSL headers.
- Keep a single “openssl” virtual group for navigation.
- Ensure HEADER_SEARCH_PATHS includes ../../../addons/ofxPoco/libs/openssl/include.
Also applies to: 377-385, 534-541, 588-595, 599-606
EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/project.pbxproj (1)
59-69: Bundled third-party binaries and firmware — verify licenses and provenanceYou’re shipping bossac, FirmwareUploader, and multiple firmware binaries. Ensure all licenses permit redistribution in your installer and that LICENSE.txt coverage is sufficient.
I can help inventory and verify upstream licenses for these artifacts and suggest a NOTICE file if needed.
Also applies to: 65-67
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these settings in your CodeRabbit configuration.
⛔ Files ignored due to path filters (2)
EmotiBitFirmwareInstaller/bin/data/EmotiBit_stock_firmware.ino.feather_esp32.binis excluded by!**/*.binEmotiBitFirmwareInstaller/bin/data/EmotiBit_stock_firmware.ino.feather_m0.binis excluded by!**/*.bin
📒 Files selected for processing (20)
.github/workflows/check-installer-project-version.yml(1 hunks).github/workflows/create-draft-release.yml(1 hunks).gitignore(1 hunks)EmotiBitDataParser/EmotiBitDataParser.xcodeproj/project.pbxproj(15 hunks)EmotiBitDataParser/EmotiBitDataParser.xcodeproj/xcshareddata/xcschemes/Debug.xcscheme(4 hunks)EmotiBitDataParser/EmotiBitDataParser.xcodeproj/xcshareddata/xcschemes/Release.xcscheme(4 hunks)EmotiBitDataParser/Project.xcconfig(1 hunks)EmotiBitDataParser/openFrameworks-Info.plist(2 hunks)EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/project.pbxproj(34 hunks)EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/xcshareddata/xcschemes/Debug.xcscheme(5 hunks)EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/xcshareddata/xcschemes/Release.xcscheme(5 hunks)EmotiBitFirmwareInstaller/openFrameworks-Info.plist(1 hunks)EmotiBitInstaller/EmotiBitInstaller/EmotiBitInstaller.vdproj(1 hunks)EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-arm64.xcscheme(3 hunks)EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-x86_64.xcscheme(2 hunks)EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Release-x86_64.xcscheme(2 hunks)EmotiBitOscilloscope/Project.xcconfig(1 hunks)EmotiBitOscilloscope/openFrameworks-Info.plist(1 hunks)README.md(2 hunks)src/ofxEmotiBitVersion.h(1 hunks)
🧰 Additional context used
🪛 LanguageTool
README.md
[grammar] ~59-~59: There might be a mistake here.
Context: ...r - ofxSerial: EmotiBit ofxSerial - ofxIO: [bakercp ofxIO](https://github....
(QB_NEW_EN)
[grammar] ~60-~60: There might be a mistake here.
Context: ...ofxSerial) - ofxIO: bakercp ofxIO - Additional notes - The project is buil...
(QB_NEW_EN)
🪛 actionlint (1.7.7)
.github/workflows/create-draft-release.yml
20-20: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
65-65: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
171-171: the runner of "softprops/action-gh-release@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🪛 YAMLlint (1.37.1)
.github/workflows/create-draft-release.yml
[error] 54-54: trailing spaces
(trailing-spaces)
[error] 99-99: trailing spaces
(trailing-spaces)
[error] 131-131: trailing spaces
(trailing-spaces)
[error] 144-144: trailing spaces
(trailing-spaces)
🔇 Additional comments (22)
EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Release-x86_64.xcscheme (1)
72-73: Analyze in Release: LGTMAnalyzing in Release for the Release scheme makes sense for parity with shipping configuration.
EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-x86_64.xcscheme (1)
75-77: ArchiveAction in Debug schemes uses Debug—confirm your distribution workflow
Archiving with a Debug build configuration produces non-optimized archives that aren’t suitable for signing or notarization. You already have aRelease-x86_64.xcscheme(usingReleasefor ArchiveAction), so this may be intentional for your Debug-only schemes. If you expect to ship from the Debug-* schemes instead, switch their ArchiveAction toRelease; otherwise, continue using your existing Release scheme for distribution.• EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-x86_64.xcscheme (line 75)
• EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-arm64.xcscheme (line 55)Suggested change if you do want to archive Debug schemes as Release:
- <ArchiveAction - buildConfiguration = "Debug" + <ArchiveAction + buildConfiguration = "Release"README.md (1)
82-90: Branch Verification CompletedVerified that the
stablebranch exists in bothEmotiBit/ofxSerialandbakercp/ofxIO. No changes to the README setup script are required.EmotiBitDataParser/EmotiBitDataParser.xcodeproj/xcshareddata/xcschemes/Release.xcscheme (3)
30-38: MacroExpansion addition looks goodAdding MacroExpansion ensures tests pick up scheme arguments/env. No issues.
68-68: Explicitly disabling document versioning in ProfileAction is fineNo functional concerns; this can reduce overhead when profiling.
81-81: AnalyzeAction using Release configurationReasonable if you want analysis against optimized settings. No issues.
EmotiBitDataParser/EmotiBitDataParser.xcodeproj/xcshareddata/xcschemes/Debug.xcscheme (2)
30-38: MacroExpansion addition looks goodThis helps TestAction resolve the correct build product. No issues.
68-68: debugDocumentVersioning disabled in ProfileActionFine; keeps profiling runs clean of document versioning overhead.
EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/xcshareddata/xcschemes/Debug.xcscheme (3)
30-38: MacroExpansion addition looks goodEnsures TestAction picks the right target context. No issues.
49-49: debugDocumentVersioning disabled in LaunchActionReasonable; helps avoid versioning overhead during debug runs.
68-68: debugDocumentVersioning disabled in ProfileActionConsistent with the LaunchAction choice; no issues.
src/ofxEmotiBitVersion.h (1)
6-6: Version bump verified: Bothsrc/ofxEmotiBitVersion.hand the Windows installer (EmotiBitInstaller.vdproj) now read 1.12.2, and there are no remaining references to 1.12.1. Ready to merge.EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/xcshareddata/xcschemes/Release.xcscheme (2)
30-38: Adding MacroExpansion in TestAction is correct.This ensures environment substitutions resolve consistently when tests/macros are evaluated. No issues spotted.
3-3: Review comment update: No regression in LastUpgradeVersion
Both Debug.xcscheme and Release.xcscheme showLastUpgradeVersion = "0600"in this commit and the previous commit—there was no inadvertent downgrade. If you need to bump this to match your local Xcode version, please open the project in Xcode and let it migrate the schemes automatically.Likely an incorrect or invalid review comment.
EmotiBitInstaller/EmotiBitInstaller/EmotiBitInstaller.vdproj (1)
2227-2236: MSI identifiers and version updated correctly.
- ProductCode and PackageCode regenerated.
- ProductVersion bumped to 1.12.2.
- UpgradeCode unchanged.
- RemovePreviousVersions and DetectNewerInstalledVersion already enabled.
This aligns with src/ofxEmotiBitVersion.h.
EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-arm64.xcscheme (1)
17-21: BlueprintIdentifier/BuildableName alignment looks goodTargeting the arm64 variant explicitly here makes sense given the new app bundle name. Once the LaunchAction runnable is restored, this should work as expected.
EmotiBitDataParser/EmotiBitDataParser.xcodeproj/project.pbxproj (3)
31-42: Resource copy phase rename is sensible; verify data files are present at build timeThe new “Copy files to Resources” phase for parsedDataFormat.json and verdana.ttf is clear and correct. Ensure these files exist in bin/data at build time on CI and self-hosted agents.
If you’d like, I can add a pre-build check script that fails fast when required resource files are missing.
Also applies to: 55-57, 916-929
18-21: EmotiBitPacket.cpp moved under EmotiBit_XPlat_Utils — good modularizationPointing to ../../../addons/EmotiBit_XPlat_Utils/src/EmotiBitPacket.cpp reduces duplication and centralizes shared code. Ensure the header search paths include this directory for all configurations.
Also applies to: 1048-1064
1154-1155: macOS deployment target raised to 10.14 — verify intended support windowBumping from 10.9 to 10.14 will drop support for older macOS versions. If that’s the policy going forward, great. Otherwise, confirm downstream consumers (e.g., lab Macs) aren’t stuck on <10.14.
If needed, we can gate features that require 10.14 with compile-time checks while keeping a lower deployment target.
Also applies to: 1302-1303, 1358-1359
EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/project.pbxproj (3)
118-133: Copy Files phases: good granularity; ensure executable flags and code signing on copied toolsYou correctly set CodeSignOnCopy on executables (bossac, FirmwareUploader, esptool). Ensure these files have executable permissions in the repo and that Gatekeeper considerations are acceptable for distribution.
If you want, I can add a pre-build validation script to chmod +x these tools when needed.
Also applies to: 135-147, 149-161, 163-174, 176-185
2089-2108: macOS deployment target raised to 10.14 — confirm intended minimum OSSame concern as DataParser. If 10.14 is the new baseline, all good; otherwise double-check user environments.
Also applies to: 2331-2346, 2416-2433
721-728: New addon groups (ofxEmotiBit/ofxJSON/jsoncpp) look correctThe grouping and added file references for JSON are coherent; builds include jsoncpp.cpp in Sources. Good step towards consistent JSON handling.
Also applies to: 869-876, 1303-1314
| runs-on: [self-hosted, Linux] | ||
| if: github.event_name == 'workflow_dispatch' || (github.event.pull_request.merged == true && github.event.pull_request.head.ref == 'dev') | ||
|
|
There was a problem hiding this comment.
Job guard is fine, but missing explicit permissions can break artifact listing and release creation
Listing workflows and artifacts needs actions: read; creating releases needs contents: write. Without explicit permissions, GITHUB_TOKEN may be insufficient on pull_request/closed and workflow_dispatch.
on:
pull_request:
types: [closed]
branches:
- master
workflow_dispatch:
+permissions:
+ contents: write # required for release creation
+ actions: read # required to list workflows/runs/artifacts
+ id-token: none
+ issues: read
+ pull-requests: read📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| runs-on: [self-hosted, Linux] | |
| if: github.event_name == 'workflow_dispatch' || (github.event.pull_request.merged == true && github.event.pull_request.head.ref == 'dev') | |
| on: | |
| pull_request: | |
| types: [closed] | |
| branches: | |
| - master | |
| workflow_dispatch: | |
| permissions: | |
| contents: write # required for release creation | |
| actions: read # required to list workflows/runs/artifacts | |
| id-token: none | |
| issues: read | |
| pull-requests: read |
🤖 Prompt for AI Agents
.github/workflows/create-draft-release.yml around lines 12 to 14: the workflow
lacks explicit permissions which can cause GITHUB_TOKEN to be insufficient for
listing artifacts/workflows and creating releases; add a permissions block at
the top of the workflow declaring at minimum actions: read (for listing
workflows/artifacts) and contents: write (for creating releases) so the jobs
that list artifacts and create a release have the needed scopes.
| uses: actions/github-script@v6 | ||
| id: download-mac-artifacts |
There was a problem hiding this comment.
Update deprecated actions to Node20-compatible versions
actionlint flagged actions using deprecated Node runtimes. Upgrade to resolve runtime failures on GitHub-hosted and many self-hosted runners.
- uses: actions/github-script@v6
+ uses: actions/github-script@v7
...
- uses: actions/github-script@v6
+ uses: actions/github-script@v7
...
- uses: softprops/action-gh-release@v1
+ uses: softprops/action-gh-release@v2Also applies to: 65-66, 171-172
🧰 Tools
🪛 actionlint (1.7.7)
20-20: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🤖 Prompt for AI Agents
In .github/workflows/create-draft-release.yml around lines 20-21 (and also
update occurrences at 65-66 and 171-172), the workflow uses
actions/github-script@v6 which depends on a deprecated Node runtime; update the
action references to a Node20-compatible version (for example the latest major
that supports Node20 or switch to actions/github-script@v7+ or an alternative
maintained action), and verify any inputs or script syntax remain compatible;
replace each occurrence and run a quick workflow lint to ensure actionlint no
longer flags deprecated Node runtimes.
| body: ${{ steps.generate-release-notes.outputs.release_notes }} | ||
| files: | | ||
| EmotiBitSoftware-macos.zip | ||
| EmotiBitSoftware-Windows.zip | ||
| config.txt | ||
| env: |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Gracefully handle missing artifacts to avoid release step failures
If either artifact isn’t found, softprops/action-gh-release will fail when files are missing. Either conditionally include files, or instruct the action to ignore unmatched files.
with:
draft: true
tag_name: ${{ steps.get_version.outputs.tag }}
name: Draft Release ${{ steps.get_version.outputs.tag }}
body: ${{ steps.generate-release-notes.outputs.release_notes }}
+ fail_on_unmatched_files: false
files: |
EmotiBitSoftware-macos.zip
EmotiBitSoftware-Windows.zip
config.txt📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| body: ${{ steps.generate-release-notes.outputs.release_notes }} | |
| files: | | |
| EmotiBitSoftware-macos.zip | |
| EmotiBitSoftware-Windows.zip | |
| config.txt | |
| env: | |
| with: | |
| draft: true | |
| tag_name: ${{ steps.get_version.outputs.tag }} | |
| name: Draft Release ${{ steps.get_version.outputs.tag }} | |
| body: ${{ steps.generate-release-notes.outputs.release_notes }} | |
| fail_on_unmatched_files: false | |
| files: | | |
| EmotiBitSoftware-macos.zip | |
| EmotiBitSoftware-Windows.zip | |
| config.txt |
🤖 Prompt for AI Agents
In .github/workflows/create-draft-release.yml around lines 176-181, the release
step will fail when listed artifact files are missing; update the workflow to
either (A) detect whether each artifact exists prior to invoking
softprops/action-gh-release and only pass the paths for files that exist, or (B)
add the action input to ignore unmatched files (e.g., enable the option that
allows unmatched file patterns) so missing artifacts do not cause the step to
fail; implement one of these approaches and ensure the files list is built or
the action configured accordingly.
| */*xcodeproj/*workspace/* | ||
| **/xcuser*/** |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Over-broad Xcode ignore may drop shared schemes from future changes
Ignoring the entire project.xcworkspace subtree (Line 54) will also ignore xcshareddata, preventing shared schemes from being added/updated in the repo. You already track shared schemes in this PR; this rule will make future scheme updates silently untracked for untracked files.
Refine the patterns to ignore only per-user data:
Apply this diff:
-*/*xcodeproj/*workspace/*
-**/xcuser*/**
+**/*.xcodeproj/project.xcworkspace/xcuserdata/**
+**/*.xcodeproj/xcuserdata/**
+**/*.xcuserstateFollow-up:
- Verify existing shared schemes under xcshareddata remain tracked after this change. If any were accidentally ignored locally, remove from .gitignore as above, then git add them explicitly.
🏁 Script executed:
#!/bin/bash
set -e
echo "Lines 54-60 of .gitignore:"
sed -n '54,60p' .gitignore || echo "Unable to read .gitignore"
echo
echo "Occurrences of 'xcshareddata' in .gitignore:"
grep -n "xcshareddata" .gitignore || echo "None"
echo
echo "Tracked files with 'xcshareddata' in path:"
git ls-files | grep "xcshareddata" || echo "None"Length of output: 1114
🏁 Script executed:
#!/bin/bash
set -e
echo "List of .xcworkspace directories:"
find . -type d -name "*.xcworkspace" || echo "None"
echo
echo "Contents of each .xcworkspace directory (depth 2):"
for d in $(find . -type d -name "*.xcworkspace"); do
echo "Directory: $d"
find "$d" -maxdepth 2 | sed 's/^/ /'
done
echo
echo "xcshareddata directories under .xcworkspace:"
find . -type d -name "xcshareddata" | grep "\.xcworkspace" || echo "None"Length of output: 466
🏁 Script executed:
#!/bin/bash
set -e
echo "Checking .gitignore rules affecting xcshareddata files:"
files=$(git ls-files | grep '/xcshareddata/')
if [ -z "$files"; then
echo "No xcshareddata files found"
exit 0
fi
echo "Files to check:"
echo "$files"
echo
echo "Ignored entries (if any):"
git check-ignore -v $files || echo "None of the xcshareddata files are ignored"Length of output: 3851
🏁 Script executed:
#!/bin/bash
set -e
echo "Inspecting contents of EmotiBitDataParser.xcodeproj at depth 2:"
find EmotiBitDataParser/EmotiBitDataParser.xcodeproj -maxdepth 2 | sed 's/^/ /'Length of output: 480
Refine .gitignore to ignore only per-user Xcode data and preserve shared schemes
We’ve verified that none of the files under xcshareddata/ are currently ignored (all existing shared schemes remain tracked). To prevent future workspace-level shared schemes from being silently excluded, update your .gitignore to target only user data:
- */*xcodeproj/*workspace/*
- **/xcuser*/**
+ **/*.xcworkspace/xcuserdata/**
+ **/*.xcodeproj/xcuserdata/**
+ **/*.xcuserstateFollow-up:
- After merging, ensure no new workspace-level shared schemes (e.g. in
*.xcworkspace/xcshareddata/) are omitted by your ignore rules. - If any shared-scheme files were previously ignored locally, remove them from
.gitignoreandgit addthose files explicitly.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| */*xcodeproj/*workspace/* | |
| **/xcuser*/** | |
| **/*.xcworkspace/xcuserdata/** | |
| **/*.xcodeproj/xcuserdata/** | |
| **/*.xcuserstate |
🤖 Prompt for AI Agents
In .gitignore around lines 54-55, the rules are too broad and may ignore
workspace-level shared schemes; narrow them to only ignore per-user Xcode data
by replacing the current patterns with ones that target xcuserdata and
xcuserstate (e.g., ignore **/xcuserdata/** and **/xcuserstate/**) while ensuring
**/xcshareddata/** remains tracked; after updating, check the repo for any
shared-scheme files that were previously ignored and, if found, remove them from
.gitignore and add them back to git so workspace-level shared schemes are
preserved.
| ICON_FILE = "$(ICON_FILE_PATH)$(ICON)"; | ||
| ICON_FILE_PATH = ../EmotiBitIcons/macOS/; | ||
| ICON_NAME_DEBUG = EmotiBit.icns; | ||
| ICON_NAME_RELEASE = EmotiBit.icns; | ||
| INFOPLIST_FILE = "openFrameworks-Info.plist"; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Icon configuration diverges between targets; align with the source of truth
Here you set ICON_FILE_PATH to ../EmotiBitIcons/macOS/ and both names to EmotiBit.icns. That’s consistent and avoids surprises. It conflicts with EmotiBitOscilloscope which uses OF_PATH and custom icon names. Recommend standardizing across apps.
# Align other targets (e.g., Oscilloscope) to this convention for consistency:
ICON = "$(ICON_NAME_RELEASE|ICON_NAME_DEBUG)"
ICON_FILE = "$(ICON_FILE_PATH)$(ICON)"
ICON_FILE_PATH = ../EmotiBitIcons/macOS/
ICON_NAME_DEBUG = EmotiBit.icns
ICON_NAME_RELEASE = EmotiBit.icnsAlso applies to: 1296-1299, 1353-1355
🤖 Prompt for AI Agents
In EmotiBitDataParser/EmotiBitDataParser.xcodeproj/project.pbxproj around lines
1147-1151 (and also update the similar blocks at 1296-1299 and 1353-1355), the
icon variables are defined locally as ICON_FILE_PATH = ../EmotiBitIcons/macOS/
and ICON_NAME_* = EmotiBit.icns which diverges from the EmotiBitOscilloscope
target; change these entries to use the shared, source-of-truth variables (e.g.
reference OF_PATH or the common icon path variable used by EmotiBitOscilloscope)
and set ICON_NAME_DEBUG and ICON_NAME_RELEASE to the same centralized icon name
or to the variables used by the other target so all targets reference the same
icon path/names.
| <?xml version="1.0" encoding="UTF-8"?> | ||
| <Scheme | ||
| LastUpgradeVersion = "1420" | ||
| LastUpgradeVersion = "0600" |
There was a problem hiding this comment.
LastUpgradeVersion downgraded to "0600" (Xcode 6) — likely unintended
Revert to the previous/current Xcode version to prevent confusion and accidental downgrades.
- LastUpgradeVersion = "0600"
+ LastUpgradeVersion = "1420"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| LastUpgradeVersion = "0600" | |
| LastUpgradeVersion = "1420" |
🤖 Prompt for AI Agents
In
EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/xcshareddata/xcschemes/Debug.xcscheme
around line 3, LastUpgradeVersion was unintentionally changed to "0600" (Xcode
6); restore it to the prior/current Xcode version to avoid downgrades. Revert
this single-line change either by checking out the previous version from Git or
replacing "0600" with the project’s correct LastUpgradeVersion string (the value
used by your current Xcode), save the file, and recommit so the scheme reflects
the proper Xcode version.
| </AnalyzeAction> | ||
| <ArchiveAction | ||
| buildConfiguration = "Release" | ||
| buildConfiguration = "Debug" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
ArchiveAction should target Release configuration
Archiving Debug is rarely desired for distribution and may impact code signing and artifact size.
- buildConfiguration = "Debug"
+ buildConfiguration = "Release"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| buildConfiguration = "Debug" | |
| buildConfiguration = "Release" |
🤖 Prompt for AI Agents
In
EmotiBitFirmwareInstaller/EmotiBitFirmwareInstaller.xcodeproj/xcshareddata/xcschemes/Debug.xcscheme
around line 84, the ArchiveAction is currently set to use the "Debug"
buildConfiguration; change it to "Release" so archiving uses the Release
configuration (update the buildConfiguration value from "Debug" to "Release" for
the ArchiveAction entry).
| buildConfiguration = "Debug" | ||
| shouldUseLaunchSchemeArgsEnv = "YES" | ||
| savedToolIdentifier = "" | ||
| useCustomWorkingDirectory = "NO" | ||
| debugDocumentVersioning = "YES"> | ||
| <BuildableProductRunnable | ||
| runnableDebuggingMode = "0"> | ||
| <BuildableReference | ||
| BuildableIdentifier = "primary" | ||
| BlueprintIdentifier = "B990E5B62C0E7A370094B63E" | ||
| BuildableName = "EmotiBitOscilloscope.app" | ||
| BlueprintName = "EmotiBitOscilloscope-arm64" | ||
| ReferencedContainer = "container:EmotiBitOscilloscope.xcodeproj"> | ||
| </BuildableReference> | ||
| </BuildableProductRunnable> | ||
| debugDocumentVersioning = "NO"> | ||
| </ProfileAction> |
There was a problem hiding this comment.
Profile/Archive actions should be Release, not Debug
Profiling and archiving with Debug undermines performance measurements and produces non-optimized artifacts.
<ProfileAction
- buildConfiguration = "Debug"
+ buildConfiguration = "Release"
shouldUseLaunchSchemeArgsEnv = "YES"
savedToolIdentifier = ""
useCustomWorkingDirectory = "NO"
debugDocumentVersioning = "NO">
</ProfileAction>
...
<ArchiveAction
- buildConfiguration = "Debug"
+ buildConfiguration = "Release"
revealArchiveInOrganizer = "YES">
</ArchiveAction>Also applies to: 55-57
🤖 Prompt for AI Agents
In
EmotiBitOscilloscope/EmotiBitOscilloscope.xcodeproj/xcshareddata/xcschemes/Debug-arm64.xcscheme
around lines 45-50 (and also lines 55-57), the Profile and Archive actions are
set to "Debug"; change those buildConfiguration attributes to "Release" so
profiling and archiving use optimized Release builds. Open the .xcscheme and
replace the buildConfiguration="Debug" entries for the ProfileAction and
ArchiveAction with buildConfiguration="Release", save, and verify the scheme XML
now references Release for both actions.
| <key>NSHighResolutionCapable</key> | ||
| <false/> |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Disabling high-resolution rendering may degrade UI on Retina displays
Setting NSHighResolutionCapable to false forces non-HiDPI rendering, likely causing blurry UI on Retina Macs. If the intent is performance testing, consider restricting this to Debug builds; otherwise set to true or remove the key (defaults typically allow HiDPI).
Apply this diff to enable HiDPI:
- <key>NSHighResolutionCapable</key>
- <false/>
+ <key>NSHighResolutionCapable</key>
+ <true/>Follow-up:
- Confirm this change aligns with the corresponding Info.plist updates in other modules (DataParser, FirmwareInstaller) to keep behavior consistent across apps.
🏁 Script executed:
#!/bin/bash
set -e
echo "=== Info.plist files in repo ==="
fd --type f --extension plist
echo
echo "=== Occurrences of NSHighResolutionCapable ==="
rg -n --color=never "NSHighResolutionCapable"
echo
echo "=== Directories named DataParser and FirmwareInstaller ==="
fd --type d DataParser || echo "No DataParser directory found"
fd --type d FirmwareInstaller || echo "No FirmwareInstaller directory found"Length of output: 1054
🏁 Script executed:
#!/bin/bash
set -e
echo "=== EmotiBitDataParser/openFrameworks-Info.plist around NSHighResolutionCapable ==="
rg -C2 NSHighResolutionCapable EmotiBitDataParser/openFrameworks-Info.plist || true
echo
echo "=== EmotiBitFirmwareInstaller/openFrameworks-Info.plist around NSHighResolutionCapable ==="
rg -C2 NSHighResolutionCapable EmotiBitFirmwareInstaller/openFrameworks-Info.plist || trueLength of output: 878
Ensure Retina (HiDPI) support across all apps
Disabling NSHighResolutionCapable forces non-HiDPI rendering and will result in blurry UI on Retina Macs. Currently, all three Info.plist files have this key set to false. To restore crisp rendering, update each one to true (or remove the key to use the default behavior). If you only need to disable HiDPI in Debug builds for performance testing, scope the false setting accordingly.
Files to update:
- EmotiBitOscilloscope/openFrameworks-Info.plist (lines 25–26)
- EmotiBitDataParser/openFrameworks-Info.plist (around line 23)
- EmotiBitFirmwareInstaller/openFrameworks-Info.plist (around line 25)
Apply this diff in each file:
- <key>NSHighResolutionCapable</key>
- <false/>
+ <key>NSHighResolutionCapable</key>
+ <true/>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <key>NSHighResolutionCapable</key> | |
| <false/> | |
| <key>NSHighResolutionCapable</key> | |
| <true/> |
🤖 Prompt for AI Agents
In EmotiBitOscilloscope/openFrameworks-Info.plist around lines 25–26,
NSHighResolutionCapable is explicitly set to false which forces non-HiDPI
rendering and causes blurry UI on Retina Macs; change the value to true (or
remove the key to use default HiDPI behavior), or if you must disable HiDPI only
in Debug builds, conditionally set it for that configuration; apply the same
update to EmotiBitDataParser/openFrameworks-Info.plist (around line 23) and
EmotiBitFirmwareInstaller/openFrameworks-Info.plist (around line 25).
| ICON_NAME_DEBUG = icon-debug.icns | ||
| ICON_NAME_RELEASE = icon.icns | ||
| ICON_FILE_PATH = $(OF_PATH)/libs/openFrameworksCompiled/project/osx/ | ||
|
|
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Icon path likely incorrect and inconsistent with other targets; verify files exist or align with shared icon location
You’ve switched to $(OF_PATH)/libs/openFrameworksCompiled/project/osx/ with custom names icon-debug.icns/icon.icns. That directory typically contains openFrameworks’ default icon(s), not these custom filenames. Other targets in this PR use ../EmotiBitIcons/macOS/ with EmotiBit.icns. If these files don’t exist at the OF path, the post-build copy step will fail.
Consider aligning to the shared EmotiBitIcons location (or ensure the files actually exist at the configured path).
Apply this diff if you intend to use the shared icon set (mirroring other targets):
-ICON_NAME_DEBUG = icon-debug.icns
-ICON_NAME_RELEASE = icon.icns
-ICON_FILE_PATH = $(OF_PATH)/libs/openFrameworksCompiled/project/osx/
+ICON_NAME_DEBUG = EmotiBit.icns
+ICON_NAME_RELEASE = EmotiBit.icns
+ICON_FILE_PATH = ../EmotiBitIcons/macOS/Run this script to verify icon files exist where expected:
🏁 Script executed:
#!/bin/bash
echo "Searching for icon files..."
fd -a 'EmotiBit.icns'
fd -a 'icon-debug.icns'
fd -a 'icon.icns'Length of output: 181
Align icon configuration to shared EmotiBitIcons location
The search shows only EmotiBit.icns in EmotiBitIcons/macOS/, while icon-debug.icns and icon.icns are missing under $(OF_PATH)/libs/openFrameworksCompiled/project/osx/. To avoid post-build copy failures, update the xcconfig to point both debug and release to the shared icon:
- File:
EmotiBitOscilloscope/Project.xcconfig(lines 9-12)
-ICON_NAME_DEBUG = icon-debug.icns
-ICON_NAME_RELEASE = icon.icns
-ICON_FILE_PATH = $(OF_PATH)/libs/openFrameworksCompiled/project/osx/
+ICON_NAME_DEBUG = EmotiBit.icns
+ICON_NAME_RELEASE = EmotiBit.icns
+ICON_FILE_PATH = ../EmotiBitIcons/macOS/📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ICON_NAME_DEBUG = icon-debug.icns | |
| ICON_NAME_RELEASE = icon.icns | |
| ICON_FILE_PATH = $(OF_PATH)/libs/openFrameworksCompiled/project/osx/ | |
| ICON_NAME_DEBUG = EmotiBit.icns | |
| ICON_NAME_RELEASE = EmotiBit.icns | |
| ICON_FILE_PATH = ../EmotiBitIcons/macOS/ |
🤖 Prompt for AI Agents
In EmotiBitOscilloscope/Project.xcconfig around lines 9-12, both ICON_NAME_DEBUG
and ICON_NAME_RELEASE are pointing to non-existent icons under
$(OF_PATH)/libs/openFrameworksCompiled/project/osx/ causing post-build copy
failures; change both ICON_NAME_DEBUG and ICON_NAME_RELEASE to EmotiBit.icns and
update ICON_FILE_PATH to the shared EmotiBitIcons/macOS/ directory (e.g. the
relative path that points to EmotiBitIcons/macOS/ in this repo) so both build
configurations use the single existing EmotiBit.icns file.
1 participant
Description
Summary by CodeRabbit