It turns out that I’m currently following a course on Javascript in Max. My previous coding experience is close to 0, and it’s mainly about Live API and control surfaces, but still…
I’d be happy to help. Won’t be available much this big week-end (going to Paris to see The Smile in concert) but after that, I’ll be (more) free.
Wow that’s very kind !
I’ll receive my Rytm only tomorrow at best, so it’s no rush. Are you french ?
Yes. We traded a Digitone and a Heat if you remember (Quentin, worked at IRCAM)
Of course I remember !
Thanks a lot for the offer, and let’s move to PMs if you don’t mind.
kudos … somewhat more impressive than merely stopping outside to get a cheeky selfie (as i just had to )
thanks
Current Kit Request: F0 00 20 3C 07 00 68 01 01 00 00 00 00 05 F7
0x68 is the ID (found in sysex.h under ar_sysex_request_id_t)
0x00 is the NR (kit #) since we are asking for the currently loaded kit.
That’s for the Current Kit Work Buffer loaded in the RYTM, not Saved Kits.
Sysex is encoded to save space…think of it as being encrypted…without decoding the received sysex, you won’t be able to make sense of the numbers or do anything useful.
You need to request -> decode -> edit values -> encode -> send
The library handles encoding / decoding. You could try to port those functions over to javascript.
Thanks a lot !
Because for a non (classic) developer, although an advance Max one, learning a dynamically typed language (with all the memory management taken care of) is way easier.
The library is nice. I was just taking a look at it.
Although trying out a few functions successfully ( such as getting pattern A1) returned a huge dump
I couldn’t find any info about making sense of the dump other than the header, in the library.
Do you think I should try to reverse it or is there any info I’ve missed somewhere?
After you send a request for sysex to the machine, it will return a large array of numbers (the raw sysex)…the library has functions for converting that array of encoded #'s into an array of decoded #'s…the decoded #'s are what you want and represent actual parameter values.
So, if you request a Kit and decoded it…the kit.h header has structs which show what the decoded #'s represent.
It is ridiculously funny that I have missed those!
And I’ve spent 2-3 hours of reversing some of it
I still can’t believe it
Thanks!
I might port this to Rust.
If I find enough motivation, I might make a crate out of it.
I will DM you tomorrow the changes I made to the library (not functions, just headers / structs to support new Rytm OS’s), as the current ones are old
This would be great, thank you!
I’ll just attach here…over the years the structs for Tracks / Sequences haven gotten larger to accommodate new features…can’t vouch for the best comments or completeness, but it’s what I use for Collider.
libAR.zip (33.5 KB)
Thank you for sharing this. It seems that some unknowns are became knowns here also.
I’d like to port it to Rust because I have a Rust app which I’ve written which runs on a single board computer which acts as a hub for my controllers and other devices to enhance functionality.
I’d use this library to mostly generate controlled semi random patterns.
On the other hand it seems that it is not very useful to the community. I assume that very little people would use it as I use it here and in rust.
So I don’t promise but maybe later I compile a max object with it since I assume that is most useful to the people around here.