@maccesar/titools 5.2.5 → 5.4.0

package/skills/ti-howtos/references/web-content-integration.md

@@ -1,287 +0,0 @@
-# Web content integration
-
-## 1. The WebView component
-
-### WKWebView (Titanium SDK 8.0.0+)
-As of Titanium SDK 8.0.0, WKWebView is the only supported web view on iOS. UIWebView was deprecated and removed. WKWebView behaves differently, so plan for that.
-
-### Basic WebView creation
-
-Remote URL:
-```javascript
-const webview = Ti.UI.createWebView({
-  url: 'https://titaniumsdk.com'
-});
-win.add(webview);
-win.open();
-```
-
-Local HTML:
-```javascript
-const webview = Ti.UI.createWebView({
-  url: 'local.html' // Relative to Resources or app/assets/app/lib
-});
-win.add(webview);
-```
-
-Inline HTML:
-```javascript
-const webview = Ti.UI.createWebView({
-  html: '<html><body><h1>Hello</h1></body></html>'
-});
-```
-
-### Local web content with assets
-Local content can include CSS, JS, and images. Paths are relative to Resources (Classic) or app/assets/app/lib (Alloy).
-
-`local.html`:
-```html
-<html>
-  <head>
-    <link rel="stylesheet" type="text/css" href="local.css"/>
-    <script src="local.js"></script>
-  </head>
-  <body>
-    <p>Local content</p>
-  </body>
-</html>
-```
-
-### WebView properties and methods
-
-Navigation:
-- `canGoBack()` - returns true if possible to go back
-- `canGoForward()` - returns true if possible to go forward
-- `goBack()` - navigate back in history
-- `goForward()` - navigate forward in history
-
-Load control:
-- `loading` (Boolean) - current loading state
-- `reload()` - refresh the page
-- `stopLoading()` - stop loading
-- `repaint()` - force repaint
-
-Data handling:
-- `url` - local or remote URL
-- `html` - inline HTML string
-- `scalesPageToFit` - scale content to dimensions
-- `setBasicAuthentication(host, username, password)` - HTTP auth
-
-```javascript
-webView.setBasicAuthentication('myDomain.com', 'username', 'password');
-```
-
-Events:
-- `beforeload` - fires before loading begins (`e.url` contains the source)
-- `load` - fires when content has loaded
-- `error` - fires on load failures (`e.url`, `e.message`)
-
-## 2. Communication between WebViews and Titanium
-
-### Local web content communication
-
-Logging from WebView: Ti.API methods work inside local HTML.
-
-```html
-<html>
-  <body onload="Ti.API.info('Page loaded!');">
-    <p>Logging works!</p>
-  </body>
-</html>
-```
-
-Bidirectional events with `Ti.App`:
-
-In local HTML:
-```html
-<html>
-  <head>
-    <script>
-      // Listen for events from Titanium
-      Ti.App.addEventListener('app:fromTitanium', (e) => {
-        alert(e.message);
-        document.getElementById('output').textContent = e.message;
-      });
-
-      // Send event to Titanium
-      function sendToApp() {
-        Ti.App.fireEvent('app:fromWebView', {
-          message: 'Hello from WebView!'
-        });
-      }
-    </script>
-  </head>
-  <body>
-    <button onclick="sendToApp()">Send to Titanium</button>
-    <div id="output"></div>
-  </body>
-</html>
-```
-
-In Titanium:
-```javascript
-const webview = Ti.UI.createWebView({ url: 'local.html' });
-
-// Listen for events from the WebView
-Ti.App.addEventListener('app:fromWebView', (e) => {
-  alert(e.message);
-});
-
-// Send event to the WebView
-const button = Ti.UI.createButton({
-  title: 'Send to WebView'
-});
-button.addEventListener('click', () => {
-  Ti.App.fireEvent('app:fromTitanium', {
-    message: 'Hello from Titanium!'
-  });
-});
-```
-
-### Remote web content communication
-
-Titanium statements (`Ti.API`, `Ti.App`) do not work in remote HTML content.
-
-Warning: On iOS 12.0+, calling `evalJS()` synchronously from some contexts can deadlock. Prefer the async version with a callback.
-
-#### Using `evalJS()` for remote content
-Inject JavaScript and retrieve results as strings:
-
-```javascript
-const webview = Ti.UI.createWebView({ url: 'https://example.com' });
-
-webview.addEventListener('load', (e) => {
-  // Get the page title
-  const title = webview.evalJS('document.title');
-  Ti.API.info(`Page title: ${title}`);
-
-  // Get cookies
-  const cookies = webview.evalJS('document.cookie');
-  Ti.API.info(`Cookies: ${cookies}`);
-
-  // Execute a custom function
-  webview.evalJS('alert("Hello from Titanium!");');
-});
-```
-
-`evalJS()` rules:
-- Call it from the `load` event (page must be loaded)
-- Pass code as a single string
-- Returns a string (or null)
-- Use `JSON.stringify()` for complex data
-
-#### Passing data to remote content
-
-```javascript
-webview.addEventListener('load', () => {
-  const data = { user: 'John', score: 100 };
-  webview.evalJS(`window.appData = ${JSON.stringify(data)};`);
-});
-```
-
-Then in remote HTML:
-```html
-<script>
-  console.log(window.appData.user); // 'John'
-</script>
-```
-
-## 3. Performance and interaction concerns
-
-### WebView performance
-WebView consumes significant resources:
-- Each WebView has its own rendering context
-- Memory overhead is high
-- Load time is independent of content complexity
-
-Best practice: if you can recreate the content with native Titanium components, do it.
-
-### WebView in TableViews
-Anti-pattern: embedding WebViews in TableViewRows causes slow scrolling.
-
-### WebView in scrollable components
-WebViews do not behave well inside other scrollable containers (ScrollView, TableView). They consume touch events.
-
-Workaround: set `touchEnabled: false` on the WebView if it sits inside a scrollable parent:
-
-```javascript
-const webview = Ti.UI.createWebView({
-  url: 'content.html',
-  touchEnabled: false // Allow parent to handle touches
-});
-```
-
-### Viewport meta tag
-For mobile-optimized content, use the viewport meta tag:
-
-```html
-<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
-```
-
-## 4. WebView use cases
-
-Common WebView use cases:
-- HTML forms: auto-scroll to focused fields, next/previous navigation, native keyboard integration
-- Rich text or HTML email: render styled content that is hard to replicate with native labels
-- Canvas/graphics: HTML5 Canvas provides 2D drawing not available in native Titanium APIs
-- OAuth flows: load third-party auth pages in a WebView and intercept redirects
-
-### Authentication flows
-Many OAuth providers use WebView for login (for example, the Facebook module).
-
-```javascript
-const authWebView = Ti.UI.createWebView({
-  url: 'https://auth.example.com/oauth'
-});
-
-authWebView.addEventListener('load', (e) => {
-  // Detect redirect to callback URL with token
-  if (e.url.indexOf('myapp://callback') === 0) {
-    const token = extractTokenFromUrl(e.url);
-    Ti.App.fireEvent('auth:success', { token: token });
-  }
-});
-```
-
-### Canvas and graphics
-For complex graphics, use HTML5 Canvas:
-
-`local.html`:
-```html
-<canvas id="myCanvas" width="300" height="200"></canvas>
-<script>
-  const ctx = document.getElementById('myCanvas').getContext('2d');
-  ctx.fillStyle = 'green';
-  ctx.fillRect(10, 10, 150, 100);
-</script>
-```
-
-## 5. WKWebView behavioral differences (iOS)
-
-- Cookies: WKWebView uses a separate cookie store from `Ti.Network`. Cookies set via HTTPClient are not shared with WebViews.
-- `localStorage`/`sessionStorage`: not shared between the native app and the WebView. Each WKWebView has its own storage.
-- `evalJS` is async: on iOS 12.0+, synchronous `evalJS()` can deadlock. Use the callback form instead:
-
-```javascript
-webView.evalJS('document.title', (result) => {
-  Ti.API.info(`Title: ${result}`);
-});
-```
-
-- Viewport meta tag required: WKWebView needs an explicit viewport tag to scale content correctly:
-
-```html
-<meta name="viewport" content="width=device-width, initial-scale=1.0">
-```
-
-- Custom fonts: use a special `@font-face` path format in WKWebView CSS. Fonts must be in the app bundle and referenced correctly.
-- Remote HTML limitations: `Ti.API`, `Ti.App.fireEvent()`, and other Titanium calls do not work in remotely-loaded HTML. Only local HTML can communicate with the Titanium runtime.
-
-## Best practices summary
-
-1. Avoid WebViews when possible. Use native components.
-2. Never embed a WebView in a TableView.
-3. Use local content for integration. Only local content supports `Ti.App` events.
-4. Use `evalJS()` for remote content. It is the only way to interact with remote pages.
-5. Wait for the `load` event before calling `evalJS()`.
-6. Configure the viewport for proper mobile rendering.

