'C:\Users\DF-85\AppData\Roaming\Renoise\V3.1.1\Scripts\Tools\com.renoise.Noodletrap.xrnx\main.lua' failed in one of its notifiers.
The notifier will be disabled to prevent further errors.
Please contact the author (danoise (firstname.lastname@example.org)) for assistance...
.\classes/NTrap.lua:631: attempt to index global 'rns' (a nil value)
.\classes/NTrap.lua:631: in function 'attach_to_song'
.\classes/NTrapUI.lua:104: in function 'show'
.\classes/NTrap.lua:360: in function 'show_dialog'
main.lua:100: in function <main.lua:93>
This happens when installing the beta tool. It seems that the definition "rns" (renoise.song()) is a nuisance in many tools.
Sometimes I do visual exercises to learn things about GUIs from other tools (I only mention it as something curious). I tell you how much I notice certain things, to see if I can locate the code directly to correct it or study it. Some refined examples:
- The surrounding frame seems to be missing 1 pixel on the right, perhaps due to a fixed width.
- The red button starts 2 pixels further to the right. It seems that you are using negative spacing.
- The wraparound column of Startup... Log Events... Phrases... it seems that it lacks a margin of... 4 pixels?
After looking at these things, I look at the code, to see if I have guessed right. It seems a good exercise to refine the GUI of the own tools.
All this is curious to me. I have become obsessed with the fact that the GUI must be perfectly defined, everything well framed. By doing so, the GUI becomes more attractive, even if it is very simple. I have seen many very neglected tools in this regard. Why do I comment on all this? When I started to build tools, I did not notice these things, now I do .
Another very different matter is how the tool works, whether it does it correctly or not, and whether it is easily understandable or not. I have also noticed that some users ignore instructions, tooltips, user manuals, and therefore do not know what certain tools are for. For the moment, what is most difficult for me is that a complex tool, which introduces a new idea never seen in other tools, must be easy to understand. And this has a lot to do with the order or distribution of the elements within the GUI, the words, the icons ... I guess any programmer will be dealing with all these things constantly.
Oh and then there is the location of errors. Lately I have discovered a very specific error in some of my valueboxes, which have conversion to hexadecimal values. For a bad definition in the tonumber, when entering in the valuebox a letter, like "q", or "y" or whatever, it returned an error. Another typical error of mine was a poor definition between the decimal values of the valuebox, which when pressing the CTRL key and turning the mouse wheel did not return the tostring that it should have. This betrays how stupid the programming becomes, and that absolutely everything has to be perfectly defined to avoid strange or unwanted behavior when controlling the tool.
I have never studied programming nor have I taken a career with this. So I find this learning path very curious and at the same time exciting. I guess this topic would give to open a new thread. It is a pity that this characteristic of Renoise, which implies being able to build our own tools, is not exploited by many more people. It seems that it is really more difficult than you would expect for many people.
Finally, right now I am building another tool, which has common elements with other tools that I built a long time ago. When I look back, I notice many of my mistakes, by mistake or mainly by ignorance. But in the end I come to the conclusion that it is better to make a new tool from scratch to improve it, than to take the old tool and correct it. I guess the more tools I build, the less it will happen to me. I guess it also has to do with seeing something new. The old ends up boring!!!