Skip to content

Releases: Tratosca/rx3-toolkit

XDJ-RX3 Toolkit v0.5.2

Choose a tag to compare

@github-actions github-actions released this 14 Aug 18:28
73bf2ce

0.5.2

A runtime built on Windows loads its modules again.

Fixed

  • An autoexec.bin built on Windows stopped with STOP: one or more runtime modules violate their contract, one FAILED: unsafe runtime module directory per selected module. The index naming the modules to load was
    written with the building machine's line endings, and the shell that reads it
    took the trailing carriage return as part of the directory name. Affects
    0.5.0 and 0.5.1 built on Windows; 0.4.0 predates the index.

XDJ-RX3 Toolkit v0.5.1

Choose a tag to compare

@github-actions github-actions released this 14 Aug 02:37

Reinserting the drive works. It used to be refused, and before that it was what
the deck made you do, because applying a module emptied the media list. The
runtime also stops writing to the drive unless you ask it to.

Fixed

  • Reinserting a drive without a power cycle no longer stops with
    STOP: unsupported rbp SHA-1. The check hashes the whole player binary, so a
    session this runtime had already patched no longer matched the state it
    started from. The guarded words are put back to their stock values before the
    comparison, which answers the question the check means to ask — is this the
    binary I know? — without being fooled by our own writes. A guarded word
    holding neither value still survives normalisation, and the word-by-word
    audit that follows still rejects it before anything is written.
  • Reinserting a drive no longer restarts the player. A drive pulled out as
    sda comes back as sdb, so it mounts somewhere else; the sidecar directory
    is read once at load time, so a moved path meant stopping and relaunching —
    which froze the screen and emptied the media list, which is what made the
    drive get pulled again. The player is handed one fixed path, re-pointed on
    each insertion, and a reinsertion now changes nothing.
  • A player that exits straight after being relaunched is rolled back to the
    stock binary instead of to the previous bytes. On a reinsertion those
    previous bytes are the patched ones, so the rollback relaunched exactly what
    had just died. The runtime's shared objects come out of LD_PRELOAD with it.
  • The log of the run that applied the patch survives the next insertion, in
    session-previous.txt. The player's cumulative output carries a marker per
    launch, so one run's crash no longer reads as the next run's.

Added

  • Session logging is a module of its own, and it is not selected by
    default: an ordinary build now writes nothing to the drive at all. Tick it to
    get RX3_RUNTIME/session.txt and the player's output — and eject the drive
    rather than pulling it out while that build is in use, because the player
    keeps the log open for as long as it plays. That open handle is also what
    stopped the kernel releasing the device, which is why a drive came back under
    another name.
  • The log names what forced a restart, and each module says what it saw that
    made it ask.

Changed

  • A relaunched player is given up to the same eight seconds, but the wait ends
    as soon as every module has written its readiness file — a second, in
    practice. The media that is already mounted is announced to it as soon as the
    process is alive, rather than after the readiness verdict.
  • Everything the RX3 executes moved from runtime/ to mod/. The word said
    when the code runs, which the directory above it does too — apps/ and
    tools/ are runtimes of their own, and two of them are literally named
    rx3_runtime. mod/ says what the directory holds and matches the word the
    documentation already uses when it speaks to a DJ. The runtime_directory key
    in a module manifest, the RX3_RUNTIME/ folder written to the drive, and the
    separation runtime are unrelated names and keep theirs.

Known issues

  • A drive still takes several seconds to reappear after a module is applied.
    The runtime announces it about a second after the player is relaunched, so
    what remains is on the device side: the player is seen to crash twice before
    a third launch sticks, and the log reports
    rejected: unexpected PcmReader::load prologue on those attempts. The
    binary patch that widens the image table stays applied even when the hook
    gives up installing it, which leaves the player accepting identifiers it has
    no records for. Under investigation.

XDJ-RX3 Toolkit v0.5.0

Choose a tag to compare

@github-actions github-actions released this 13 Aug 21:34

Things get better.

  • Stems algorithms presets (very fast / normal / high quality) are supposedly arranged nicely for all platforms
  • Modules are now independently loaded and organized
  • So many other things changed under the hood

As #4 suggested:

  • One single app, to generate stems and create the modding USB
  • App texts should be easier to read
  • Estimated duration for separation is now a thing (while being unperfect ATM)

But (all of that is "will fix in the future"):

  • It takes time to load USB key after applying the patch: please wait & don't replug (or it will try to patch again).
  • Don't trust the stem generation progress bar or estimated time yet
  • On the RX3 screen, going from Stems / Key to Beats FX / Status is still a bit buggy
  • Key shifting is using Pioneer's DSP which is poor quality, tried vibe coding a better algorithm that is still not perfect but already better

XDJ-RX3 Toolkit v0.4.0

Choose a tag to compare

@github-actions github-actions released this 12 Aug 15:25

What's Changed

  • fix(stems): match the drive filename and the deck's decode grid by @Tratosca in #1
  • chore(release): 0.4.0 by @Tratosca in #2
  • fix(ci): run the mod generator tests under their current name by @Tratosca in #3

New Contributors

Full Changelog: v0.3.0...v0.4.0