package/skills/ti-howtos/references/webpack-build-pipeline.md

@@ -1,124 +0,0 @@
-# Webpack build pipeline
-
-> **⚠️ Appcelerator/Axway era feature**
-> The Webpack pipeline documented here was introduced with Titanium SDK 9.1.0 as part of the Axway AMPLIFY toolchain (`appcd` daemon). Since Axway discontinued Appcelerator, this feature is **not maintained** in the current TiDev CLI (`ti`). If you are using the community TiDev CLI, this pipeline may not be available. Prefer the standard `ti build` pipeline unless your project already uses Webpack.
-
-Webpack integration is an alternative build pipeline starting with Titanium SDK 9.1.0. It is optional. When enabled, Webpack manages asset and code bundling.
-
-## 1. Key benefits
-- Fast incremental builds: only changed files are processed.
-- npm support: install packages in the root and import them directly.
-- Build-time resolution: `require` calls are resolved during compilation, not at runtime.
-
-## 2. The `@` alias
-Webpack adds the `@` alias to reference the source root without deep relative paths.
-
-| Project type | Path mapped by `@` |
-| :----------- | :----------------- |
-| Alloy        | `app/lib`          |
-| Classic      | `src`              |
-
-Usage example:
-
-```javascript
-// Before (without webpack)
-import Utils from '../../utils/helper';
-
-// Now (with webpack)
-import Utils from '@/utils/helper';
-```
-
-## 3. npm dependency management
-Install a package in the project root:
-
-```bash
-npm install lodash
-```
-
-Use it in Titanium code:
-
-```javascript
-import _ from 'lodash';
-const data = _.chunk(['a', 'b', 'c', 'd'], 2);
-```
-
-## 4. Platform-specific files
-Webpack detects platform-specific files using the `filename.<platform>.js` pattern.
-
-Example:
-- `utils.js` (common)
-- `utils.ios.js` (iOS only)
-- `utils.android.js` (Android only)
-
-When you `import { func } from '@/utils'`, Webpack picks the correct version for the build target.
-
-## 5. Diagnostic web UI
-Webpack includes a web interface to analyze builds and asset sizes. Default URL: `http://localhost:1732/webpack/latest/web`
-
-## 6. Project plugins
-Webpack support is powered by plugins chosen based on project type:
-
-| Plugin                             | Purpose                 |
-| ---------------------------------- | ----------------------- |
-| `@appcd/webpack-plugin-alloy`      | Alloy project support   |
-| `@appcd/webpack-plugin-classic`    | Classic project support |
-| `@appcd/webpack-plugin-babel`      | Babel transpilation     |
-| `@appcd/webpack-plugin-typescript` | TypeScript support      |
-
-### Custom plugin configuration
-Customize with the `webpack-chain` API in `webpack.config.js`:
-
-```javascript
-module.exports = (api) => {
-  // Add a custom alias
-  api.chainWebpack((config) => {
-    config.resolve.alias.set('@utils', api.resolve('app/lib/utils'));
-  });
-};
-```
-
-Common customizations:
-- Add alias: `config.resolve.alias.set(name, path)`
-- Add loader: `config.module.rule(name).use(name).loader(loader)`
-- Delete plugin: `config.plugins.delete(name)`
-
-## 7. Advanced configuration
-Extend configuration via plugins in `package.json`:
-
-```json
-{
-  "appcdWebpackPlugins": [
-    "my-local-plugin.js"
-  ]
-}
-```
-
-## 8. Global configuration
-Configure Webpack daemon settings in `~/.appcelerator/appcd/config.json`:
-
-```json
-{
-  "webpack": {
-    "inactivityTimeout": 600000
-  }
-}
-```
-
-## 9. Troubleshooting
-
-Build seems stuck: the Webpack daemon may need a restart.
-
-```bash
-appcd exec /webpack/latest/stop
-```
-
-View build logs:
-
-```bash
-appcd logcat "*webpack*"
-```
-
-## 10. Known limitations
-- Hyperloop is not compatible with the Webpack pipeline.
-- Alloy.jmk build hooks are not supported. Use Webpack plugins instead.
-- The first build may be slower due to daemon startup.

