What am I doing wrong? I had no instrument selected in the instrument box.
Ugh, looks like a bug. I’ll investigate…
Just wanted to say dude, you’re a debugging ninja 
I also admire the little motivational trick you pulled on yourself, hehe 
Since I’m pushing updates to people who might have the tool updater running I think it’s fair.
I’m using you all as guinea pigs
Ugh, looks like a bug. I’ll investigate…
good luck! hope you find it 
Ugh, looks like a bug. I’ll investigate…
Yeah, me to - I was not aware of this tool until now - and it looks completely amazing!!
@esaruoho: hmm, I was not able to reproduce your exact problem.
Tried with the version from the tools page, running from a blank/new song.
Need to investigate a bit deeper…
What am I doing wrong? I had no instrument selected in the instrument box.
Technically, you always have a selected instrument - empty, or not
So I guess, in your case it was completely empty. No phrases, no nothing, as in “recently created” ?
Lots of hanging notes here when noodling away .
Especcially when playing octaves
Latest renoise /noodle trap version
I think that Noodletrap is the only tool that has potential to open real-time sequencing of phrases with different length (polyrhythms).
Have you been thinking maybe about combining noodletrap and duplex so there would be posibility to record and trigger phrases for different instruments (via launchpad for example - 8 x 8)?
It would be amazing.
Lots of hanging notes here when noodling away .
Especcially when playing octaves
Latest renoise /noodle trap version
I’ll need a bit more info. Such as, whether you are noodling via QWERTY or MIDI input?
If you care about precision, you should stay away from QWERTY input - it’s basically a “clever” workaround that simulates key release events - something we don’t yet have in the Renoise API. But if you’re experiencing this with MIDI input, then the tool needs fixing
It would be amazing.
Yep, Duplex is a bit of an island here.
But I would probably think about ways to “route” the MIDI from Duplex into NT instead of rewriting the whole thing, as other things could benefit from this too then.
Azerty noodling
'K, I’ll take a look at it.
Lots of hanging notes here when noodling away
I’m currently updating this tool and thought I would give your hanging notes issue an additional shot.
But I’m still not able to produce any hanging notes in my tests.
Like I previously wrote, I think you misunderstood how QWERTY input works -
I implemented PC keyboard support simply as a way to quickly put down that beat or chord progression idea … but precision of note duration is limited. it’s simply not possible to play precisely (especially short, staccato notes) with the QWERTY. If you want precision, use a MIDI keyboard instead.
I will change the tool to make this limitation more clear
Other than that, I’m also looking into everything that’s listed on the github issue tracker.
https://github.com/renoise/xrnx/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+NoodleTrap
… And whatever else I have time for
Here’s a beta version which fixes most known issues and simplifies things a bit.
Gone is the integrated event log, it was rarely something I’d look at myself and it could potentially (if you were using the tool for a looooong time) also lead to a drop in performance.
The ability to view incoming events is not gone though, it has merely been assigned to the scripting terminal.
Also, I replaced the visual “phrasebar” with a more accurate one (able to show more phrases in a smaller space, and with less “jitter”).
Finally, I added a disclaimer when you’re enabling PC keyboard input for recording, to clarify that it’s not perfect.
'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 (bjorn@renoise.com)) for assistance...
.\classes/NTrap.lua:631: attempt to index global 'rns' (a nil value)
stack traceback:
.\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:
8106 
- 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 :lol: :lol: :lol:.
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 hexadecimalvalues. 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!!!
Thanks, Raul
yes since this tool comes with auto-launching, I should test when dropping the installer onto the window.
Or did you double-click the XRNX to launch Renoise?
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.
Absolutely. Like you say, if it’s a complex tool then you have a challenge explaining it.
Videos are great for this purpose - but I never really could be bothered creating video tutorials for my own tools, as this is quite time consuming - time I’d rather spend fixing bugs and improving the tool itself
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 hexadecimalvalues. For a bad definition in the tonumber, when entering in the valuebox a letter, like “q”, or “y” or whatever, it returned an error.
If you make your code modular, split everything into smaller parts, you can easily test each component separately (a process called unit testing).
It’s extra work, but it saves you from tedious testing later on, when/if you decide to change something, and also, the unit tests themselves can document how the component is working.
But this is a different topic though…
…
Or did you double-click the XRNX to launch Renoise?
…
Yes!
Could we have this updated for 3.3?
3 Likes
bump
1 Like
still good in 2023!!