So you have gone back to having your ‘content’ gui build table fully global (rather than defined in the function gt16_content), along with the viewbulder vb like how you originally programmed the tool? You see Raul if you take a moment to think about this you can’t have ‘content’ gui table local in a function with your vb object global. You’ll get an error (as you have found) when the user opens your tool subsequent times. As now ‘content’ is trying to always initialise the global vb when it executes the gt16_content function. If you move your vb into a function (and reduce scope) you would have to completely readjust most of your code that uses vb (which is a lot and hence why I didn’t do it in my example) and start passing vb around as a parameter in functions that require vb (which to be honest is how I would write it.)
Why do you want your tool to autostart anyway? Surely it would be fine just bound to a key shortcut? Save you the hassle with notifiers
Also two other things I noticed Raul:
Your ‘includes’:
require ("tools/tool_01")
would probably need to be changed to:
require ("Tools/tool_01")
for it to work under Linux (and I suspect MacOS) as they are case sensitive operating systems.
And don’t forget about the key handler function, this:
function keyhandler( key )
would need to be changed to something like:
function keyhandler( dlg,key )
otherwise your key handler will throw errors.
Thanks for the advice!I will use all folders in lowercase.I quit “dialog” or “dlg”, to disable the keys because it was changing the modules of site.
There really is no problem for using the GUI in a single file.The problem is not to modify the code or change things, the problem is me, that I want to have separate modules. Using sliders (or similar elements) does not allow you to split the GUI into different files. For them,is necessary to invoke a new window.
The tool already has 90% of autostart (missing a detail) and can already be invoked by keyboard command.
Am I building a tool? Nah, I find that joule/danoise/ledger/afta8 have pretty much covered all the bases Raul
Just as a side thought: With all the talent of people mentioned above I often wonder why joule/danoise/afta8 etc don’t collaborate on a tool. I often imagine that collaborative coding is a skill in itself to coordinate
Just as a side thought: With all the talent of people mentioned above I often wonder why joule/danoise/afta8 etc don’t collaborate on a tool. I often imagine that collaborative coding is a skill in itself to coordinate
True. I complained about this on one occasion.When I seriously started building my first serious tool, I wondered why there are no collaborations between different experts.Each one goes by one side.
I also wonder why Danoise has no responsibility within Renoise’s team to improve it. He could be adding things and even fixing bugs, while taktik is in another isolated world.He seems to make only tools, while Renoise is stuck.And being honest, the renoise forum is maintained because it’s Danoise. But this would be a disaster.
Joule is also making its own tool “Chord tracker”.I guess he works at short times, slowly, in installments.I do not see much afta8 activity lately.Certainly very few people are trying to do things with Lua API.
It is also true that it is complicated to collaborate. Each person is from a different country.On the other hand, how is it possible that there is no serious news of Taktik?Does no nobody know him closely and can filter something?It is a very antisocial philosophy. What problem is there in informing the forums?
One day he answered a user by telling him that he was working on something that had nothing to do with Renoise / Redux, and the people applauded him.The world upside down.
Is there any particular idea that would benefit from a team of scripters atm?
Yeps Joule, my MiniRoll program that isn’t even started and probably never finish
But seriously what I mean is it isn’t the end result necessarily of the script (the script itself could be very simple), it is the process of writing a basic script and how people see algorithms and structure the solution to a particular problem
I also wonder why Danoise has no responsibility within Renoise’s team to improve it. He could be adding things and even fixing bugs, while taktik is in another isolated world.He seems to make only tools, while Renoise is stuck.And being honest, the renoise forum is maintained because it’s Danoise. But this would be a disaster.
Joule is also making its own tool “Chord tracker”.I guess he works at short times, slowly, in installments.I do not see much afta8 activity lately.Certainly very few people are trying to do things with Lua API.
It is also true that it is complicated to collaborate. Each person is from a different country.On the other hand, how is it possible that there is no serious news of Taktik?Does no nobody know him closely and can filter something?It is a very antisocial philosophy. What problem is there in informing the forums?
I am involved - I already have been dabbling with some of the API, implementing a little feature here and there. So you could call me “one of the developers”
But first and foremost, I see it as my job description to support people who have questions regarding the API. I get a lot of PMs with questions regarding XY and Z.
As for collaborations, I think we have that covered. It’s called the forum!
For example, the awesome CDP tool is the result of djeroek proposing it, and afta8 picking up the challenge
Also, I’m happy to see some people pick up the cLib/vLib/xLib libraries, at least to extract a bit of code or get inspired in some way. I would call this a kind of collaboration too.
Anyone feeling like adding a few additional unit-tests?
@Danose. I believe that 4Tey means to collaborate as a team, approving a project and working together on the code, type the CDP tool.For example, create a miniroll like the one proposed by 4Tey.I’ve noticed, the more I know about the available API(not just the LUA code itself), is possible to create really impressive tools.Things that I thought were not possible before.
However, teamwork should be disinterested, as it is not perceived economically.I mean that in the team, some will work more than others, and this really should not matter. But the important thing is the end result: the tool.
But all this is complicated, precisely because each one has different knowledge, different levels.Collaborating or helping in the forum is like another topic.I, for my part, am very happy.I am solving a lot of things thanks to the help in the forums.I go forward, I do not get stuck.For any newbie, the worst thing that can happen is to get stuck, not to advance.If this happens, building the code can be a horror, resulting in abandonment of the project or a poorly constructed tool.
Danoise, returning to the thread, can you take a look at this? : comment #20I think it’s missing some detail to operate at 100% (the window tool does not always stay on top).Solving this, I would put this topic as solved.
The tool window now appears correctly above Renoise.However, something seems to be missing. When you click on the Renoise window, the renoise window superimposes the tool window.I close and re-open the tool and this no longer happens, the tool always remains above.It seems that something is missing to force the window to always be superimposed…
What is missing?
You mean that the dialog is launched on startup, appears on top, but once you click Renoise it disappears?
Well, my guess is that it could’ve happened as a result of you having 2 “competing” methods for launching the window.
First, you’re doing the idle notifier thing which will invoke “show_dialog”. And this really should be enough.
But then you’re also listening for “new document”. This will also trigger “show_dialog”, and perhaps it happens a wee bit too soon?
And indeed, in the example tool I shared with you, I’m also listening for the new document.
The difference is that this will start the idle notifier and thus, only have one outcome.
@Raul, collaborating with other coders would be great in principle but for me making a tool has always been needs led so I think having a strong idea or concept that people can get behind would be a necessary trigger for this to happen… this was certainly what created the momentum behind the CDP tool.
You mean that the dialog is launched on startup, appears on top, but once you click Renoise it disappears?
Exact!
And indeed, in the example tool I shared with you, I’m also listening for the new document.
The difference is that this will start the idle notifier and thus, only have one outcome.
This is beyond my comprehension: “The difference is that this will start the idle notifier and thus, only have one outcome”.
"and perhaps it happens a wee bit too soon?"It may be this.It’s like I loaded it before, not after.But I do not quite understand.
I have tried different combinations of code (with trial and error, to understand), but they all work the same or similar except one:causes a crash beast, which seems to be caused by an infinite loop perhaps?
The issue is that I can not always keep the window above, if I do not close it once, an reopen.It is a bit of a nuisance, which confuses the use of the tool.
As this whole “pop-under” issue comes down to timing, it’s crucial to delay things with an idle observer.
Did you try removing the new_document notifier? Like I said, the idle observer should be enough.
Fuck, that’s right! ^^ ^^ ^^ ^^I did not realize I was repeating 2 times the same thing, the new_document notifier with “prefs.autostart.value”. Perfect!