package/skills/ti-synthengine/references/android-sim80-correction.json

@@ -1,162 +0,0 @@
-{
-  "schemaVersion": 1,
-  "date": "2026-10-23",
-  "moduleVersion": "1.0.0 beta",
-  "status": "corrected-for-tested-Sim80-headphone-case",
-  "acceptanceComplete": false,
-  "listening": {
-    "accepted": true,
-    "reviewer": "Cesar",
-    "replyTranslation": "Clean, no perceptible distortion.",
-    "scenario": "Real Sim80, live synthesis, headphones, eight-output candidate",
-    "scope": "Subjective acceptance of this short scene, not every voice/effect or a ten-minute maximum-load pass."
-  },
-  "implementation": {
-    "platform": "Android ARM64",
-    "change": "Reuse FIR coefficients across eight consecutive samples per voice while preserving each sample partial-sum and reduction order. Bound tiles at sequence attacks. Keep the previous stereo and other-ABI paths.",
-    "gainQualityOrVoiceLimitsChanged": false,
-    "outputBufferChanged": false,
-    "publicApiChanged": false,
-    "diagnosticInterfacesInProduction": false
-  },
-  "comparisonWithIOS": {
-    "sharedBinauralAlgorithm": true,
-    "ipadMeasuredRate": 44100,
-    "ipadMeasuredBlockFrames": 1024,
-    "androidMeasuredRate": 48000,
-    "androidMeasuredBlockFrames": 256,
-    "ipadTaps": 128,
-    "androidTaps": 140,
-    "limits": "Different measured hardware/output configurations; larger blocks alone do not cure sustained CPU overload."
-  },
-  "profilingBeforeCorrection": {
-    "route": "speaker",
-    "volumeIndex": 80,
-    "callbacks": 1801,
-    "xruns": 73,
-    "cpuBlocksAboveDeadline": 455,
-    "withoutOnsetCpuBlocksAboveDeadline": 357,
-    "onsetCpuShare": 0.004458489684975288,
-    "spatialFirSamples": 1017,
-    "audioThreadSamples": 1566,
-    "scope": "Actual Sim80, flat250HzCPU sampling with inline symbol attribution, not DSP-only isolation."
-  },
-  "fourOutputCandidate": {
-    "speakerXruns": 1,
-    "speakerCpuP95LoadInterval": [
-      1.205,
-      1.21
-    ],
-    "manualHeadphoneXruns": 37,
-    "manualHeadphoneVolumeIndex": 120,
-    "manualHeadphoneCpuP95LoadInterval": [
-      1.62,
-      1.625
-    ],
-    "listening": "Improved but still a couple of perceived distorted moments.",
-    "limits": "Speaker profiling and manual headphone capture are distinct runs/routes, not a controlled route comparison."
-  },
-  "eightOutputCapture": {
-    "device": "Android CPH2639",
-    "route": "wired headphones",
-    "volumeIndex": 120,
-    "volumeMax": 160,
-    "sampleRate": 48000,
-    "callbackFrames": 256,
-    "burstFrames": 256,
-    "bufferFrames": 512,
-    "frames": 480000,
-    "capturedSeconds": 10,
-    "xruns": 0,
-    "routeStayedValid": true,
-    "callbacks": 1875,
-    "maxVoices": 32,
-    "maxTails": 25,
-    "wallP95LoadInterval": [
-      1.02,
-      1.025
-    ],
-    "cpuP95LoadInterval": [
-      0.965,
-      0.97
-    ],
-    "wallMaxNs": 9150154,
-    "cpuMaxNs": 8857462,
-    "wallBlocksAboveDeadline": 104,
-    "cpuBlocksAboveDeadline": 80,
-    "clockErrors": 0,
-    "pcmHash": "7f89b839f15ce44d",
-    "nonFiniteFrames": 0,
-    "peakLeft": 0.8500000238418579,
-    "peakRight": 0.8500000238418579,
-    "scope": "Private instrumented module with PCM capture/clocks and250Hzsampling. Observed output delivery passed this ten-second scene; callback overruns still prevent a strict render-deadline pass."
-  },
-  "verification": {
-    "streamingVsBlocked": "120000 standalone frames/sixrates8\u2013192k, ramps, wrap and complete state bit-identical on Android; varied short blocks also pass C and forcedAndroidNEON on ARM host.",
-    "renderer": "135onset/fullstate,20fractionaltransport/fullstate,9legacy renders, spatial regression and fullheld regression match or pass on ARM host.",
-    "review": "Independent source review found no critical/important issue in four/eight windows, clocks, tails, sends, stereo guard or bounded stack.",
-    "physicalAcceptance": false,
-    "stereoBypassChange": {
-      "scope": "One stereo voice, new fix versus immediately preceding205a renderer, same warmed process, both4slots; previous937screen separate",
-      "pairs": 10,
-      "medianRenderRatio": 1.0113211982131405,
-      "medianP95Ratio": 1.0053333333333334,
-      "ratios": [
-        1.0005653275429052,
-        1.0126349702109787,
-        1.0196281518419976,
-        1.0126315815643214,
-        1.0206466219701242,
-        1.0100108148619595,
-        0.996436735715484,
-        1.016768104985823,
-        1.0091023055656232,
-        0.9846528665539155
-      ],
-      "bitExact": true
-    },
-    "finalProductionClockHeldLegacy": "Byte-identical to the pre-correction renderer after restoring lazy scalar clock reads and forced inlining."
-  },
-  "productionSourceSha256": {
-    "android/jni/SynthOboeEngine.cpp": "cc7f050084871a79cb028b48081a8e51158a3a69f876c59e0f9de1a6ea7ecac6",
-    "shared/synth_spatial.h": "d628ef9c60776be463c5dc45a972c9f9bbb0d183656f0dc177211038ba39d75a",
-    "tests/spatial_regression.c": "2cf768e4dc18035010819b74837921c8b27ae391670acde0bf56197793c655c0"
-  },
-  "measuredPrivateArtifact": {
-    "apkSha256": "324dc75a4b6caddbf6205915287ad90f68f0c735ac9d395ffb6bfb4821cbd934",
-    "aarSha256": "156156df699eabc8647598b5da7fa4f0d20014c3a765b04120a43a0800e40d47",
-    "sourceSha256": {
-      "android/jni/SynthOboeEngine.cpp": "8b0fc7eb99bc1f0b1d76643776fcb7e8eb540f4ba5cd9379313e7f615670e1b0",
-      "shared/synth_spatial.h": "9184a9d81de04c5216c52b96a8860c33bfd3492081089b34df35743d51e90bbb"
-    },
-    "nativeHashes": {
-      "lib/arm64-v8a/liboboe.so": "2696179a9e302f4047ce04146de39f64930bdfaa75d51da63bc7af1a228b8d73",
-      "lib/arm64-v8a/libti.synthengine.so": "3c04735e3f4a60b4d5218fadb192121978c30e105f02115383ba68120635c272",
-      "lib/armeabi-v7a/liboboe.so": "6eebcff8923f11f79d10bd3404afccab9c8d9ba629709334fc76663894b0e914",
-      "lib/armeabi-v7a/libti.synthengine.so": "b07a4b3d2e1d32b71a5267cd47d52024f9f8414d2531867ebcb0281548402919",
-      "lib/x86/liboboe.so": "8846bdc73a1ad884e017c7f3082042184bb8c9876651f48e77faef24f7c7eec4",
-      "lib/x86/libti.synthengine.so": "b13a3adcc8681090d6c305ca7436d60e367ffbcabce0fec0c64861925fcb28cc",
-      "lib/x86_64/liboboe.so": "f1168819d87b8571bb7c8147176854a2e5783bae6e35d2a420d99dc19692db94",
-      "lib/x86_64/libti.synthengine.so": "c008b2eb71b38e271a39fc3c5a1d70698e60bd06da578c723637890291970e98"
-    }
-  },
-  "rawEvidenceArchive": "android-sim80-correction-evidence.zip",
-  "remaining": [
-    "Android ten-minute maximum-load criterion is still open; do not reinterpret this short Sim80 result as that acceptance.",
-    "The measured candidate still has80CPU/104wall callbacks above one deadline.",
-    "Whole-process192k memory, prior one-voice bypass screen, Android Sim20 renderer elapsed work and strict Sim80 presentation matching retain their prior limits."
-  ],
-  "publication": "Beta1.0.0, no release or push.",
-  "rawEvidenceArchiveSha256": "faff448de458ef0cb5299e234177f17a914f7801c27581ab969a9010a68c3c5f",
-  "productionAndroidBuild": {
-    "aarSha256": "7e98bf4fbc6fbe4d1f4a5d9f5a561137522e831fb54480ae0310dd22b60a0c2c",
-    "nativeSoSha256": {
-      "arm64-v8a": "631aaca4f4dabcedc33cf3bf1b23601de3da6291448a299e195cbf5b07f526e3",
-      "armeabi-v7a": "1a4100a25f920784dfc5bda91f30fa6f405e2b85deee51a8b14ce5502a2cf47c",
-      "x86": "8f4545e24cb7f35220445b6e8c04f561bbf5a6cbf55b755c8e8aeffe923e748d",
-      "x86_64": "96a8c5224129de2cd215c9d3b6a2cc50c08865f2de35bf95274026ea452a4a57"
-    },
-    "realFourAbiBuild": true,
-    "diagnosticCodeAbsent": true
-  }
-}

