@m4l-jweb/wrapper 0.9.1 → 0.9.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@m4l-jweb/wrapper",
-  "version": "0.9.1",
+  "version": "0.9.9",
   "description": "m4l-jweb: the Max for Live glue layer connecting a device to LiveAPI.",
   "type": "module",
   "license": "MIT",

package/src/core.ts

@@ -754,56 +754,107 @@ function placeFetch(fetched: ActiveFetch): void {
 }
 
 /* ------------------------------------------------------------------ *
- * Samples - the `samples` chain
+ * Save-to-disk
+ *
+ * The inverse of fetch-to-disk: the APP has the bytes (a rendered WAV), and hands
+ * them over base64 in slices (`saveToFile()` in the bridge). We writebytes them into
+ * a `<dest>.part` file exactly as extractPayload does - same 16 KB truncation cap, same
+ * byte-count verification - then reuse the fetch machinery's PHASE 3 to atomically place
+ * `.part` over the destination through [maxurl]. The destination is never touched until
+ * the .part has been written AND verified. Requires the `download` chain (for [maxurl]).
  * ------------------------------------------------------------------ */
 
-/**
- * The app: `buffer_load <slot> <path>` - read a file into that slot's [buffer~].
- *
- * WHY THIS GOES THROUGH [js] AT ALL, when the chain could route it straight to the
- * buffer: because the path the app wrote is not a path [buffer~] can open, and it
- * fails in the two ways this file exists to prevent.
- *
- * A RELATIVE path is resolved against the device's folder - the same resolution
- * `fetch_to_file` does, and it has to be the same one or the app downloads a file to
- * one place and loads it from another. [buffer~] does not resolve it that way: a bare
- * name is looked up in MAX's SEARCH PATH, which does not contain the device's folder,
- * so `preview.wav` - freshly downloaded, right there next to the .amxd - reports
- * "can't open" and the promise times out.
- *
- * ...and the resolved path CONTAINS SPACES on a normal Live install ("Ableton
- * Library", "Max For Live"). A message travelling through the patcher as text would
- * split there into three atoms and [buffer~] would open the first one. Handed out of
- * [js] as a string, it stays ONE symbol all the way to `replace`.
- *
- * The file is checked before the buffer is asked for it, because a missing file makes
- * [buffer~] print to the Max console and stay silent - there is no failure bang to
- * bind to, and the app would learn nothing until the timeout. `buffer_error` says so
- * at once.
- */
-function buffer_load(slot: string, path: string): void {
-  var resolved = resolveFetchPath(path); // the same folder the download wrote to
+var SAVE_PLACE_RESPONSE_DICT = "m4ljweb_save_place_response";
+
+interface ActiveSave {
+  requestId: string;
+  /** Absolute, resolved destination. */
+  destPath: string;
+  /** Bytes the app promised in save_begin - the size the .part must match. */
+  expect: number;
+  /** Bytes actually written so far, for the verify. */
+  written: number;
+  /** The open .part file, held across the chunk messages. */
+  file: File | null;
+}
+
+var activeSave: ActiveSave | null = null;
+
+/** The app: `save_begin <requestId> <destPath> <byteCount>` - open the .part file. */
+function save_begin(requestId: string, destPath: string, byteCount: number): void {
+  // A save already in flight is abandoned - its .part is left for the next place/overwrite.
+  if (activeSave && activeSave.file && activeSave.file.isopen) activeSave.file.close();
+
+  var resolved = resolveFetchPath(destPath);
+  var target = partPath(resolved);
   var f: File | null = null;
   try {
-    f = new File(resolved, "read");
+    f = new File(target, "write");
+    if (!f.isopen) f.open();
   } catch (e) {
     f = null;
   }
   if (!f || !f.isopen) {
-    outlet(0, "buffer_error", slot, "no file at " + resolved);
+    outlet(0, "save_error", requestId, "cannot open " + target);
+    activeSave = null;
     return;
   }
-  var bytes = f.eof;
-  f.close();
-  if (!bytes) {
-    outlet(0, "buffer_error", slot, "empty file at " + resolved);
+  f.eof = 0;
+  activeSave = { requestId: requestId, destPath: resolved, expect: Number(byteCount), written: 0, file: f };
+}
+
+/** The app: `save_chunk <requestId> <base64>` - write one slice. */
+function save_chunk(requestId: string, b64: string): void {
+  if (!activeSave || activeSave.requestId !== requestId || !activeSave.file) return;
+  var bytes = b64decode(b64);
+  var SLICE = 4096; // File.writebytes truncates large calls (~16 KB cap) - same as extractPayload
+  for (var off = 0; off < bytes.length; off += SLICE) {
+    activeSave.file.writebytes(bytes.slice(off, off + SLICE));
+  }
+  activeSave.written += bytes.length;
+}
+
+/** The app: `save_end <requestId>` - close, verify size, place atomically. */
+function save_end(requestId: string): void {
+  if (!activeSave || activeSave.requestId !== requestId) return;
+  var save = activeSave;
+  if (save.file && save.file.isopen) save.file.close();
+
+  var onDisk = fileSize(partPath(save.destPath));
+  if (onDisk !== save.expect) {
+    outlet(0, "save_error", requestId, "size mismatch: wrote " + onDisk + " bytes, expected " + save.expect);
+    activeSave = null;
     return;
   }
+  // PHASE 3: place the verified .part over the destination via [maxurl]. NOTE the
+  // destPath must be a FLAT filename in the device folder - maxurl (libcurl) and Max's
+  // [js] File resolve a subdirectory differently, so `sub/x.wav` writes the .part where
+  // File agrees but maxurl cannot reach it, and the place returns -1. Keep saves flat.
+  var placeUrl = encodeURI("file:///" + partPath(save.destPath));
+  post("m4l-jweb: save place " + placeUrl + " -> " + save.destPath + "\n");
+  var reqDict = new Dict();
+  reqDict.set("url", placeUrl);
+  reqDict.set("http_method", "get");
+  reqDict.set("filename_out", save.destPath);
+  reqDict.set("overwrite_output_file", 1);
+  reqDict.set("response_dict", SAVE_PLACE_RESPONSE_DICT);
+  outlet(1, "maxurl", "dictionary", reqDict.name);
+}
 
-  // Outlet 1 is the aux outlet; the `samples` chain routes `buffer_replace` off it,
-  // exactly as the `download` chain routes `maxurl`. Outlet 0 belongs to [jweb].
-  post("m4l-jweb: buffer_load " + slot + " -> " + resolved + "\n");
-  outlet(1, "buffer_replace", slot, resolved);
+/** maxurl finished the save's place copy. Validate on bytes, like finishPlace. */
+function finishSavePlace(): void {
+  if (!activeSave) return;
+  var save = activeSave;
+  var placed = fileSize(save.destPath);
+  if (placed !== save.expect) {
+    outlet(0, "save_error", save.requestId, "could not place save: " + placed + " bytes at destination, expected " + save.expect);
+    activeSave = null;
+    return;
+  }
+  truncate(partPath(save.destPath)); // [js] cannot delete; zero it
+  post("m4l-jweb: saved " + placed + " bytes to " + save.destPath + "\n");
+  outlet(0, "save_done", save.requestId, placed);
+  activeSave = null;
 }
 
 /** The app: `fetch_to_file <requestId> <url> <destPath>`. */
@@ -824,6 +875,8 @@ function maxurl_done(msgType: string, dictName: string): void {
   // hook, a request the device made lands here, finds no `currentFetch`, and is
   // dropped in silence - which looks exactly like maxurl never answering.
   if (typeof onMaxurlReply === "function" && onMaxurlReply(dictName)) return;
+  // A save's place copy comes back on its own dict, and has no `currentFetch` behind it.
+  if (dictName === SAVE_PLACE_RESPONSE_DICT) return finishSavePlace();
   if (!currentFetch) return;
   var fetched = currentFetch;