Transfer Kits f/t AR with Transfer or OB

Elektron Gear Analog Rytm
1

Hello. I searched the forum.

I made some kits with AR that I wanted to save seperately on my computer.

I was surprised that

  • Transfer sees only samples and projects
  • OB sees kits but cannot save them on the computer, just on the AR itself

I found out that

  • Kit management is part of the original design of AR
  • Sysex send and receive works (even in 1.70)
    • I used C6 on my music Mac (Mojave, last working OB Version: 2.8.4) and it works, although many additional steps involved (C6: receive, AR: send, C6 stop, C6 save)

I am considering transition to newer hardware, however

  • Which possibilities would I have to manage kits, patterns etc. on a newer Mac?
    • Will Transfer or newer OB have management for these categories?
    • Or do I have to find another SysEx-Tool that works with newer systems?

Thanks a lot for any helping input. :slight_smile:

2

what I would do instead of messing with C6 stuff is just make a dedicated project for kits and copy kits there and back up the project, moving kits between projects is pretty straight forward and you can store 128 kits per project.

3

Great workaround! :smiley: Thx for the idea.

So it’s true, neither OB nor Transfer can manage kits and patterns? :flushed:

4

nope because it belongs to a project…
there is the Max package you probably can build around a manager with but still, I would use Transfer and dedicated project…

1 Like
5

The OG designers might have other opinions (all the sysex send and receive options :wink:

It’s not only about backup but also about sharing.

Edit: Thanks for the kink! :star_struck::+1: will look into that.

6

yeah but moving a kit into existing project can be destructive, i.e. overriding existing kit slot, if you wrap it in a project you make sure the kit and existing projects are safe

1 Like
7

Oh - they don’t use the next empty slot? :flushed::grimacing:

Anyway, ability to manage from within OB would have been nice. And would fit the concept of OB.

Well, they have so many other things going on. Guess it is what it is.

8

I guess it depends on the tool and the implementation but still, wrapping kit in a project is kind of fail-safe mechanism

1 Like
9

my approach - overbridge is just dealing with whats loaded on the device, and streaming the audio… its not a full blown librarian for managing projects / kits / patterns / songs / samples / sounds etc.

something like that would be nice, but its not OB.

Kits on AR always confuses me , i typically lose work and remember how to deal with it … though i rarely use my AR.

10

I’m the author of the max object and rytm-rs.
These are the objects you can send separately through the sysex api:

  • Pattern
  • Kit
  • Sound
  • Settings
  • Global
  • Song

It is possible to save kits and send them back to AR.

Actually I was planning to include that functionality for rytm-rs but this was a project I was building when I was switching between jobs, unfortunately I couldn’t develop it further due to not having time, although I’ll complete it sometime. At least I’ll try :slight_smile:

In theory you can redirect the output of [sysexin] from max to a file, fetch the kit you want and then read that file to [sysexout] to another rytm device or the same one.

After you’re done with the transfer you can save your project in rytm and you’re good.

I hope it helps.

But since a Kit also has reference to Sounds you might not need to have the same Sounds in the other machine I suppose kit should also transfer them in the package so you have the identical Kit there. (assumption)

This is how a kit looks like in rust code (you don’t need to understand the code but you can at least read the names of the fields as much as we reverse engineered it)

/// Represents a kit in the analog rytm.
///
/// It does not map identically to the structure in the firmware.
#[derive(Derivative, Clone, Serialize, Deserialize)]
#[derivative(Debug)]
pub struct Kit {
    #[derivative(Debug = "ignore")]
    sysex_meta: SysexMeta,
    /// Version of the kit structure.
    version: u32,
    pub(crate) index: usize,

    /// Name of the kit.
    name: ObjectName,

    // 13th is the fx track.
    #[derivative(Debug = "ignore")]
    track_levels: [u8; 13],
    #[derivative(Debug = "ignore")]
    track_retrig_settings: [retrig::TrackRetrigMenu; 13],
    #[derivative(Debug = "ignore")]
    sounds: [Sound; 12],

    fx_delay: FxDelay,
    fx_distortion: FxDistortion,
    fx_reverb: FxReverb,
    fx_compressor: FxCompressor,
    fx_lfo: FxLfo,

    control_in_1_mod_target_1: ControlInModTarget,
    control_in_1_mod_target_2: ControlInModTarget,
    control_in_1_mod_target_3: ControlInModTarget,
    control_in_1_mod_target_4: ControlInModTarget,

    control_in_2_mod_target_1: ControlInModTarget,
    control_in_2_mod_target_2: ControlInModTarget,
    control_in_2_mod_target_3: ControlInModTarget,
    control_in_2_mod_target_4: ControlInModTarget,

    control_in_1_mod_amt_1: i8,
    control_in_1_mod_amt_2: i8,
    control_in_1_mod_amt_3: i8,
    control_in_1_mod_amt_4: i8,

    control_in_2_mod_amt_1: i8,
    control_in_2_mod_amt_2: i8,
    control_in_2_mod_amt_3: i8,
    control_in_2_mod_amt_4: i8,

    // Currently these are out of my interest.
    // Maybe in the feature we can add support for these.
    //
    // ---- TODO: ----
    #[derivative(Debug = "ignore")]
    #[serde(with = "BigArray")]
    pub(crate) perf_ctl: [u8; 48 * 4], /* @0x0842..0x0901 */
    #[derivative(Debug = "ignore")]
    #[serde(with = "BigArray")]
    pub(crate) scene_ctl: [u8; 48 * 4], /* @0x0917..0x09D6 */
    // 0..=11 device 0..=11
    #[derivative(Debug = "ignore")]
    pub(crate) current_scene_id: u8, /* @0x09D8 (0..11) */
    // ----------------
    //
    #[derivative(Debug = "ignore")]
    pub(crate) __unknown: KitUnknown,
}

See this part:

 sounds: [Sound; 12],
2 Likes
11

I’ll also let you know when this is released.

1 Like
12

You can give this one a try:

1 Like