package/skills/ti-synthengine/references/audio-pipeline-validation.md

@@ -1,19 +0,0 @@
-> Source snapshot: official TiSynthEngine documentation at commit `ec04f4e634075c41b55f66279eabcd78b9652d58` (2026-11-02). Published module 1.1.0; public API 1.1.0. Upstream `documentation/audio-pipeline-validation.md` SHA-256: `7359d85de63e9fe94f85477e03a22fc1531c8acaabe30333e7ff2515cc5ec3e9`.
-
-# Audio pipeline correction
-
-Version 1.0.2 removes final-output retention on Android and iOS while retaining one stereo output per platform, fixed event gains, waveform profiles and chord compensation. It adds no public options. Existing envelopes, release tails and parameter transitions keep their roles.
-
-The final protector responds immediately to each stereo sample peak. This removes the old mandatory 10 ms delay, at the cost of a different overload response. Heavy mixes can audibly change waveform shape. Protection recovers with a 100 ms exponential time constant. The 0.85/0.70 ceilings describe sample values, not inter-sample peaks or speaker behavior. The master now follows the same linear 10 ms ramp on both platforms. iOS consumers requesting `raw` now receive its documented gain instead of the conservative gain; review those mixes.
-
-`tests/output_core_regression.c` checks linked impulses, silence/reset, bounded recovery and exact/retargeted master ramps at 16, 44.1, 48, 96 and 192 kHz (absolute double tolerance 1e-12). Android host checks compile the real C++ callback. Apple checks extract the actual callback, helpers and start validation/profile selection, replacing device/Titanium plumbing. The historical Java DSP model is not an oracle for native sound. CI runs production output checks alongside transport, effects, spatial and statistics regressions.
-
-`tools/calibrate_studio.py` (Android by default, `--platform ios` for Apple) reports all 37 Studio presets individually across independent low/mid/high notes, grouped chords, unisons and overlapping releases at 1, 2, 4, 8, 16 and 32 voices. Its recommendation uses the maximum measured pre-protection peak for the declared usual configuration (1-8 voices) to target −6 dBFS, with 0.01 dB measurement margin and the public volume limit. It reports 16/32-voice stress separately. The recommendations apply to the measured configuration. Event gains remain fixed, and other workloads can exceed the target. Effects and new LFOs are disabled in preset calibration. It never edits Studio.
-
-The before/after host comparison covered 80 PCM pairs across both renderers at five sample rates. After aligning the former output delay, all 40 cases without overload preserved the waveform within an absolute float tolerance of 1e-7. Overload cases remained finite and within the sample ceiling; their waveform differences were measured. Matched host benchmarks found no median callback-time increase. These measurements do not establish whole-app CPU use or physical output latency.
-
-Physical comparisons used Studio and Frontier on an OPPO CPH2639 running Android 16 and an iPad. Studio checks covered its 37 presets, short notes, Hold, chords, repetitions, sequences, effects and spatial controls. Frontier checks covered gameplay with simultaneous sounds. The same native candidate binaries were then integrated into the real Studio and Frontier apps, which built and launched on both devices. Their presets and gains were preserved. Route-wide latency, Bluetooth behavior and extended maximum-load acceptance remain outside these results.
-
-Android can report an underrun during stream startup. An initial matched repeat recorded it in four of six starts for both the original and candidate, with no additional underruns during the subsequent note/chord checks. Further silent tests reproduced the symptom with an independent Oboe 1.11.0 callback that only writes zeros. The startup condition remains unresolved; the counter is retained. Silent tests do not establish whether it causes an audible defect. Oboe's open [LatencyTuner proposal](https://github.com/google/oboe/pull/2432) discusses how startup XRuns affect buffer tuning, but does not eliminate their cause. TiSynthEngine does not use that tuner.
-
-PCM, original and candidate packages, commands, hashes and device traces are retained outside the app repositories. The physical results apply to the tested devices and scenarios.