cLib: Renoise Core Library

There is this thing called “cLib” on the Renoise github page. Has been there for a few months.

It’s a collection of classes that can be used in your own scripts and tools.

com.renoise.cLib.xrnx is the packaged version. It doesn’t do anything except to run a few unit-tests.

Link to github:

https://github.com/renoise/xrnx/tree/master/Tools/com.renoise.cLib.xrnx/cLib/classes

1 Like

I was thinking this might be the place to add some handy access to the Renoise preference colors? (read-only?) For example:

cPreferencesColors.main_main_back --> { r, g, b }

cPreferencesColors.vu_meter_meter_low

If it’s of interest, I could make a class finding and returning the values. I’m not completely sure how to deal with xml in the prettiest way, meaning “someone” should probably clean it up a bit afterwards in that case. Let me know.

PS. Any chance of some vector system going for generating bmp’s? :wink: I’ve also looked around for some LUA anti-aliasing routine without success, but perhaps there are generic ones available. Perhaps it’s not within the scope of cLib, though?

I was thinking this might be the place to add some handy access to the Renoise preference colors? (read-only?) For example:

cPreferencesColors.main_main_back → { r, g, b }

cPreferencesColors.vu_meter_meter_low

If it’s of interest, I could make a class finding and returning the values. I’m not completely sure how to deal with xml in the prettiest way, meaning “someone” should probably clean it up a bit afterwards in that case. Let me know.

PS. Any chance of some vector system going for generating bmp’s? :wink: I’ve also looked around for some LUA anti-aliasing routine without success, but perhaps there are generic ones available. Perhaps it’s not within the scope of cLib, though?

Aha, a dedicated class for parsing user theme colors?

Yes, I remember we briefly talkedabout this, and I pointed out that the configuration parser (cConfig) was largely untested across various OS.

What would be perfect here was to add that to the unit-tests and then ask a few people to run it and gather the results.

Then, it would be pretty easy actually to create that class. But it needs a solid foundation to begin with :slight_smile:

As for the cLib XML parser, well…it’s pretty dumb (= streaming parser). But as long as you know where to look for things it gets the job done.

Again, it makes sense to create a test case and stick it out for a few people to try.

Speaking of antialiased vector drawing, I’m not aware of any general-purpose lua implementations, no.

Rosettacode is usually a good resource for finding stuff like this, but the closest I could find was this:

https://rosettacode.org/wiki/Xiaolin_Wu%27s_line_algorithm

No love for lua. But it’s not a hard algorithm to convert :slight_smile:

I’m just about to try to develop my first real tools, but am a little confused: there’s clib and vlib, both seem partially to do the same like file operations or xml digestion, but seemingly in different ways? Why this redundancy? Did I get it right and clib is the slim toolkit, while vlib gets more into the big world with gui action and stuff like this?

Am I right best to spread some love for others would be to package the tool with a suitable clib/vlib version completely stuffed inside?

@Danosie,

  1. We don’t actually have a way in the API to check if the OSC server is enabled, and at which port it is listening. So right now, as a tool author, you basically need to display a one-time message to the user that (s)he needs to enable the OSC server in Renoise.

I was thinking about this yesterday… isn’t the osc server available in the preferences.xml? (tickbox and server/port/protocol) :wink: That would be reachable if that’s the case and should be highly usable for warning the user. (even though it wouldn’t be verifying it is actually online and available… can’t ping it)

I’m just about to try to develop my first real tools, but am a little confused: there’s clib and vlib, both seem partially to do the same like file operations or xml digestion, but seemingly in different ways? Why this redundancy? Did I get it right and clib is the slim toolkit, while vlib gets more into the big world with gui action and stuff like this?

Am I right best to spread some love for others would be to package the tool with a suitable clib/vlib version completely stuffed inside?

The whole thing actually started as xLib, my attempt at streamlining some of my own tools.

Since, xLib grew into quite a big thing and I had to split it into the “core” cLib, the “visual” vLib and finally, the renoise-specific xLib

Redundancy is bad - I’m trying to get rid of what little that remains. You’re right about the XML parser, I think it’s stated in the class itself.

As for filesystem, some vLib classes are using cLib - is this what you mean?

And I’m open for discussion about which things actually belong where - before more people step aboard and begin using these classes as starting points

I’m in a good position, as I can simply modify my own tools and make them fit with whatever we agree on :slight_smile:

Also, Raul complained that the libraries are quite big. Which is true, especially with vLib including hundreds of (hardly used) BPM images. I’ve never really given this much thought, except that I have a function that strips debug (TRACE) messages from the tool+libraries. I use that as part of my release cycle.

I could add an additional method that could wipe everything but the files included by main.lua - brute-force, but that would slim down any c/v/xLib tools considerably.

I was thinking about this yesterday… isn’t the osc server available in the preferences.xml? (tickbox and server/port/protocol) :wink: That would be reachable if that’s the case and should be highly usable for warning the user. (even though it wouldn’t be verifying it is actually online and available… can’t ping it)

You mean config.xml?

Well, the config is (AFAIK) not updated in realtime, so this information is not really reliable?

You are correct …

You could make a dirty test by sending a note (or something less obtrusive?) to the server when edit mode is on. If it gets recorded, then the test was passed. Of course restore everything to normal afterwards.

OscClient:verify() --> bool

if false, show a warning.

This seems to be relevant in default UDP mode only.

Hey danoise, is there some kind of table->xml->disk and disk->xml->table config functionality in your libraries, and if so, in which library? The clib doc seems to be pretty basic, also I only foundcConfig. IscConfig for reading the tools’ manifest xml?

Also found these code snippets:
lua table to xml (recursively) (well the result could be returned, it is using a global variable…)

EDIT: LOL did not realize i linked the same 2 times :blush: So I am also looking for a xml->lua table snippet.

Nvm found a good json library: https://github.com/rxi/json.lua