New Tool: Recycle (Rex Files) 4 Renoise

Latest release:

— >8 —

After using Reason for a couple of years, I’ve amassed copious amounts of REX2 loops. I actually kinda like the format, as you don’t need to cut it up by hand and it comes with precise timing data (not as precise as Renoise, though ). Anyway, right now, when I want to use those loops, I load Kontakt in Renoise, open the loop in Kontakt, map the slices to individual notes, and export them using Renoise’s awesome “Render plugin to instrument” feature. It works, but it’s not perfect, not to mention the timing information is lost that way.

So I had the idea to use free CLI converter to convert the loops into individual samples, exports the timing to a table, and write a Renoise extension that loads and maps all those samples to create a nice instrument, ideally also populating a pattern with the slices in default order, including the delay values to make it fit perfectly. Problem is: I couldn’t find such a tool. The REX SDK is free, but it seems nobody cared enough to write such a thing. Even though it’s such a widely popular format, and writing the actual converter seems really easy, too. The SDK is just a header and some glue to link an application to the REX Shared Library, which will handle decryption and decompression and simply returns the metadata and the individual slices to buffers. Just a couple of API calls. The drawback is that the SDK is in C. I have some experience with PHP, Javascript and shell scripting, so LUA seems right up my alley, but C… Man, that’s not my kind of language. It took me hours to get the SDK to compile, and I can’t even get a simple command line app to return loop metadata. Way over my head.

So basically, if someone could help me out with said CLI app (or maybe even a wrapper that exposes the REX API to LUA), I’ll try to handle the LUA side of things. If anyone who knows C is actually interested in that kind of functionality, that is…

— 8< —

C’s way over my head too , but I love to see this implemented .

+1

Small update: Had some time to spare, so I invested a couple more hours in the C application. The REX SDK I use seems to be horribly outdated, though - the actual loader won’t work on current Macs. And I’m not eligible to apply as a registered developer (Propellerhead only accepts companies in the audio industry), so I can’t get a more recent SDK. Sucks, as I only have a Mac. I guess updating the loader would be trivial for someone who actually knows what he’s doing. I’ll try to find some example code, maybe I can figure something out.

Yes,

It is a bit sad that this has not gotten that much interest from the ones making the changes in the software.

Not blaming, great job overall with renoise…

…but still, we are dealing with a copy of FT2… That cannot handle the most widely used beat format in any way.

And this is also one of the reasons why most tracked breakbeats do not sound good, they do not have a great groove and they sound demo-like…

I doubt you would get the latest SDK off Props for this but worth a try

Personally i would consider just using Reaper to convert the REX files to MIDI and Wav slices
Then create a LUA extension that loads a MIDI file and slices as instrument and pattern in Renoise

There is a video on you tube showing how to get the data out of Reaper ready for Renoise import and to be honest you could probably code an extension in Reaper to do it in one click

B

.

Requiring Reaper isn’t much better than requiring Kontakt.

Anyway, I’ve dropped the official SDK and try to communicate directly with the REX library now through dlopen and dyld. It kinda works, but I still suck at C, so it’s very much trial and error and starts getting a little frustrating. Right now, the library always complains about me passing an invalid handle - sadly, I’ve no idea which handle it expects me to pass. It seems that neither the handle of my application nor the handle of the REX library work.

seems the only way you can get this to work is to hack it together like you are doing now. unless you can find somebody who knows C and is willing to assist you, you will probably be on your own. however, you will learn a lot, and i predict your efforts would be highly appreciated here. i also have a ton of Rex-files hanging around, and all i do with them is exporting the good ones out of Reason as audio files, so nowhere near the usefulness of the Rex-format. at least i have the beats though.

Edit: what i meant to say was: keep up the good work!

Do you have some stub-file or header-file that comes with the library? It usually contains enough info what kind of types and handles should be passed.

How that works in practice to use on a Mac though, i have no idea. (Have no idea how libraries are called on a Mac environment)

That’s the thing: I have the header, but it’s not documented. I would have expected comments detailing the usage of all those calls, but all I have is a couple of typedefs with more or less cryptic variable names and some error codes (those have proven really useful, though).

As far as I understand, to use the library, you first have to use _Open. _Open takes no arguments and returns an error code - in my case “1”, so that worked. The next step is _Create, which takes a whole bunch of arguments (handle (unsigned long), buffer (const char), length (long), a callback function, and userData (void)). I haven’t really figured that one out, yet - it returns error code “204”, or “Invalid Argument”.

Anyway, once this works, the rest looks like a piece of cake. Most of the functions don’t seem relevant to my purposes. The next step would be to call _GetInfo, which returns stuff like the length, number of slices, tempo etc., and _GetCreatorInfo, which returns the author, copyright notice and stuff like that. Once you know the number of slices, you can use _GetSlice to load the individual, decrypted and decompressed slices to a buffer. _Delete and _Close are then used to clean up.

