Limit size for tools: 2MB. Increase to double or more?

With the new HiDPI compatibility of R3.2.0, it is easier to exceed the 2MB limit per XRNX tool. This is due to the need to duplicate the icons by increasing them 4 times in size. It all adds up.


Would it be possible to double this value? Would 4MB be too much? Even if it were possible to set the value much higher (10-15MB) it would be magnificent. Nor are there many people uploading tools every day.

Please, can you check it?


The issue comes from your tool including a full resolution photo of the Arturia KeyLab mkII synth itself, which eats up the vast majority of the total filesize.

I think a 1284x600 image is hardly what most people would consider to be an “icon”, wouldn’t you agree?

Either way, there are several steps you could take to reduce the filesize of this “icon”, including basic things like limiting the total number of colours in the palette, reducing the image dimensions, running your images through a PNG optimiser, and so on…

Is the high resolution image even necessary to aide the functionality of the tool itself? Considering that it’s intended for such a specific MIDI controller, do the users really need to be reminded of what their controller actuially looks like? :slight_smile:

Is the image really necessary?

Just my personal thoughts…


Hi dblue
So, regardless of the tool you are referring to and what it contains, increasing more of the 2MB is too much?

I am aware of everything you say. I know everything that this XRNX contains in particular and I am always determined to optimize the tools to the maximum. But I wasn’t asking that.

If yourselves consider it too much to increase the limit I will understand.

Maybe the server doesn’t have so much space to increase that limit. However, in the forums you can add a lot of content of a considerable size and it does not seem so important. Is that because the forums are hosted on another server with greater capacity? I just wanted to know if it is really necessary to have a 2MB limit for the tools. I really consider it a somewhat low limit.

In fact some tools could include some instruction manual (html, pdf …), which includes images or other content (light weight, but there are several and all sum) and all together it is very easy to exceed the limit of 2MB. I know you can share documentation separately. But if you add an integrated manual, you don’t share it separately. The manual could be larger than the tool itself (LUA code), or occupy more than one or several large images.

And well, if I’m frank, yourselves allow absurd threads of memes with a lot of useless images (yes, it’s very funny and all that), and then having this 2MB limit is currently a bit strange.

I use a server to host content, and the least problems I have is space. The limit is in the nodes. That is why I asked this question about the limit.

Maybe sharing a screenshot showing the 2MB limit has been an error that causes the thread to derail.

I can agree that perhaps the 2MB limit is a bit on the low side, but my point was mainly about trying to be more thoughtful and conscientious when it comes to our tool resources.

When it comes to the Lua code, we must take care to write clean code that is efficient, well optimised, and uses the least amount of CPU cycles possible; taking into consideration the limitations of the API, the best ways to access certain properties and functions, the proper methods to optimise speed, and so on.

Likewise, we must take care with any additional resources such as embedded graphics and icons, and use our due diligence to ensure that the overall tool package is as light as possible and free from bloat when installed on the end-user’s system.

Running large PNG images through simple optimisers like TinyPNG, for example, can often reduce the filesize by fairly huge amounts — 75% smaller in the case of your “keylab_mkii_ico@4x.png” image, for example, reducing it from ~1.1MB down to ~283KB.

Once again, I agree that the filesize limits could be tweaked — and presumably at some point they will be — but I hope you can also understand the small points I’m trying to make here. Disk space is obviously not the main concern here, since as you pointed out, it is it dirt cheap these days and really a non-issue.

For me personally, seeing well optimised files/resources in a tool or program gives me a good feeling, and a real sense that the developer has taken the care and time to focus on those small details.


@dBlue. It seems that we agree on everything. 2MB is a somewhat low limit, regardless of how optimized the code is.

Unfortunately, tool programmers, many newbies here, do not have the experience of people who have been for many years. It is also true that the code, however extensive (much text), occupies very few KB. Only here you will not save significant space.

On the theme of icons, you can obviously do tricks with the images. Do not use the BMP format. Use preferably PNG, 8 or 24 bits instead of 32 bits, which saves a lot of space. Use small images when possible. But once again, even if you optimize everything to the maximum, 2MB is a somewhat low limit for tools. In addition, window tools use images as “icons”, regardless of the size of their surface. If an image is 400x400 pixels, it will also be enlarged when scaling from Renoise 3.2.0. Therefore it will look blurry. That the fact that adding several images translates into a problem seems a bit awkward, not to call it otherwise.

It is also true that the vast majority of users who download tools have no idea what you are talking about. They don’t know about code, nor about optimizing images, and they don’t see if their XRNX tool occupies 1MB or 3MB. They care the same. They don’t even open a main.lua file to read the text. Obviously, it is important for programmers who want good content. But this really has very little impact with the size. We are talking about 2MB not 20MB or 50MB.

If it is a matter of keeping the server space controlled, I will understand. Otherwise, I don’t see reasonable to maintain that 2MB limit. Maybe years ago.

In fact I believed that this limit would be increased by changing the forums, a few months ago.

I believe that tool programmers should have a little more privileges here (tool sharing area at, than in the forums themselves where the size of the content or the optimization of the texts does not seem to be very restricted.

I just saw an image of a thread in a Renoise forum that occupies approximately 1MB, just this image (it’s a meme). There are many similar. When you open the forum in the browser, that image is downloaded to the user’s hard drive to view it. I assure you that the user will not be very worried about such fact. It’s not about comparing the tools with the forums, but this comparison will make you think.

Nor are there thousands of shared tools. It doesn’t seem like a critical issue.

Anyway, it would be gratifying to have a little more privileges for tool programmers. Having an upper limit will not cause dozens of programmers to fill the server with poorly optimized tools. :smiley:

I agree with dblue that tool files should not be too big - if possible - but the current limit of 2MB is way too oldshool. I guess that 2MB limit actually comes only from drupal’s default settings for file uploads, but it can be changed.

Let’s make that 16MB?


True, I agree.

That would be perfect. I don’t think at all that the server is going to fill with very heavy 7 or 10MB tools, but it’s great to have more freedom here for tool developers.

Thank you for this!

1 Like