EDIT: OK, someone correct me if I’m wrong, but as far as I understand, _Create doesn’t expect an actual handle, but a variable it can assign the handle to. I tried this:

 rexCreate = dlsym(handle, "REXCreate");  
 err = (*rexCreate)(&rexHandle, buffer, fileLen, NULL, NULL);  
 printf("_Create: %i (rexHandle: %i)\n", err, rexHandle);  

which returns “_Create: 1 (rexHandle: -1071382479)”. That looks promising I think. Now, if I call something else, it doesn’t complain about a wrong handle anymore. Now I need to figure out how to populate a struct this way, as this won’t compile (“info” is a struct):

 rexGetInfo = dlsym(handle, "REXGetInfo");  
 err = (*rexGetInfo)(rexHandle, 64, &info);  

EDIT2: Progress: _Create seems to work as expected now. It opens any file I throw at it from the command line, and the library (rightfully) complains if the file in question isn’t a REX loop. That’s something I guess. Now I need to figure out that _GetInfo struct thing…

yes REX fiel has tons of librarys available online
and it has so cook slice feature where renoise fail.

http://www.propellerheads.se/developer/index.cfm?fuseaction=get_article&article=rextechinfo2

Native surrpot for Rex file was BIGBABOOOM…

1 Reaper is a bunch cheaper than Kontakt

2 If you looked at the video you will see that once you have completed the transfer from Reaper to Renoise (All two minutes work) it is now fully native inside Renoises sampler and pattern and saveable as a instrument

3 You may well be treading on dodgy legal grounds here not having permission off props to do this (Hopefully not because i really want REX2 support, thats why i did the video to show how you get em into Renoise)

4 Might be worth asking Taktik to upgrade the props licence to contain REX2 and open it to the LUA extensions (I would guess there is a reason this hasn’t been done already but worth a shot as its free)

Either way good luck and i hope you succeed

B

Of course. But where’s the fun in that? And I’m trying to create something that’s free and has no external dependencies. Well, it has a dependency, and I may not bundle the library with my app, but it’s easy (and legal) to get it for free.

Thought about this, and I don’t really see any issues. My app contains no copyrighted code and I don’t think you need permission to interface with a shared library. As far as I’m aware, several big open source projects like Wine or MPlayer do this as well.

Thanks. Me too…

I’m finally getting somewhere…

The attached file is just a very early prototype of the CLI application. It only runs on Intel Macs, and it doesn’t actually convert the loops just yet. All it does right now is to load a REX file and return some of the metadata. Would be nice if a few people could try it out, as it’s mostly based on guesswork and assumptions (about the location of the actual library for example). Remember that you have to have the REX Shared Library installed. It should ship with all applications supporting the format, even with demos.

This should not blow up your Mac or anything, but still: Try it at your own risk!

EDIT: Maybe I should detail the actual usage as well. Extract the file somewhere you can find it, copy a REX file to the same directory, open a terminal, and enter “./r4r your_rex_file.rx2”. Without the quotes, obviously. It should output lots and lots of more or less cryptic stuff - or an error message, if the file isn’t a REX file or the library couldn’t be found.

Glad to hear you are working on this app,

I will definetely (have got to) try this on my fathers mac…

Will take few days to report on this, but I’ll try to make it tomorrow.

Hey, you’re the first one!

Seriously, I hope some more people will try this. I want to release something that actually works for everyone.

Oh man
Sorry i can’t help testing this (Windows only here) as soon as there is something i can help with i will be all over it though

B

Heads up: The command line application is pretty much done. It actually exports the individual slices now.

EDIT: Mono loops only. Weird. Not quite ready for release after all…

im sorry too WIN only here…
but if avaialbel for windows i can help you with the test.

cant wait to see the win’port

keep up the good work

Mono and stereo loops work now! That was frustrating. It was actually a very simple mistake, but it was not obvious and hidden somewhere else in the code (an if statement that was always wrong, which prevented the creation of a stereo buffer). Anyway, that’s about it on the C side of things. I’ll probably have to bundle SOX with the extension as well, unless I find a way to directly import headerless RAW PCM data in Renoise. I guess it’s time for me to RTFM.

About the Windows version: I’m not sure I can handle the port. The problem is that the only Windows PC I have access to once in a while is my fathers gaming rig, and after dealing exclusively with UNIX systems for roughly a decade, it would take me a while to find my way around again. I’ll try - no promises though. If someone wants to help with the port, I’ll hand over the code (even if it’s slightly embarrassing, as it’s a complete mess). Should be as simple as replacing all the dlopen and dyld calls with their equivalent Windows functions I guess. Might also be worth noting that my code was 100% written from scratch - it doesn’t include a single line of code by Propellerhead.